From GavinModi@batterytrial.com Sun Dec 02 15:33:38 2007
Return-path: <GavinModi@batterytrial.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IyvVS-0001dT-P7
	for atompub-archive@lists.ietf.org; Sun, 02 Dec 2007 15:33:38 -0500
Received: from [189.24.42.72] (helo=18924042072.user.veloxzone.com.br)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IyvVN-0002tZ-M0
	for atompub-archive@lists.ietf.org; Sun, 02 Dec 2007 15:33:34 -0500
Received: from vitor-937622918 ([104.117.58.4] helo=vitor-937622918)
	by 18924042072.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1MHvWM-000KGK-ze
	for atompub-archive@lists.ietf.org; Sun, 2 Dec 2007 18:34:07 -0200
Message-ID: <ECF40551.CE0A98DB@batterytrial.com>
Date: Sun, 2 Dec 2007 18:33:33 -0200
From: "Gavin Modi" <GavinModi@batterytrial.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: dmaklern
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

A n1ght on the town? dont get caught out with a wee winky! get a gorilla dick and impress the fuck out of her http://omealy.com/



From hamada@littlemountainltd.com Mon Dec 03 14:14:54 2007
Return-path: <hamada@littlemountainltd.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IzGko-00086n-1K
	for atompub-archive@lists.ietf.org; Mon, 03 Dec 2007 14:14:54 -0500
Received: from cr-217-129-234-217.netvisao.pt ([217.129.234.217])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IzGkl-0006Zr-GM
	for atompub-archive@lists.ietf.org; Mon, 03 Dec 2007 14:14:51 -0500
Received: from o-elm23h9ij74tu ([148.125.139.88]:19350 "EHLO o-elm23h9ij74tu"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by cr-217-129-234-217.netvisao.pt with ESMTP id S22VXKMWBUYKDZEW (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Mon, 3 Dec 2007 19:15:29 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 3 Dec 2007 19:14:55 -0000
To: atompub-archive@lists.ietf.org
From: "hamada Mae" <hamada@littlemountainltd.com>
Subject: {ivett{{
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

holy shit! can you even piss out of that thing? http://www.comoot.com/



From Kijo_Jesus@ellgass.ch Tue Dec 04 06:17:37 2007
Return-path: <Kijo_Jesus@ellgass.ch>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IzVmT-0007El-S4
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 06:17:37 -0500
Received: from [82.84.140.95] (helo=[82.84.140.95])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IzVmT-0002LU-7n
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 06:17:37 -0500
Received: from ServerAsus ([109.139.53.95] helo=ServerAsus)
	by [82.84.140.95] ( sendmail 8.13.3/8.13.1) with esmtpa id 1bUUed-000KDH-TA
	for atompub-archive@lists.ietf.org; Tue, 4 Dec 2007 12:17:55 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 4 Dec 2007 12:17:45 +0100
To: atompub-archive@lists.ietf.org
From: "Kijo Jesus" <Kijo_Jesus@ellgass.ch>
Subject: oreksiaa
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.5 (+)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

wether its too small, cums too fast or you cant keep it hard, penis pills are your natural solution http://osiolkek.com/



From owner-atom-syntax@mail.imc.org Tue Dec 04 22:03:46 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IzkY6-0003cb-F3
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 22:03:46 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IzkY6-0002JB-2N
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 22:03:46 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52cUYf068146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Dec 2007 19:38:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB52cUrb068145;
	Tue, 4 Dec 2007 19:38:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52cRJu068137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 4 Dec 2007 19:38:29 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [130.129.84.85] (unknown [130.129.84.85])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 0E150D05A5
	for <atom-syntax@imc.org>; Tue,  4 Dec 2007 21:38:26 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Atom Syntax <atom-syntax@imc.org>
From: Mark Nottingham <mnot@mnot.net>
Subject: Tombstones
Date: Tue, 4 Dec 2007 18:38:23 -0800
X-Mailer: Apple Mail (2.752.3)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25



What's the current state of proposals for and interest in what we  
called tombstones a while back?

I'm seeing use cases for managing spam; e.g., if your site accepts  
user-generated-content, and you make a feed of it available, it would  
be nice to be able to be able to have spam control reflected not only  
on the Web page, and in the feed, but also in aggregators' views of  
the data.

Cheers,

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 04 23:19:53 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Izljl-0000jd-3H
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 23:19:53 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Izljk-0005cG-Hu
	for atompub-archive@lists.ietf.org; Tue, 04 Dec 2007 23:19:53 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB54885X075313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Dec 2007 21:08:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5488NP075312;
	Tue, 4 Dec 2007 21:08:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5486Ic075305
	for <atom-syntax@imc.org>; Tue, 4 Dec 2007 21:08:07 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by py-out-1112.google.com with SMTP id u77so768748pyb
        for <atom-syntax@imc.org>; Tue, 04 Dec 2007 20:08:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=w2p53/+Jo0t2wAvHk577DdElelb3P31HZV5d16BNKPo=;
        b=KuSpSJoLLTP2WKn8YmHdW012jFWth4kVMID+gw1dWBNnFvWAguqm+NQxEzyFxzWaJRIl9OoByqN+8zFmbTgeOKWjUN0B4wGdWlB8BYz2YHazebfiFO6H8A9+9m9cYaBy7ZNDEpKQUq48xZt0j7blp7nuPtIGaa+SCrxIrX2EypU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=hbCjfLPXDqv7NV0/uVPG2DNXgLUxM4fneIhWK6HGbKOQQmzxtUOMa/9gUCRsW9EcMtzHLi9CsPJO+H5eE6emThn/nE8UNyjgx7xY4ZqDcS0KeWJodxSZyWxqS6DBx0S2n66JNlWT+ca/FSxVVDL0aGE/MdBdlfCtC2+E1Gh1Yk4=
Received: by 10.64.203.4 with SMTP id a4mr126865qbg.1196827685393;
        Tue, 04 Dec 2007 20:08:05 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id 40sm622852nzf.2007.12.04.20.08.04
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 04 Dec 2007 20:08:04 -0800 (PST)
Message-ID: <47562422.40408@gmail.com>
Date: Tue, 04 Dec 2007 20:08:02 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
In-Reply-To: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1



Mark Nottingham wrote:
> 
> 
> What's the current state of proposals for and interest in what we called
> tombstones a while back?
> 

There really isn't a current status.  Msft SSE extensions come the
closest but there are some definite issues that I personally think would
need to be resolved.

What I personally would like to see is an evolved form of SSE produced
on the standards track by a WG.  Tombstones would be covered as part of
that activity.

> I'm seeing use cases for managing spam; e.g., if your site accepts
> user-generated-content, and you make a feed of it available, it would be
> nice to be able to be able to have spam control reflected not only on
> the Web page, and in the feed, but also in aggregators' views of the data.
> 

We have use cases for offline synchronization, bidirectional sync,
seeding search engines, spam control, more efficient subscription models
(e.g. just give me the changes since the last time I checked), and so
on.  After exploring the issue, I strongly believe a single, common
approach would be ideal.

- James

> Cheers,
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 




From owner-atom-syntax@mail.imc.org Wed Dec 05 00:16:01 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Izmc5-0002Hr-Ca
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 00:16:01 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Izmc3-0007DP-MS
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 00:16:01 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB554nv5078445
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Dec 2007 22:04:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB554n4r078444;
	Tue, 4 Dec 2007 22:04:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB554miw078438
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Tue, 4 Dec 2007 22:04:49 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Tue, 4 Dec 2007 21:03:23 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Tue,
 4 Dec 2007 21:03:51 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
CC: Atom Syntax <atom-syntax@imc.org>
Date: Tue, 4 Dec 2007 21:03:41 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg29jYcJtLZ3x7ERKmHF3aJc8bJ8QABDVHA
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
In-Reply-To: <47562422.40408@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB554niv078439
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


James Snell wrote:

> There really isn't a current status.  Msft SSE extensions come the
> closest but there are some definite issues that I personally think
> would
> need to be resolved.

It would be great to hear about those issues. For what it's worth, we released our "v1" spec of SSE today. (Not to say that there isn't room for more discussion.) We also renamed it to "FeedSync", hoping that name might be a little easier to remember/spell/etc. The new spec is on http://feedsync.org/spec/.

> We have use cases for offline synchronization, bidirectional sync,
> seeding search engines, spam control, more efficient subscription
> models
> (e.g. just give me the changes since the last time I checked), and so
> on.  After exploring the issue, I strongly believe a single, common
> approach would be ideal.

I definitely agree. We considered a separate spec for tombstones that was independent of the other sync extensions. It didn't seem worth it given the benefit of having all of the sync-related extensions in a single, coherent spec. If you want spam control, chances are pretty good you want one-way sync, and at that point you want more than just tombstones.

Steven




From owner-atom-syntax@mail.imc.org Wed Dec 05 00:39:52 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IzmzA-0003v0-MV
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 00:39:52 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IzmzA-0007qY-2U
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 00:39:52 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB55MbfI079654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Dec 2007 22:22:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB55MbNp079653;
	Tue, 4 Dec 2007 22:22:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB55Maet079646
	for <atom-syntax@imc.org>; Tue, 4 Dec 2007 22:22:37 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so919642anc
        for <atom-syntax@imc.org>; Tue, 04 Dec 2007 21:22:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=wvxMkf2Jjf5BiLpcJIweq5j29U6kwgK0kHCJx7M7poA=;
        b=Gnel/WK5z2UYAxn503QiUZ3qBclhFSTpsejOpMqHQsDmgkbDwtsI+asvQlz5aN8kb2cTvya6d5XHlOttUEAKX+ItVWZJ8gciBQMPiZsUEnM3M7yGN46rTS120sJlRv/+fIbQQ/OO/PAAPwq/ih9iH62E+/P7oHQI/jdvB9AR7v4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=C72D8CBwPS+LikxEVnEieTbsvsRwloGx3nHkL4oObQKXrTI1Vh/9HkjWGGETdRz7txlskCmUHGA4154UImg/IvJmGecIVsnemOzruCjlCsstVoT+nEPN9kaD1EAYlnmYKugjr5u9Lxg3MN6aGXcvxsNGabqh3ThGlPE53bgsLQs=
Received: by 10.100.207.5 with SMTP id e5mr3171149ang.1196832155676;
        Tue, 04 Dec 2007 21:22:35 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id j7sm10112347nzd.2007.12.04.21.22.34
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 04 Dec 2007 21:22:34 -0800 (PST)
Message-ID: <47563598.3020108@gmail.com>
Date: Tue, 04 Dec 2007 21:22:32 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steven Lees <Steven.Lees@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


http://www.snellspace.com/wp/?p=818

- James

Steven Lees wrote:
> James Snell wrote:
> 
>> There really isn't a current status.  Msft SSE extensions come the
>> closest but there are some definite issues that I personally think
>> would
>> need to be resolved.
> 
> It would be great to hear about those issues. For what it's worth, we released our "v1" spec of SSE today. (Not to say that there isn't room for more discussion.) We also renamed it to "FeedSync", hoping that name might be a little easier to remember/spell/etc. The new spec is on http://feedsync.org/spec/.
> 
>> We have use cases for offline synchronization, bidirectional sync,
>> seeding search engines, spam control, more efficient subscription
>> models
>> (e.g. just give me the changes since the last time I checked), and so
>> on.  After exploring the issue, I strongly believe a single, common
>> approach would be ideal.
> 
> I definitely agree. We considered a separate spec for tombstones that was independent of the other sync extensions. It didn't seem worth it given the benefit of having all of the sync-related extensions in a single, coherent spec. If you want spam control, chances are pretty good you want one-way sync, and at that point you want more than just tombstones.
> 
> Steven
> 




From owner-atom-syntax@mail.imc.org Wed Dec 05 02:04:42 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IzoJG-0002zn-Gw
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 02:04:42 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IzoJG-0001aa-3o
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 02:04:42 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB56rBGB086281
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Dec 2007 23:53:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB56rBZA086280;
	Tue, 4 Dec 2007 23:53:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s10.bay0.hotmail.com (bay0-omc1-s10.bay0.hotmail.com [65.54.246.82])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB56rABi086274
	for <atom-syntax@imc.org>; Tue, 4 Dec 2007 23:53:10 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.20]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 4 Dec 2007 22:53:10 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 4 Dec 2007 22:53:10 -0800
Message-ID: <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl>
Received: from 85.211.235.130 by BAY141-DAV10.phx.gbl with DAV;
	Wed, 05 Dec 2007 06:53:05 +0000
X-Originating-IP: [85.211.235.130]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "Atom Syntax" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com>
Subject: Re: Tombstones
Date: Wed, 5 Dec 2007 06:53:02 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 05 Dec 2007 06:53:10.0268 (UTC) FILETIME=[7F7633C0:01C8370B]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


James M Snell wrote:
> What I personally would like to see is an evolved form of SSE produced
> on the standards track by a WG.  Tombstones would be covered as part of
> that activity.

FWIW I'm not interested in anything more complicated than your tombstone 
proposal from last year. I just want a simple way to mark an item in a feed 
as deleted.

I was considering implementing something based on your last draft, even if 
only for personal use. It would be preferable if there was a real spec to 
work from, but there's no way I would implement anything as complicated as 
SSE when all I want to do is delete spam.

Regards
James




From owner-atom-syntax@mail.imc.org Wed Dec 05 04:49:48 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Izqt2-0000mR-6k
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 04:49:48 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Izqt1-0006x1-KI
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 04:49:48 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB59ZQmk097355
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Dec 2007 02:35:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB59ZQxJ097354;
	Wed, 5 Dec 2007 02:35:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB59ZPvE097345
	for <atom-syntax@imc.org>; Wed, 5 Dec 2007 02:35:25 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so936722anc
        for <atom-syntax@imc.org>; Wed, 05 Dec 2007 01:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=1SPey2loj0y/Jl4E4Xb2tL3dVhisa/nLbB1QfhnsJHE=;
        b=DDufKqkEvE/PqkVNTsL9r5QTSFFPDWRqyjVH7ia50WkH+p/tHD5EZcBLXiONn58pnlsGelJj8tGXnQf3uGKQKdrSBrxuG+j/Uvd4n2RaqareG0XETSvwLhkcljTxKEeWN6+JzceCCDYcAE20/U/XPoXIvi+ae47GuN1I17Z+e3g=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=OdJbk8NEzp7REK/wt6GC12oFXi1Hv942X76BSfpvI+eKmuikH55IbwC6N+oWxgN/A/Ua9/Vr7SI612NkAjXxunbsm2xzubL0qonN0zHz8gk2kkOTqW++diX1UJiMwkIR1cToBHd2fFWcyizC1l1RpPPAUSkon9hesXUvJYuga+8=
Received: by 10.100.202.9 with SMTP id z9mr3674179anf.1196847324796;
        Wed, 05 Dec 2007 01:35:24 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id 15sm76627nzp.2007.12.05.01.35.18
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 05 Dec 2007 01:35:22 -0800 (PST)
Message-ID: <475670CA.9030408@gmail.com>
Date: Wed, 05 Dec 2007 01:35:06 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: James Holderness <j4_james@hotmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl>
In-Reply-To: <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464


+1. What I want is an approach that scales up well from the simplest
case (just marking tombstones) to more complicated cases.  Just having
an x:deleted element would go a very long ways towards solving the
majority of use cases I've come across.  The rest would seem to be
covered by having a consistent model of being able to request just the
changes that have occurred within a specific period of time.  Everything
else tends to just be variations on the theme.

- James

James Holderness wrote:
> 
> James M Snell wrote:
>> What I personally would like to see is an evolved form of SSE produced
>> on the standards track by a WG.  Tombstones would be covered as part of
>> that activity.
> 
> FWIW I'm not interested in anything more complicated than your tombstone
> proposal from last year. I just want a simple way to mark an item in a
> feed as deleted.
> 
> I was considering implementing something based on your last draft, even
> if only for personal use. It would be preferable if there was a real
> spec to work from, but there's no way I would implement anything as
> complicated as SSE when all I want to do is delete spam.
> 
> Regards
> James
> 
> 




From owner-atom-syntax@mail.imc.org Wed Dec 05 13:11:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Izyit-0007GO-Q2
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 13:11:51 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Izyiq-0003Zo-Lo
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 13:11:51 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5HuJ7X042496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Dec 2007 10:56:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5HuJWl042495;
	Wed, 5 Dec 2007 10:56:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5HuIK0042479
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 5 Dec 2007 10:56:19 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id BA4E523E4B8
	for <atom-syntax@imc.org>; Wed,  5 Dec 2007 12:56:16 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com>
Subject: RE: Tombstones
Date: Thu, 6 Dec 2007 00:56:10 +0700
Message-ID: <008801c83768$24b02830$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg2/zEykVpKNJnJRSyioEflR62w/QAZIlRw
In-Reply-To: <47563598.3020108@gmail.com>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


James M Snell wrote:
> 
> http://www.snellspace.com/wp/?p=818
> 

> Steven Lees wrote:
> > 
> > It would be great to hear about those issues. For what it's 
> worth, we released our "v1" spec of SSE today. (Not to say 
> that there isn't room for more discussion.) We also renamed 
> it to "FeedSync", hoping that name might be a little easier 
> to remember/spell/etc. The new spec is on
> http://feedsync.org/spec/.

The main issue I have had with FeedSync is that deleted entries look
like "live" entries for every consumer that doesn't understand FeedSync.
This means that you cannot use FeedSync unless all clients are
FeedSync-aware. James idea of using an extension element solves this
problem nicely.

The "by" endpoint label is supposed to be user-readable but unique; that
seems difficult to achieve. I would like to see some advice on how to
achieve this, especially in the case where one authenticated user has
multiple endpoints (say, two phones, an in-office desktop machine, and a
large pool of laptops). 

> We considered a separate spec for tombstones
> that was independent of the other sync extensions.
> It didn't seem worth it given the benefit of having
> all of the sync-related extensions in a single,
> coherent spec. If you want spam control, chances
> are pretty good you want one-way sync, and at that
> point you want more than just tombstones.

In a single-user blog, where the user is editing the blog in both a
blogging client and in the blog's web interface, the blogging client
should be notified (via the feed) when the user deletes an entry using
the web interface. A simple tombstone mechanism is sufficient for
handling this, because none of the conflict-resolution stuff is
necessary.

- Brian





From owner-atom-syntax@mail.imc.org Wed Dec 05 20:29:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J05Yl-00081R-0z
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 20:29:51 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J05Yj-000376-AT
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 20:29:51 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB61HGcg083646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Dec 2007 18:17:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB61HGZi083645;
	Wed, 5 Dec 2007 18:17:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB61HF9A083637
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Wed, 5 Dec 2007 18:17:15 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by
 TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Wed, 5 Dec 2007 17:17:14 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Wed,
 5 Dec 2007 17:17:15 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Wed, 5 Dec 2007 17:17:14 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg2/zEykVpKNJnJRSyioEflR62w/QAZIlRwABA4qcA=
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk>
In-Reply-To: <008801c83768$24b02830$2501a8c0@Junk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB61HF99083640
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9


Brian Smith wrote:

> The main issue I have had with FeedSync is that deleted entries look
> like "live" entries for every consumer that doesn't understand
> FeedSync.
> This means that you cannot use FeedSync unless all clients are
> FeedSync-aware. James idea of using an extension element solves this
> problem nicely.

This issue came up in the August AtomPub interop. Our current solution on http://feedsync.mslivelabs.com is that, by default, the server doesn't give you tombstoned entries. You have to ask for them with a query parameter. I've also been hunting for the right HTTP header to ask for tombstones as an alternate mechanism.

James's suggestion of using a different element is another reasonable solution, but I think it introduces problems as well. More on that a little later...

> The "by" endpoint label is supposed to be user-readable but unique;
> that
> seems difficult to achieve. I would like to see some advice on how to
> achieve this, especially in the case where one authenticated user has
> multiple endpoints (say, two phones, an in-office desktop machine, and
> a
> large pool of laptops).

I discussed that recently here: http://blogs.msdn.com/stevenlees/archive/2007/12/02/about-a-by.aspx. The short answer is that "by" is not really meant to be user readable. For that we'd recommend atom:author or something else in your data model.

> > We considered a separate spec for tombstones
> > that was independent of the other sync extensions.
> > It didn't seem worth it given the benefit of having
> > all of the sync-related extensions in a single,
> > coherent spec. If you want spam control, chances
> > are pretty good you want one-way sync, and at that
> > point you want more than just tombstones.
>
> In a single-user blog, where the user is editing the blog in both a
> blogging client and in the blog's web interface, the blogging client
> should be notified (via the feed) when the user deletes an entry using
> the web interface. A simple tombstone mechanism is sufficient for
> handling this, because none of the conflict-resolution stuff is
> necessary.

I wasn't so much referring to the conflict resolution part as the other sync metadata. Once piece that's really useful is the sx:sync/@updates attribute--it's simpler and more reliable than a timestamp for detecting updates. If you really only care about one-way (aka publish only) sync, then your FeedSync implementation becomes that much simpler.

Steven




From owner-atom-syntax@mail.imc.org Wed Dec 05 23:34:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J08R6-0006As-4W
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 23:34:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J08R5-0007P3-I9
	for atompub-archive@lists.ietf.org; Wed, 05 Dec 2007 23:34:08 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB64KRuO096970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Dec 2007 21:20:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB64KRv0096968;
	Wed, 5 Dec 2007 21:20:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB64KOfA096959
	for <atom-syntax@imc.org>; Wed, 5 Dec 2007 21:20:24 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so87037anc
        for <atom-syntax@imc.org>; Wed, 05 Dec 2007 20:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=qV/XpTw/w/dVR5CK9Oazi1MMsDA0gJA6zyhepwV1TGw=;
        b=UBEsu7FMAQq9Y5dAA1iy7ApOTsc43Ip+YmeJgGExuN8ldVkpgCxizrtipqRA88yw2n28TiEt+k+YEuyUEqeNwzAOszESiEOC9bjl4gtuMAa8+JclJbTOrmI2r1UR78kv8Rx/UdMuuAI75rRD5oS090CtutpV7jU4oRJsdu1zWo4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=n1CIfKw3IKHjk335Zv2tcCbqUj6W9fcx6GiJPsnz6uPazZQNgAx+zqiVbVsX0j9Idg/o43QMT7DPI2aAo7+//BNjKhL2OpI+CVrXYnF25nMarcKPlf3EVU703B5hDYjMoXu0xkF39CSLPqyhGibI64CRXBUauvfQQczK5Yn7BiE=
Received: by 10.100.227.20 with SMTP id z20mr5770624ang.1196914823551;
        Wed, 05 Dec 2007 20:20:23 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id s36sm1962523rnf.2007.12.05.20.20.22
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 05 Dec 2007 20:20:23 -0800 (PST)
Message-ID: <47577884.8060401@gmail.com>
Date: Wed, 05 Dec 2007 20:20:20 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steven Lees <Steven.Lees@microsoft.com>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab


Comments below.

Steven Lees wrote:
> Brian Smith wrote:
> 
>> The main issue I have had with FeedSync is that deleted entries look
>> like "live" entries for every consumer that doesn't understand
>> FeedSync.
>> This means that you cannot use FeedSync unless all clients are
>> FeedSync-aware. James idea of using an extension element solves this
>> problem nicely.
> 
> This issue came up in the August AtomPub interop. Our current solution 
> on http://feedsync.mslivelabs.com is that, by default, the server doesn't 
> give you tombstoned entries. You have to ask for them with a query parameter. 
> I've also been hunting for the right HTTP header to ask for tombstones as an 
> alternate mechanism.
> 

Such mechanisms are only necessary if you overload atom:entry. Using
something like x:deleted, there's no reason a client would have to do
anything special to get the tombstones.

> James's suggestion of using a different element is another reasonable solution, 
> but I think it introduces problems as well. More on that a little later...
> 

Definitely please do post your thoughts on that.

> [snip]
>>> We considered a separate spec for tombstones
>>> that was independent of the other sync extensions.
>>> It didn't seem worth it given the benefit of having
>>> all of the sync-related extensions in a single,
>>> coherent spec. If you want spam control, chances
>>> are pretty good you want one-way sync, and at that
>>> point you want more than just tombstones.
>> In a single-user blog, where the user is editing the blog in both a
>> blogging client and in the blog's web interface, the blogging client
>> should be notified (via the feed) when the user deletes an entry using
>> the web interface. A simple tombstone mechanism is sufficient for
>> handling this, because none of the conflict-resolution stuff is
>> necessary.
> 
> I wasn't so much referring to the conflict resolution part as the 
> other sync metadata. Once piece that's really useful is the sx:sync/@updates 
> attribute--it's simpler and more reliable than a timestamp for detecting 
> updates. If you really only care about one-way (aka publish only) sync, 
> then your FeedSync implementation becomes that much simpler.
> 

I'm not convinced about the "more reliable" part.  If app:edited
elements are used properly, they would seem to be more than sufficient.
 I'm curious if you have specific examples of where using the timestamp
breaks down?

- James




From owner-atom-syntax@mail.imc.org Thu Dec 06 08:06:48 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0GRE-0000ml-81
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:06:48 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0GR8-0005HH-Au
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:06:48 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6CjNwt031872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 05:45:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6CjNX5031871;
	Thu, 6 Dec 2007 05:45:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from earth.34sp.com (earth.34sp.com [80.82.113.251])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6CjLvS031862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 05:45:22 -0700 (MST)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 99495 invoked from network); 6 Dec 2007 12:45:20 +0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 6 Dec 2007 12:45:20 +0000
Received: from 82.153.203.115 ([82.153.203.115]) by webmail.djpowell.net
	(Horde MIME library) with HTTP; Thu, 06 Dec 2007 12:45:19 +0000
Message-ID: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
Date: Thu, 06 Dec 2007 12:45:19 +0000
From: David Powell <djpowell@djpowell.net>
To: James M Snell <jasnell@gmail.com>
Cc: Steven Lees <Steven.Lees@microsoft.com>, Mark Nottingham
	<mnot@mnot.net>,
        Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
	<47562422.40408@gmail.com>
	<9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
	<47563598.3020108@gmail.com>
In-Reply-To: <47563598.3020108@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6CjNvR031864
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44


Quoting James M Snell <jasnell@gmail.com>:

>
> http://www.snellspace.com/wp/?p=818
>
> - James


> 1. Deleted entries (aka Tombstones) are indicated by extension elements
> contained within the atom:entry element. For clients that do not understand
> the SSE extensions, these will appear no different than any other entry
> such clients would have no way of knowing that the entry was deleted.  Also,
> this solution assumes that there is still enough data in the database to
> reconstruct the deleted entry in the feed. The content, title, tags, etc may
> all have been removed from the database.

I disagree.  Having clients that don't understand the extensions
processing them in the same way as updates to the entries seems like a
massive plus-point for FeedSync to me.

I assumed that you aren't supposed to reconstruct those items, after
all you are trying to delete the item.  The tombstone entry would look
something like this:

<entry>
   <id>id of the original entry</id>
   <updated>deletion date</updated>
   <sx:deleted />
   <title>This entry has been removed</title>
   <summary>This entry has been removed</summary>
   ...
</entry>

If the client supports sx:deleted it can remove the entry from its
store, if the client doesn't support sx:deleted, it will replace the
old entry with this low-tech tombstone.  If the client is a framework,
sub-clients will have the opportunity to implement sx:deleted, even if
the framework doesn't.  A publishing client that understands
sx:deleted could delete an entry in this way on any arbitrary atompub
server.  There is very little coordination cost - you can use it today
and wait for the rest of the infrastructure to catch up.

The feed + stream of entries model is the 'protocol' of how feeds
work.  FeedSync is backwards compatible with this protocol; your
alternate proposal seems to require a boil-the-ocean from publishing
clients, atompub servers, intermediaries, feed servers, aggregator
frameworks, and aggregators before these tombstones will work.

Why create a new protocol when we can use an existing one?

-- 
Dave








From owner-atom-syntax@mail.imc.org Thu Dec 06 08:24:03 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Ghv-0005Su-Hf
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:24:03 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Ghq-00069X-Mv
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:24:03 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6D2Mbs033236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 06:02:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6D2MEi033235;
	Thu, 6 Dec 2007 06:02:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6D2JKZ033226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 06:02:21 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 77F0023E4A3
	for <atom-syntax@imc.org>; Thu,  6 Dec 2007 08:02:17 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Feed Paging for Efficient Feed Synchronization
Date: Thu, 6 Dec 2007 20:02:14 +0700
Message-ID: <000001c83808$3dbed6f0$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acg4CDiW97wm8nzBRYGSW4vNubRDOg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6D2LKY033230
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lB6D2Mbs033236
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976


James Snell wrote at http://www.snellspace.com/wp/?p=3D818:

> <x:link-template rel=3D"sync"
>   pattern=3D"http://.../myfeed;sync?{join|&|since,until}" />

<snip>

> If the until param is omitted, it is assumed to be =E2=80=9Cnow=E2=80=9D
> as determined by the server. The server must indicate the
> until date in the response feed. If the since param is
> omitted, it is assumed to be a timestamp indicating the
> moment the collection was created.

Do "since" and "until" refer to atom:updated or app:edited?

> The URL returns a single, complete Atom feed listing ONLY
> the entries that have been modified within the window of
> time specified.

It is unreasonable to require this to be done in a single page if there a=
re many entries that need to be sent during the sync. Consider a collecti=
on that has thousands of items and a client that always uses http://.../m=
yfeed;sync?since=3D1900-01-01T00:00:00Z to constantly download the entire=
 collection. Paging is still needed.

<snip>

> We can differentiate new and updated entries using the
> x:sync element and the existing atom:published,
> atom:updated and app:edited timestamps.

Most AtomPub applications will consider an entry to be updated if they al=
ready had a copy of the entry with an earlier app:edited, and new otherwi=
se, without needing FeedSync at all. FeedSync is more useful for non-Atom=
Pub feeds because many implementations do not do a good job of managing t=
he atom:updated property of entries.

<snip>

> And Because the entire snapshot is contained within a single=20
> feed document, we do not have to worry about the race
> condition that is inherent in the rolling window feed
> paging model.

The race condition is not an inherent problem in the paging model; it is =
an implementation issue. In my implementation, I do all the paging in my =
collection feed using links like:

   <link rel=3D'prev' href=3D'?until=3D{END}'/>
   <link rel=3D'next' href=3D'?since=3D{START}'/>

Where START is the earliest app:edited in the current page and END is the=
 latest app:edited in the current page. By assuring that all entries with=
 the same app:edited value are collected on the same page, and following =
the specification requirements about the ordering of the feed, there is n=
o chance for a race condition.

Furthermore, the first page of the feed (the collection subscription docu=
ment) contains:

    <link rel=3D'next' href=3D'?since=3D{START}'/>

Where START is the latest app:edited value in the collection. As a result=
, any client can efficiently sync with the collection like so:

1. When initially subscribing to the collection, pull down the subscripti=
on document. Remember the value of the 'next' as SYNC and page backwards =
using the 'prev' link relation.

2. Whenever the client needs to re-sync with the collection, instead of r=
etrieving the subscription feed document as usually, pull the feed docume=
nt from the SYNC IRI. Then page forward using the 'next' link relation, s=
topping at the page that has
      <link rel=3D'next' href=3D''/>
(which will be a feed document with no entries). Remember the IRI of that=
 last page as SYNC, for subsequent re-syncs.

- Brian





From owner-atom-syntax@mail.imc.org Thu Dec 06 08:43:17 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0H0X-0003wT-Jz
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:43:17 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0H0T-0007Av-2T
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 08:43:17 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6DRq7f035603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 06:27:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6DRq8m035602;
	Thu, 6 Dec 2007 06:27:52 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6DRpJZ035588
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 06:27:52 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id CDF8223E4AA;
	Thu,  6 Dec 2007 08:27:49 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'David Powell'" <djpowell@djpowell.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net><47562422.40408@gmail.com><9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com><47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
Subject: RE: Tombstones
Date: Thu, 6 Dec 2007 20:27:50 +0700
Message-ID: <000101c8380b$cf729d90$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
Thread-Index: Acg4BpYkw5gV7t++SwuHsG8++QSVfAAAapsQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135


David Powell
> I disagree.  Having clients that don't understand the 
> extensions processing them in the same way as updates to the 
> entries seems like a massive plus-point for FeedSync to me.

<snip>

> <entry>
>    <id>id of the original entry</id>
>    <updated>deletion date</updated>
>    <sx:deleted />
>    <title>This entry has been removed</title>
>    <summary>This entry has been removed</summary>
>    ...
> </entry>
> 
> If the client supports sx:deleted it can remove the entry 
> from its store, if the client doesn't support sx:deleted, it 
> will replace the old entry with this low-tech tombstone.  If 
> the client is a framework, sub-clients will have the 
> opportunity to implement sx:deleted, even if the framework 
> doesn't.  A publishing client that understands sx:deleted 
> could delete an entry in this way on any arbitrary atompub 
> server.  There is very little coordination cost - you can use 
> it today and wait for the rest of the infrastructure to catch
> up.

You make a good point. But, if there are frequent deletions then
non-FeedSync-aware clients will have to wade through "This entry has
been removed" entries showing up to replace entries that they have
previously marked as read or otherwise filed as "don't show me this
again unless it is updated".

Consider this alternative formulation:

  <entry>
   <id>id of the original entry</id>
   <updated>deletion date</updated>
   <title>This entry has been removed</title>
   <summary>This entry has been removed</summary>
   ...
  </entry>
  <sx:deleted>
     <atom:id>id of the original entry</atom:id>
  </sx:deleted>

This accomplishes your goal, but makes the "low tech tombstone"
optional, for cases where asking clients to navigate "This entry has
been removed" entries is inappropriate. It does require the server to
insert <xs:deleted>, though.

> The feed + stream of entries model is the 'protocol' of how 
> feeds work.  FeedSync is backwards compatible with this 
> protocol; your alternate proposal seems to require a 
> boil-the-ocean from publishing clients, atompub servers, 
> intermediaries, feed servers, aggregator frameworks, and 
> aggregators before these tombstones will work.

The FeedSync mechanism is reasonable if only a few entries are
occasionally deleted. But, it is not reasonable in other situations. In
particular, in WLW I save all my drafts on the server and often delete
drafts without publishing them. I don't want to see a bunch of tombstone
entries in the article list. The Snell mechanism would be more
appropriate in that scenario.

- Brian




From owner-atom-syntax@mail.imc.org Thu Dec 06 11:41:18 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Jmo-00080l-CK
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 11:41:18 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Jmm-0004kX-Fg
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 11:41:18 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6G7amw052021
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 09:07:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6G7ack052020;
	Thu, 6 Dec 2007 09:07:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6G7YA0052009
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 09:07:35 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so267817rvf
        for <atom-syntax@imc.org>; Thu, 06 Dec 2007 08:07:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=OTmcT6y2dAbdmL550RK5vqsvqoiS1A9e+kgJXHoEjFw=;
        b=oS1V1BkcbZxRstCw9NtTZ2G+jLfpbHqZBAc0hctjMnsOEWBBk08dcMbk5f/ZBPL7YLPvqLfnGJcebwxKEX21TQtHzPSKQC+yGmQGPX3QVTYk0U9KzxQa9JeW4GWRY6GqGGQMzfG8+V9HO1pNOFcI/VxoXRHLKDcFvt94hwIzznA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=YtmZcnVeDF2pGEhwBj9u31Qvqn6gD0C1YAm9M6d3wMvKRbvKA7Om258Ajeyh5GuVFYhnIprUbnsw2iKYOCm7xcxJc85g9BBHQXO6YZN9RWKm98VqnYzOQKXpCX5BmuDe+J/PUodyAnSzlSYp0+CKJ+d+gjqf49h1o7y45Dl2Ha4=
Received: by 10.140.147.18 with SMTP id u18mr2053238rvd.1196957254055;
        Thu, 06 Dec 2007 08:07:34 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id b24sm48318rvf.2007.12.06.08.07.30
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 06 Dec 2007 08:07:33 -0800 (PST)
Message-ID: <47581E35.4050103@gmail.com>
Date: Thu, 06 Dec 2007 08:07:17 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Feed Paging for Efficient Feed Synchronization
References: <000001c83808$3dbed6f0$2501a8c0@Junk>
In-Reply-To: <000001c83808$3dbed6f0$2501a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lB6G7amw052021
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6



Brian Smith wrote:
> James Snell wrote at http://www.snellspace.com/wp/?p=3D818:
>=20
>> <x:link-template rel=3D"sync"
>>   pattern=3D"http://.../myfeed;sync?{join|&|since,until}" />
>=20
> <snip>
>=20
>> If the until param is omitted, it is assumed to be =E2=80=9Cnow=E2=80=9D
>> as determined by the server. The server must indicate the
>> until date in the response feed. If the since param is
>> omitted, it is assumed to be a timestamp indicating the
>> moment the collection was created.
>=20
> Do "since" and "until" refer to atom:updated or app:edited?
>=20

It would be app:edited

> [snip]
>> And Because the entire snapshot is contained within a single=20
>> feed document, we do not have to worry about the race
>> condition that is inherent in the rolling window feed
>> paging model.
>=20
> The race condition is not an inherent problem in the paging model; it i=
s an implementation issue. In my implementation, I do all the paging in m=
y collection feed using links like:
>=20
>    <link rel=3D'prev' href=3D'?until=3D{END}'/>
>    <link rel=3D'next' href=3D'?since=3D{START}'/>
>=20
> Where START is the earliest app:edited in the current page and END is t=
he latest app:edited in the current page. By assuring that all entries wi=
th the same app:edited value are collected on the same page, and followin=
g the specification requirements about the ordering of the feed, there is=
 no chance for a race condition.
>=20

Note that I specifically indicated the rolling window feed paging model.
 Yes, there are ways of doing the paging where the pages are stable, and
if we can rely on folks doing it that way consistently then paging is
fine.  The key requirement is that the snapshot has to remain stable
throughout the sync process.

That said, however, once the initial sync is completed, subsequent
incremental sync's are much more efficient if paging is not used (e.g.
give me one feed document describing just the things that have changed
over the last twelve hours, etc).

> Furthermore, the first page of the feed (the collection subscription do=
cument) contains:
>=20
>     <link rel=3D'next' href=3D'?since=3D{START}'/>
>=20
> Where START is the latest app:edited value in the collection. As a resu=
lt, any client can efficiently sync with the collection like so:
>=20
> 1. When initially subscribing to the collection, pull down the subscrip=
tion document. Remember the value of the 'next' as SYNC and page backward=
s using the 'prev' link relation.
>=20
> 2. Whenever the client needs to re-sync with the collection, instead of=
 retrieving the subscription feed document as usually, pull the feed docu=
ment from the SYNC IRI. Then page forward using the 'next' link relation,=
 stopping at the page that has
>       <link rel=3D'next' href=3D''/>
> (which will be a feed document with no entries). Remember the IRI of th=
at last page as SYNC, for subsequent re-syncs.
>=20

Again, this would work so long as the pages remain stable; however, I
would very much like to see a comparison of how the two approaches
compare in terms of performance / efficiency.

- James

> - Brian
>=20
>=20
>=20




From owner-atom-syntax@mail.imc.org Thu Dec 06 12:39:21 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Kgz-0003tt-Lx
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 12:39:21 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Kgy-0000vT-Tm
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 12:39:21 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HFQUh058217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 10:15:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HFQe2058216;
	Thu, 6 Dec 2007 10:15:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HFPLU058210
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 10:15:26 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 7554D23E4A9;
	Thu,  6 Dec 2007 12:15:22 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James M Snell'" <jasnell@gmail.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com>
Subject: RE: Feed Paging for Efficient Feed Synchronization
Date: Fri, 7 Dec 2007 00:15:17 +0700
Message-ID: <000601c8382b$99961c40$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <47581E35.4050103@gmail.com>
Thread-Index: Acg4I+EAy6tjjZwlTXO+4HuATSMYMwAAa/Ug
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6HFQLT058211
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d


James M Snell wrote:
> Brian Smith wrote:
> > James Snell wrote at http://www.snellspace.com/wp/?p=818:
> >> And Because the entire snapshot is contained within a single feed 
> >> document, we do not have to worry about the race condition that is 
> >> inherent in the rolling window feed paging model.
> > 
> > The race condition is not an inherent problem in the paging 
> > model; it is an implementation issue. In my implementation, I 
> > do all the paging in my collection feed using links like:
> 
> Note that I specifically indicated the rolling window feed 
> paging model.
>  Yes, there are ways of doing the paging where the pages are 
> stable, and if we can rely on folks doing it that way 
> consistently then paging is fine.  The key requirement is 
> that the snapshot has to remain stable throughout the sync process.

To be clear, I don't provide any kind of snapshot mechanism. The client needs to go back to the start of the feeds (most recently edited entries) after it has paged through all the older entries, to see if some older entry has been modified during the paging process. If some entry or entries are constantly being edited, then it is possible that the client will never see them. On the other hand, what good does it do for the client to receive an old representation of an entry that is currently being relentlessly edited? The cost of implementing snapshotting seems to nearly always outweigh any benefits it might have.

The only guarantees that I make beyond what AtomPub requires are: (1) if any entries are skipped during paging, they will appear at the start of the feed, (2) navigating to each "prev" page will always result in older entries than the ones in the current page, and (3) navigating to each "next" page will result in an empty page or in entries newer than the ones in the current page. Implementations that do paging by numbering each page ("?page=2", "?page=3") often cannot make those guarantees when entries are being added/edited faster than the client can page through the feed.

> That said, however, once the initial sync is completed, 
> subsequent incremental sync's are much more efficient if 
> paging is not used (e.g. give me one feed document describing
> just the things that have changed over the last twelve hours, etc).

On the other hand, if there were hundreds of entries updated in the last 12 hours (e.g. a server upgrade which modifies the representation of every entry, or whatever else WordPress users do that causes every entry to appear updated), the client and the server will probably both benefit from chunking that up. Especially, on mobile phones, the larger the response, the less likely the service provider's proxies will let it go through to the device.

> Again, this would work so long as the pages remain stable; 
> however, I would very much like to see a comparison of how 
> the two approaches compare in terms of performance / efficiency.

Well, obviously paging is going to require more roundtrips if there are multiple pages used for the sync. If the server decides to use one page per resync then both approaches are equivalent. In fact, disregarding snapshotting, my solution is the same as yours, except in mine the server controls the values of the "since" and "until" parameters, whereas in yours the client controls them, and mine allows the server to break up the response into multiple (cacheable) pages.

- Brian





From owner-atom-syntax@mail.imc.org Thu Dec 06 13:02:45 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0L3d-0005K6-B5
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:02:45 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0L3c-0003L5-LV
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:02:45 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HcjjK060006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 10:38:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HcjX8060005;
	Thu, 6 Dec 2007 10:38:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HciAP059997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 10:38:44 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 3599B23E4A9;
	Thu,  6 Dec 2007 12:38:41 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Steven Lees'" <Steven.Lees@microsoft.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
Subject: RE: Tombstones
Date: Fri, 7 Dec 2007 00:38:43 +0700
Message-ID: <001601c8382e$db559810$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
Thread-Index: Acg2/zEykVpKNJnJRSyioEflR62w/QAZIlRwABA4qcAAIeVBoA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64


Steven Lees wrote:
> This issue came up in the August AtomPub interop. Our current 
> solution on http://feedsync.mslivelabs.com is that, by 
> default, the server doesn't give you tombstoned entries. You 
> have to ask for them with a query parameter. I've also been 
> hunting for the right HTTP header to ask for tombstones as an 
> alternate mechanism.

The most obvious way to do it would be to add a parameter to the
application/atom+xml mime type, and use that parameter along with a
strong "q" parameter in an Accept header:

   Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
           application/atom+xml;q=0.9

I don't know what kind of politics are involved in that, though.

> I discussed that recently here: 
> http://blogs.msdn.com/stevenlees/archive/2007/12/02/about-a-by
> .aspx. The short answer is that "by" is not really meant to 
> be user readable. For that we'd recommend atom:author or 
> something else in your data model.

Thanks for the link. I could have sworn that I had read that it was
intended to be user-readable. I guess as long as a (urn:uuid:) URI could
be used, there is no real problem.

> I wasn't so much referring to the conflict resolution part as 
> the other sync metadata. Once piece that's really useful is 
> the sx:sync/@updates attribute--it's simpler and more 
> reliable than a timestamp for detecting updates. If you 
> really only care about one-way (aka publish only) sync, then 
> your FeedSync implementation becomes that much simpler.

Like James, I am not sure how much simpler it is for AtomPub. For other
feeds, I agree that it might be useful, but only if implementations are
more careful about updating it than they have been about updating
atom:updated.

Another question about FeedSync: In the FeedSync model, is it assumed
that the feed contains the complete, canonical representation of each
entry? See the thread "Indicate entry in Collection Feed is full
representation" on the atom-protocol mailing list:

http://www.imc.org/atom-protocol/mail-archive/msg10621.html

If so, then I think that most AtomPub implementations would require a
separate feed for FeedSync anyway (linked from the service document or
the collection feed using some new link relation), and the
backward-compatibility issue would not really be a factor.

- Brian




From owner-atom-syntax@mail.imc.org Thu Dec 06 13:03:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0L4P-0005yv-KR
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:03:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0L4O-0003P8-IK
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:03:33 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HgSlD060376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 10:42:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HgSli060375;
	Thu, 6 Dec 2007 10:42:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HgRxT060367
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 10:42:28 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [172.16.0.243] (unknown [209.79.152.172])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 2BA6DD05A8;
	Thu,  6 Dec 2007 12:42:26 -0500 (EST)
In-Reply-To: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
Cc: James M Snell <jasnell@gmail.com>, Steven Lees <Steven.Lees@microsoft.com>,
        Atom Syntax <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: Tombstones
Date: Thu, 6 Dec 2007 09:42:23 -0800
To: David Powell <djpowell@djpowell.net>
X-Mailer: Apple Mail (2.752.3)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024


Hmm. Seems like SSE tombstones are good enough for the use case I  
illustrated; it's acceptable that clients who don't understand them  
ignore them (they'll just see more spam), and the rest of the entry  
isn't needed (it's spam, after all).

Are there any aggregators who implement this?

Cheers,


On 06/12/2007, at 4:45 AM, David Powell wrote:

> Quoting James M Snell <jasnell@gmail.com>:
>
>>
>> http://www.snellspace.com/wp/?p=818
>>
>> - James
>
>
>> 1. Deleted entries (aka Tombstones) are indicated by extension  
>> elements
>> contained within the atom:entry element. For clients that do not  
>> understand
>> the SSE extensions, these will appear no different than any other  
>> entry
>> such clients would have no way of knowing that the entry was  
>> deleted.  Also,
>> this solution assumes that there is still enough data in the  
>> database to
>> reconstruct the deleted entry in the feed. The content, title,  
>> tags, etc may
>> all have been removed from the database.
>
> I disagree.  Having clients that don't understand the extensions
> processing them in the same way as updates to the entries seems like a
> massive plus-point for FeedSync to me.
>
> I assumed that you aren't supposed to reconstruct those items, after
> all you are trying to delete the item.  The tombstone entry would look
> something like this:
>
> <entry>
>   <id>id of the original entry</id>
>   <updated>deletion date</updated>
>   <sx:deleted />
>   <title>This entry has been removed</title>
>   <summary>This entry has been removed</summary>
>   ...
> </entry>
>
> If the client supports sx:deleted it can remove the entry from its
> store, if the client doesn't support sx:deleted, it will replace the
> old entry with this low-tech tombstone.  If the client is a framework,
> sub-clients will have the opportunity to implement sx:deleted, even if
> the framework doesn't.  A publishing client that understands
> sx:deleted could delete an entry in this way on any arbitrary atompub
> server.  There is very little coordination cost - you can use it today
> and wait for the rest of the infrastructure to catch up.
>
> The feed + stream of entries model is the 'protocol' of how feeds
> work.  FeedSync is backwards compatible with this protocol; your
> alternate proposal seems to require a boil-the-ocean from publishing
> clients, atompub servers, intermediaries, feed servers, aggregator
> frameworks, and aggregators before these tombstones will work.
>
> Why create a new protocol when we can use an existing one?
>
> -- 
> Dave
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Thu Dec 06 13:12:16 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0LCq-000491-P0
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:12:16 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0LCq-00045c-6r
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 13:12:16 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HhTm1060459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 10:43:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HhTQs060458;
	Thu, 6 Dec 2007 10:43:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HhSil060450
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 10:43:29 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so299039rvf
        for <atom-syntax@imc.org>; Thu, 06 Dec 2007 09:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=Dt2DLAvS17UuQjKiEBF9g76ljfpcViAnZIHeGbrlDVA=;
        b=VKePnGwvnAFWl0aVJSdoXY+p9gbHyu8xKyKMGsZ4it8iNXDnN3VZ+Qs0qHC0sW8Mp8Cg84yEyuxMLCVOodla8Gi2DiAWmX3SskyNC0eCVCrBR4PSGkhDxNK0zitA9J8shtU7eMwn5d5CsLPK4/UwTIuIWSM8iWZ2Loug88KJpVk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=I+6KQnG/ZnlKTzxf1P6urEiUtJbaWRkvNof530Q5+McNjUzxh0jne8iYy7vVje8LjMceY25IFKtDGY7Wrdgiqea0hglPU54yjSb7g5Dak+DLHQl+iKIePMd2ctnrG5PQFbcsSTMkFuz/3c841JiTMdFsB6s9UXm4R4mPdNUufzI=
Received: by 10.140.126.14 with SMTP id y14mr2123075rvc.1196963008056;
        Thu, 06 Dec 2007 09:43:28 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id b2sm43225rvf.2007.12.06.09.43.26
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 06 Dec 2007 09:43:27 -0800 (PST)
Message-ID: <475834B5.2080203@gmail.com>
Date: Thu, 06 Dec 2007 09:43:17 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Feed Paging for Efficient Feed Synchronization
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk>
In-Reply-To: <000601c8382b$99961c40$2501a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab


Comments below.

Brian Smith wrote:
> [snip]
>> That said, however, once the initial sync is completed, 
>> subsequent incremental sync's are much more efficient if 
>> paging is not used (e.g. give me one feed document describing
>> just the things that have changed over the last twelve hours, etc).
> 
> On the other hand, if there were hundreds of entries updated in 
> the last 12 hours (e.g. a server upgrade which modifies the 
> representation of every entry, or whatever else WordPress users 
> do that causes every entry to appear updated), the client and the 
> server will probably both benefit from chunking that up. Especially, 
> on mobile phones, the larger the response, the less likely the service 
> provider's proxies will let it go through to the device.
> 

Either way, it's generally the same amount of data being transferred,
only you have to deal with multiple requests and scanning through each
page to detect which items have changed.  Even with pipelining, that's
less efficient than making a single request with a single response that
you know for certain contains only items that have been modified.

Regarding mobile devices: I may just be demonstrating my ignorance of
mobile device development, but I'd be rather surprised to find a mobile
device that would want to maintain a complete, persistent local snapshot
of a collection.  What I suspect would be most common is the device
wanting only to maintain a limited listing of the 10-20 most recently
updated posts -- something that can be achieved currently without feedsync.

>> Again, this would work so long as the pages remain stable; 
>> however, I would very much like to see a comparison of how 
>> the two approaches compare in terms of performance / efficiency.
> 
> Well, obviously paging is going to require more roundtrips if there 
> are multiple pages used for the sync. If the server decides to use 
> one page per resync then both approaches are equivalent. In fact, 
> disregarding snapshotting, my solution is the same as yours, except 
> in mine the server controls the values of the "since" and "until" 
> parameters, whereas in yours the client controls them, and mine allows 
> the server to break up the response into multiple (cacheable) pages.

So long as the feeds contain only the entries that were modified within
the specified period of time then yes, without paging the approaches are
equivalent.  In other words, I want to avoid having to scan through the
entries to determine which entries have or have not changed since the
last time I looked at the feed; instead, I want to know that when I'm
syncing, ALL of the entries listed in that feed document have changed
since the last time I sync'd.

- James

> 
> - Brian
> 
> 




From owner-atom-syntax@mail.imc.org Thu Dec 06 14:36:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0MWp-0005kq-9r
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:36:59 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0MWo-0002jS-Bt
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:36:59 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6J6ofL068902
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 12:06:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6J6o80068900;
	Thu, 6 Dec 2007 12:06:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6J6k2h068892
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 12:06:47 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so325208rvf
        for <atom-syntax@imc.org>; Thu, 06 Dec 2007 11:06:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=6o3SXJM1M4H7mDYoIpW9CZD9HPCaDLpnN9N5CHQtUTc=;
        b=WFhimKRRMtE1i7jaij9gUwrrIPXJTY8znJn4UK9/AkAeFAD1U8NYPieZfzN0DL1QBV/LLP/ZxuBiDsnbtJ3d4OHtPIiRTL6avWyajTGiS1MPKwOuXkop6Pz1vzWyO6PGUSVCPZbdaiFliJATv/kr6mFbP+F8jNvt5pjY2zHBEfw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=d/kq+eK+5EI8qJ8W1ensgJfJE4AEkG4O7clpHGDavef1Hnog8pWQg6VHBo/J3qpurmdxH/CDchfID0A2zgFQ3fdRHNrYqfWcZkS0ceXV6L+wYM4pajrLxF8q1XxZfeVaK3wGUJYoAQG7AhJPIW6GdIlsHj9XzvMri9nmcbOBvAQ=
Received: by 10.142.171.6 with SMTP id t6mr1854381wfe.1196968006268;
        Thu, 06 Dec 2007 11:06:46 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id n5sm3079271rnf.2007.12.06.11.06.43
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 06 Dec 2007 11:06:44 -0800 (PST)
Message-ID: <4758483E.5070705@gmail.com>
Date: Thu, 06 Dec 2007 11:06:38 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Feed Paging for Efficient Feed Synchronization
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk>
In-Reply-To: <000601c8382b$99961c40$2501a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc


A quick note on the efficiency issue.  I just ran a quick test.  I
created 20 feed pages, each with 20 entries each.  Using the feed paging
model, I grab the first feed, scan the entries to see if they have been
deleted or updated.  Deleted entries are represented by an x:deleted
element *within the entry*.  Then I grab the next page[1], scan the
entries, grab the next, scan the entries, etc until I come to an entry
whose app:edited timestamp is earlier than the cutoff I defined (which
assumes the entries are sorted according to app:edited, which is not
guaranteed)[2].  I ran the process 100 times, throwing away the first
run because of initialization overhead.  The times (ms) for each run are:

[1681, 6114, 2049, 1923, 1657, 1596, 1634, 1676, 1630, 1635, 1790, 1610,
1900, 1639, 1604, 1809, 1763, 1775, 2040, 8441, 2126, 2229, 1713, 1687,
1812, 2012, 1722, 1770, 1734, 1683, 1625, 1613, 1622, 1617, 2130, 1687,
1675, 1867, 7261, 2006, 1661, 1610, 1662, 1584, 1686, 1753, 1632, 1629,
1808, 1691, 1631, 1756, 7585, 1660, 1638, 2671, 1702, 1872, 1593, 1895,
1606, 1692, 1647, 1987, 1750, 1880, 1708, 1793, 2160, 1654, 1854, 1931,
1613, 3006, 2041, 2319, 2493, 1654, 1713, 1619, 1588, 1765, 2046, 1579,
2308, 1940, 1820, 1996, 1655, 1603, 1863, 1723, 1628, 1575, 1645, 1568,
1860, 1700, 1864]

[1]: http pipelining is enabled.
[2]: If entries are not sorted by app:edited, things get much worse.

By comparison, I created a single snapshot feed containing exactly the
same set of modified entries.  Deleted entries are represented using an
x:deleted tombstone element rather than atom:entry elements.  The feed
ONLY contains x:deleted and atom:entry elements representative of items
updated after the cutoff I selected.  I ran the process 100 times,
throwing away the first run because of initialization overhead.  The
times (ms) for each run are:

[225, 253, 415, 208, 155, 95, 104, 66, 106, 74, 102, 76, 70, 113, 64,
68, 73, 90, 64, 101, 427, 181, 177, 58, 58, 947, 50, 46, 48, 70, 83, 89,
41, 143, 74, 101, 39, 59, 38, 41, 37, 45, 269, 40, 403, 37, 38, 37, 62,
38, 36, 64, 36, 37, 57, 36, 37, 70, 36, 38, 84, 41, 34, 50, 33, 33, 53,
130, 107, 132, 55, 37, 53, 38, 39, 88, 39, 39, 168, 95, 73, 102, 62, 48,
84, 47, 45, 133, 43, 81, 367, 55, 50, 89, 45, 67, 47, 67, 57]

The test feeds and code are located at
http://www.snellspace.com/public/feeds

- James

Brian Smith wrote:
> James M Snell wrote:
>> Brian Smith wrote:
>>> James Snell wrote at http://www.snellspace.com/wp/?p=818:
>>>> And Because the entire snapshot is contained within a single feed 
>>>> document, we do not have to worry about the race condition that is 
>>>> inherent in the rolling window feed paging model.
>>> The race condition is not an inherent problem in the paging 
>>> model; it is an implementation issue. In my implementation, I 
>>> do all the paging in my collection feed using links like:
>> Note that I specifically indicated the rolling window feed 
>> paging model.
>>  Yes, there are ways of doing the paging where the pages are 
>> stable, and if we can rely on folks doing it that way 
>> consistently then paging is fine.  The key requirement is 
>> that the snapshot has to remain stable throughout the sync process.
> 
> To be clear, I don't provide any kind of snapshot mechanism. The client needs to go back to the start of the feeds (most recently edited entries) after it has paged through all the older entries, to see if some older entry has been modified during the paging process. If some entry or entries are constantly being edited, then it is possible that the client will never see them. On the other hand, what good does it do for the client to receive an old representation of an entry that is currently being relentlessly edited? The cost of implementing snapshotting seems to nearly always outweigh any benefits it might have.
> 
> The only guarantees that I make beyond what AtomPub requires are: (1) if any entries are skipped during paging, they will appear at the start of the feed, (2) navigating to each "prev" page will always result in older entries than the ones in the current page, and (3) navigating to each "next" page will result in an empty page or in entries newer than the ones in the current page. Implementations that do paging by numbering each page ("?page=2", "?page=3") often cannot make those guarantees when entries are being added/edited faster than the client can page through the feed.
> 
>> That said, however, once the initial sync is completed, 
>> subsequent incremental sync's are much more efficient if 
>> paging is not used (e.g. give me one feed document describing
>> just the things that have changed over the last twelve hours, etc).
> 
> On the other hand, if there were hundreds of entries updated in the last 12 hours (e.g. a server upgrade which modifies the representation of every entry, or whatever else WordPress users do that causes every entry to appear updated), the client and the server will probably both benefit from chunking that up. Especially, on mobile phones, the larger the response, the less likely the service provider's proxies will let it go through to the device.
> 
>> Again, this would work so long as the pages remain stable; 
>> however, I would very much like to see a comparison of how 
>> the two approaches compare in terms of performance / efficiency.
> 
> Well, obviously paging is going to require more roundtrips if there are multiple pages used for the sync. If the server decides to use one page per resync then both approaches are equivalent. In fact, disregarding snapshotting, my solution is the same as yours, except in mine the server controls the values of the "since" and "until" parameters, whereas in yours the client controls them, and mine allows the server to break up the response into multiple (cacheable) pages.
> 
> - Brian
> 
> 




From owner-atom-syntax@mail.imc.org Thu Dec 06 14:39:01 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0MYn-00068s-QY
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:39:01 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0MYn-0002t3-Bu
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:39:01 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6JI7es069848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 12:18:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6JI7sP069847;
	Thu, 6 Dec 2007 12:18:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6JI6wu069838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 12:18:06 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 4591723E503;
	Thu,  6 Dec 2007 14:18:04 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James M Snell'" <jasnell@gmail.com>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com>
Subject: RE: Feed Paging for Efficient Feed Synchronization
Date: Fri, 7 Dec 2007 02:17:57 +0700
Message-ID: <000a01c8383c$bcce0270$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <475834B5.2080203@gmail.com>
Thread-Index: Acg4L4NygyjLfqmDQ7+e/D5DW7+6AgAATLMQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6JI6wt069842
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


James M Snell wrote:
> Either way, it's generally the same amount of data being 
> transferred, only you have to deal with multiple requests and 
> scanning through each page to detect which items have 
> changed.  Even with pipelining, that's less efficient than 
> making a single request with a single response that you know 
> for certain contains only items that have been modified.

> So long as the feeds contain only the entries that were 
> modified within the specified period of time then yes, 
> without paging the approaches are equivalent.  In other 
> words, I want to avoid having to scan through the entries to 
> determine which entries have or have not changed since the 
> last time I looked at the feed; instead, I want to know that 
> when I'm syncing, ALL of the entries listed in that feed 
> document have changed since the last time I sync'd.

The subscription page of a collection feed does not usually have a "next" link, and the only way to find new entries in a collection is to poll the subscription page of the collection feed (at the collection URI). My suggestion is: (a) the server adds a "next" link to the subscription page, that links to a document that represents all entries nwerer than the currently-newest entry, (b) the client chases these "next" links and thus never has to poll the collection URI. By doing this, the client will never encounter an entry that it already has an up-to-date copy of.

- Brian





From owner-atom-syntax@mail.imc.org Thu Dec 06 14:39:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0MZB-0006Jc-8K
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:39:25 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0MZA-0002ui-RX
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 14:39:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6JI6As069836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 12:18:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6JI6Vx069835;
	Thu, 6 Dec 2007 12:18:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6JI4l7069826
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 12:18:05 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 0137C23E500;
	Thu,  6 Dec 2007 14:18:02 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Mark Nottingham'" <mnot@mnot.net>, "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
Subject: RE: Tombstones
Date: Fri, 7 Dec 2007 02:17:57 +0700
Message-ID: <000001c8383c$bbc7b600$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
Thread-Index: Acg4MPM1LPq/OEJXQa6JsrWbJ8/8tAABxSGQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


Mark Nottingham wrote:
> Hmm. Seems like SSE tombstones are good enough for the use 
> case I illustrated; it's acceptable that clients who don't 
> understand them ignore them (they'll just see more spam), and 
> the rest of the entry isn't needed (it's spam, after all).

They will see 2X as much spam: once, when they mark the original spam as
read, and then they will see the tombstone show up as an updated entry.
So, effectively, spam is up to twice as bad with the SSE tombstones as
it is without them. 

- Brian




From owner-atom-syntax@mail.imc.org Thu Dec 06 15:30:11 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0NMJ-00068L-4r
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 15:30:11 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0NMI-0005sI-Hm
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 15:30:11 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6K42PT073717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 13:04:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6K42Ir073716;
	Thu, 6 Dec 2007 13:04:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6K40Ep073707
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 13:04:01 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so342861rvf
        for <atom-syntax@imc.org>; Thu, 06 Dec 2007 12:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=CqLjQKxk0YI3/XzsIlNi+qzGd/f+UoyjjtlT6CN01Jc=;
        b=lTS9FhRRLVPDBeET+IRJYtvHendgMbao74eqtf2GKw/cMDbjGsrltJaC6sQu9MVT/7vwJo2TOgBb70hW7AlXZj8t1oic4laiurxy5oVFvlebijkzmyuLxC3VadfYjtctdN390lLhhuuUz0LnKgYnxnuUMMk6EG8Izj8KBIeMFEk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=g+RMYFXh/unDMos5u3YkbscepZkSkO/ZfWU9U6rdy4oFLXz7p1kaCGKMh+7rUQyysaizcBB8Xj0kPfHmRDHVuW4oT6vQo4KxrbkhGCgMptE2W+E404BFhG3jzrPoqXlo3HrYto4TVBKtvRjDZwHZMyqXbX5qxXfLZydbmoJuCH8=
Received: by 10.141.163.12 with SMTP id q12mr1260207rvo.1196971440051;
        Thu, 06 Dec 2007 12:04:00 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id f13sm56137rvb.2007.12.06.12.03.58
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 06 Dec 2007 12:03:58 -0800 (PST)
Message-ID: <475855A5.5010902@gmail.com>
Date: Thu, 06 Dec 2007 12:03:49 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Feed Paging for Efficient Feed Synchronization
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk>
In-Reply-To: <000a01c8383c$bcce0270$2501a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a


Ok, another test.. using the paging forward in time approach (e.g.
starting from the last page I looked at, GET each subsequent "next" page
containing entries modified since the last run as you describe below...
running 100 iterations pulling the feeds from localhost, with pipelining
enabled, the times for each run (in ms) are (first run is thrown out).

400 entries over 20 pages:

[520, 364, 593, 1092, 547, 971, 628, 769, 368, 1557, 462, 293, 495, 889,
991, 457, 559, 1040, 391, 309, 296, 325, 275, 552, 397, 303, 308, 341,
360, 299, 430, 322, 308, 321, 275, 314, 318, 332, 321, 431, 400, 488,
322, 343, 271, 369, 387, 404, 324, 464, 436, 392, 392, 1108, 320, 537,
275, 330, 302, 277, 403, 348, 265, 275, 364, 637, 351, 293, 276, 268,
275, 273, 301, 298, 557, 304, 360, 468, 368, 435, 375, 354, 331, 372,
417, 335, 485, 315, 356, 292, 288, 296, 320, 292, 384, 312, 416, 257]

400 entries in a single feed:

[204, 482, 251, 191, 577, 163, 150, 186, 223, 136, 159, 168, 170, 223,
905, 186, 166, 139, 157, 145, 283, 143, 150, 397, 144, 146, 185, 167,
313, 177, 147, 177, 143, 462, 162, 158, 136, 137, 162, 115, 265, 121,
183, 319, 121, 405, 169, 545, 163, 191, 156, 535, 146, 150, 518, 118,
144, 263, 145, 152, 132, 152, 509, 123, 165, 130, 171, 139, 135, 122,
152, 121, 128, 147, 117, 168, 141, 144, 142, 464, 578, 142, 143, 139,
143, 124, 151, 181, 214, 117, 160, 176, 134, 150, 116, 150, 150, 323, 127]

- James

Brian Smith wrote:
> James M Snell wrote:
>> Either way, it's generally the same amount of data being 
>> transferred, only you have to deal with multiple requests and 
>> scanning through each page to detect which items have 
>> changed.  Even with pipelining, that's less efficient than 
>> making a single request with a single response that you know 
>> for certain contains only items that have been modified.
> 
>> So long as the feeds contain only the entries that were 
>> modified within the specified period of time then yes, 
>> without paging the approaches are equivalent.  In other 
>> words, I want to avoid having to scan through the entries to 
>> determine which entries have or have not changed since the 
>> last time I looked at the feed; instead, I want to know that 
>> when I'm syncing, ALL of the entries listed in that feed 
>> document have changed since the last time I sync'd.
> 
> The subscription page of a collection feed does not usually have a 
> "next" link, and the only way to find new entries in a collection 
> is to poll the subscription page of the collection feed (at the 
> collection URI). My suggestion is: (a) the server adds a "next" link 
> to the subscription page, that links to a document that represents all 
> entries nwerer than the currently-newest entry, (b) the client chases 
> these "next" links and thus never has to poll the collection URI. By 
> doing this, the client will never encounter an entry that it already has 
> an up-to-date copy of.
> 
> - Brian
> 
> 




From owner-atom-syntax@mail.imc.org Thu Dec 06 16:45:13 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0OWv-0003Pp-Id
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 16:45:13 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0OWv-0004DR-37
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 16:45:13 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6LNK1o081721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 14:23:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6LNK8E081720;
	Thu, 6 Dec 2007 14:23:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6LNISX081713
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 14:23:19 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Thu, 6 Dec 2007 13:23:18 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu,
 6 Dec 2007 13:23:16 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James M Snell <jasnell@gmail.com>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Thu, 6 Dec 2007 13:23:14 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg3v1PCFpgdje80RoKGrZYxzNfg8gAjSIrg
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2E93@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47577884.8060401@gmail.com>
In-Reply-To: <47577884.8060401@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6LNJSW081714
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22


I wrote:

> > I wasn't so much referring to the conflict resolution part as the
> > other sync metadata. Once piece that's really useful is the
> sx:sync/@updates
> > attribute--it's simpler and more reliable than a timestamp for
> detecting
> > updates. If you really only care about one-way (aka publish only)
> sync,
> > then your FeedSync implementation becomes that much simpler.

James Snell replied:

> I'm not convinced about the "more reliable" part.  If app:edited
> elements are used properly, they would seem to be more than sufficient.
>  I'm curious if you have specific examples of where using the timestamp
> breaks down?
>
> - James

Timestamps are problematic for sync because they assume that you can synchronize clocks across different machines. You also have to do things like convert between timezones which doesn't work well in practice. There are problems for the publish-only case as well as bidirectional sync. On a single machine, reported time values don't always move forward linearly when your clock resyncs against some time authority, and of course because of daylight saving time.  Or your AtomPub "server" is really a server farm, and you make successive edits that are server by different machines who's clocks are offset.

We still have a timestamp in sx:history for use as an approximate time value. We also use it as a tiebreaker in the case of conflict, but only to decide which edit goes on the "outside". We use sx:sync/@updates as the primary way to detect updates and conflicts. I think that makes sense when you consider that our primary design point was around making sync work for many scenarios, and not just deleting previously published items.

Steven





From owner-atom-syntax@mail.imc.org Thu Dec 06 17:06:13 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0OrF-0006rw-Ng
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 17:06:13 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0OrF-0005zd-1x
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 17:06:13 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6LfIUm083771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 14:41:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6LfI0o083770;
	Thu, 6 Dec 2007 14:41:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6LfHvS083761
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 14:41:17 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Thu, 6 Dec 2007 13:41:17 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu,
 6 Dec 2007 13:41:16 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: Brian Smith <brian@briansmith.org>,
        "'David Powell'"
	<djpowell@djpowell.net>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Thu, 6 Dec 2007 13:41:15 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg4BpYkw5gV7t++SwuHsG8++QSVfAAAapsQABHBa6A=
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2EC2@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net><47562422.40408@gmail.com><9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com><47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <000101c8380b$cf729d90$2501a8c0@Junk>
In-Reply-To: <000101c8380b$cf729d90$2501a8c0@Junk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6LfIvR083763
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002


Brian Smith wrote:

> You make a good point. But, if there are frequent deletions then
> non-FeedSync-aware clients will have to wade through "This entry has
> been removed" entries showing up to replace entries that they have
> previously marked as read or otherwise filed as "don't show me this
> again unless it is updated".

As a publisher, you have to consider two kinds of clients: those that don't understand deletions, and those that do.

If you *really* want to make sure that information disappears from any client aggregator, then the most reliable way to do that given the state of the world today is to issue an updated item where the new fields are either empty, or have some message like the one you suggest below.

If you just want to provide deletion as a feature for those who are willing to upgrade their feed client, then you can go with either tombstone method.

> Consider this alternative formulation:
>
>   <entry>
>    <id>id of the original entry</id>
>    <updated>deletion date</updated>
>    <title>This entry has been removed</title>
>    <summary>This entry has been removed</summary>
>    ...
>   </entry>
>   <sx:deleted>
>      <atom:id>id of the original entry</atom:id>
>   </sx:deleted>
>
> This accomplishes your goal, but makes the "low tech tombstone"
> optional, for cases where asking clients to navigate "This entry has
> been removed" entries is inappropriate. It does require the server to
> insert <xs:deleted>, though.

This is approximately what we do in FeedSync. You add (or change) sx:sync/@deleted to "true", and any client that is aware of that attribute will recognize the deletion. Publishers can choose to alter the entry, or not.

> The FeedSync mechanism is reasonable if only a few entries are
> occasionally deleted. But, it is not reasonable in other situations. In
> particular, in WLW I save all my drafts on the server and often delete
> drafts without publishing them. I don't want to see a bunch of
> tombstone
> entries in the article list. The Snell mechanism would be more
> appropriate in that scenario.
>
> - Brian

That doesn't seem like a good example. If your drafts are never published in a feed, then you don't ever need to tombstone them in a feed. But that kind of scenario (having downlevel clients who never care about seeing deletions) is why our default on http://feedsync.mslivelabs.com is to omit tombstones from the feed. Since any client that wants them is already doing some extra work, it's easy enough for that client to opt in to tombstones as well, via a query parameter or HTTP header.

Steven




From owner-atom-syntax@mail.imc.org Thu Dec 06 17:32:36 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0PGm-00051B-3c
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 17:32:36 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0PGl-0008RO-Aa
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 17:32:36 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6M9mv6086262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 15:09:48 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6M9mHW086261;
	Thu, 6 Dec 2007 15:09:48 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6M9hSD086254
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 15:09:48 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by
 TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Thu, 6 Dec 2007 14:09:43 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu,
 6 Dec 2007 14:09:43 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Thu, 6 Dec 2007 14:09:40 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg2/zEykVpKNJnJRSyioEflR62w/QAZIlRwABA4qcAAIeVBoAAJp1zg
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <001601c8382e$db559810$2501a8c0@Junk>
In-Reply-To: <001601c8382e$db559810$2501a8c0@Junk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB6M9mSC086256
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a


Brian Smith wrote:

> Steven Lees wrote:
> > This issue came up in the August AtomPub interop. Our current
> > solution on http://feedsync.mslivelabs.com is that, by
> > default, the server doesn't give you tombstoned entries. You
> > have to ask for them with a query parameter. I've also been
> > hunting for the right HTTP header to ask for tombstones as an
> > alternate mechanism.
>
> The most obvious way to do it would be to add a parameter to the
> application/atom+xml mime type, and use that parameter along with a
> strong "q" parameter in an Accept header:
>
>    Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
>            application/atom+xml;q=0.9

Thanks, seems like a good suggestion. Presumably the client could specify:

        Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1

if it only wants the feed with tombstones. And then on the return trip, the server uses the same Content-Type:

Content-Type: application/atom+xml;type=feed;FeedSync=1.0

One potential drawback is that in both cases, the entity returned is actually a valid Atom feed. It might be nice to have the "tombstone-ness" reflected in a way that doesn't alter the Content-Type.

>
> > I discussed that recently here:
> > http://blogs.msdn.com/stevenlees/archive/2007/12/02/about-a-by
> > .aspx. The short answer is that "by" is not really meant to
> > be user readable. For that we'd recommend atom:author or
> > something else in your data model.
>
> Thanks for the link. I could have sworn that I had read that it was
> intended to be user-readable. I guess as long as a (urn:uuid:) URI
> could
> be used, there is no real problem.

You're probably not mistaken, the reason that I wrote up the post was that we haven't been very clear with "by". In the past we've often used values that look temptingly user-readable. Any kind of URI is perfectly reasonable to use for by, including urn:uuid.

> > I wasn't so much referring to the conflict resolution part as
> > the other sync metadata. Once piece that's really useful is
> > the sx:sync/@updates attribute--it's simpler and more
> > reliable than a timestamp for detecting updates. If you
> > really only care about one-way (aka publish only) sync, then
> > your FeedSync implementation becomes that much simpler.
>
> Like James, I am not sure how much simpler it is for AtomPub. For other
> feeds, I agree that it might be useful, but only if implementations are
> more careful about updating it than they have been about updating
> atom:updated.

You're absolutely right that for sync to work, clients must always correctly update the "updates" attribute. That's what makes the whole thing work. Luckily, it's pretty simple to do, even for someone hand editing the feed. It's a lot harder to generate the UUID by hand. :-)

> Another question about FeedSync: In the FeedSync model, is it assumed
> that the feed contains the complete, canonical representation of each
> entry? See the thread "Indicate entry in Collection Feed is full
> representation" on the atom-protocol mailing list:
>
> http://www.imc.org/atom-protocol/mail-archive/msg10621.html
>
> If so, then I think that most AtomPub implementations would require a
> separate feed for FeedSync anyway (linked from the service document or
> the collection feed using some new link relation), and the
> backward-compatibility issue would not really be a factor.
>
> - Brian

FeedSync is no different from plain Atom in this regard. The data that you want to synchronize needs to be in the feed; whether that's partial data or complete is up to the implementer. It's perfectly reasonable to have a separate feed for sync, but our goal is to design the system so that's not at all a requirement.

Steven




From owner-atom-syntax@mail.imc.org Thu Dec 06 18:06:37 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Pnh-0003dy-B2
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:06:37 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Pnf-0002KN-Of
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:06:37 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6MfZ2D089542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 15:41:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6MfZSt089541;
	Thu, 6 Dec 2007 15:41:35 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6MfXET089534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 15:41:34 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [172.21.222.42] (unknown [216.145.49.15])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 1A67B23E4A0;
	Thu,  6 Dec 2007 17:41:32 -0500 (EST)
In-Reply-To: <000001c8383c$bbc7b600$2501a8c0@Junk>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: Tombstones
Date: Thu, 6 Dec 2007 14:41:28 -0800
To: "Brian Smith" <brian@briansmith.org>
X-Mailer: Apple Mail (2.752.3)
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>
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


Argh, yeah, good point. This depends on the details of how the  
perceive change etc., of course, but I imagine most would show them  
twice.

OTOH, this may be good incentive for aggregators to start respecting  
tombstones :)

Cheers,


On 06/12/2007, at 11:17 AM, Brian Smith wrote:

> Mark Nottingham wrote:
>> Hmm. Seems like SSE tombstones are good enough for the use
>> case I illustrated; it's acceptable that clients who don't
>> understand them ignore them (they'll just see more spam), and
>> the rest of the entry isn't needed (it's spam, after all).
>
> They will see 2X as much spam: once, when they mark the original  
> spam as
> read, and then they will see the tombstone show up as an updated  
> entry.
> So, effectively, spam is up to twice as bad with the SSE tombstones as
> it is without them.
>
> - Brian
>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Thu Dec 06 18:30:05 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0QAP-0003hI-7m
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:30:05 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0QAO-0004IW-Ii
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:30:05 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6NITvB092321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 16:18:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6NITWZ092320;
	Thu, 6 Dec 2007 16:18:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6NIShD092314
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 16:18:29 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so304556anc
        for <atom-syntax@imc.org>; Thu, 06 Dec 2007 15:18:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=/ydWuiX3k7jXrXzUvzOjv8ekQ6oatsGDFBtPx8eFpAo=;
        b=gx+rNbvTXHumlirHjNSzP+y47Go08C6OLQ98fTaQugag/Zhm7jRW3bojr5zTTmcxEAbISAu4iyXDI0CPoSNTK/0io9dwcXpMzBf1Zu2k1Uy8rHgHM5Phi2vDX8GeI+rYWgSI/9eXOom2rvqXWJOnY4ARDRxqdYNfk0g8sblOXPw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=pIy3pdth2vnF1dK0fPUiH9Tj2JAnzup/dhxnfi5iTB83GKwtl1Xxsfa/2jd/Z6yR9SxLTr+mPW32Gz2/VWooywZywEbcN0XRvkXsaPscYC0uZc5mP7bng+uYQ5idY0Eg6Z+4k8l5JNvoDkeMntw8gnjnvb3ZbMxQNfk++mkD6q4=
Received: by 10.100.201.16 with SMTP id y16mr6498411anf.1196983108202;
        Thu, 06 Dec 2007 15:18:28 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id i49sm3479010rne.2007.12.06.15.18.26
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Thu, 06 Dec 2007 15:18:27 -0800 (PST)
Message-ID: <4758833F.9050404@gmail.com>
Date: Thu, 06 Dec 2007 15:18:23 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net>
In-Reply-To: <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 1.5 (+)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632


Using the x:deleted tombstone element, on the other hand, the spam entry
only shows up once, at a maximum. Readers that do not understand the
tombstone element would act no differently than they currently do and
users should not see any change in current feed reader behavior.

Example: we have a feed with two entries. There are two feed reader
clients, neither of which know about tombstones.  Client A requests the
feed and sees both entries.

  <feed>
    ...
    <entry>
      <id>tag:example.org,2007:1</id>
      ...
    </entry>
    <entry>
      <id>tag:example.org,2007:2</id>
      ...
    </entry>
  </feed>

Entry 1 is then deleted.  Using the tombstone-inside-entry approach, the
feed becomes

  <feed>
    ...
    <entry>
      <id>tag:example.org,2007:1</id>
      <x:deleted />
      ...
    </entry>
    <entry>
      <id>tag:example.org,2007:2</id>
      ...
    </entry>
  </feed>

Client A gets the feed and still sees two entries, one of which is
marked as being updated.

Client B comes along and requests the feed and see two entries, both of
which are new to it but one of which doesn't actually exist.  Why should
Client B have to see that entry at all?  If the entry was deleted, it
shouldn't be in the feed.

Now use the separate tombstone element,

  <feed>
    ...
    <x:deleted>
      <id>tag:example.org,2007:1</id>
    </x:deleted>
    <entry>
      <id>tag:example.org,2007:2</id>
      ...
    </entry>
  </feed>

Client A continues to operate as it always has when an entry that was
once in the feed suddenly isn't and Client B never has to see the
deleted entry at all.  That makes a whole lot more sense to me.

Now, Steven indicates that their implementation will not include the
tombstone by default. Clients that want tombstones would have to ask for
them explicitly.  While that would solve the problem, using the
tombstone element would avoid the need to have that kind of negotiation
mechanism at all.

- James

Mark Nottingham wrote:
> 
> Argh, yeah, good point. This depends on the details of how the perceive
> change etc., of course, but I imagine most would show them twice.
> 
> OTOH, this may be good incentive for aggregators to start respecting
> tombstones :)
> 
> Cheers,
> 
> 
> On 06/12/2007, at 11:17 AM, Brian Smith wrote:
> 
>> Mark Nottingham wrote:
>>> Hmm. Seems like SSE tombstones are good enough for the use
>>> case I illustrated; it's acceptable that clients who don't
>>> understand them ignore them (they'll just see more spam), and
>>> the rest of the entry isn't needed (it's spam, after all).
>>
>> They will see 2X as much spam: once, when they mark the original spam as
>> read, and then they will see the tombstone show up as an updated entry.
>> So, effectively, spam is up to twice as bad with the SSE tombstones as
>> it is without them.
>>
>> - Brian
>>
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 




From owner-atom-syntax@mail.imc.org Thu Dec 06 18:35:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0QFI-00078y-2q
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:35:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0QFH-0004kI-Iw
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 18:35:08 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6NNp3l092690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 16:23:51 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6NNpgH092689;
	Thu, 6 Dec 2007 16:23:51 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s1.bay0.hotmail.com (bay0-omc1-s1.bay0.hotmail.com [65.54.246.73])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6NNoSF092683
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 16:23:50 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.14]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 6 Dec 2007 15:23:50 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 6 Dec 2007 15:23:50 -0800
Message-ID: <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl>
Received: from 85.211.242.20 by BAY141-DAV4.phx.gbl with DAV;
	Thu, 06 Dec 2007 23:23:45 +0000
X-Originating-IP: [85.211.242.20]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk>
Subject: Re: Tombstones
Date: Thu, 6 Dec 2007 23:23:41 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 06 Dec 2007 23:23:50.0281 (UTC) FILETIME=[0EE22790:01C8385F]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8


Brian Smith wrote:
> They will see 2X as much spam: once, when they mark the original spam as
> read, and then they will see the tombstone show up as an updated entry.
> So, effectively, spam is up to twice as bad with the SSE tombstones as
> it is without them.

That's not the only flaw. Imagine you have a feed full of deleted entries. 
With the SSE method, a new user (that didn't understand tombstones) would 
end up seeing a feed full of entries with blank or "This is deleted" 
content. With James' method, they'd see nothing (which is exactly what you'd 
want).

This was discussed last year when James first proposed tombstones. I suggest 
anyone that wasn't around at the time go and look up the threads from back 
then. Might save some time rehashing old arguments.

Regards
James




From owner-atom-syntax@mail.imc.org Thu Dec 06 21:12:16 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0ShM-000564-0M
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:12:16 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0ShL-0006bz-9r
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:12:15 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB71wkJ3004021
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 18:58:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB71wksM004020;
	Thu, 6 Dec 2007 18:58:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB71wj1k004013
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 18:58:45 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Thu, 6 Dec 2007 17:58:44 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Thu,
 6 Dec 2007 17:58:44 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Thu, 6 Dec 2007 17:58:43 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg4YBztqcS6QRtiSv+yoGCMWqtPEQAE4ztw
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com>
In-Reply-To: <4758833F.9050404@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB71wj1j004015
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>
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3


James Snell wrote:

> Using the x:deleted tombstone element, on the other hand, the spam
> entry
> only shows up once, at a maximum. Readers that do not understand the
> tombstone element would act no differently than they currently do and
> users should not see any change in current feed reader behavior.

The "spam-shows-up-more-than-once" idea is not correct, regardless of which tombstone mechanism you use. Even if you hand tombstoned entries to a non-tombstone client, the entry only shows up once. If, as we're recommending, you only give tombstones to clients that ask for them, then there's no entry at all.

> Example: we have a feed with two entries. There are two feed reader
> clients, neither of which know about tombstones.  Client A requests the
> feed and sees both entries.

<snip>

> Client A gets the feed and still sees two entries, one of which is
> marked as being updated.
>
> Client B comes along and requests the feed and see two entries, both of
> which are new to it but one of which doesn't actually exist.  Why
> should
> Client B have to see that entry at all?  If the entry was deleted, it
> shouldn't be in the feed.

Agreed. But with the <x:deleted> element, you're still passing unnecessary info to the client. If you go and delete ALL of the entries from the feed, then the client receives a feed with nothing but tombstones, which it didn't want in the first place. In that case, asking the client to opt-in seems like a pretty good idea.

> Now use the separate tombstone element,
>
>   <feed>
>     ...
>     <x:deleted>
>       <id>tag:example.org,2007:1</id>
>     </x:deleted>
>     <entry>
>       <id>tag:example.org,2007:2</id>
>       ...
>     </entry>
>   </feed>
>
> Client A continues to operate as it always has when an entry that was
> once in the feed suddenly isn't and Client B never has to see the
> deleted entry at all.  That makes a whole lot more sense to me.
>
> Now, Steven indicates that their implementation will not include the
> tombstone by default. Clients that want tombstones would have to ask
> for
> them explicitly.  While that would solve the problem, using the
> tombstone element would avoid the need to have that kind of negotiation
> mechanism at all.

Again, the mechanism seems pretty simple to me, and it has the benefit of not passing any tombstones to a client that won't understand them anyway.

Steven




From owner-atom-syntax@mail.imc.org Thu Dec 06 21:13:46 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Sio-000111-T2
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:13:46 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Sim-0006i6-Il
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:13:46 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB722wdr004328
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 19:02:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB722wZY004327;
	Thu, 6 Dec 2007 19:02:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB722vbi004320
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 19:02:58 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Thu, 6 Dec 2007 18:02:57 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Thu,
 6 Dec 2007 18:02:57 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James Holderness <j4_james@hotmail.com>,
        "'Atom-Syntax'"
	<atom-syntax@imc.org>
Date: Thu, 6 Dec 2007 18:02:55 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg4YMp9XC7Vo7u+Tp2FtGVa8WO9DAAE/c6Q
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl>
In-Reply-To: <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB722wbh004321
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


James Holderness wrote:

> That's not the only flaw. Imagine you have a feed full of deleted
> entries.
> With the SSE method, a new user (that didn't understand tombstones)
> would
> end up seeing a feed full of entries with blank or "This is deleted"
> content. With James' method, they'd see nothing (which is exactly what
> you'd
> want).
>
> This was discussed last year when James first proposed tombstones. I
> suggest
> anyone that wasn't around at the time go and look up the threads from
> back
> then. Might save some time rehashing old arguments.
>
> Regards
> James

As I mentioned in my response to James, if clients need to ask for tombstones, then this problem disappears.

As you hinted at above, the opt-in for clients has an added benefit even for clients that DO understand tombstones. On the initial sync of a feed, most sync-aware clients will still want to ask for the feed without tombstones, so that they can just get the non-deleted items. After the initial sync, then they can ask for tombstoned items as well.

Steven




From owner-atom-syntax@mail.imc.org Thu Dec 06 21:27:53 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0SwT-0001L4-2L
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:27:53 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0SwS-0007jn-74
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:27:53 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72BVGi004841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 19:11:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB72BVMo004840;
	Thu, 6 Dec 2007 19:11:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72BUpG004833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 19:11:30 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [172.21.222.42] (unknown [216.145.49.15])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 4620923E497;
	Thu,  6 Dec 2007 21:11:29 -0500 (EST)
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DD725C9B-56AF-4C1A-92BD-73F0A927CB31@mnot.net>
Cc: James M Snell <jasnell@gmail.com>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: Tombstones
Date: Thu, 6 Dec 2007 18:11:25 -0800
To: Steven Lees <Steven.Lees@microsoft.com>
X-Mailer: Apple Mail (2.752.3)
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>
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5



In an ideal world, yes. However, many aggregators I've seen will  
highlight or otherwise draw attention to entries that have changed,  
using various metrics for 'change' -- including, I suspect, the  
introduction of new child elements. YMMV, of course.

Has anyone done a survey of how aggregators behave under different  
conditions like this?

Cheers,


On 06/12/2007, at 5:58 PM, Steven Lees wrote:
> The "spam-shows-up-more-than-once" idea is not correct, regardless  
> of which tombstone mechanism you use. Even if you hand tombstoned  
> entries to a non-tombstone client, the entry only shows up once.  
> If, as we're recommending, you only give tombstones to clients that  
> ask for them, then there's no entry at all.
>
>> Example: we have a feed with two entries. There are two feed reader
>> clients, neither of which know about tombstones.  Client A  
>> requests the
>> feed and sees both entries.
>
> <snip>
>
>> Client A gets the feed and still sees two entries, one of which is
>> marked as being updated.
>>
>> Client B comes along and requests the feed and see two entries,  
>> both of
>> which are new to it but one of which doesn't actually exist.  Why
>> should
>> Client B have to see that entry at all?  If the entry was deleted, it
>> shouldn't be in the feed.
>
> Agreed. But with the <x:deleted> element, you're still passing  
> unnecessary info to the client. If you go and delete ALL of the  
> entries from the feed, then the client receives a feed with nothing  
> but tombstones, which it didn't want in the first place. In that  
> case, asking the client to opt-in seems like a pretty good idea.
>
>> Now use the separate tombstone element,
>>
>>   <feed>
>>     ...
>>     <x:deleted>
>>       <id>tag:example.org,2007:1</id>
>>     </x:deleted>
>>     <entry>
>>       <id>tag:example.org,2007:2</id>
>>       ...
>>     </entry>
>>   </feed>
>>
>> Client A continues to operate as it always has when an entry that was
>> once in the feed suddenly isn't and Client B never has to see the
>> deleted entry at all.  That makes a whole lot more sense to me.
>>
>> Now, Steven indicates that their implementation will not include the
>> tombstone by default. Clients that want tombstones would have to ask
>> for
>> them explicitly.  While that would solve the problem, using the
>> tombstone element would avoid the need to have that kind of  
>> negotiation
>> mechanism at all.
>
> Again, the mechanism seems pretty simple to me, and it has the  
> benefit of not passing any tombstones to a client that won't  
> understand them anyway.
>
> Steven


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Thu Dec 06 21:55:41 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0TNN-000092-RQ
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:55:41 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0TNN-0001GQ-ED
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 21:55:41 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72f7LR007226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 19:41:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB72f7Ve007225;
	Thu, 6 Dec 2007 19:41:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc2-s32.bay0.hotmail.com (bay0-omc2-s32.bay0.hotmail.com [65.54.246.168])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72f5bB007218
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 19:41:06 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.12]) by bay0-omc2-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 6 Dec 2007 18:41:05 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 6 Dec 2007 18:41:05 -0800
Message-ID: <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl>
Received: from 85.211.242.20 by BAY141-DAV2.phx.gbl with DAV;
	Fri, 07 Dec 2007 02:41:02 +0000
X-Originating-IP: [85.211.242.20]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com>
Subject: Re: Tombstones
Date: Fri, 7 Dec 2007 02:40:57 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 07 Dec 2007 02:41:05.0488 (UTC) FILETIME=[9D376D00:01C8387A]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


Steven Lees wrote:
> As I mentioned in my response to James, if clients need to ask
> for tombstones, then this problem disappears.

The thing I don't like about that is it requires a more complicated backend. 
There are assumedly caching issues too.

> On the initial sync of a feed, most sync-aware clients will
> still want to ask for the feed without tombstones, so that
> they can just get the non-deleted items.

I wouldn't think that's worth the effort. Tombstones should be small enough 
and infrequent enough that I wouldn't care about getting them on an initial 
sync.

Regards
James




From owner-atom-syntax@mail.imc.org Thu Dec 06 22:09:20 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Taa-0003E7-VN
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 22:09:20 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0TaY-00024b-J7
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 22:09:20 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72rQ3v008258
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 19:53:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB72rQI7008257;
	Thu, 6 Dec 2007 19:53:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc3-s3.bay0.hotmail.com (bay0-omc3-s3.bay0.hotmail.com [65.54.246.203])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB72rP6d008251
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 19:53:26 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.25]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 6 Dec 2007 18:53:25 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 6 Dec 2007 18:53:25 -0800
Message-ID: <BAY141-DAV1529926B7D57B98CF3EA76BE680@phx.gbl>
Received: from 85.211.242.20 by BAY141-DAV15.phx.gbl with DAV;
	Fri, 07 Dec 2007 02:53:20 +0000
X-Originating-IP: [85.211.242.20]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com> <DD725C9B-56AF-4C1A-92BD-73F0A927CB31@mnot.net>
Subject: Re: Tombstones
Date: Fri, 7 Dec 2007 02:53:16 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 07 Dec 2007 02:53:25.0321 (UTC) FILETIME=[5630FB90:01C8387C]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab


Mark Nottingham:
> In an ideal world, yes. However, many aggregators I've seen will 
> highlight or otherwise draw attention to entries that have changed,  using 
> various metrics for 'change' -- including, I suspect, the  introduction of 
> new child elements. YMMV, of course.

For me at least, the key issue is whether the atom:updated time has changed 
(what RFC4287 considers a significant update). However there would have to 
be a content change too (replacing the content with "this entry has been 
deleted" would do it). New child elements wouldn't make any difference.

> Has anyone done a survey of how aggregators behave under different 
> conditions like this?

Well there's the "Updated Conformance Test" on the Atom wiki. It's not a 
very good test, but I suppose it's something.
http://www.intertwingly.net/wiki/pie/UpdatedConformanceTests

Regards
James




From owner-atom-syntax@mail.imc.org Thu Dec 06 22:43:00 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0U7A-0004qS-IQ
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 22:43:00 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0U79-0004JH-T8
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 22:43:00 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB73Oi8v009933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 20:24:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB73OibY009932;
	Thu, 6 Dec 2007 20:24:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB73OfIo009924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 20:24:44 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 3D4A323E4A9;
	Thu,  6 Dec 2007 22:24:38 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Steven Lees'" <Steven.Lees@microsoft.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com> <001601c8382e$db559810$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
Subject: RE: Tombstones
Date: Fri, 7 Dec 2007 10:24:32 +0700
Message-ID: <000601c83880$b6284180$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg2/zEykVpKNJnJRSyioEflR62w/QAZIlRwABA4qcAAIeVBoAAJp1zgAAsiPlA=
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da


Steven Lees wrote:
> Brian Smith wrote:
> > The most obvious way to do it would be to add a parameter to the 
> > application/atom+xml mime type, and use that parameter along with a 
> > strong "q" parameter in an Accept header:
> >
> >    Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
> >            application/atom+xml;q=0.9
> 
> Thanks, seems like a good suggestion. Presumably the client 
> could specify:
> 
>         Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1
> 
> if it only wants the feed with tombstones. 

I would expect the presence of the FeedSync parameter to enable the
whole FeedSync mechanism, and the absence of the mechanism to indicate
that none of the FeedSync mechanism is wanted.

> And then on the return trip, the server uses the same Content-Type:
> Content-Type: application/atom+xml;type=feed;FeedSync=1.0
> 
> One potential drawback is that in both cases, the entity 
> returned is actually a valid Atom feed. It might be nice to 
> have the "tombstone-ness" reflected in a way that doesn't 
> alter the Content-Type.

Clients already have to deal with the optional "type" parameter for the
Atom mime type, and if they are using the parameter in the request, then
they should be able to handle it in the response. Further, a
FeedSync-enabled server might require that clients provide the parameter
the Content-Type of PUT and POST requests, so that the client can
indicate that it follows the FeedSync specification.

> You're absolutely right that for sync to work, clients must 
> always correctly update the "updates" attribute. That's what 
> makes the whole thing work. Luckily, it's pretty simple to 
> do, even for someone hand editing the feed. It's a lot harder 
> to generate the UUID by hand. :-)

Every time I open my feed reader, I find at least one feed where all
entries appear updated "today" because the author upgraded to a new
version of WordPress or changed their template or some other thing. The
vast majority of my feeds are authored and admined by top-tier
programmers, and yet these kinds of problems still happen all the time.
To me, this is a good indication that the updates attribute is likely to
not be handled properly either.

> FeedSync is no different from plain Atom in this regard. The 
> data that you want to synchronize needs to be in the feed; 
> whether that's partial data or complete is up to the 
> implementer. It's perfectly reasonable to have a separate 
> feed for sync, but our goal is to design the system so that's 
> not at all a requirement.

Note that this is the opposite of AtomPub; see section 10 of RFC 5023.
In particular, the entries in an AtomPub collection feed are likely to
be only summaries of the actual entries. That is why I think that a
FeedSync feed is likely to be separate from the normal collection feed
(either difference URIs or by using the Accept header or something).

- Brian




From owner-atom-syntax@mail.imc.org Thu Dec 06 23:24:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0Ulb-00008w-8s
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 23:24:47 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0Ula-0006gp-H3
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 23:24:47 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB74CVos013082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 21:12:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB74CV19013081;
	Thu, 6 Dec 2007 21:12:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB74CT5a013074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 21:12:30 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 87E4C23E3E8;
	Thu,  6 Dec 2007 23:12:28 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Steven Lees'" <Steven.Lees@microsoft.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
Subject: RE: Tombstones
Date: Fri, 7 Dec 2007 11:12:27 +0700
Message-ID: <001001c83887$6423d730$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg4YBztqcS6QRtiSv+yoGCMWqtPEQAE4ztwAANLBMA=
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8


Steven Lees wrote:
> James Snell wrote:
> 
> > Using the x:deleted tombstone element, on the other hand, the spam 
> > entry only shows up once, at a maximum. Readers that do not 
> > understand the tombstone element would act no differently than they 
> > currently do and users should not see any change in current feed
> > reader behavior.
> 
> The "spam-shows-up-more-than-once" idea is not correct, 
> regardless of which tombstone mechanism you use. Even if you 
> hand tombstoned entries to a non-tombstone client, the entry 
> only shows up once. If, as we're recommending, you only give 
> tombstones to clients that ask for them, then there's no entry at all.

What I meant was, first the spam will show up, the user will mark it
read, then the feed reader will see the tombstone, which looks like an
updated version of the original entry, and then mark the entry as
new/unread, and then the user will have to mark it (the tombstone) as
read. The only way to hope to prevent this in FeedSync is to ensure that
the atom:updated value is not updated when the entry is converted into a
tombstone. But, that causes problems when other specifications (e.g. RFC
5005) require that entries be paged/ordered by their atom:updated
property.

> Agreed. But with the <x:deleted> element, you're still 
> passing unnecessary info to the client. If you go and delete 
> ALL of the entries from the feed, then the client receives a 
> feed with nothing but tombstones, which it didn't want in the 
> first place. In that case, asking the client to opt-in seems 
> like a pretty good idea.

But, with the Snell mechanism, the tombstones are invisible to every
client that doesn't understand them. So, they might be bloating up the
feed (slightly), but it is almost guaranteed that they won't be visible
in the UI.

> Again, the mechanism seems pretty simple to me, and it has 
> the benefit of not passing any tombstones to a client that 
> won't understand them anyway.

Sure, but:

(1) Many (most?) AtomPub applications will not significantly benefit
from FeedSync except the tombstone mechanism (because FeedSync and
AtomPub each have their own synchronization protocols). When I look at
the FeedSync spec, I see a lot of stuff I don't really care about. It
feels wrong to implement only the tombstone part of FeedSync when that
isn't even its primary feature, but I'm not going to implement the whole
spec just to feel comfortable using its tombstone mechanism either. When
I look at James' tombstone mechanism, I see exactly what I need.

(2) James Snell's mechanism can be implemented in existing feeds without
causing any problems whatsoever; it is an almost zero-cost solution.

(3) Using a query parameter to control the tombstones does not fit with
the "RESTful" design AtomPub and other Atom-related standards. Unless
you change the opt-in mechanism to one of the following, you will never
be able to win over the hardcore Atom crowd, and another mechanism will
be chosen instead: (a) an HTTP header (perhaps Accept:, like I mentioned
in another post) to request FeedSync annotations within a feed, (b) an
atom link relation to link to a FeedSync-annotated feed, or (c) an
IRI-template-based mechanism for discovering the FeedSync-enabled feed.
(These are listed in order of my personal preference.)

(4) FeedSync could be easily adapted to use James's mechanism [1], or
both mechanisms can coexist. 

Personally, I am willing to implement the FeedSync mechanism if it is
requested via the Accept: header, or if there is otherwise consensus to
use it. Otherwise, I strongly prefer James Snell's solution (the
<x:deleted><atom:id>...</atom:id></x:deleted> variant) because it is so
unobtrusive. In fact, I could implement it in a half hour if we could
agree on a namespace to use for it (preferably one without the word
"tombstone" or other references to death).

- Brian

[1] http://www.snellspace.com/wp/?p=818, starting with "Here's a
modified take"




From owner-atom-syntax@mail.imc.org Thu Dec 06 23:51:23 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0VBL-0001Q2-Hi
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 23:51:23 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0VBL-0007uk-1y
	for atompub-archive@lists.ietf.org; Thu, 06 Dec 2007 23:51:23 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB74ZFLh014007
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Dec 2007 21:35:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB74ZFWc014006;
	Thu, 6 Dec 2007 21:35:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB74ZDDY013999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 6 Dec 2007 21:35:14 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 437C923E3E8;
	Thu,  6 Dec 2007 23:35:12 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James M Snell'" <jasnell@gmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com>
Subject: RE: Feed Paging for Efficient Feed Synchronization
Date: Fri, 7 Dec 2007 11:35:05 +0700
Message-ID: <002001c8388a$90c65b20$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <475855A5.5010902@gmail.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg4RNVxxzGq+qEYTfK9e3wlzLiP9AAQqT4A
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB74ZFDX014001
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


James M Snell wrote:
> 400 entries over 20 pages:
...
> 400 entries in a single feed:

If the server can rely on the client handling 400 entries per feed, then it would not need to split the feed into twenty pages; only two pages would be needed. Conversely, if the client cannot handle a response with 400 entries in it, then the single-page-result query mechanism will always fail.

To see this more clearly, we should test the performance of ten clients simultaneously syncing 10,000 10KB entries using each approach, using a reasonable page size (say 100K compressed, to stay within the limits of many mobile devices), with caching reverse proxy in front of the AtomPub servers, and a caching proxy in front of the client, with a new entry inserted in between each client request. The single-page-result mechanism would have to generate and transmit ten unique 100MB documents, that many desktop clients wouldn't even be able to handle, whereas the paging mechanism would be able to offload most of its work to the client-side caching proxy server and still interoperate with most mobile devices.

I think we could also run the paging version from my $6.00/month shared hosting account (a CGI script gets 6 seconds to run before its process gets killed). I'm pretty sure that wouldn't be possible with the single-page-result implementation.

To summarize, the single-page-result solution might have better raw performance when not resource constrained, but the paging mechanism offers better cachability and scales up and down nicely. That is why I prefer the paging mechanism.

- Brian





From owner-atom-syntax@mail.imc.org Fri Dec 07 14:09:40 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0iZw-0003C1-Cn
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 14:09:40 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0iZu-0003Eq-3P
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 14:09:40 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7Iuxbg089035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 11:56:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB7Iux4a089034;
	Fri, 7 Dec 2007 11:56:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7Iuwuu089026
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 11:56:59 -0700 (MST)
	(envelope-from Joe.Cheng@microsoft.com)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Fri, 7 Dec 2007 10:56:57 -0800
Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Fri,
 7 Dec 2007 10:56:47 -0800
From: Joe Cheng <Joe.Cheng@microsoft.com>
To: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>,
        Steven Lees <Steven.Lees@microsoft.com>
Date: Fri, 7 Dec 2007 10:56:43 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg4YBz0YkLqTeLfQgOBv2mQ/9q8BgAnAE7Q
Message-ID: <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com>
In-Reply-To: <4758833F.9050404@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB7Iuxut089029
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab


> Now, Steven indicates that their implementation will not include the
> tombstone by default. Clients that want tombstones would have to ask for
> them explicitly.

This doesn't belong in the implementation, it belongs in the spec.
(Would this discussion even be taking place if opt-in had been in the
spec from the start?) I have advocated HTTP headers for opt-in the
past, but to avoid caching problems it seems like a link relation would
be better.

I like the idea of building tombstone-aware clients on top of client
libraries that are not tombstone aware. The inline opt-in model seems
like the easiest way of achieving that, to me.

By the way, it's worth noting that while we're all still more or less
talking about using tombstones in simple scenarios where AtomPub is
already being used today, like keeping a feed reader store synchronized
with a blog, Steven and his team is thinking of more ambitious
scenarios, such as (but not limited to) multi-master replication with
eventual consistency.




From owner-atom-syntax@mail.imc.org Fri Dec 07 15:41:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0k0r-0006nP-Ei
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 15:41:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0k0p-0000F1-R9
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 15:41:33 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7KS3sV096987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 13:28:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB7KS3d6096986;
	Fri, 7 Dec 2007 13:28:03 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7KS2EV096979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 13:28:03 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 1818223E4A0;
	Fri,  7 Dec 2007 15:27:59 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James Holderness'" <j4_james@hotmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl>
Subject: RE: Tombstones
Date: Sat, 8 Dec 2007 03:27:50 +0700
Message-ID: <000001c8390f$ab7bd050$2501a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acg3C/QgH8LFTGNwSu2Ad3LoVblvzgCAJ3tQ
In-Reply-To: <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1


James Holderness wrote:
> James M Snell wrote:
> > What I personally would like to see is an evolved form of 
> > SSE produced on the standards track by a WG.  Tombstones
> > would be covered as part of that activity.
> 
> FWIW I'm not interested in anything more complicated than 
> your tombstone proposal from last year. I just want a simple 
> way to mark an item in a feed as deleted.
> 
> I was considering implementing something based on your last 
> draft, even if only for personal use. It would be preferable 
> if there was a real spec to work from, but there's no way I 
> would implement anything as complicated as SSE when all I 
> want to do is delete spam.

How do you suggest dealing with inappropriate data in the atom:id
element? Examples:

 <x:deleted
id='http://example.org/blog/i-am-so-high-at-work-right-now'/>
 <x:deleted
id='http://example.org/blog/im-getting-divorced-and-marrying-my-secretar
y'/>
 <x:deleted id='http://engizmet.org/{embargoed-iphone-news-item}'/>

(I've seen very similar entries posted and then deleted from actual
feeds.)

This still discloses a significant amount of information that the feed
author doesn't want disclosed after deleting the entry, and this kind of
disclosure is something that a non-technical blogger would not expect.
It would be better to avoid sending the tombstones to clients that
hadn't received the entries.

- Brian




From owner-atom-syntax@mail.imc.org Fri Dec 07 20:47:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0onA-000423-6Z
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 20:47:44 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0on8-00057S-KI
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 20:47:44 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB81ZQIm017725
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 18:35:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB81ZQBC017724;
	Fri, 7 Dec 2007 18:35:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc2-s14.bay0.hotmail.com (bay0-omc2-s14.bay0.hotmail.com [65.54.246.150])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB81ZQA0017718
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 18:35:26 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.19]) by bay0-omc2-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Fri, 7 Dec 2007 17:35:25 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 7 Dec 2007 17:35:25 -0800
Message-ID: <BAY141-DAV9A1AD45A46003A51D1E3EBE690@phx.gbl>
Received: from 85.211.242.20 by BAY141-DAV9.phx.gbl with DAV;
	Sat, 08 Dec 2007 01:35:22 +0000
X-Originating-IP: [85.211.242.20]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <BAY141-DAV108EB889BCAA9B37DA7876BE6E0@phx.gbl> <000001c8390f$ab7bd050$2501a8c0@Junk>
Subject: Re: Tombstones
Date: Sat, 8 Dec 2007 01:35:22 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 08 Dec 2007 01:35:25.0717 (UTC) FILETIME=[9B57D450:01C8393A]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32


Brian Smith wrote:
> How do you suggest dealing with inappropriate data in the atom:id
> element?

Blackmail?

> It would be better to avoid sending the tombstones to clients that
> hadn't received the entries.

Once the post itself has leaked, an inappropriate atom:id is the least of 
your problems. For someone to see your incriminating id they'd have to be 
looking at the source of the feed. And if they're that keen to find 
something incriminating, there's a good chance they would have logged the 
original post.

Anyone that thinks tombstones (in any form) can be used to destroy evidence 
of misposts is going to be sorely disappointed. They're a convenience for 
the reader not the author. The author gets to say: 'I don't think you should 
waste your time reading this post', but it's ultimately the reader's 
decision to follow that recommendation.

Regards
James




From owner-atom-syntax@mail.imc.org Fri Dec 07 23:06:45 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0qxh-0001i6-Gk
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 23:06:45 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0qxh-0003S4-4O
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 23:06:45 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB83rCRC025780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 20:53:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB83rCdU025779;
	Fri, 7 Dec 2007 20:53:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB83r0Dv025768
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 20:53:06 -0700 (MST)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.1904089334 for <atom-syntax@imc.org>; Sat, 08 Dec 2007 14:52:45 +1100
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 08 Dec 2007 14:52:50 +1100
Subject: Re: Tombstones
From: Eric Scheid <eric.scheid@ironclad.net.au>
To: Atom Syntax <atom-syntax@imc.org>
Message-ID: <C3806042.11F20B%eric.scheid@ironclad.net.au>
In-Reply-To: <BAY141-DAV9A1AD45A46003A51D1E3EBE690@phx.gbl>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


On 8/12/07 12:35 PM, "James Holderness" <j4_james@hotmail.com> wrote:

> Anyone that thinks tombstones (in any form) can be used to destroy evidence
> of misposts is going to be sorely disappointed. They're a convenience for
> the reader not the author. The author gets to say: 'I don't think you should
> waste your time reading this post', but it's ultimately the reader's
> decision to follow that recommendation.

/me still amused by "So-n-so would like to recall the message 'x'" emails

e.




From owner-atom-syntax@mail.imc.org Fri Dec 07 23:31:10 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0rLK-0003eU-I8
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 23:31:10 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0rLK-0004as-5D
	for atompub-archive@lists.ietf.org; Fri, 07 Dec 2007 23:31:10 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB84J2wi027996
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 21:19:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB84J2At027995;
	Fri, 7 Dec 2007 21:19:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB84IxQZ027988
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 21:19:02 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so808170rvf
        for <atom-syntax@imc.org>; Fri, 07 Dec 2007 20:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=fga65k8O9FiJHDXNfik4qizCuXzItVpHqXglUvXXnGw=;
        b=ZXBR1qp/jnmC3AoeR4wrVkhzFAx4rhsr5p0qrx6p8gmW8aSKQrDfM2EI25WkS1sZp59jkZmdEl6yIhWOqQ2gBqC1Kr8kINH58QTe41I0/x8sx39HWNh6DlFCzPH9p9ZUXMCeE9XTFh/nIXDOx9F/nrvkU/DNftKeCKEOz6QNCUo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=P2tAUdzB9fCET5/zKdeQsyKlZMy0XERqFuOPva/G54m9xJotc6WKiXgu+XwYwilFMVXRgADD1PAimxKsroCRC/4kPkGQ31nEnjBr+0p3uLwE6c3GCM8r4HUOwz/15XXTgv4pvgRz1i3kvp4Z3Zis9Pk7Bo0TK56vlWIDSx6zR04=
Received: by 10.141.20.7 with SMTP id x7mr3108893rvi.1197087539231;
        Fri, 07 Dec 2007 20:18:59 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id k19sm837917rvb.2007.12.07.20.18.57
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 07 Dec 2007 20:18:58 -0800 (PST)
Message-ID: <475A1B28.8050707@gmail.com>
Date: Fri, 07 Dec 2007 20:18:48 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steven Lees <Steven.Lees@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A3186@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8



Steven Lees wrote:
> [snip]
> Agreed. But with the <x:deleted> element, you're still passing unnecessary 
> info to the client. If you go and delete ALL of the entries from the feed, 
> then the client receives a feed with nothing but tombstones, which it didn't 
> want in the first place. In that case, asking the client to opt-in seems like 
> a pretty good idea.
> [snip]

Perhaps, but there's really not a lot of harm in that; the feed could
end up having lots of information any given client may not find useful.
And if an opt-in mechanism really is needed, one could be used just as
easily with x:deleted as it could with tombstone entries -- that is, the
choice of how to represent the tombstone is orthogonal to the mechanism
clients use to request tombstones.

- James




From owner-atom-syntax@mail.imc.org Sat Dec 08 00:31:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0sHd-0004BE-3N
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:31:25 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0sHa-0008A8-Q3
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:31:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85G47S030520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 22:16:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB85G4pC030519;
	Fri, 7 Dec 2007 22:16:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85G3lJ030513
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 22:16:03 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by py-out-1112.google.com with SMTP id u77so2072034pyb
        for <atom-syntax@imc.org>; Fri, 07 Dec 2007 21:16:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=47rd2qps18Jvtid1MzKJm5nqpzU1YWSuNBsk8LVeXrQ=;
        b=n67/LZCt0zI+u+medD5IUn69SZQZLG2clsoiL58K6bpuNTKD87iEOITgR0RIXKo+PFBCU0k4jcbKK0UJmS3KqosGVpkXsRH3hy+lC+hgEFuvMyPylZRxkXkVf7FeM2YEI8wIm+EogWj6H4IQIcTNv0kSytblOd1TTt3LCQyTk/w=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=P9/5InwbL3vwqFUecqoVlTyc73DL2slh6aiNuR3k4wD2/sG+F1JB0VhRbLliqr7RRVJVxNnndbAdfoRUb440iuNaxvetfhkgllI7R6SgVjreIHYwPdTAK6W0Aur+BIw+EXrt4ZZzuQC2HPjRuYaFIFFMKJAnq+JB9DmxSsSBwwQ=
Received: by 10.35.102.1 with SMTP id e1mr4359121pym.1197090962503;
        Fri, 07 Dec 2007 21:16:02 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id p4sm918844nzc.2007.12.07.21.16.01
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 07 Dec 2007 21:16:01 -0800 (PST)
Message-ID: <475A288F.10301@gmail.com>
Date: Fri, 07 Dec 2007 21:15:59 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Feed Paging for Efficient Feed Synchronization
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk>
In-Reply-To: <002001c8388a$90c65b20$2501a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


Excellent points.  The primary issue for me is the fact that the set of
entries we're synchronizing has to remain stable throughout the
synchronization process or else we risk race conditions and a variety of
 possible conflicts.  If the stability of the pages can be reasonably
guaranteed then paging is acceptable.

- James

Brian Smith wrote:
> James M Snell wrote:
>> 400 entries over 20 pages:
> ...
>> 400 entries in a single feed:
> 
> If the server can rely on the client handling 400 entries per feed, then it would not need to split the feed into twenty pages; only two pages would be needed. Conversely, if the client cannot handle a response with 400 entries in it, then the single-page-result query mechanism will always fail.
> 
> To see this more clearly, we should test the performance of ten clients simultaneously syncing 10,000 10KB entries using each approach, using a reasonable page size (say 100K compressed, to stay within the limits of many mobile devices), with caching reverse proxy in front of the AtomPub servers, and a caching proxy in front of the client, with a new entry inserted in between each client request. The single-page-result mechanism would have to generate and transmit ten unique 100MB documents, that many desktop clients wouldn't even be able to handle, whereas the paging mechanism would be able to offload most of its work to the client-side caching proxy server and still interoperate with most mobile devices.
> 
> I think we could also run the paging version from my $6.00/month shared hosting account (a CGI script gets 6 seconds to run before its process gets killed). I'm pretty sure that wouldn't be possible with the single-page-result implementation.
> 
> To summarize, the single-page-result solution might have better raw performance when not resource constrained, but the paging mechanism offers better cachability and scales up and down nicely. That is why I prefer the paging mechanism.
> 
> - Brian
> 
> 




From owner-atom-syntax@mail.imc.org Sat Dec 08 00:34:21 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0sKT-0007JE-BJ
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:34:21 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0sKS-0008IO-SI
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:34:21 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85PQc2030978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 22:25:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB85PQKP030977;
	Fri, 7 Dec 2007 22:25:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85POBu030967
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 22:25:25 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by py-out-1112.google.com with SMTP id u77so2075093pyb
        for <atom-syntax@imc.org>; Fri, 07 Dec 2007 21:25:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=xG9MNVx6rzPuarxHCZpIeqWGRRwCi9iyU1hNeRwA0bc=;
        b=IiMt+pxo+aRRyUy/KOgO+fr12ZhO/DrWuNTmwlCA8w0FvbcyxqC2BVth+Cr0W8STYWdOdXf29CePAN/e4Ev3cueOdiZ55z/4tN41RP1NfUzDxR0d+EXO+FB96NwTY25KJbgvuprCKhGCAa3Nz+Sf4V1O8AyXAsOaPfhZMku5PDw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=sw0kkR3u0Fj/qG84bCl6vChKjxSUy+kGWuDUOKx6sql0A5kRbk3I/OBhRvW4Z+OHP8mRYbAhpOUDZhv088C/MBw5gQ5PoAngDx/2RDm5ojIjaR+b0+r4LU0hxSFbL5qI6lbOMuJTNG5lnR00vFJnRNoky1nGc+273u71Ru0EYbw=
Received: by 10.35.98.3 with SMTP id a3mr4375245pym.1197091524098;
        Fri, 07 Dec 2007 21:25:24 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id 6sm2988890nzn.2007.12.07.21.25.22
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 07 Dec 2007 21:25:23 -0800 (PST)
Message-ID: <475A2AC1.7050703@gmail.com>
Date: Fri, 07 Dec 2007 21:25:21 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Cheng <Joe.Cheng@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>,
        Steven Lees <Steven.Lees@microsoft.com>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
In-Reply-To: <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9


This could probably help:

  http://tools.ietf.org/html/draft-snell-http-prefer-00

Request:
========
GET /feed
Host: example.org
Prefer: feedsync-tombstones

Response:
=========
HTTP/1.1 200 OK
Vary: Prefer

...

- James

Joe Cheng wrote:
>> Now, Steven indicates that their implementation will not include the
>> tombstone by default. Clients that want tombstones would have to ask for
>> them explicitly.
> 
> This doesn't belong in the implementation, it belongs in the spec.
> (Would this discussion even be taking place if opt-in had been in the
> spec from the start?) I have advocated HTTP headers for opt-in the
> past, but to avoid caching problems it seems like a link relation would
> be better.
> 
> I like the idea of building tombstone-aware clients on top of client
> libraries that are not tombstone aware. The inline opt-in model seems
> like the easiest way of achieving that, to me.
> 
> By the way, it's worth noting that while we're all still more or less
> talking about using tombstones in simple scenarios where AtomPub is
> already being used today, like keeping a feed reader store synchronized
> with a blog, Steven and his team is thinking of more ambitious
> scenarios, such as (but not limited to) multi-master replication with
> eventual consistency.
> 




From owner-atom-syntax@mail.imc.org Sat Dec 08 00:52:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J0scT-0001zX-1g
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:52:57 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J0scS-0000w1-I3
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 00:52:57 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85cFeH031790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Dec 2007 22:38:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB85cF9K031789;
	Fri, 7 Dec 2007 22:38:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB85cEpf031783
	for <atom-syntax@imc.org>; Fri, 7 Dec 2007 22:38:15 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by py-out-1112.google.com with SMTP id u77so2079281pyb
        for <atom-syntax@imc.org>; Fri, 07 Dec 2007 21:38:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=atIlrMxSF+qeQ1jFKXnqx81hJwtWHQBxQy7rngJgJJc=;
        b=LLKPxFcminr/lJbSJQ5SwaXxb1O890GF1JuCDyLLbyxeEVCILUobrJ09TPDBlJWu7cShSNex8dIDoWCzjQ6iEn2nTEyVkPbmZSukW+d3eLFdLqI+Hy2EYTGQ5TX1dnohgwNSLKh0nDOD9xeSbbAiqeDAoepstEAA32HswfMwrl8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=WIFJ1277WtyTyJSrsXypmp7udE79umTlYSM783ihoFZpYZ4HycVpD+67lXz7WrkbZyZI/uDFrASZv1iTAp3NYyUaF5FZSKydv9at+k2P8tlDtDtgugyb3juIWjfcPacBrNgf2VGqtmeq6W9HudUMolnW2GnWy/pDVDrQutvQVdQ=
Received: by 10.64.131.4 with SMTP id e4mr8312381qbd.1197092293448;
        Fri, 07 Dec 2007 21:38:13 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id v76sm2818090nzh.2007.12.07.21.38.11
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 07 Dec 2007 21:38:12 -0800 (PST)
Message-ID: <475A2DC2.7020407@gmail.com>
Date: Fri, 07 Dec 2007 21:38:10 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Cheng <Joe.Cheng@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>,
        Steven Lees <Steven.Lees@microsoft.com>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com> <475A2AC1.7050703@gmail.com>
In-Reply-To: <475A2AC1.7050703@gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465


Updated version to fix a few typos in the original....

  http://www.ietf.org/internet-drafts/draft-snell-http-prefer-01.txt

- James

James M Snell wrote:
> This could probably help:
> 
>   http://tools.ietf.org/html/draft-snell-http-prefer-00
> 
> Request:
> ========
> GET /feed
> Host: example.org
> Prefer: feedsync-tombstones
> 
> Response:
> =========
> HTTP/1.1 200 OK
> Vary: Prefer
> 
> ...
> 
> - James
> 
> Joe Cheng wrote:
>>> Now, Steven indicates that their implementation will not include the
>>> tombstone by default. Clients that want tombstones would have to ask for
>>> them explicitly.
>> This doesn't belong in the implementation, it belongs in the spec.
>> (Would this discussion even be taking place if opt-in had been in the
>> spec from the start?) I have advocated HTTP headers for opt-in the
>> past, but to avoid caching problems it seems like a link relation would
>> be better.
>>
>> I like the idea of building tombstone-aware clients on top of client
>> libraries that are not tombstone aware. The inline opt-in model seems
>> like the easiest way of achieving that, to me.
>>
>> By the way, it's worth noting that while we're all still more or less
>> talking about using tombstones in simple scenarios where AtomPub is
>> already being used today, like keeping a feed reader store synchronized
>> with a blog, Steven and his team is thinking of more ambitious
>> scenarios, such as (but not limited to) multi-master replication with
>> eventual consistency.
>>
> 




From owner-atom-syntax@mail.imc.org Sat Dec 08 10:37:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J11kd-0001Ja-44
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:37:59 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J11kb-00079k-DC
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:37:59 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FOT5b072053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Dec 2007 08:24:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8FOTM2072052;
	Sat, 8 Dec 2007 08:24:29 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FOQDm072042
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 8 Dec 2007 08:24:29 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 554EA23E4B8;
	Sat,  8 Dec 2007 10:24:23 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James M Snell'" <jasnell@gmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com> <475A2AC1.7050703@gmail.com> <475A2DC2.7020407@gmail.com>
Subject: RE: Tombstones
Date: Sat, 8 Dec 2007 22:24:11 +0700
Message-ID: <003001c839ae$6d1fea40$2101a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <475A2DC2.7020407@gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg5XLn5LZPr0ItFSY2vCT29D/7d1QAT9ZJQ
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32


James M Snell wrote:
> 
> Updated version to fix a few typos in the original....
> 
>   http://www.ietf.org/internet-drafts/draft-snell-http-prefer-01.txt
> 

This seems to overlap the functionality of the Opt header from RFC 2774
[1], which is already registered [2], and which I've seen in actual use.

Anyway, I still think that adding a parameter to the
application/atom+xml MIME type makes the most sense, because FeedSync is
effectively a "must-understand" extension, and the "Accept" header is
already used for content negotiation.

Failing that, how about the "Accept-Feature" header from RFC 2295 [3],
which is also already registered [2]?.

[1] http://rfc.net/rfc2774.html#s4.1
[2] http://www.iana.org/assignments/message-headers/perm-headers.html
[3] http://rfc.net/rfc2295.html#s8.2

- Brian




From owner-atom-syntax@mail.imc.org Sat Dec 08 10:39:20 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J11lw-0004Fe-TA
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:39:20 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J11lv-0007Bm-HN
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:39:20 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FUMHF072387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Dec 2007 08:30:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8FUMdo072386;
	Sat, 8 Dec 2007 08:30:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FULkO072380
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 8 Dec 2007 08:30:22 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 3B7F323E4C0;
	Sat,  8 Dec 2007 10:30:17 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Joe Cheng'" <Joe.Cheng@microsoft.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
Subject: RE: Tombstones
Date: Sat, 8 Dec 2007 22:30:19 +0700
Message-ID: <005301c839af$4005ef90$2101a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg4YBz0YkLqTeLfQgOBv2mQ/9q8BgAnAE7QACy1CZA=
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


Joe Cheng wrote:
> > Now, Steven indicates that their implementation will not 
> > include the tombstone by default. Clients that want
> > tombstones would have to ask for them explicitly.
> 
> This doesn't belong in the implementation, it belongs in the spec.
> (Would this discussion even be taking place if opt-in had 
> been in the spec from the start?) I have advocated HTTP 
> headers for opt-in the past, but to avoid caching problems it 
> seems like a link relation would be better.

What kind of caching problems are you thinking of?

- Brian




From owner-atom-syntax@mail.imc.org Sat Dec 08 10:42:09 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J11of-00063Q-8x
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:42:09 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J11oe-0007F3-TY
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 10:42:09 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FQbxR072158
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Dec 2007 08:26:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8FQbxw072157;
	Sat, 8 Dec 2007 08:26:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FQaDp072151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 8 Dec 2007 08:26:36 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 03A1C23E4B8;
	Sat,  8 Dec 2007 10:26:34 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'James M Snell'" <jasnell@gmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <000001c83808$3dbed6f0$2501a8c0@Junk> <47581E35.4050103@gmail.com> <000601c8382b$99961c40$2501a8c0@Junk> <475834B5.2080203@gmail.com> <000a01c8383c$bcce0270$2501a8c0@Junk> <475855A5.5010902@gmail.com> <002001c8388a$90c65b20$2501a8c0@Junk> <475A288F.10301@gmail.com>
Subject: RE: Feed Paging for Efficient Feed Synchronization
Date: Sat, 8 Dec 2007 22:26:36 +0700
Message-ID: <003a01c839ae$bac27ce0$2101a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <475A288F.10301@gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Acg5Wj3+rlAyWhqIQW+wBChmvn6aBQAVEGKg
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


James M Snell wrote:
> Excellent points.  The primary issue for me is the fact that 
> the set of entries we're synchronizing has to remain stable 
> throughout the synchronization process or else we risk race 
> conditions and a variety of  possible conflicts.  If the 
> stability of the pages can be reasonably guaranteed then 
> paging is acceptable.

I'm pretty sure I agree with you, but please define "stable".

- Brian




From Stafford777@nationalagroinds.com Sat Dec 08 23:14:23 2007
Return-path: <Stafford777@nationalagroinds.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1DYd-0007v2-8C
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 23:14:23 -0500
Received: from bb121-7-254-11.singnet.com.sg ([121.7.254.11] helo=bbcache155-93.singnet.com.sg)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J1DYc-0004K8-C2
	for atompub-archive@lists.ietf.org; Sat, 08 Dec 2007 23:14:23 -0500
Received: from user-nhwtxz66ou
	by nationalagroinds.com with ASMTP id FBB250C2
	for <atompub-archive@lists.ietf.org>; Sun, 9 Dec 2007 12:14:53 +0800
Received: from user-nhwtxz66ou ([149.144.99.102])
	by nationalagroinds.com with ESMTP id D9D5D01A14D1
	for <atompub-archive@lists.ietf.org>; Sun, 9 Dec 2007 12:14:53 +0800
Message-ID: <E317853F.CEAC198F@nationalagroinds.com>
Date: Sun, 9 Dec 2007 12:14:24 +0800
From: "Stafford Hubel" <Stafford777@nationalagroinds.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: nlowsdoo
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
give her a satisfying smile everytime you fuck <a href="http://igvalic.com/">http://igvalic.com/</a><br>
</html>



From jjueh@MAXENGR.COM Mon Dec 10 06:30:29 2007
Return-path: <jjueh@MAXENGR.COM>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1gqD-0007KR-63
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 06:30:29 -0500
Received: from hfh114.internetdsl.tpnet.pl ([79.187.137.114])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J1gqC-0000rK-JI
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 06:30:29 -0500
Received: from bytom-handlowcy
	by MAXENGR.COM with ASMTP id 03079DFE
	for <atompub-archive@lists.ietf.org>; Mon, 10 Dec 2007 12:30:58 +0100
Received: from bytom-handlowcy ([156.168.183.133])
	by MAXENGR.COM with ESMTP id 418C1EF052B4
	for <atompub-archive@lists.ietf.org>; Mon, 10 Dec 2007 12:30:58 +0100
Message-ID: <1AFAB550.8F4B50D1@MAXENGR.COM>
Date: Mon, 10 Dec 2007 12:30:36 +0100
From: "Hanyu jj" <jjueh@MAXENGR.COM>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: eifern
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.5 (++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Tired of taking medicine pills to make your "willie" bigger? Try this. <a href="http://aqcyu.com/">http://aqcyu.com/</a><br>
</html>



From owner-atom-syntax@mail.imc.org Mon Dec 10 06:32:34 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1gsE-0002fp-43
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 06:32:34 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1gsC-0006aI-D9
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 06:32:34 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBABFEqD086414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 04:15:14 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBABFEOk086413;
	Mon, 10 Dec 2007 04:15:14 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBABFDgD086406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 04:15:13 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [127.0.0.1] (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 0AFD6D05A6;
	Mon, 10 Dec 2007 06:15:10 -0500 (EST)
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com> <001601c8382e$db559810$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <86E8A8ED-3C79-49A2-924E-DCD94EFF0440@mnot.net>
Cc: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Content-Transfer-Encoding: 7bit
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: Tombstones
Date: Mon, 10 Dec 2007 22:15:04 +1100
To: Steven Lees <Steven.Lees@microsoft.com>
X-Mailer: Apple Mail (2.752.3)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5


Please, please don't use a media type parameter for this; it works  
fine for the first extension or two that wants to do this, and scales  
horribly after that.

Cheers,


On 07/12/2007, at 9:09 AM, Steven Lees wrote:

>> The most obvious way to do it would be to add a parameter to the
>> application/atom+xml mime type, and use that parameter along with a
>> strong "q" parameter in an Accept header:
>>
>>    Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
>>            application/atom+xml;q=0.9
>
> Thanks, seems like a good suggestion. Presumably the client could  
> specify:
>
>         Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1
>
> if it only wants the feed with tombstones. And then on the return  
> trip, the server uses the same Content-Type:
>
> Content-Type: application/atom+xml;type=feed;FeedSync=1.0
>
> One potential drawback is that in both cases, the entity returned  
> is actually a valid Atom feed. It might be nice to have the  
> "tombstone-ness" reflected in a way that doesn't alter the Content- 
> Type.


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Mon Dec 10 08:12:54 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1iRK-0005bo-Rc
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 08:12:54 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1iRI-0000MZ-Cz
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 08:12:54 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBACwN0r094928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 05:58:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBACwNU5094927;
	Mon, 10 Dec 2007 05:58:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from joe.greenbytes.de (mail.greenbytes.de [217.91.35.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBACwIt6094905
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 05:58:19 -0700 (MST)
	(envelope-from stefan.eissing@greenbytes.de)
Received: from [192.168.1.6] (unknown [192.168.1.6])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id CB714DF755;
	Mon, 10 Dec 2007 13:58:16 +0100 (CET)
In-Reply-To: <4758833F.9050404@gmail.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <38598213-008E-4BD6-9C32-BE363C69B452@greenbytes.de>
Cc: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Subject: Re: Tombstones
Date: Mon, 10 Dec 2007 13:58:09 +0100
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBACwKt6094908
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBACwN0r094928
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78


I realize that there is huge deployed infrastructure where you want =20
to introduce this extension. And maybe it is a good idea to tip-toe =20
around and show tombstones only to people who ask for it, etc. From =20
the technical point of view I think this would do atom a disservice. =20
The sooner atom feed readers learn to handle extensions properly, the =20
better for the whole protocol suite.

As Mark noted, the trick with Accept headers only works for few =20
possible extensions. A good, modern client would some day have to =20
supply either a long list of extensions it understands or start some =20
sort of negotation/discovery thing with every server (once a day or =20
once a week?). "Hey, I know about tombstones and graveyard and =20
afterlife extensions. Which is the feed url I should really use?"

The alternative I see is to push extensions to client so that they =20
learn how to deal with the unkown ones. The earlier the better, =20
future extensions then have it easy. Use a real XML parser, look at =20
element names and namespaces.

James second example - <x:deleted> intermixed with <entry> - sounds =20
superior to the first style which basically reads to me "here is the =20
list of entries, except this one is not, if you know what i mean".

Cheers, Stefan

Am 07.12.2007 um 00:18 schrieb James M Snell:
> Using the x:deleted tombstone element, on the other hand, the spam =20
> entry
> only shows up once, at a maximum. Readers that do not understand the
> tombstone element would act no differently than they currently do and
> users should not see any change in current feed reader behavior.


>
> Example: we have a feed with two entries. There are two feed reader
> clients, neither of which know about tombstones.  Client A requests =20
> the
> feed and sees both entries.
>
>   <feed>
>     ...
>     <entry>
>       <id>tag:example.org,2007:1</id>
>       ...
>     </entry>
>     <entry>
>       <id>tag:example.org,2007:2</id>
>       ...
>     </entry>
>   </feed>
>
> Entry 1 is then deleted.  Using the tombstone-inside-entry =20
> approach, the
> feed becomes
>
>   <feed>
>     ...
>     <entry>
>       <id>tag:example.org,2007:1</id>
>       <x:deleted />
>       ...
>     </entry>
>     <entry>
>       <id>tag:example.org,2007:2</id>
>       ...
>     </entry>
>   </feed>
>
> Client A gets the feed and still sees two entries, one of which is
> marked as being updated.
>
> Client B comes along and requests the feed and see two entries, =20
> both of
> which are new to it but one of which doesn't actually exist.  Why =20
> should
> Client B have to see that entry at all?  If the entry was deleted, it
> shouldn't be in the feed.
>
> Now use the separate tombstone element,
>
>   <feed>
>     ...
>     <x:deleted>
>       <id>tag:example.org,2007:1</id>
>     </x:deleted>
>     <entry>
>       <id>tag:example.org,2007:2</id>
>       ...
>     </entry>
>   </feed>
>
> Client A continues to operate as it always has when an entry that was
> once in the feed suddenly isn't and Client B never has to see the
> deleted entry at all.  That makes a whole lot more sense to me.
>
> Now, Steven indicates that their implementation will not include the
> tombstone by default. Clients that want tombstones would have to =20
> ask for
> them explicitly.  While that would solve the problem, using the
> tombstone element would avoid the need to have that kind of =20
> negotiation
> mechanism at all.
>
> - James
>
> Mark Nottingham wrote:
>>
>> Argh, yeah, good point. This depends on the details of how the =20
>> perceive
>> change etc., of course, but I imagine most would show them twice.
>>
>> OTOH, this may be good incentive for aggregators to start respecting
>> tombstones :)
>>
>> Cheers,
>>
>>
>> On 06/12/2007, at 11:17 AM, Brian Smith wrote:
>>
>>> Mark Nottingham wrote:
>>>> Hmm. Seems like SSE tombstones are good enough for the use
>>>> case I illustrated; it's acceptable that clients who don't
>>>> understand them ignore them (they'll just see more spam), and
>>>> the rest of the entry isn't needed (it's spam, after all).
>>>
>>> They will see 2X as much spam: once, when they mark the original =20
>>> spam as
>>> read, and then they will see the tombstone show up as an updated =20
>>> entry.
>>> So, effectively, spam is up to twice as bad with the SSE =20
>>> tombstones as
>>> it is without them.
>>>
>>> - Brian
>>>
>>
>>
>> --=20
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>

--
<green/>bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany
Amtsgericht M=FCnster: HRB5782








From owner-atom-syntax@mail.imc.org Mon Dec 10 12:24:07 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1mMR-00035u-Ek
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 12:24:07 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1mMP-0006Tn-3V
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 12:24:07 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAH9VwC019456
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 10:09:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAH9VBD019455;
	Mon, 10 Dec 2007 10:09:31 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAH9UVQ019446
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 10:09:30 -0700 (MST)
	(envelope-from Joe.Cheng@microsoft.com)
Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Mon, 10 Dec 2007 09:09:29 -0800
Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.158]) by
 tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Mon,
 10 Dec 2007 09:09:29 -0800
From: Joe Cheng <Joe.Cheng@microsoft.com>
To: James M Snell <jasnell@gmail.com>
CC: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>,
        Steven Lees <Steven.Lees@microsoft.com>
Date: Mon, 10 Dec 2007 09:09:27 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg5XIdvAh41snI8QOOpYoUwKJEpGwB8n5FQ
Message-ID: <EF14FE208FC8364F94E8A58EF085979A210EA8D909@NA-EXMSG-C109.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com>
 <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
 <475A2AC1.7050703@gmail.com> <475A2DC2.7020407@gmail.com>
In-Reply-To: <475A2DC2.7020407@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBAH9UVP019448
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89


James M Snell wrote:
> This could probably help:
>
>   http://tools.ietf.org/html/draft-snell-http-prefer-00

Ah, I was not aware of the Vary field. Brian, never mind about caching
issues, as they are addressed by Vary.

(The things I learn about HTTP from this list...)




From owner-atom-syntax@mail.imc.org Mon Dec 10 13:36:55 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1nUt-0001vL-Df
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 13:36:55 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1nUr-0008NR-4F
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 13:36:55 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIEvhs027286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 11:14:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAIEvHC027285;
	Mon, 10 Dec 2007 11:14:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s24.bay0.hotmail.com (bay0-omc1-s24.bay0.hotmail.com [65.54.246.96])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIEuJT027278
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 11:14:56 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.21]) by bay0-omc1-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Mon, 10 Dec 2007 10:14:55 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 10 Dec 2007 10:14:55 -0800
Message-ID: <BAY141-DAV115A94AFB4DCEAD54B10B9BE6B0@phx.gbl>
Received: from 85.211.248.249 by BAY141-DAV11.phx.gbl with DAV;
	Mon, 10 Dec 2007 18:14:50 +0000
X-Originating-IP: [85.211.248.249]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com> <475A2AC1.7050703@gmail.com> <475A2DC2.7020407@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D909@NA-EXMSG-C109.redmond.corp.microsoft.com>
Subject: Re: Tombstones
Date: Mon, 10 Dec 2007 18:14:49 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 10 Dec 2007 18:14:55.0745 (UTC) FILETIME=[91176710:01C83B58]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199


Joe Cheng wrote:
> Ah, I was not aware of the Vary field. Brian, never mind about caching
> issues, as they are addressed by Vary.

I thought the problem was that Vary wasn't always well supported by proxies. 
I don't remember the issues exactly, but I'm sure Mark did some research 
into this.

Regards
James




From owner-atom-syntax@mail.imc.org Mon Dec 10 15:42:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1pSR-0000ts-TF
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 15:42:31 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1pSR-0003fr-CN
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 15:42:31 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKBh9A039122
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 13:11:43 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAKBhva039121;
	Mon, 10 Dec 2007 13:11:43 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKBeK1039110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 13:11:43 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.75.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id BD56623E4AF
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 15:11:38 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com> <475A2AC1.7050703@gmail.com> <475A2DC2.7020407@gmail.com> <EF14FE208FC8364F94E8A58EF085979A210EA8D909@NA-EXMSG-C109.redmond.corp.microsoft.com> <BAY141-DAV115A94AFB4DCEAD54B10B9BE6B0@phx.gbl>
Subject: RE: Tombstones
Date: Tue, 11 Dec 2007 03:11:38 +0700
Message-ID: <006601c83b68$e173a830$2101a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <BAY141-DAV115A94AFB4DCEAD54B10B9BE6B0@phx.gbl>
Thread-Index: Acg7Wj+W/nq4Gja2RfKvlja8MfCOXgADQXWw
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb


James Holderness wrote:
> Joe Cheng wrote:
> > Ah, I was not aware of the Vary field. Brian, never mind 
> > about caching issues, as they are addressed by Vary.
> 
> I thought the problem was that Vary wasn't always well 
> supported by proxies. I don't remember the issues exactly, but
> I'm sure Mark did some research into this.

If content negotiation is going to be used at all, then "Vary: Accept"
header is more likely to work correctly than anything else besides
"Vary: Content-Encoding".

Regardless of whether a media type parameter is added for FeedSync,
content negotiation should not be required. I think it is just an issue
of whether we want to have:

   <!-- register a media type parameter for FeedSync -->
   <link rel='alternate' href='...'
         type='application/atom+xml;FeedSync=1.0'/>

Or:

   <!-- register an Atom link relation for FeedSync -->
   <link rel='FeedSync' href='...'
         type='application/atom+xml'/>

Or both:
   
   <link rel='FeedSync' href='...'
         type='application/atom+xml;FeedSync=1.0'/>

Or neither:

   <!-- Don't register anything -->
   <link rel='http://feedsync.org/blah' href='...'
         type='application/atom+xml'/>

- Brian




From owner-atom-syntax@mail.imc.org Mon Dec 10 20:21:22 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1toI-0001QR-5J
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 20:21:22 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1toH-000257-MY
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 20:21:22 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBB19w93063116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 18:09:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBB19w1Y063115;
	Mon, 10 Dec 2007 18:09:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBB19vfX063108
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 18:09:58 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Mon, 10 Dec 2007 17:09:56 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) with mapi; Mon, 10
 Dec 2007 17:09:56 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Mon, 10 Dec 2007 17:09:55 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg7HfmM2TOOP0dNQ2OwvSEcDzOjbAAdCGiQ
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE83CA18@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <001601c8382e$db559810$2501a8c0@Junk>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A2F2C@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <86E8A8ED-3C79-49A2-924E-DCD94EFF0440@mnot.net>
In-Reply-To: <86E8A8ED-3C79-49A2-924E-DCD94EFF0440@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBB19wfW063110
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


Mark Nottingham wrote:

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Monday, December 10, 2007 3:15 AM
> To: Steven Lees
> Cc: Brian Smith; 'Atom-Syntax'
> Subject: Re: Tombstones
>
> Please, please don't use a media type parameter for this; it works
> fine for the first extension or two that wants to do this, and scales
> horribly after that.
>
> Cheers,
>
>
> On 07/12/2007, at 9:09 AM, Steven Lees wrote:
>
> >> The most obvious way to do it would be to add a parameter to the
> >> application/atom+xml mime type, and use that parameter along with a
> >> strong "q" parameter in an Accept header:
> >>
> >>    Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1,
> >>            application/atom+xml;q=0.9
> >
> > Thanks, seems like a good suggestion. Presumably the client could
> > specify:
> >
> >         Accept: application/atom+xml;type=feed;FeedSync=1.0;q=1
> >
> > if it only wants the feed with tombstones. And then on the return
> > trip, the server uses the same Content-Type:
> >
> > Content-Type: application/atom+xml;type=feed;FeedSync=1.0
> >
> > One potential drawback is that in both cases, the entity returned
> > is actually a valid Atom feed. It might be nice to have the
> > "tombstone-ness" reflected in a way that doesn't alter the Content-
> > Type.

Thanks for the guidance. Is there a longer form explanation anywhere of how/why this breaks down? And is there any existing header that is better suited to this purpose?

Steven




From owner-atom-syntax@mail.imc.org Mon Dec 10 20:21:22 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J1toI-0001Qd-6y
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 20:21:22 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J1toH-000259-Ni
	for atompub-archive@lists.ietf.org; Mon, 10 Dec 2007 20:21:22 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBB16Nh2062933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Dec 2007 18:06:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBB16NNu062932;
	Mon, 10 Dec 2007 18:06:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBB16LFk062926
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Mon, 10 Dec 2007 18:06:22 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Mon, 10 Dec 2007 17:06:20 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Mon,
 10 Dec 2007 17:06:20 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James M Snell <jasnell@gmail.com>, Joe Cheng <Joe.Cheng@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Mon, 10 Dec 2007 17:06:19 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg5XIcp/JL9wfQpQz6E7uisf0RGZgCNR5HA
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE83CA0A@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <7DB22ECE-61E9-40F2-8120-77D472C280FB@mnot.net> <4758833F.9050404@gmail.com>
 <EF14FE208FC8364F94E8A58EF085979A210EA8D482@NA-EXMSG-C109.redmond.corp.microsoft.com>
 <475A2AC1.7050703@gmail.com> <475A2DC2.7020407@gmail.com>
In-Reply-To: <475A2DC2.7020407@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBB16MFj062927
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b


James Snell wrote:

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Friday, December 07, 2007 9:38 PM
> To: Joe Cheng
> Cc: Mark Nottingham; Brian Smith; 'Atom-Syntax'; Steven Lees
> Subject: Re: Tombstones
>
> Updated version to fix a few typos in the original....
>
>   http://www.ietf.org/internet-drafts/draft-snell-http-prefer-01.txt
>
> - James
>
> James M Snell wrote:
> > This could probably help:
> >
> >   http://tools.ietf.org/html/draft-snell-http-prefer-00
> >
> > Request:
> > ========
> > GET /feed
> > Host: example.org
> > Prefer: feedsync-tombstones
> >
> > Response:
> > =========
> > HTTP/1.1 200 OK
> > Vary: Prefer
> >
> > ...
> >
> > - James

The Prefer: header looks like it would work. It is a problem, though, that the server isn't required to follow the request? In practice it seems like it could still work, because the server has no reason not to provide tombstones, if they are asked for.

Steven




From Sardielowyk@untealthen.com Tue Dec 11 04:45:40 2007
Return-path: <Sardielowyk@untealthen.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J21gK-0004L8-0y
	for atompub-archive@lists.ietf.org; Tue, 11 Dec 2007 04:45:40 -0500
Received: from e178078047.adsl.alicedsl.de ([85.178.78.47])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J21gJ-0000d6-6G
	for atompub-archive@lists.ietf.org; Tue, 11 Dec 2007 04:45:39 -0500
Received: from aliu-lfv6buoh0n ([125.161.56.51] helo=aliu-lfv6buoh0n)
	by e178078047.adsl.alicedsl.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1VkzPz-000OCO-vk
	for atompub-archive@lists.ietf.org; Tue, 11 Dec 2007 10:41:38 +0100
Message-ID: <153053F6.23633165@untealthen.com>
Date: Tue, 11 Dec 2007 10:40:59 +0100
From: "marcel Sardielo" <Sardielowyk@untealthen.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: rodeos
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.5 (++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
studies do show that women do love big dicks <a href="http://www.genitahospital.com/">http://www.genitahospital.com/</a><br>
</html>



From owner-atom-syntax@mail.imc.org Tue Dec 11 22:05:11 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2HuI-0002CP-W6
	for atompub-archive@lists.ietf.org; Tue, 11 Dec 2007 22:05:10 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2HuH-0002Qc-Ch
	for atompub-archive@lists.ietf.org; Tue, 11 Dec 2007 22:05:10 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC2q12w075675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Dec 2007 19:52:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBC2q1ie075674;
	Tue, 11 Dec 2007 19:52:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBC2q0ZZ075657
	for <atom-syntax@imc.org>; Tue, 11 Dec 2007 19:52:00 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 12 Dec 2007 02:51:58 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp002) with SMTP; 12 Dec 2007 03:51:58 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX19iCuIkhb1imvGl3snUkaEFhM2tfSU4Xh5YuGM1wB
	1DjuQaRz34C94c
Date: Wed, 12 Dec 2007 03:51:57 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
Message-ID: <20071212025157.GA30766@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com> <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBC2q12w075675
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


* James Holderness <j4_james@hotmail.com> [2007-12-07 03:55]:
> Steven Lees wrote:
>> On the initial sync of a feed, most sync-aware clients will
>> still want to ask for the feed without tombstones, so that
>> they can just get the non-deleted items.
>
> I wouldn't think that's worth the effort. Tombstones should be
> small enough and infrequent enough that I wouldn't care about
> getting them on an initial sync.

It=E2=80=99s pointless either way. You might avoid receiving a bunch of
irrelevant tombstones on the first fetch =E2=80=93 only to end up getting
them all on your second fetch.

You could invest somewhat significant extra complexity to make it
actually work=E2=80=A6 all so you can avoid a handful of tombstones for a
short period after subscribing to a feed. Ahem.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Dec 12 00:43:19 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2KNL-0004R8-QY
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 00:43:19 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2KNL-000628-8c
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 00:43:19 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC5NjfG085107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Dec 2007 22:23:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBC5NjHT085106;
	Tue, 11 Dec 2007 22:23:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC5Nixh085100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 11 Dec 2007 22:23:45 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [127.0.0.1] (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 1D03FD051E;
	Wed, 12 Dec 2007 00:23:42 -0500 (EST)
In-Reply-To: <20071212025157.GA30766@klangraum>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com> <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl> <20071212025157.GA30766@klangraum>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Message-Id: <67D2337E-F8A5-4915-80F9-8660876B7E38@mnot.net>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
From: Mark Nottingham <mnot@mnot.net>
Subject: Re: Tombstones
Date: Wed, 12 Dec 2007 16:23:33 +1100
To: "A. Pagaltzis" <pagaltzis@gmx.de>
X-Mailer: Apple Mail (2.752.3)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBC5Njxg085101
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBC5NjfG085107
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


Yeah, +1 -- I smell premature optimisation.


On 12/12/2007, at 1:51 PM, A. Pagaltzis wrote:

>
> * James Holderness <j4_james@hotmail.com> [2007-12-07 03:55]:
>> Steven Lees wrote:
>>> On the initial sync of a feed, most sync-aware clients will
>>> still want to ask for the feed without tombstones, so that
>>> they can just get the non-deleted items.
>>
>> I wouldn't think that's worth the effort. Tombstones should be
>> small enough and infrequent enough that I wouldn't care about
>> getting them on an initial sync.
>
> It=92s pointless either way. You might avoid receiving a bunch of
> irrelevant tombstones on the first fetch =96 only to end up getting
> them all on your second fetch.
>
> You could invest somewhat significant extra complexity to make it
> actually work=85 all so you can avoid a handful of tombstones for a
> short period after subscribing to a feed. Ahem.
>
> Regards,
> --=20
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>


--
Mark Nottingham     http://www.mnot.net/





From owner-atom-syntax@mail.imc.org Wed Dec 12 01:19:17 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2Kw9-0000X6-UW
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 01:19:17 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2Kw6-0006Xl-O1
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 01:19:16 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBC668nV087773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Dec 2007 23:06:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBC668rN087772;
	Tue, 11 Dec 2007 23:06:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBC666ve087766
	for <atom-syntax@imc.org>; Tue, 11 Dec 2007 23:06:07 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 12 Dec 2007 06:06:05 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp011) with SMTP; 12 Dec 2007 07:06:05 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1/vRoF3UCzvchzLIGoO5pXok96u0+i8oLOhYmmvfT
	gPIBD0LBHTSCHE
Date: Wed, 12 Dec 2007 07:06:05 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
Message-ID: <20071212060605.GD30766@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk> <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com> <47577884.8060401@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE7A2E93@NA-EXMSG-C103.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE7A2E93@NA-EXMSG-C103.redmond.corp.microsoft.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBC668nV087773
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


* Steven Lees <Steven.Lees@microsoft.com> [2007-12-06 22:45]:
> Timestamps are problematic for sync because they assume that
> you can synchronize clocks across different machines.

I suppose that=E2=80=99s important when you actually try to do something
where clocks across different machines need to synchronise.

I assume that FeedSync (which I haven=E2=80=99t looked at) tries to cover
some such cases.

But for tombstones, only the server=E2=80=99s clock matters.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From Parikshit-Napartuk@stuartfew.com Wed Dec 12 08:54:48 2007
Return-path: <Parikshit-Napartuk@stuartfew.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2S2y-00089f-Mq
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 08:54:48 -0500
Received: from [66.50.159.103] (helo=[66.50.159.103])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J2S2y-0003zi-9h
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 08:54:48 -0500
Received: from damaris ([128.154.96.62]:25652 "EHLO damaris"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by [66.50.159.103] with ESMTP id S22UQQKIXLHHHTML (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Wed, 12 Dec 2007 09:51:57 -0800
Message-ID: <28172C88.914EA6DA@stuartfew.com>
Date: Wed, 12 Dec 2007 09:51:45 -0800
From: "Parikshit Napartuk" <Parikshit-Napartuk@stuartfew.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: wdraluog
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.1 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

be proud and be able to say you have a big dick http://djtimetk.com/



From owner-atom-syntax@mail.imc.org Wed Dec 12 20:44:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2d7k-0008V0-UE
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 20:44:28 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2d7k-0002Ps-FX
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 20:44:28 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBD1PnDC084653
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Dec 2007 18:25:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBD1PnEu084652;
	Wed, 12 Dec 2007 18:25:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBD1PlAC084642
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Wed, 12 Dec 2007 18:25:49 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Wed, 12 Dec 2007 17:25:46 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed,
 12 Dec 2007 17:25:47 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: "A. Pagaltzis" <pagaltzis@gmx.de>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Wed, 12 Dec 2007 17:25:45 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg8a/TRBX5dcy6uSD6MmaEqXQKRbQAuYR6g
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE8FA50A@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com>
 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
 <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net>
 <000001c8383c$bbc7b600$2501a8c0@Junk>
 <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl>
 <20071212025157.GA30766@klangraum>
In-Reply-To: <20071212025157.GA30766@klangraum>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lBD1PnAB084647
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBD1PnDC084653
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5


Aristotle Pagaltzis wrote:

> * James Holderness <j4_james@hotmail.com> [2007-12-07 03:55]:
> > Steven Lees wrote:
> >> On the initial sync of a feed, most sync-aware clients will
> >> still want to ask for the feed without tombstones, so that
> >> they can just get the non-deleted items.
> >
> > I wouldn't think that's worth the effort. Tombstones should be
> > small enough and infrequent enough that I wouldn't care about
> > getting them on an initial sync.
>
> It=E2=80=99s pointless either way. You might avoid receiving a bunch of
> irrelevant tombstones on the first fetch =E2=80=93 only to end up getti=
ng
> them all on your second fetch.
>
> You could invest somewhat significant extra complexity to make it
> actually work=E2=80=A6 all so you can avoid a handful of tombstones for=
 a
> short period after subscribing to a feed. Ahem.

Maybe I've had too much of the ETag cool aid, but I would think that with=
 a reasonably straightforward ETag implementation on the feed, then I wou=
ld never need to see the tombstones in place before my first sync, regard=
less of how many times I resync.

I certainly agree that creates a little more work on both the client and =
server. Whether or not you think it's worth it depends on your scenario. =
For blog publishing, it's probably not that interesting. For two-way sync=
 of a larger data set, it's a lot more useful.

Steven





From owner-atom-syntax@mail.imc.org Wed Dec 12 20:44:48 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2d84-0000BM-J9
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 20:44:48 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2d82-0002QB-8l
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 20:44:48 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBD1VliG085458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Dec 2007 18:31:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBD1VlXo085457;
	Wed, 12 Dec 2007 18:31:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBD1Vkj7085450
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Wed, 12 Dec 2007 18:31:46 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by
 TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Wed, 12 Dec 2007 17:31:45 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.9]) by
 tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Wed,
 12 Dec 2007 17:31:45 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: "A. Pagaltzis" <pagaltzis@gmx.de>, "'Atom-Syntax'" <atom-syntax@imc.org>
Date: Wed, 12 Dec 2007 17:31:44 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: Acg8hwkDVLo7wBYWSRiUWmuJgVAOzgAoEv6w
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FE8FA516@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
 <47562422.40408@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47563598.3020108@gmail.com> <008801c83768$24b02830$2501a8c0@Junk>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A28C4@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47577884.8060401@gmail.com>
 <9F59E90E6E525B40BB7B59BD72271CF763FE7A2E93@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <20071212060605.GD30766@klangraum>
In-Reply-To: <20071212060605.GD30766@klangraum>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lBD1Vlj6085452
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBD1VliG085458
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22


Aristotle Pagaltzis wrote:

>
> * Steven Lees <Steven.Lees@microsoft.com> [2007-12-06 22:45]:
> > Timestamps are problematic for sync because they assume that
> > you can synchronize clocks across different machines.
>
> I suppose that=E2=80=99s important when you actually try to do somethin=
g
> where clocks across different machines need to synchronise.
>
> I assume that FeedSync (which I haven=E2=80=99t looked at) tries to cov=
er
> some such cases.

Our design approach for FeedSync is that you're not going to have differe=
nt clocks in sync, but we want data sync to work anyway. That's why we us=
e version numbers instead of timestamps.

> But for tombstones, only the server=E2=80=99s clock matters.

Agreed. That starts to be not quite as true when your server hardware is =
upgraded, or your successive edit requests are handled by different machi=
nes, and so on, but in practice it will mostly work (for one-way sync).

Steven




From owner-atom-syntax@mail.imc.org Wed Dec 12 22:00:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2eJY-0004yd-2P
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 22:00:44 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J2eJX-0003zh-KG
	for atompub-archive@lists.ietf.org; Wed, 12 Dec 2007 22:00:44 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBD2clZi089142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Dec 2007 19:38:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBD2clGI089141;
	Wed, 12 Dec 2007 19:38:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBD2cjQj089133
	for <atom-syntax@imc.org>; Wed, 12 Dec 2007 19:38:46 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 13 Dec 2007 02:38:44 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp055) with SMTP; 13 Dec 2007 03:38:44 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1+wBEsaoxOw2LJRIyJ8FaCIFAbONd4W5sTEr1Iw1a
	vN2Xbz+94OBFpc
Date: Thu, 13 Dec 2007 03:38:43 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
Message-ID: <20071213023843.GM15399@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <CB22A09B-BF95-4AC5-BC89-CAFB2E454ACB@mnot.net> <000001c8383c$bbc7b600$2501a8c0@Junk> <BAY141-DAV407A4FBD859A899D53EA7BE6F0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FE7A3189@NA-EXMSG-C103.redmond.corp.microsoft.com> <BAY141-DAV239549364C311A0ECA3D6BE680@phx.gbl> <20071212025157.GA30766@klangraum> <9F59E90E6E525B40BB7B59BD72271CF763FE8FA50A@NA-EXMSG-C103.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FE8FA50A@NA-EXMSG-C103.redmond.corp.microsoft.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBD2clZi089142
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581


* Steven Lees <Steven.Lees@microsoft.com> [2007-12-13 02:30]:
> Maybe I've had too much of the ETag cool aid, but I would think
> that with a reasonably straightforward ETag implementation on
> the feed, then I would never need to see the tombstones in
> place before my first sync, regardless of how many times I
> resync.

That sounds like RFC=C2=A03229+feed, except it applies to tombstones
only and with probably no consideration given yet to how
intermediaries affect the picture. (But I might not giving enough
credit on the second point.)

The difference is that RFC=C2=A03229+feed actually offers dramatic
bandwidth savings, whereas a tombstone-specific mechanism would
deliver only negligible ones.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From Ferosh_Scheuer@aycesistemas.com.ar Thu Dec 13 11:34:21 2007
Return-path: <Ferosh_Scheuer@aycesistemas.com.ar>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J2r0v-0002ce-CW
	for atompub-archive@lists.ietf.org; Thu, 13 Dec 2007 11:34:21 -0500
Received: from [63.227.84.30] (helo=[63.227.84.30])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J2r0u-0001Ju-Gj
	for atompub-archive@lists.ietf.org; Thu, 13 Dec 2007 11:34:21 -0500
Received: from accounts1 ([170.188.57.89] helo=accounts1)
	by [63.227.84.30] ( sendmail 8.13.3/8.13.1) with esmtpa id 1jKuIR-000KTD-dP
	for atompub-archive@lists.ietf.org; Thu, 13 Dec 2007 09:36:46 -0700
Message-ID: <98391BD6.147B8646@aycesistemas.com.ar>
Date: Thu, 13 Dec 2007 09:36:18 -0700
From: "Ferosh Scheuer" <Ferosh_Scheuer@aycesistemas.com.ar>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: vitsevaa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
be a pimpin baller when you have a big dick <a href="http://machbeuf.com/">http://machbeuf.com/</a><br>
</html>



From Valerie.Dutra@china-epoch.com Fri Dec 14 16:34:19 2007
Return-path: <Valerie.Dutra@china-epoch.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J3IAl-00044I-71
	for atompub-archive@lists.ietf.org; Fri, 14 Dec 2007 16:34:19 -0500
Received: from pd9e0faa6.dip0.t-ipconnect.de ([217.224.250.166])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J3IAk-00034z-CQ
	for atompub-archive@lists.ietf.org; Fri, 14 Dec 2007 16:34:18 -0500
Received: from home-pc ([117.173.47.144] helo=home-pc)
	by pD9E0FAA6.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1Nsyrw-000RUR-ZS
	for atompub-archive@lists.ietf.org; Fri, 14 Dec 2007 22:28:38 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 14 Dec 2007 22:28:17 +0100
To: atompub-archive@lists.ietf.org
From: "Valerie Dutra" <Valerie.Dutra@china-epoch.com>
Subject: rtezraal
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.0 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

having a small dick will never be your problem anymore! http://www.ramataz.com/



From owner-atom-syntax@mail.imc.org Sat Dec 15 13:07:51 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J3bQV-0003R4-7F
	for atompub-archive@lists.ietf.org; Sat, 15 Dec 2007 13:07:51 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J3bQT-0004E8-IJ
	for atompub-archive@lists.ietf.org; Sat, 15 Dec 2007 13:07:51 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBFHkLub010124
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 15 Dec 2007 10:46:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBFHkL3M010123;
	Sat, 15 Dec 2007 10:46:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.fimug.fi (mail.fimug.fi [212.149.83.83])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBFHkKr0010113
	for <atom-syntax@imc.org>; Sat, 15 Dec 2007 10:46:20 -0700 (MST)
	(envelope-from hsivonen@iki.fi)
Received: from a175-85.24online.fi (a175-85.24online.fi [84.239.175.85])
	by posti.fidisk.fi (Postfix) with ESMTP id 88E442C8DF06
	for <atom-syntax@imc.org>; Sat, 15 Dec 2007 19:46:18 +0200 (EET)
Message-Id: <76C0B057-D3DE-4346-BE3E-E24CD8DDE543@iki.fi>
From: Henri Sivonen <hsivonen@iki.fi>
To: Atom Syntax <atom-syntax@imc.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Best schema version
Date: Sat, 15 Dec 2007 19:46:18 +0200
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


I recall someone found a bug or two in the informative schema that is  
included in the RFC.

What's currently considered the best version of the RELAX NG schema  
around? Is it available under a Free Software license?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/





From Denell@csmcalanda.com Sat Dec 15 17:24:17 2007
Return-path: <Denell@csmcalanda.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J3fQe-0006qa-TP
	for atompub-archive@lists.ietf.org; Sat, 15 Dec 2007 17:24:17 -0500
Received: from [86.62.28.26] (helo=26-28-62-86.digitalskys.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J3fQX-0004C1-Aq
	for atompub-archive@lists.ietf.org; Sat, 15 Dec 2007 17:24:16 -0500
Received: from nn-0fe5fff1b61b ([158.180.129.37]:13026 "EHLO nn-0fe5fff1b61b"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by 26-28-62-86.digitalskys.com with ESMTP id S22YXYWOOYFKYRTZ (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Sun, 25 Nov 2007 13:30:20 -0800
Message-ID: <A6DEAA34.3A6C331C@csmcalanda.com>
Date: Sun, 25 Nov 2007 13:30:05 -0800
From: "Denell Moreli" <Denell@csmcalanda.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: tewor
Content-Type: multipart/alternative;
 boundary="------------010700040202070803050503"
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

--------------010700040202070803050503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

trust us, she really wants your dick bigger http://www.landich.com/

--------------010700040202070803050503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
trust us, she really wants your dick bigger <a href="http://www.landich.com/">http://www.landich.com/</a><br>
</body>
</html>

--------------010700040202070803050503--



From Grant-Reiling@hunde-online.net Sun Dec 16 23:12:19 2007
Return-path: <Grant-Reiling@hunde-online.net>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J47L1-0006I6-7w
	for atompub-archive@lists.ietf.org; Sun, 16 Dec 2007 23:12:19 -0500
Received: from [59.94.74.36] (helo=[59.94.74.36])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J47Kz-0003R5-Hi
	for atompub-archive@lists.ietf.org; Sun, 16 Dec 2007 23:12:18 -0500
Received: from system3 ([141.160.33.133] helo=system3)
	by [59.94.74.36] ( sendmail 8.13.3/8.13.1) with esmtpa id 1tCmWI-000IIK-nm
	for atompub-archive@lists.ietf.org; Mon, 17 Dec 2007 09:35:11 +05-30
Message-ID: <DDEABAD8.95F4EFD0@hunde-online.net>
Date: Mon, 17 Dec 2007 09:34:34 +05-30
From: "Grant Reiling" <Grant-Reiling@hunde-online.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: omodomot
Content-Type: multipart/alternative;
 boundary="------------030604080007030302040400"
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8

--------------030604080007030302040400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hold on, large dicks get sucked dry so you better make it big! http://pueuia.com/

--------------030604080007030302040400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
hold on, large dicks get sucked dry so you better make it big! <a href="http://pueuia.com/">http://pueuia.com/</a><br>
</body>
</html>

--------------030604080007030302040400--



From hamid_leyhan@magtuning.ru Mon Dec 17 21:22:08 2007
Return-path: <hamid_leyhan@magtuning.ru>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4S5w-0006K0-Kg
	for atompub-archive@lists.ietf.org; Mon, 17 Dec 2007 21:22:08 -0500
Received: from [189.54.70.132] (helo=[189.54.70.132])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J4S5t-0000vu-Sg
	for atompub-archive@lists.ietf.org; Mon, 17 Dec 2007 21:22:06 -0500
Received: from athlon-xp-2800 ([156.111.105.79]:23384 "EHLO athlon-xp-2800"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by [189.54.70.132] with ESMTP id S22LSDWUYWZJFJBB (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Tue, 18 Dec 2007 00:22:34 -0200
Message-ID: <49DC5AA6.B9F7B891@magtuning.ru>
Date: Tue, 18 Dec 2007 00:22:20 -0200
From: "hamid leyhan" <hamid_leyhan@magtuning.ru>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: erever0
Content-Type: multipart/alternative;
 boundary="------------060503040702040201030800"
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab

--------------060503040702040201030800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sick of your girl, whining about your short dick? Shut her mouth, by proving that your dick is a MONSTER. Only with this medicine you'll achieve your goal. http://www.schoolofmeds.com/

--------------060503040702040201030800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Sick of your girl, whining about your short dick? Shut her mouth, by<br>
proving that your dick is a MONSTER. Only with this medicine you'll<br>
achieve your goal. <a href="http://www.schoolofmeds.com/">http://www.schoolofmeds.com/</a><br>
</body>
</html>

--------------060503040702040201030800--



From owner-atom-syntax@mail.imc.org Mon Dec 17 23:07:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4Tk3-0002o5-G4
	for atompub-archive@lists.ietf.org; Mon, 17 Dec 2007 23:07:39 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4Tk1-0002Fu-V0
	for atompub-archive@lists.ietf.org; Mon, 17 Dec 2007 23:07:39 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI3onFR056532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Dec 2007 20:50:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBI3onxh056531;
	Mon, 17 Dec 2007 20:50:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.228])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI3olir056525
	for <atom-syntax@imc.org>; Mon, 17 Dec 2007 20:50:48 -0700 (MST)
	(envelope-from joe.gregorio@gmail.com)
Received: by hu-out-0506.google.com with SMTP id 22so976066hug.24
        for <atom-syntax@imc.org>; Mon, 17 Dec 2007 19:50:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=/VgWu8vbyaHqFVwxe/mGauuZ9t4zIf1lwKvN7WMvrpk=;
        b=Kp3eBmMkTI14TQ/PlsowIT2wb/znaA1btsjYSSesuoGCiPejo7bQWH5VIx3QJeg8LEqr8lvvIW5PThCeD5WF8KjP6TQR2vTQARHKDVGGQu6wnwn2d9KZ/WDQR8wpIToReTlxu4Ycm5hJNeapnO6vSNtkamjLnqfycxEgIb3O3Tc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=mCo2XaiRbiytw4K6xCghe7/vYMAr26HvIU2x6yqtxXueN62uglwg8YoF9LVMPt+AJCI1F2G+cJJcKs2axhBRYXDcES7fIqREOYzRyc+ZIuPk4PZUvOsDI4FXrSgf7m7eXlLo3Lek0vohFsmENFCPmDDpa0bgYIsFvwUK4EIJeF8=
Received: by 10.86.99.9 with SMTP id w9mr7184527fgb.22.1197949846356;
        Mon, 17 Dec 2007 19:50:46 -0800 (PST)
Received: by 10.86.61.9 with HTTP; Mon, 17 Dec 2007 19:50:46 -0800 (PST)
Message-ID: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
Date: Mon, 17 Dec 2007 22:50:46 -0500
From: "Joe Gregorio" <joe@bitworking.org>
To: "David Powell" <djpowell@djpowell.net>
Subject: Re: Tombstones
Cc: "James M Snell" <jasnell@gmail.com>,
        "Steven Lees" <Steven.Lees@microsoft.com>,
        "Mark Nottingham" <mnot@mnot.net>, "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
	 <47562422.40408@gmail.com>
	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
	 <47563598.3020108@gmail.com>
	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
X-Google-Sender-Auth: 3332ac9c3a464740
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3


On Dec 6, 2007 7:45 AM, David Powell <djpowell@djpowell.net> wrote:
> Quoting James M Snell <jasnell@gmail.com>:
> > 1. Deleted entries (aka Tombstones) are indicated by extension elements
> > contained within the atom:entry element. For clients that do not understand
> > the SSE extensions, these will appear no different than any other entry
> > such clients would have no way of knowing that the entry was deleted.  Also,
> > this solution assumes that there is still enough data in the database to
> > reconstruct the deleted entry in the feed. The content, title, tags, etc may
> > all have been removed from the database.
>
> I disagree.  Having clients that don't understand the extensions
> processing them in the same way as updates to the entries seems like a
> massive plus-point for FeedSync to me.

Agreed that putting the deleted entries in the same feed is problematic.
So why not put them in another feed? A feed dedicated to such
deleted entries, ala a trash/tombstone feed?

If I have feed that I want to keep track of deleted entries
for I could have a link to a trash/tombstone feed:

<feed ..>
    <link rel="trash" href="http://example.org/trash/feed/">
    <entry>
       ...
    </entry>
</feed>

And the feed at http://example.org/trash/feed/ would look like:

<feed ..>
    <entry>
      <id></id>
        ...
    </entry>
     ....
</feed>

Now since atom:id does not change for an entry I need only trawl
through the entries
in the trash feed looking for atom:id's I've seen before. Require
that entries be ordered in reverse order by their app:edited value
and that trash feeds are chained together via link/@rel="next" links ala
AtomPub collections and you're all set. All that functionality
and the only thing you have to do is register a new link
relation of 'trash' or 'tombstone'. [Add the atom:link element with a
relation of "trash" to an AtomPub service document
collection as a way for collections to signal that they
support tombstones.]

   -joe

-- 
Joe Gregorio        http://bitworking.org




From owner-atom-syntax@mail.imc.org Tue Dec 18 01:11:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4Vfx-0005eY-P2
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 01:11:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4Vfv-0003s6-Vr
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 01:11:33 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI5vxJT063804
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Dec 2007 22:57:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBI5vxBr063803;
	Mon, 17 Dec 2007 22:57:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI5vwHC063797
	for <atom-syntax@imc.org>; Mon, 17 Dec 2007 22:57:58 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so604929anc.44
        for <atom-syntax@imc.org>; Mon, 17 Dec 2007 21:57:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=ebDI+ogE8acXZp2NR8FSGSrM7gMf8VmsJB5omvte140=;
        b=RGf3DyMp/mE2+rwxr+/MfiFPD+ylP2+sIMRCZ0SPt9iNciIF5JMvA1Azm4TuwKu+wTDzoUneQ+4X4NSNCYKl8WqHBjZOsS6lbRDKEXx7zrhDO3TL5u2tNAAwj/vnrC/wxzLNOChCaqOj5Lv6TgnR/wtb7yPmvaZwsdgkOkvqr0I=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=AbqsIVjyr9YDnexSihiP1kLsh4MQPiMjxGLEBqBw2m3lmAlEeNpwnoUwCQZ2CuL21A18lGoBkpgJ3kdTQ7OdqIXkBpHAjxsbcbkCSVDhUj0ERPtmrGQKPNMD1334CIhggX6YOCKEHr/N9MLHvUTPvf0bu7wgbDN7F66VMm7jQKM=
Received: by 10.100.94.14 with SMTP id r14mr16573367anb.101.1197957477525;
        Mon, 17 Dec 2007 21:57:57 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id i52sm16391035rne.2007.12.17.21.57.55
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 17 Dec 2007 21:57:56 -0800 (PST)
Message-ID: <47676162.3050207@gmail.com>
Date: Mon, 17 Dec 2007 21:57:54 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Gregorio <joe@bitworking.org>
CC: David Powell <djpowell@djpowell.net>,
        Steven Lees <Steven.Lees@microsoft.com>,
        Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <47562422.40408@gmail.com>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
In-Reply-To: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976


FWIW, this is the model currently implemented by the Lotus Connections
Activities component.  The primary reason it works is because Activities
uses the notion of a soft-delete; where a deleted entry is moved to a
Trash collection and all of it's metadata is preserved.  The entry still
exists, it's state has just changed. A soft-deleted entry can be
undeleted and restored to it's original collection or purged.  We have
no way of representing a purged entry because the data is completely
removed from the database.

If a system is using soft-deletes and the notion of a trash collection,
then I would say that this is a fairly good approach, mainly because the
atom:entry element are pointing to something that still actually exists.
 However, if the system is doing a hard-delete and is only preserving
the id of items that have been deleted, it does not make any sense to
represent those deleted items using the atom:entry element and doing so
runs the risk of confusing certain clients into thinking that they're
looking at some piece of content that still actually exists on the server.

Bottom line: we should avoid over-overloading atom:entry.  Regardless of
the specific solution required, some invention is required and clients
will have to take specific actions to support tombstones, so we are not
saving anyone any work by reusing atom:entry for this and we run the
risk of confusing clients.  The x:deleted tombstone element avoids that
risk entirely, which for me, makes it the superior solution.

- James

Joe Gregorio wrote:
> On Dec 6, 2007 7:45 AM, David Powell <djpowell@djpowell.net> wrote:
>> Quoting James M Snell <jasnell@gmail.com>:
>>> 1. Deleted entries (aka Tombstones) are indicated by extension elements
>>> contained within the atom:entry element. For clients that do not understand
>>> the SSE extensions, these will appear no different than any other entry
>>> such clients would have no way of knowing that the entry was deleted.  Also,
>>> this solution assumes that there is still enough data in the database to
>>> reconstruct the deleted entry in the feed. The content, title, tags, etc may
>>> all have been removed from the database.
>> I disagree.  Having clients that don't understand the extensions
>> processing them in the same way as updates to the entries seems like a
>> massive plus-point for FeedSync to me.
> 
> Agreed that putting the deleted entries in the same feed is problematic.
> So why not put them in another feed? A feed dedicated to such
> deleted entries, ala a trash/tombstone feed?
> 
> If I have feed that I want to keep track of deleted entries
> for I could have a link to a trash/tombstone feed:
> 
> <feed ..>
>     <link rel="trash" href="http://example.org/trash/feed/">
>     <entry>
>        ...
>     </entry>
> </feed>
> 
> And the feed at http://example.org/trash/feed/ would look like:
> 
> <feed ..>
>     <entry>
>       <id></id>
>         ...
>     </entry>
>      ....
> </feed>
> 
> Now since atom:id does not change for an entry I need only trawl
> through the entries
> in the trash feed looking for atom:id's I've seen before. Require
> that entries be ordered in reverse order by their app:edited value
> and that trash feeds are chained together via link/@rel="next" links ala
> AtomPub collections and you're all set. All that functionality
> and the only thing you have to do is register a new link
> relation of 'trash' or 'tombstone'. [Add the atom:link element with a
> relation of "trash" to an AtomPub service document
> collection as a way for collections to signal that they
> support tombstones.]
> 
>    -joe
> 




From owner-atom-syntax@mail.imc.org Tue Dec 18 05:00:14 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4ZFG-00032O-Go
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 05:00:14 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4ZFF-00015o-W8
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 05:00:14 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI9jg81078103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 02:45:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBI9jgjq078102;
	Tue, 18 Dec 2007 02:45:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from joe.greenbytes.de (mail.greenbytes.de [217.91.35.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBI9jctw078094
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 02:45:41 -0700 (MST)
	(envelope-from stefan.eissing@greenbytes.de)
Received: from [192.168.1.6] (unknown [192.168.1.6])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by joe.greenbytes.de (Postfix) with ESMTP id 54FD8DFDA1;
	Tue, 18 Dec 2007 10:45:37 +0100 (CET)
In-Reply-To: <47676162.3050207@gmail.com>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <47562422.40408@gmail.com>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <01D6C937-0D8A-4C02-8BCC-85782518AF92@greenbytes.de>
Cc: Joe Gregorio <joe@bitworking.org>, David Powell <djpowell@djpowell.net>,
        Steven Lees <Steven.Lees@microsoft.com>,
        Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Subject: Re: Tombstones
Date: Tue, 18 Dec 2007 10:45:25 +0100
To: James M Snell <jasnell@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBI9jftw078097
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBI9jg81078103
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3



Am 18.12.2007 um 06:57 schrieb James M Snell:
> [...]
> Bottom line: we should avoid over-overloading atom:entry.  =20
> Regardless of
> the specific solution required, some invention is required and clients
> will have to take specific actions to support tombstones, so we are =20
> not
> saving anyone any work by reusing atom:entry for this and we run the
> risk of confusing clients.  The x:deleted tombstone element avoids =20
> that
> risk entirely, which for me, makes it the superior solution.

+1

Very good summary.

--
<green/>bytes GmbH, Hafenweg 16, D-48155 M=FCnster, Germany
Amtsgericht M=FCnster: HRB5782








From owner-atom-syntax@mail.imc.org Tue Dec 18 12:21:03 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4g7r-0007j5-RH
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 12:21:03 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4g7r-0005O5-Fo
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 12:21:03 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIH0vTs019792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 10:00:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIH0v88019791;
	Tue, 18 Dec 2007 10:00:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mwest.oreilly.com (mwest.oreilly.com [209.204.146.24])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIH0uPG019784
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 10:00:56 -0700 (MST)
	(envelope-from keith@oreilly.com)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mwest.oreilly.com (Postfix) with ESMTP id DE2C71B88032;
	Tue, 18 Dec 2007 08:58:42 -0800 (PST)
X-Quarantine-ID: <PnbuNp0-f5iQ>
X-Virus-Scanned: amavisd-new at 
Received: from mwest.oreilly.com ([127.0.0.1])
	by localhost (hugo.west.ora.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id PnbuNp0-f5iQ; Tue, 18 Dec 2007 08:58:42 -0800 (PST)
Received: from MacKeith.local (unknown [172.24.41.11])
	by mwest.oreilly.com (Postfix) with ESMTP id AD99D1B8802F;
	Tue, 18 Dec 2007 08:58:42 -0800 (PST)
Message-ID: <4767FCC7.2060608@oreilly.com>
Date: Tue, 18 Dec 2007 09:00:55 -0800
From: Keith Fahlgren <keith@oreilly.com>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
CC: Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <47562422.40408@gmail.com>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com>
In-Reply-To: <47676162.3050207@gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


On 12/17/07 9:57 PM, James M Snell wrote:
> FWIW, this is the model currently implemented by the Lotus Connections
> Activities component.  The primary reason it works is because Activities
> uses the notion of a soft-delete; where a deleted entry is moved to a
> Trash collection and all of it's metadata is preserved.  

This is what we do for Books in our implementations, though we haven't really
thought about the undelete that James has (we just preserve some of the metadata).


HTH,
Keith




From owner-atom-syntax@mail.imc.org Tue Dec 18 12:59:04 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4gie-0002fY-NJ
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 12:59:04 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4gie-0006Sp-6r
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 12:59:04 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIHd8ZW023167
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 10:39:13 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIHd8QO023166;
	Tue, 18 Dec 2007 10:39:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.231])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIHd6hL023158
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 10:39:07 -0700 (MST)
	(envelope-from joe.gregorio@gmail.com)
Received: by hu-out-0506.google.com with SMTP id 22so1048545hug.24
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 09:39:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=iPf7AeeNWu0Y+0bqFIF9D5sT5m8TxIoDe+5Hn3f0C4c=;
        b=d/y8kioujv7HIWCl+QUUZqsG7EeD2Ibm38FRczHkhY2R4726dBWliNKKomo09etP/j5W/TD+2ZKTDWj12MHbQBJxw3guQIm40eHJkF+q2ozmXt4w4ySWO1rYgEU/JxmGdBDptqATdCdvApzTrNWbYB7Ayfy5Jc0R+V3U5f3exeM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=TmHIRS8h8nxvYv5t94gNYiqkJGOlsD1sRZ5DzE+ukITp/BYt4JMsUik5HSejljnCKLolwWu05wBNw5EIDIM4InHGXZk5yXUAKfa6LOlpMm3Gh22R/y9KhGtPT46YBdc14X6YuoQa0Mu7j7jl7NJR8PJUgOdJA8ySjkxw9qS7Yo4=
Received: by 10.86.30.9 with SMTP id d9mr7895514fgd.52.1197999545686;
        Tue, 18 Dec 2007 09:39:05 -0800 (PST)
Received: by 10.86.61.9 with HTTP; Tue, 18 Dec 2007 09:39:05 -0800 (PST)
Message-ID: <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
Date: Tue, 18 Dec 2007 12:39:05 -0500
From: "Joe Gregorio" <joe@bitworking.org>
To: "James M Snell" <jasnell@gmail.com>
Subject: Re: Tombstones
Cc: "David Powell" <djpowell@djpowell.net>,
        "Steven Lees" <Steven.Lees@microsoft.com>,
        "Mark Nottingham" <mnot@mnot.net>, "Atom Syntax" <atom-syntax@imc.org>
In-Reply-To: <47676162.3050207@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
	 <47562422.40408@gmail.com>
	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
	 <47563598.3020108@gmail.com>
	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
	 <47676162.3050207@gmail.com>
X-Google-Sender-Auth: 58dc602f3ce0a2d4
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69


On Dec 18, 2007 12:57 AM, James M Snell <jasnell@gmail.com> wrote:
> FWIW, this is the model currently implemented by the Lotus Connections
> Activities component.

Good.

> The primary reason it works is because Activities
> uses the notion of a soft-delete; where a deleted entry is moved to a
> Trash collection and all of it's metadata is preserved.  The entry still
> exists, it's state has just changed. A soft-deleted entry can be
> undeleted and restored to it's original collection or purged.  We have
> no way of representing a purged entry because the data is completely
> removed from the database.

Not true, the *only* thing you need is the atom:id, everything else
in the purged entry can be auto-generated.

>
> If a system is using soft-deletes and the notion of a trash collection,
> then I would say that this is a fairly good approach, mainly because the
> atom:entry element are pointing to something that still actually exists.

>  However, if the system is doing a hard-delete and is only preserving
> the id of items that have been deleted, it does not make any sense to
> represent those deleted items using the atom:entry element and doing so
> runs the risk of confusing certain clients into thinking that they're
> looking at some piece of content that still actually exists on the server.

Sorry, that's a straw-man, these are completely different feeds living at
different URIs, there's no chance of "confusing certain clients".

Worst case an aggregator is subscribed to both feeds and
it combines all entries with the same atom:id
and over-writes the old entry with the new 'deleted' entries
auto-generated content. Oh wait, that's *exactly* what you'd want
to happen.This just reinforces the idea of altering the entry with
auto-generated content, like changing the title
to "Tombstone Number {num}".

   -joe

-- 
Joe Gregorio        http://bitworking.org




From owner-atom-syntax@mail.imc.org Tue Dec 18 13:50:46 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4hWg-0000VQ-6S
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 13:50:46 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4hWe-00082x-DL
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 13:50:46 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIIWLcW028240
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 11:32:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIIWLxR028239;
	Tue, 18 Dec 2007 11:32:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIIWJGM028231
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 11:32:20 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so2077695rvf.34
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 10:32:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=/euozNqCI1QogHfB1E7AS9wCkfDKzOnxZFYBXa5aAM4=;
        b=Yn1/pgtkFc98ojEC5UUYzDecGmcFQ0kxEep6UIbGlpI1LKW3+CRDDsM6j/9alKLpib0kxKXvP9DNzOBGbTtYOG4I7DwWd+eCH7I6Z8tKGLEDJAEBYD/XCqgDio1PPAyICAAwJ1TMrRCuGNg/Ze5FREhXCjNadV1eGBVVI4cgy2M=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=b29MhXQEGUv/5+dWYz5MrLxAo8LKab8nVZbzjcYhclyANv1S3mioNqU71q4h6mxsLII1gTUDF64p2vMIfT66knRQTsWcYch5jBQRabpp4YtvJbVbl67sFIisu012+M3oeMYXTV1qPhgmLGYMi3YEZLapMwSYRbREI4tmUPzUI2o=
Received: by 10.141.189.4 with SMTP id r4mr5185033rvp.98.1198002738915;
        Tue, 18 Dec 2007 10:32:18 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id i49sm17613278rne.2007.12.18.10.32.17
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 18 Dec 2007 10:32:18 -0800 (PST)
Message-ID: <4768122A.3050801@gmail.com>
Date: Tue, 18 Dec 2007 10:32:10 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Gregorio <joe@bitworking.org>
CC: David Powell <djpowell@djpowell.net>,
        Steven Lees <Steven.Lees@microsoft.com>,
        Mark Nottingham <mnot@mnot.net>, Atom Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <47562422.40408@gmail.com>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>	 <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
In-Reply-To: <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2



Joe Gregorio wrote:
> [snip]
>> The primary reason it works is because Activities
>> uses the notion of a soft-delete; where a deleted entry is moved to a
>> Trash collection and all of it's metadata is preserved.  The entry still
>> exists, it's state has just changed. A soft-deleted entry can be
>> undeleted and restored to it's original collection or purged.  We have
>> no way of representing a purged entry because the data is completely
>> removed from the database.
> 
> Not true, the *only* thing you need is the atom:id, everything else
> in the purged entry can be auto-generated.
> 

What are you saying isn't true? I was describing a fact about an
existing implementation. When an entry is purged, we do not keep any
record of it (not even the atom:id) so we have no way of representing
the purged entry. To implement full tombstone support, the most we
should have to do is start tracking the atom:id's of the purged entries
and the date/time of deletion. Why should I have to auto-generate
anything?

That said, what is the value of reusing atom:entry in this case?

Why is this...

<entry>
  <id>tag:example.org,2007:/the/only/useful/thing/here</id>
  <updated>2007-12-12T12:12:12Z</updated>
  <title>useless</title>
  <author><name>useless</name></author>
  <summary>useless</summary>
</entry>

Better than this:

<x:deleted>
  <id>tag:example.org,2007:/the/only/useful/thing/here</id>
  <updated>2007-12-12T12:12:12Z</updated>
</x:deleted>

Or even just this:

<x:deleted>
  <id>tag:example.org,2007:/the/only/useful/thing/here</id>
</x:deleted>

>> If a system is using soft-deletes and the notion of a trash collection,
>> then I would say that this is a fairly good approach, mainly because the
>> atom:entry element are pointing to something that still actually exists.
> 
>>  However, if the system is doing a hard-delete and is only preserving
>> the id of items that have been deleted, it does not make any sense to
>> represent those deleted items using the atom:entry element and doing so
>> runs the risk of confusing certain clients into thinking that they're
>> looking at some piece of content that still actually exists on the server.
> 
> Sorry, that's a straw-man, these are completely different feeds living at
> different URIs, there's no chance of "confusing certain clients".
> 

Are you sure about that?  I've tested the behavior (subscribing to
separate entry and trash feeds) in several reader clients and it's
certainly not ideal, at least not imho.

> Worst case an aggregator is subscribed to both feeds and
> it combines all entries with the same atom:id
> and over-writes the old entry with the new 'deleted' entries
> auto-generated content. Oh wait, that's *exactly* what you'd want
> to happen.This just reinforces the idea of altering the entry with
> auto-generated content, like changing the title
> to "Tombstone Number {num}".
> 

No. Worst case is that the reader shows two entries.  For instance, in
Liferea, I subscribed to two feeds:

Main...
  <feed xmlns="http://www.w3.org/2005/Atom">
    <id>tag:example.org,2007:foo</id>
    <title>test feed</title>
    <updated>2007-12-12T12:12:12Z</updated>
    <link rel="trash" href="trash.xml" />
    <author><name>James</name></author>
    <entry>
      <id>tag:example.org,2007:foo/1</id>
      <title>An entry</title>
      <summary>A summary</summary>
      <updated>2007-12-12T12:12:12Z</updated>
      <link href="http://example.org" />
    </entry>
  </feed>

Trash...
  <feed xmlns="http://www.w3.org/2005/Atom">
    <id>tag:example.org,2007:foo</id>
    <title>test feed</title>
    <updated>2007-12-12T12:12:12Z</updated>
    <author><name>James</name></author>
    <entry>
      <id>tag:example.org,2007:foo/1</id>
      <title>Deleted</title>
      <updated>2007-12-12T12:13:12Z</updated>
      <content>Deleted</content>
    </entry>
  </feed>

Liferea shows two entries with no obvious relationship to one another,
which is appropriate behavior in order to avoid the risk of spoofing
attacks.  Unfortunately, there is no good way the user can know that the
"Deleted" item listed by one feed is related to the "An entry" item from
the other feed.  The only clue the user has is the fact that when you
click on either one of the entries, the other entries read status is
toggled as well.  It get's worse when there are multiple deleted entries
in the trash folder.

- James

>    -joe
> 




From owner-atom-syntax@mail.imc.org Tue Dec 18 14:32:32 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4iB6-0007CF-Si
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 14:32:32 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4iB5-0000pN-A9
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 14:32:32 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIJ7MUr030943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 12:07:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIJ7MPR030942;
	Tue, 18 Dec 2007 12:07:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIJ7Kdq030931
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 12:07:21 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 08B97D05A2
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 14:07:18 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>
Subject: RE: Tombstones
Date: Wed, 19 Dec 2007 02:07:13 +0700
Message-ID: <001c01c841a9$382f46c0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>
Thread-Index: AchBpVMeUB2OXf65SJSmcMZ5bzGnoAAAC8vw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464


Joe Gregorio wrote:
> > I agree that there are ways to avoid the confusion. But, 
> > the latency from having to sync with the extra feed is 
> > unacceptable,
> 
> To whom? And who is bearing the burden of your trade-off?

If the client is on a high-latency connection, then the last thing you
want to do is double the number of requests and thus double the latency.
For example, if you have 5 second latency, you don't want to make the
user wait five extra seconds to verify that he hasn't deleted any
entries today.

> Most aggregators will ignore the 'deleted' status of an entry 
> and all those deleted entries will just be wasted bandwidth.

That is true if the number of deleted entries is large. But, that will
be rare for most applications I am interested in. Anyway, Atom isn't
really a bandwidth-friendly format to start with.

> > especially when
> > multiplied by dozens or hundreds of feeds.
> 
> There's no reason you couldn't collapse multiple trash feeds 
> into a single feed, all the atom:ids are universally unique.

I am talking about a client subscribed to feeds delivered from unrelated
sites.

- Brian




From owner-atom-syntax@mail.imc.org Tue Dec 18 14:55:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4iXY-0001hm-ML
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 14:55:44 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4iXY-000275-5t
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 14:55:44 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIJXAoY033631
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 12:33:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIJXAQQ033630;
	Tue, 18 Dec 2007 12:33:10 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.238])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIJX81D033622
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 12:33:09 -0700 (MST)
	(envelope-from joe.gregorio@gmail.com)
Received: by hu-out-0506.google.com with SMTP id 22so1062872hug.24
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 11:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=pQuS9OEwJTYVzb9ud3Omr1CpnWJThOvnRBcYVtJxsTo=;
        b=Bk8v9hoKzU9H1gDkK+QmwZwQAoDh4dd/Acz+woIpOqcDPHGcGKkAVm2vHRwt0E7cNvy/THr1RJx8V7ekU6M9r+9uBKHMl+WzpWRgqMb+2VCgVjrmSeuOGKZfJHSVeUxt5BiWY4n9AkRK397922MqazYhkFzS5WgRMvT99OvH8R8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=qa3cR5EHuAm61WvRucLxJe5uruYpGau8omDmZ/MHX9JxA9L8+wO/w8v/zNMVkfODvfWVK7MQBNnRuz2stjMxe+DqYfIddQczI4RjYr5SJeseHKmO52U0NrQp1gZVE+iRxy+9cqTQozOkssS0FV8I0m3YZm07sF5zzf0Q274hmuU=
Received: by 10.86.96.18 with SMTP id t18mr8042019fgb.13.1198006387308;
        Tue, 18 Dec 2007 11:33:07 -0800 (PST)
Received: by 10.86.61.9 with HTTP; Tue, 18 Dec 2007 11:33:07 -0800 (PST)
Message-ID: <3f1451f50712181133u775dab54vcf67aca5105404ae@mail.gmail.com>
Date: Tue, 18 Dec 2007 14:33:07 -0500
From: "Joe Gregorio" <joe@bitworking.org>
To: "Brian Smith" <brian@briansmith.org>
Subject: Re: Tombstones
Cc: Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <001c01c841a9$382f46c0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>
	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>
	 <47563598.3020108@gmail.com>
	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>
	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
	 <47676162.3050207@gmail.com>
	 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
	 <000901c841a2$63f64350$0701a8c0@Junk>
	 <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>
	 <001c01c841a9$382f46c0$0701a8c0@Junk>
X-Google-Sender-Auth: 931c58b19294fd53
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336


On Dec 18, 2007 2:07 PM, Brian Smith <brian@briansmith.org> wrote:
>
> Joe Gregorio wrote:
> > > I agree that there are ways to avoid the confusion. But,
> > > the latency from having to sync with the extra feed is
> > > unacceptable,
> >
> > To whom? And who is bearing the burden of your trade-off?
>
> If the client is on a high-latency connection, then the last thing you
> want to do is double the number of requests and thus double the latency.
> For example, if you have 5 second latency, you don't want to make the
> user wait five extra seconds to verify that he hasn't deleted any
> entries today.
>
> > Most aggregators will ignore the 'deleted' status of an entry
> > and all those deleted entries will just be wasted bandwidth.
>
> That is true if the number of deleted entries is large. But, that will
> be rare for most applications I am interested in. Anyway, Atom isn't
> really a bandwidth-friendly format to start with.
>
> > > especially when
> > > multiplied by dozens or hundreds of feeds.
> >
> > There's no reason you couldn't collapse multiple trash feeds
> > into a single feed, all the atom:ids are universally unique.
>
> I am talking about a client subscribed to feeds delivered from unrelated
> sites.

Those are arguments that actually make sense. I was thinking of
tombstones solely in the case of AtomPub collections, but in the
case of syndication the

<x:deleted>
 <id>tag:example.org,2007:/the/only/useful/thing/here</id>
</x:deleted>

markup seems like a better fit.

    -joe

-- 
Joe Gregorio        http://bitworking.org




From owner-atom-syntax@mail.imc.org Tue Dec 18 15:33:28 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4j84-0004hl-D3
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 15:33:28 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4j84-0005Fr-0r
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 15:33:28 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIKB93T036720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 13:11:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIKB9nG036719;
	Tue, 18 Dec 2007 13:11:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIKB8Bj036705
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 13:11:08 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by nz-out-0506.google.com with SMTP id n1so1316363nzf.4
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 12:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=5eb9u0BEj5/+MFJYCdJRezhYBFjX0EZ0YIMKlhGjxMI=;
        b=dcRbXctoAB/OdqVegW0rdCdpBBMj8wOv2pujywXmIWYuM3+WxAX9HBTAKFzourZCeVYvgFMxapT8J4BeQnLnu+eLCklp7q4sQXRe/UU0zg7reLCkeEgAVTztCZQJ7ve6uraFv97txIRuHFyilNEwJD8Yy0SMpbEypRyHp9AzNRE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=L86tNUP85SUd6hHKX0KEX3ndhHPDrQPMM7l19xekpvfX5gSlEjqcOp/8y2lVlz4DfNrT6+/ZUbQ4Wh5szYhFNgROYrBcbhWmJo4XTgoFRVMHVd/NLgZPS2S1Nyj9pHvzrMAk31PE3zA3xkahX+s5hC+0qXVGPqQlASgHIj25QS8=
Received: by 10.141.169.9 with SMTP id w9mr3555804rvo.179.1198008666916;
        Tue, 18 Dec 2007 12:11:06 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id g39sm1717344rvb.2007.12.18.12.11.05
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Tue, 18 Dec 2007 12:11:05 -0800 (PST)
Message-ID: <4768294F.60409@gmail.com>
Date: Tue, 18 Dec 2007 12:10:55 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Gregorio <joe@bitworking.org>
CC: Brian Smith <brian@briansmith.org>, Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>	 <47676162.3050207@gmail.com>	 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>	 <000901c841a2$63f64350$0701a8c0@Junk>	 <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>	 <001c01c841a9$382f46c0$0701a8c0@Junk> <3f1451f50712181133u775dab54vcf67aca5105404ae@mail.gmail.com>
In-Reply-To: <3f1451f50712181133u775dab54vcf67aca5105404ae@mail.gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906


Which brings us back to one of my original points: it would make the
most sense to have a single solution that works well across as many use
cases as possible.  Representing tombstones using x:deleted does that.
Representing tombstones using atom:entry does not.

- James

Joe Gregorio wrote:
> [snip]
> Those are arguments that actually make sense. I was thinking of
> tombstones solely in the case of AtomPub collections, but in the
> case of syndication the
> 
> <x:deleted>
>  <id>tag:example.org,2007:/the/only/useful/thing/here</id>
> </x:deleted>
> 
> markup seems like a better fit.
> 
>     -joe
> 




From owner-atom-syntax@mail.imc.org Tue Dec 18 16:41:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4kCL-0007Ku-BR
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 16:41:57 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4kCI-0008GF-WE
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 16:41:57 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBILJ4Cg043738
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 14:19:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBILJ4oA043737;
	Tue, 18 Dec 2007 14:19:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBILJ2qd043731
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 14:19:03 -0700 (MST)
	(envelope-from dave@djpowell.net)
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout02-winn.ispmail.ntl.com with ESMTP
          id <20071218211940.FZBV6054.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
          Tue, 18 Dec 2007 21:19:40 +0000
Received: from DavePC ([86.4.235.85]) by aamtaout03-winn.ispmail.ntl.com
          with ESMTP
          id <20071218212024.NLZL26699.aamtaout03-winn.ispmail.ntl.com@DavePC>;
          Tue, 18 Dec 2007 21:20:24 +0000
From: "David Powell" <djpowell@djpowell.net>
To: "'James M Snell'" <jasnell@gmail.com>,
        "'Joe Gregorio'" <joe@bitworking.org>
Cc: "'Steven Lees'" <Steven.Lees@microsoft.com>,
        "'Mark Nottingham'" <mnot@mnot.net>,
        "'Atom Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <47562422.40408@gmail.com>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com>
In-Reply-To: <47676162.3050207@gmail.com>
Subject: RE: Tombstones
Date: Tue, 18 Dec 2007 21:19:00 -0000
Message-ID: <011901c841bb$9d231130$d7693390$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchBO8q4MxRhD25LQnynK/P/wnbU+gAfKTsQ
Content-Language: en-gb
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


> Bottom line: we should avoid over-overloading atom:entry.  Regardless of
> the specific solution required, some invention is required and clients
> will have to take specific actions to support tombstones, so we are not
> saving anyone any work by reusing atom:entry for this and we run the
> risk of confusing clients.  The x:deleted tombstone element avoids that
> risk entirely, which for me, makes it the superior solution.

The x:deleted proposal is overloading atom:feed more inapropriately
than the sx:deleted proposal overloads atom:entry.  

Atom is a great syntax for communicating a single stream of entries
belonging to a feed.  It is not a suitable syntax for communicating
*two* streams of entries and tombstones belonging to a feed.
It is the wrong shape.  Feed metadata elements aren't a good place
to embed a stream of tombstones.  Intermediaries such as
feedburner, yahoo pipes, and the windows feed platform do not support
agregating <x:deleted> feed metadata elements as they do entries.

The practical life-cycle and semantics of a top-level feed element
aren't appropriate for communicating a change in state of an entry.
I think giving up on the feed/entry model is a premature optimization.
If there are practical difficulties with combining tombstones and
normal entries in a feed, then Joe's proposal of using separate feeds
sounds like a better idea.

--
Dave





From owner-atom-syntax@mail.imc.org Tue Dec 18 16:48:02 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4kIE-0003sn-Lz
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 16:48:02 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4kIE-0008Nw-9i
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 16:48:02 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBILP4Gt044047
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 14:25:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBILP4TB044046;
	Tue, 18 Dec 2007 14:25:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBILOwjD044031
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 14:25:03 -0700 (MST)
	(envelope-from dave@djpowell.net)
Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout03-winn.ispmail.ntl.com with ESMTP
          id <20071218212547.CGNL20647.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>;
          Tue, 18 Dec 2007 21:25:47 +0000
Received: from DavePC ([86.4.235.85]) by aamtaout01-winn.ispmail.ntl.com
          with ESMTP
          id <20071218212549.QVMQ219.aamtaout01-winn.ispmail.ntl.com@DavePC>;
          Tue, 18 Dec 2007 21:25:49 +0000
From: "David Powell" <djpowell@djpowell.net>
To: "'Brian Smith'" <brian@briansmith.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com> <001c01c841a9$382f46c0$0701a8c0@Junk>
In-Reply-To: <001c01c841a9$382f46c0$0701a8c0@Junk>
Subject: RE: Tombstones
Date: Tue, 18 Dec 2007 21:24:57 -0000
Message-ID: <011a01c841bc$71c126c0$55437440$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchBpVMeUB2OXf65SJSmcMZ5bzGnoAAAC8vwAAWh3YA=
Content-Language: en-gb
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


Brian Smith wrote:

>  If the client is on a high-latency connection, then the last thing you
> want to do is double the number of requests and thus double the latency.
> For example, if you have 5 second latency, you don't want to make the
> user wait five extra seconds to verify that he hasn't deleted any
> entries today.

Would the requests need to be made synchronously?

-- 
Dave







From owner-atom-syntax@mail.imc.org Tue Dec 18 17:44:14 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4lAc-0001cU-8r
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 17:44:14 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4lAa-0001yZ-MM
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 17:44:14 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIMSNUF047897
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 15:28:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIMSNmM047896;
	Tue, 18 Dec 2007 15:28:23 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIMSMh9047890
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 15:28:23 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 285CCD05A2;
	Tue, 18 Dec 2007 17:28:19 -0500 (EST)
Cc: Joe Gregorio <joe@bitworking.org>, Brian Smith <brian@briansmith.org>,
        Atom-Syntax Syntax <atom-syntax@imc.org>
Message-Id: <0EF46214-A2BB-40B9-B96D-7E3D16DFF665@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: James M Snell <jasnell@gmail.com>
In-Reply-To: <4768294F.60409@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Tombstones
Date: Wed, 19 Dec 2007 09:28:16 +1100
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>	 <47676162.3050207@gmail.com>	 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>	 <000901c841a2$63f64350$0701a8c0@Junk>	 <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>	 <001c01c841a9$382f46c0$0701a8c0@Junk> <3f1451f50712181133u775dab54vcf67aca5105404ae@mail.gmail.com> <4768294F.60409@gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4


+1

FWIW, I think a small individual submission on the standards track  
would be the way to go here, defining a single new feed-level element  
(preferably in the Atom namespace; I hope we left ourselves enough  
wiggle room to do that!).

James?


On 19/12/2007, at 7:10 AM, James M Snell wrote:

>
> Which brings us back to one of my original points: it would make the
> most sense to have a single solution that works well across as many  
> use
> cases as possible.  Representing tombstones using x:deleted does that.
> Representing tombstones using atom:entry does not.
>
> - James
>
> Joe Gregorio wrote:
>> [snip]
>> Those are arguments that actually make sense. I was thinking of
>> tombstones solely in the case of AtomPub collections, but in the
>> case of syndication the
>>
>> <x:deleted>
>> <id>tag:example.org,2007:/the/only/useful/thing/here</id>
>> </x:deleted>
>>
>> markup seems like a better fit.
>>
>>    -joe
>>
>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 17:49:00 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4lFE-0006tk-7U
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 17:49:00 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4lFD-00023Y-KV
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 17:49:00 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIMVhLT048011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 15:31:43 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBIMVh3M048010;
	Tue, 18 Dec 2007 15:31:43 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBIMVgBP048004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 15:31:43 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 6F513D0502
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 17:31:41 -0500 (EST)
Message-Id: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Wed, 19 Dec 2007 09:31:38 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac


FYI; I'd love any feedback folks have on this.

Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: 19 December 2007 7:15:02 AM
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
> Reply-To: internet-drafts@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: FIQL: The Feed Item Query Language
> 	Author(s)	: M. Nottingham
> 	Filename	: draft-nottingham-atompub-fiql-00.txt
> 	Pages		: 16
> 	Date		: 2007-12-18
> 	
>   The Feed Item Query Language is a simple but flexible, URI-friendly
>   syntax for expressing filters across the entries in a Web feed.  It
>   also specifies a mechanism to allow feeds to indicate what types of
>   queries are supported.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-nottingham-atompub-fiql-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-nottingham-atompub-fiql-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <2007-12-18145429.I-D@ietf.org>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 18:36:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4lyq-0006YM-BL
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 18:36:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4lyp-0002so-Ue
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 18:36:08 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINEF1d051363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 16:14:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBINEF8J051362;
	Tue, 18 Dec 2007 16:14:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINEEBZ051356
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 16:14:15 -0700 (MST)
	(envelope-from hwinkler@gmail.com)
Received: by wa-out-1112.google.com with SMTP id l24so4668494waf.22
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 15:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=v9ALn+541MVBa9miq3ZWFOVxhCROwGFRqgiNrcARN1c=;
        b=TaXdf22KrQQCqeARMxgzv1CN9m58CG4RT2I+yB4r4oR/KECiDxM8mxBhxPU6mCsUOVB3Wkgd2+EzjHZCDq8itGo/s3q+ZwtRr0KT9ijGSGEZho+tbYSNC7u49Zhohf1kCsuLtO0Q29d7JhfZx0zOErG29lWbzhjTi/xJRs5jTtY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Z56LcPJ3048UtM/JIXM4JhntADaY9ZS2Ry1rO0g3xWSNTQSQAWln/IMiVqUPDr6HwRZGvfsI3FpbrPAw80u8F1pyNGSN1fzPqWW8DMsADTJl9QRJ8N5HwTQ7/6eWClfO3NTvBKwqs3dn189KfAVw7homl5guTVtUQ3ICRzfQV70=
Received: by 10.114.175.16 with SMTP id x16mr4802467wae.12.1198019654140;
        Tue, 18 Dec 2007 15:14:14 -0800 (PST)
Received: by 10.114.92.9 with HTTP; Tue, 18 Dec 2007 15:14:14 -0800 (PST)
Message-ID: <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com>
Date: Tue, 18 Dec 2007 17:14:14 -0600
From: "Hugh Winkler" <hughw@wellstorm.com>
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
	 <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
X-Google-Sender-Auth: 3920312b1f07e11b
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


On Dec 18, 2007 4:31 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> FYI; I'd love any feedback folks have on this.
>
> Begin forwarded message:
>
> > From: Internet-Drafts@ietf.org
> > Date: 19 December 2007 7:15:02 AM
> > To: i-d-announce@ietf.org
> > Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
> > Reply-To: internet-drafts@ietf.org
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >       Title           : FIQL: The Feed Item Query Language
> >       Author(s)       : M. Nottingham
> >       Filename        : draft-nottingham-atompub-fiql-00.txt
> >       Pages           : 16
> >       Date            : 2007-12-18
> >

I'm uncomfortable with prescribing how to construct URIs (sec. 4),
aren't you? It takes control of the URI namespace away from the
server. You can get the effect you want by POSTing an entity
containing the FIQL string (give it mime type application/fiql say)
and allowing the server to respond directly with the result, or return
303 to the URI of a cacheable representation. Let the server construct
the URI.


Hugh




From owner-atom-syntax@mail.imc.org Tue Dec 18 18:50:36 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4mCq-0001Sj-Mk
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 18:50:36 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4mCq-00039d-8A
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 18:50:36 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINR69r052105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 16:27:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBINR6R7052104;
	Tue, 18 Dec 2007 16:27:06 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINR1iB052096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 16:27:06 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 95B65D05A5;
	Tue, 18 Dec 2007 18:27:00 -0500 (EST)
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
Message-Id: <B369E44F-6ECE-4621-A9F7-B2609A4FCDCC@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Hugh Winkler <hughw@wellstorm.com>
In-Reply-To: <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Wed, 19 Dec 2007 10:26:57 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034



On 19/12/2007, at 10:14 AM, Hugh Winkler wrote:
>
> I'm uncomfortable with prescribing how to construct URIs (sec. 4),
> aren't you?

Why? HTML forms does it, and they're pretty successful.

> It takes control of the URI namespace away from the
> server.

Just as with forms, this only specifies a format that's meaningful if  
the server chooses to use it; it doesn't foist itself upon the URL.

> You can get the effect you want by POSTing an entity
> containing the FIQL string (give it mime type application/fiql say)
> and allowing the server to respond directly with the result, or return
> 303 to the URI of a cacheable representation. Let the server construct
> the URI.

POSTing a query works, but for whatever reason, people don't like the  
added step. The draft doesn't rule that out, of course, but most  
people will want to put it in a URI; it's up to the server to decide  
how it wants to do it. It would make sense to define a media type for  
a FIQL query if people want to do this, though; I'll add that to the  
next draft.

Cheers,


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 19:03:01 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4mOr-0003Hf-MZ
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 19:03:01 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4mOr-0003M7-3D
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 19:03:01 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINd0wl052977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 16:39:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBINd0Gc052976;
	Tue, 18 Dec 2007 16:39:00 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBINcxNv052967
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 16:39:00 -0700 (MST)
	(envelope-from hwinkler@gmail.com)
Received: by wa-out-1112.google.com with SMTP id l24so4680730waf.22
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 15:38:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=jJ2GGlohJUTD+5WPwLkvHE1Wf8Tg6+xC2n28AJ5JXQs=;
        b=BiqDyHYYb/C8hXTs7+9rcwICIApk7XiWEIo6zX+QseIWT2yjMn6MH1BvFjaMyIqIepfOnmyXhcAOKCEYrU1VwukZZlCuHIJuN1L39hmLf381xJyKYTMNxVYqzyWi4jbDXIX8YuPmvimpCVoUYxhgPVNx4vlUWnW1J1flXd0MPX0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=ELWoR0j5TrX+7YVgtLtnoeZohOyB1lszXAh0FEz5sFY0DL3lsh84EIBg36UhenYvtA27n//PQckk6GUpWZw8ZZnmhpb3xiV+57IzaMkuUSzLCIeHI0g942u4RDRw6JTwOqc1OFrL89lpwKbubV/bV96CfBcqNzksQT3w0kFZ5Z8=
Received: by 10.114.78.1 with SMTP id a1mr4703836wab.14.1198021137417;
        Tue, 18 Dec 2007 15:38:57 -0800 (PST)
Received: by 10.114.92.9 with HTTP; Tue, 18 Dec 2007 15:38:57 -0800 (PST)
Message-ID: <927441b30712181538s4bd627f2qc5adf87d42528c68@mail.gmail.com>
Date: Tue, 18 Dec 2007 17:38:57 -0600
From: "Hugh Winkler" <hughw@wellstorm.com>
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
In-Reply-To: <B369E44F-6ECE-4621-A9F7-B2609A4FCDCC@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
	 <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
	 <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com>
	 <B369E44F-6ECE-4621-A9F7-B2609A4FCDCC@mnot.net>
X-Google-Sender-Auth: 80a2feca92afcbe0
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4


On Dec 18, 2007 5:26 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> On 19/12/2007, at 10:14 AM, Hugh Winkler wrote:
> >
> > I'm uncomfortable with prescribing how to construct URIs (sec. 4),
> > aren't you?
>
> Why? HTML forms does it, and they're pretty successful.
>

Sure. But the server implementer has control over the eventual
constructed URL. The server can even send javascript down and
construct an URL without a query part. Either way, using HTML form or
javascript, the server provides the code that constructs the URL.


> > It takes control of the URI namespace away from the
> > server.
>
> Just as with forms, this only specifies a format that's meaningful if
> the server chooses to use it; it doesn't foist itself upon the URL.
>


Not sure I understand what you're saying here. Looked to me like you
contemplate clients sending GETs to URLs they construct without any
guidance from the server?

> > You can get the effect you want by POSTing an entity
> > containing the FIQL string (give it mime type application/fiql say)
> > and allowing the server to respond directly with the result, or return
> > 303 to the URI of a cacheable representation. Let the server construct
> > the URI.
>
> POSTing a query works, but for whatever reason, people don't like the
> added step.

What extra step? the client just sends the FIQL string as an entity in
a POST rather than tacking it to the URL of a GET.

>The draft doesn't rule that out, of course, but most
> people will want to put it in a URI; it's up to the server to decide
> how it wants to do it. It would make sense to define a media type for
> a FIQL query if people want to do this, though; I'll add that to the
> next draft.
>

Heck, Mark, I even threw in a cacheability argument ;)

> Cheers,
>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>



-- 
Hugh Winkler, CEO
Wellstorm Development

http://www.wellstorm.com/
+1 512 694 4795 mobile (preferred)
+1 512 264 3998 office




From owner-atom-syntax@mail.imc.org Tue Dec 18 19:42:22 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4n0w-0004Qt-Bm
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 19:42:22 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4n0v-0003y4-VT
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 19:42:22 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ0PHJm056485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 17:25:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ0PHmX056484;
	Tue, 18 Dec 2007 17:25:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.246.225])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ0PGgg056477
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 17:25:17 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.19]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Tue, 18 Dec 2007 16:25:16 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 18 Dec 2007 16:25:16 -0800
Message-ID: <BAY141-DAV9A5BAD466636EBBCE397BBE5C0@phx.gbl>
Received: from 85.211.248.249 by BAY141-DAV9.phx.gbl with DAV;
	Wed, 19 Dec 2007 00:25:15 +0000
X-Originating-IP: [85.211.248.249]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "Atom-Syntax Syntax" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Wed, 19 Dec 2007 00:25:10 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 19 Dec 2007 00:25:16.0412 (UTC) FILETIME=[A0F21BC0:01C841D5]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


> By default, a selector is treated as an XML QName
> [W3C.REC-xml-names-19990114] which selects any and all child elements
> of the entry element which share the same syntax (i.e., the same
> prefix and localname; the namespace URI is not considered)

I'm not sure I follow this. If the selector is "title", and your entry looks 
like this:

<a:entry xmlns:a="http://www.w3.org/2005/Atom">
  <a:title>Test</a:title>
</a:entry>

does that mean you won't match anything?

Regards
James




From owner-atom-syntax@mail.imc.org Tue Dec 18 20:10:56 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4nSZ-0007DP-Vu
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:10:56 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4nSZ-0004Ng-B1
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:10:55 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ0uLCF058184
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 17:56:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ0uLbo058183;
	Tue, 18 Dec 2007 17:56:21 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ0uKmR058177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 17:56:21 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id B0962D04FF;
	Tue, 18 Dec 2007 19:56:19 -0500 (EST)
From: Mark Nottingham <mnot@mnot.net>
To: James Holderness <j4_james@hotmail.com>
In-Reply-To: <BAY141-DAV9A5BAD466636EBBCE397BBE5C0@phx.gbl>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
X-Priority: 3
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <BAY141-DAV9A5BAD466636EBBCE397BBE5C0@phx.gbl>
Message-Id: <146FDC83-676A-425A-A732-690079D6A066@mnot.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 19 Dec 2007 11:56:17 +1100
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a


Yes; if you wanted to select on a:title, you'd use a:title (or, more  
likely, use the default namespace for Atom).


On 19/12/2007, at 11:25 AM, James Holderness wrote:

>
>> By default, a selector is treated as an XML QName
>> [W3C.REC-xml-names-19990114] which selects any and all child elements
>> of the entry element which share the same syntax (i.e., the same
>> prefix and localname; the namespace URI is not considered)
>
> I'm not sure I follow this. If the selector is "title", and your  
> entry looks like this:
>
> <a:entry xmlns:a="http://www.w3.org/2005/Atom">
> <a:title>Test</a:title>
> </a:entry>
>
> does that mean you won't match anything?
>
> Regards
> James
>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 20:16:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4nY3-0000v8-N5
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:16:35 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4nY3-0004V7-3j
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:16:35 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ139xl058582
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 18:03:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ139dD058581;
	Tue, 18 Dec 2007 18:03:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1375j058574
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 18:03:08 -0700 (MST)
	(envelope-from hwinkler@gmail.com)
Received: by fg-out-1718.google.com with SMTP id 22so473119fge.26
        for <atom-syntax@imc.org>; Tue, 18 Dec 2007 17:03:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        bh=T8/4oosxRNphtkES4qOUMbOX/Q31Hf6DsczBi7uR+DM=;
        b=eTUNRfoy4XyrqjX2Dw+E6/YbuuGDa2YjMtVNXkuv1/J7S7MidFqMD6QCs4zcSOzUEWd8bbAkQBzlgzEZkT2zLY7u4vbJRbHH4t3ZEuRrt9oNw4netSMjIcPUNzzg9bUlx4IxqPCn3Qn9VnI5hZXn0Z9nIaFhj1/wo/rd6cvq0Oc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=wRfml9clI6X6AnLm1LA8ajCxjjDJDzYEIZ14YN59Tob5zrf66B5SPe3dGgEB5JRWW4ZGyVOwd2recWRr/F9sjXgcs8WfTxzHFBzPJ4y0RpEY/qAVmB2aABpAv9SO0MZ76isMe/vM7Oo836N6EDvt0axySLcK/jVCbphtbPmPqDU=
Received: by 10.86.51.2 with SMTP id y2mr8295427fgy.56.1198026186848;
        Tue, 18 Dec 2007 17:03:06 -0800 (PST)
Received: by 10.86.92.4 with HTTP; Tue, 18 Dec 2007 17:03:06 -0800 (PST)
Message-ID: <927441b30712181703p722b9c4fg1e4d6029b52550ef@mail.gmail.com>
Date: Tue, 18 Dec 2007 19:03:06 -0600
From: "Hugh Winkler" <hughw@wellstorm.com>
To: "Mark Nottingham" <mnot@mnot.net>,
        "Atom-Syntax Syntax" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
In-Reply-To: <B79FF03A-BE22-4FFB-9F8D-604ABB665FFE@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
	 <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
	 <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com>
	 <B369E44F-6ECE-4621-A9F7-B2609A4FCDCC@mnot.net>
	 <927441b30712181538s4bd627f2qc5adf87d42528c68@mail.gmail.com>
	 <FFAE509B-B60A-4F27-9D50-367268F7C2A1@mnot.net>
	 <927441b30712181641n314566f4ka615ffb78d6bdcf6@mail.gmail.com>
	 <B79FF03A-BE22-4FFB-9F8D-604ABB665FFE@mnot.net>
X-Google-Sender-Auth: b00394771c120f61
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86


[ part of this exchange happened off list, replying to list]
On Dec 18, 2007 6:55 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>
> On 19/12/2007, at 11:41 AM, Hugh Winkler wrote:
>
> > On Dec 18, 2007 5:48 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >>
> >> On 19/12/2007, at 10:38 AM, Hugh Winkler wrote:
> >>>> Why? HTML forms does it, and they're pretty successful.
> >>>
> >>> Sure. But the server implementer has control over the eventual
> >>> constructed URL. The server can even send javascript down and
> >>> construct an URL without a query part. Either way, using HTML form
> >>> or
> >>> javascript, the server provides the code that constructs the URL.
> >>
> >> As does it here, using the hints in fq:interface. Admittedly, it's a
> >> pretty constrained set of hints, but so are HTML forms, really.
> >
> > Hrrm. I hadn't picked up the forms-like nature of fq:interface
> >
> >>>>> You can get the effect you want by POSTing an entity
> >>>>> containing the FIQL string (give it mime type application/fiql
> >>>>> say)
> >>>>> and allowing the server to respond directly with the result, or
> >>>>> return
> >>>>> 303 to the URI of a cacheable representation. Let the server
> >>>>> construct
> >>>>> the URI.
> >>>>
> >>>> POSTing a query works, but for whatever reason, people don't like
> >>>> the
> >>>> added step.
> >>>
> >>> What extra step? the client just sends the FIQL string as an
> >>> entity in
> >>> a POST rather than tacking it to the URL of a GET.
> >>
> >> Right, but then it has to remember the Location that it gets back,
> >> and
> >> remember to fetch it in the future. I get a certain amount of
> >> resistance to this when I suggest this to devs. *shrug*
> >
> > They don't have to do that if they don't want to. They can just POST
> > the entity each time and consume the response. That's no more trouble
> > than doing GET, and in most cases no less efficient since the '?'
> > suppresses many caches.
>
> But the point is to enable caching...
>

Right. Well the most cacheable way is POST + 303. Then the devs do
have to record the Location header. But GET url + '?' + query string
won't cache much of the time. Maybe that's getting better, and I'm
sure you're more up to date with the state of the art. But my pretty
recent Squid doesn't do it out of the box.

>
> >> In any case, I'm happy expanding section 4 to include the POST case,
> >> and defining a media type.
> >>
> >>>> The draft doesn't rule that out, of course, but most
> >>>> people will want to put it in a URI; it's up to the server to
> >>>> decide
> >>>> how it wants to do it. It would make sense to define a media type
> >>>> for
> >>>> a FIQL query if people want to do this, though; I'll add that to
> >>>> the
> >>>> next draft.
> >
> > not sure I feel so strongly about this that I'd want to muddy the
> > waters with alternatives. Let's see if there's any traction.
> >
> > (btw you replied off-list)
>
> Oops, sorry, feel free to forward.
>
>
>
> >>> Heck, Mark, I even threw in a cacheability argument ;)
> >>
> >> You nearly had me :)
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


Hugh




From owner-atom-syntax@mail.imc.org Tue Dec 18 20:24:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4nfr-0000wy-Kw
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:24:39 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4nfr-0004yU-6Y
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:24:39 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1CUr5059393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 18:12:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ1CUAr059392;
	Tue, 18 Dec 2007 18:12:30 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1CTu8059386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 18:12:29 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id DCA19D059E
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 20:12:28 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Wed, 19 Dec 2007 08:12:29 +0700
Message-ID: <005901c841dc$3ac7c3c0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Thread-Index: AchBxo59zOGjuqF2R72u596B+s6F7QAEmJ/w
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


Mark Nottingham wrote:

> I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
> FYI; I'd love any feedback folks have on this.

Why not XPath or XQuery or SPARQL (with an Atom/RDF mapping), or CSS
selectors or some subset of one of those? I guess one reason is to
abstract away Atom vs. RSS and the other reason is that namespace
proliferation in Atom/RSS documents is out of control. Those are valid
concerns but I think making namespace handling even more insane is not
the answer.

"By default, a selector is treated as an XML Qname which selects any and
all child elements of the entry element which share the same syntax
(i.e., the same prefix and localname; the namespace URI is not
considered), along with their descendant content if any." 

That is not acceptable. First, namespace handling in feed-consuming
software is bad enough as it is. And, secondly, this provides an
unnuecesssary burden on the server to preserve Qnames and prevent Qname
conflicts.

In my software, I preserve the Qnames of attributes and elements as long
as the underlying XML (SAX and XSLT) stack provides enough information
to preserve them. Unfortunately, a LOT of XML stacks do not provide
enough information to preserve QNames exactly; Python's default SAX
parser (pyexpat) and most XSLT processors (in any language binding)
don't preserve Qnames accurately enough. As a result, the Qname of any
element or attribute might change as it moves between storage and the
HTTP interface and cannot be relied upon.

- Brian




From owner-atom-syntax@mail.imc.org Tue Dec 18 20:24:43 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4nfv-0001BP-Og
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:24:43 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4nfv-0004yc-Cj
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:24:43 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1CPfd059384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 18:12:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ1CPEb059383;
	Tue, 18 Dec 2007 18:12:25 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1COHp059377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 18:12:24 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 2D977D0501;
	Tue, 18 Dec 2007 20:12:22 -0500 (EST)
Cc: "Atom-Syntax Syntax" <atom-syntax@imc.org>
Message-Id: <6E0450DD-6E60-461D-B5B4-BC582ABD4795@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: "Hugh Winkler" <hughw@wellstorm.com>
In-Reply-To: <927441b30712181703p722b9c4fg1e4d6029b52550ef@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Wed, 19 Dec 2007 12:12:20 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <927441b30712181514l6005ce98o40295333d7ff6d2f@mail.gmail.com> <B369E44F-6ECE-4621-A9F7-B2609A4FCDCC@mnot.net> <927441b30712181538s4bd627f2qc5adf87d42528c68@mail.gmail.com> <FFAE509B-B60A-4F27-9D50-367268F7C2A1@mnot.net> <927441b30712181641n314566f4ka615ffb78d6bdcf6@mail.gmail.com> <B79FF03A-BE22-4FFB-9F8D-604ABB665FFE@mnot.net> <927441b30712181703p722b9c4fg1e4d6029b52550ef@mail.gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


Not out of the box, but there's been discussion of changing it IIRC.  
The RFC says that queries shouldn't be cached if there isn't explicit  
freshness information, so there's still the opportunity. Browsers will  
cache queries now, BTW.

Cheers,


On 19/12/2007, at 12:03 PM, Hugh Winkler wrote:

> Maybe that's getting better, and I'm
> sure you're more up to date with the state of the art. But my pretty
> recent Squid doesn't do it out of the box.


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 20:29:05 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4nk9-0007fK-Ml
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:29:05 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4nk9-00052t-B7
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 20:29:05 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1FsGC059567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 18:15:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ1FsJm059566;
	Tue, 18 Dec 2007 18:15:54 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1FrS3059559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 18:15:54 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 43306D051E
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 20:15:53 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net>	 <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com>	 <47563598.3020108@gmail.com>	 <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net>	 <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>	 <47676162.3050207@gmail.com>	 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>	 <000901c841a2$63f64350$0701a8c0@Junk>	 <3f1451f50712181039s6868f620u7835e62b4a36a5c0@mail.gmail.com>	 <001c01c841a9$382f46c0$0701a8c0@Junk> <3f1451f50712181133u775dab54vcf67aca5105404ae@mail.gmail.com> <4768294F.60409@gmail.com> <0EF46214-A2BB-40B9-B96D-7E3D16DFF665@mnot.net>
Subject: RE: Tombstones
Date: Wed, 19 Dec 2007 08:15:43 +0700
Message-ID: <006301c841dc$b4a26010$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <0EF46214-A2BB-40B9-B96D-7E3D16DFF665@mnot.net>
Thread-Index: AchBxUwHTJ5U4GgWTJmJg0rkse165QAFxBZQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


Mark Nottingham wrote:
> FWIW, I think a small individual submission on the standards 
> track would be the way to go here, defining a single new 
> feed-level element (preferably in the Atom namespace; I hope 
> we left ourselves enough wiggle room to do that!).

+1 on stuffing it in the Atom namespace or some other namespace that is
commonly being used for stuff; The current way of having a new namespace
for feature is getting increasingly awkward; we have documents where the
namespace declarations outweigh the rest of the metadata.

- Brian




From owner-atom-syntax@mail.imc.org Tue Dec 18 21:01:29 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4oFV-0002C0-JN
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:01:29 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4oFT-0005Yc-Se
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:01:29 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1ji9N061405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 18:45:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ1jiVu061404;
	Tue, 18 Dec 2007 18:45:44 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ1jhg2061398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 18:45:44 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 11809D0502;
	Tue, 18 Dec 2007 20:45:41 -0500 (EST)
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Message-Id: <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Brian Smith <brian@briansmith.org>
In-Reply-To: <005901c841dc$3ac7c3c0$0701a8c0@Junk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Wed, 19 Dec 2007 12:45:39 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955



On 19/12/2007, at 12:12 PM, Brian Smith wrote:

>
> Mark Nottingham wrote:
>
>> I-D ACTION:draft-nottingham-atompub-fiql-00.txt
>> FYI; I'd love any feedback folks have on this.
>
> Why not XPath or XQuery or SPARQL (with an Atom/RDF mapping), or CSS
> selectors or some subset of one of those?

In a nutshell, there are two reasons;

1) Those query languages are optimised for data models that aren't  
feeds; respectively, XML Infosets, Infosets again, RDF graphs and CSS  
cascades. While it's possible to contort them to fit feeds, they don't  
really lend themselves to it. XQuery and SPARQL also present a fairly  
high barrier to adoption (if you're not a big XML vendor or a SW-head,  
respectively ;) Contorting them so that they're easy to fit into a URL  
isn't too attractive, either.

2) When you expose a query interface, you're allowing people to  
consume compute power on your servers. An arbitrary query language  
allows arbitrary queries, which is unacceptable when you're working  
across administrative domains. FIQL gives you tools to constrain how  
queries are shaped.

I've been asked this many times, and should probably add it as a FAQ  
in an appendix. Certainly there are use cases for using XQuery, etc.  
against feeds, but it's also become apparent that there's a place for  
something simple, reasonably flexible, and Web-friendly.

> "By default, a selector is treated as an XML Qname which selects any  
> and
> all child elements of the entry element which share the same syntax
> (i.e., the same prefix and localname; the namespace URI is not
> considered), along with their descendant content if any."
>
> That is not acceptable. First, namespace handling in feed-consuming
> software is bad enough as it is.

While true, I don't see how that's relevant.

> And, secondly, this provides an
> unnuecesssary burden on the server to preserve Qnames and prevent  
> Qname
> conflicts.
> In my software, I preserve the Qnames of attributes and elements as  
> long
> as the underlying XML (SAX and XSLT) stack provides enough information
> to preserve them. Unfortunately, a LOT of XML stacks do not provide
> enough information to preserve QNames exactly; Python's default SAX
> parser (pyexpat) and most XSLT processors (in any language binding)
> don't preserve Qnames accurately enough. As a result, the Qname of any
> element or attribute might change as it moves between storage and the
> HTTP interface and cannot be relied upon.

I'm open to other suggestions, but this seemed to be the simplest way  
to go about it. Note that the 'name' attribute on the fq:index element  
gives you a way to specify a stable name for a selector that's  
independent of the QName; if you're concerned about these issues, you  
can use that.

Cheers,

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 21:20:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4oYN-0004x6-SP
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:20:59 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4oYN-0005qR-0w
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:20:59 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ26FXU062656
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 19:06:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ26FZM062655;
	Tue, 18 Dec 2007 19:06:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ26Etw062647
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 19:06:14 -0700 (MST)
	(envelope-from pkeane@mail.utexas.edu)
DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns;
    h=Received:Received:Received:Message-ID:Date:From:
      User-Agent:MIME-Version:To:CC:Subject:References:
      In-Reply-To:Content-Type:Content-Transfer-Encoding;
    b=DLOOhg2fOPnWmRzdjpNNJT+Eont1YPTBFKYpYuOwz8PWgxMEf8mA8
      ov9f54AV7dQRQspZx0GKrrW8VPEpRL1GRy5GfBeaVzhA1pp81zOL6
      2hywUgGI18q2Y20UPWf8m8eAp4XbeFV1d9nkggWSb76SvxiiBfhAF
      TDZg/yAHK1Nk=;
Received: from wb9-a.mail.utexas.edu ([128.83.126.150])
  by ironmaiden.mail.utexas.edu with ESMTP; 18 Dec 2007 20:06:14 -0600
Received: (qmail 9648 invoked from network); 19 Dec 2007 02:06:13 -0000
Received: from 24-155-109-135.dyn.grandenetworks.net (HELO ?192.168.0.3?) (pkeane@24.155.109.135)
  by wb9.mail.utexas.edu with (RC4-MD5 encrypted) ESMTPSA; 19 Dec 2007 02:06:13 -0000
Message-ID: <47687C91.7010002@mail.utexas.edu>
Date: Tue, 18 Dec 2007 20:06:09 -0600
From: Peter Keane <pkeane@mail.utexas.edu>
User-Agent: Thunderbird 2.0.0.9 (X11/20071212)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1


This is of great interest to me, having spent the last few weeks 
devising a search query syntax for a digital library which makes 
extensive use of Atom/AtomPub.  Have you see the Contextual Query 
Language which is part of SRU? 
(http://www.loc.gov/standards/sru/specs/cql.html).  Atom is making 
inroads into the library space (note that the recently released OAI-ORE 
spec has an Atom serialization http://www.openarchives.org/ore/0.1/atom) 
and I would LOVE to see a well-thought out query language.  Perhaps FIQL 
is to OpenSearch as CQL is to SRU??  Any thoughts?

-peter keane
daseproject.org


Mark Nottingham wrote:
>
> FYI; I'd love any feedback folks have on this.
>
> Begin forwarded message:
>
>> From: Internet-Drafts@ietf.org
>> Date: 19 December 2007 7:15:02 AM
>> To: i-d-announce@ietf.org
>> Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : FIQL: The Feed Item Query Language
>>     Author(s)    : M. Nottingham
>>     Filename    : draft-nottingham-atompub-fiql-00.txt
>>     Pages        : 16
>>     Date        : 2007-12-18
>>     
>>   The Feed Item Query Language is a simple but flexible, URI-friendly
>>   syntax for expressing filters across the entries in a Web feed.  It
>>   also specifies a mechanism to allow feeds to indicate what types of
>>   queries are supported.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-nottingham-atompub-fiql-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     mailserv@ietf.org.
>> In the body type:
>>     "FILE /internet-drafts/draft-nottingham-atompub-fiql-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2007-12-18145429.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
> -- 
> Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Tue Dec 18 21:28:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4ofh-0008WJ-MH
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:28:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4ofg-0005wX-6L
	for atompub-archive@lists.ietf.org; Tue, 18 Dec 2007 21:28:33 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ2Bw71062997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Dec 2007 19:11:58 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ2Bvbl062996;
	Tue, 18 Dec 2007 19:11:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ2BuGn062986
	for <atom-syntax@imc.org>; Tue, 18 Dec 2007 19:11:57 -0700 (MST)
	(envelope-from pkeane@mail.utexas.edu)
DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns;
    h=Received:Received:Received:Message-ID:Date:From:
      User-Agent:MIME-Version:To:CC:Subject:References:
      In-Reply-To:Content-Type:Content-Transfer-Encoding;
    b=IbPaUz7rEXKt0Q7KeqYKByJoo0CTpAwn8WZ0IBeLokoRjcOOE8DKR
      kWDfoGYQQ9b5VJMrbrCnLOHnDae1zph7CwI0Rcx8EFfwd9tDHtgYX
      8sWnc6jpyiNbRnb8x24uDRMwkCu19U0TDA2S0psisHtRKbPWGJyOw
      mNtUGtDsDins=;
Received: from wb3-a.mail.utexas.edu ([128.83.126.138])
  by ironmaiden.mail.utexas.edu with ESMTP; 18 Dec 2007 20:11:56 -0600
Received: (qmail 46382 invoked from network); 19 Dec 2007 02:11:56 -0000
Received: from 24-155-109-135.dyn.grandenetworks.net (HELO ?192.168.0.3?) (pkeane@24.155.109.135)
  by wb3.mail.utexas.edu with (RC4-MD5 encrypted) ESMTPSA; 19 Dec 2007 02:11:56 -0000
Message-ID: <47687DEB.7030201@mail.utexas.edu>
Date: Tue, 18 Dec 2007 20:11:55 -0600
From: Peter Keane <pkeane@mail.utexas.edu>
User-Agent: Thunderbird 2.0.0.9 (X11/20071212)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
In-Reply-To: <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


Mark Nottingham wrote:
>
> In a nutshell, there are two reasons;
>
> 1) Those query languages are optimised for data models that aren't 
> feeds; respectively, XML Infosets, Infosets again, RDF graphs and CSS 
> cascades. While it's possible to contort them to fit feeds, they don't 
> really lend themselves to it. XQuery and SPARQL also present a fairly 
> high barrier to adoption (if you're not a big XML vendor or a SW-head, 
> respectively ;) Contorting them so that they're easy to fit into a URL 
> isn't too attractive, either.
>
> 2) When you expose a query interface, you're allowing people to 
> consume compute power on your servers. An arbitrary query language 
> allows arbitrary queries, which is unacceptable when you're working 
> across administrative domains. FIQL gives you tools to constrain how 
> queries are shaped.
>
> I've been asked this many times, and should probably add it as a FAQ 
> in an appendix. Certainly there are use cases for using XQuery, etc. 
> against feeds, but it's also become apparent that there's a place for 
> something simple, reasonably flexible, and Web-friendly.
>
+1 this hits the same sort of complexity sweet-spot (i.e., as simple as 
possible w/o being too simple + easily extensible) as Atom/AtomPub and 
thus, it seems to me, has pretty good "conceptual integrity" w/ those.

-peter keane

>
>
> -- 
> Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Wed Dec 19 03:08:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4tyK-0005G6-NO
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 03:08:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4tyI-0005UB-Ot
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 03:08:08 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ7t2g1086950
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 00:55:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ7t2ru086949;
	Wed, 19 Dec 2007 00:55:02 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ7t1Xe086940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 00:55:02 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id D2F46D05A3
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 02:54:59 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Wed, 19 Dec 2007 14:54:44 +0700
Message-ID: <008601c84214$7674e2d0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
Thread-Index: AchB4aKCO/nk8O5GR6+UMa49Whke/QAGSbfQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c


Mark Nottingham wrote:
> On 19/12/2007, at 12:12 PM, Brian Smith wrote:
> > Why not XPath or XQuery or SPARQL (with an Atom/RDF 
> > mapping), or CSS selectors or some subset of one of those?
> 
> In a nutshell, there are two reasons;
> 
> 1) Those query languages are optimised for data models that 
> aren't feeds; respectively, XML Infosets, Infosets again, RDF 
> graphs and CSS cascades. While it's possible to contort them 
> to fit feeds, they don't really lend themselves to it. XQuery 
> and SPARQL also present a fairly high barrier to adoption (if 
> you're not a big XML vendor or a SW-head, respectively ;) 
> Contorting them so that they're easy to fit into a URL isn't 
> too attractive, either.
>
> 2) When you expose a query interface, you're allowing people 
> to consume compute power on your servers. An arbitrary query 
> language allows arbitrary queries, which is unacceptable when 
> you're working across administrative domains. FIQL gives you 
> tools to constrain how queries are shaped.

Developers are used to seeing subsets of XPath. Almost every XPath
implementation I have seen has been a subset of XPath; Sometimes the
explanation was avoidance of DoS (resource consumption) attacks; other
times, the explanation was "we didn't have the resources to implement
all of it." So, I think it is reasonable to attempt to use a subset of
Xpath as a query language.

> Certainly there are use cases for using XQuery, etc.  
> against feeds, but it's also become apparent that there's a 
> place for something simple, reasonably flexible, and Web-friendly.

I agree. But, I'd rather borrow small parts from a well-specified,
widely-deployed, well-understood language than deal with a brand new
one. 

> > That is not acceptable. First, namespace handling in
> > feed-consuming software is bad enough as it is.
> 
> While true, I don't see how that's relevant.

It creates confusion. We spend a lot of time explaining to people that
they should always prefer to match elements by their namespace URI and
never by their prefix. This is making an unnecessary exception to that
rule.

> I'm open to other suggestions, but this seemed to be the 
> simplest way to go about it. Note that the 'name' attribute 
> on the fq:index element gives you a way to specify a stable 
> name for a selector that's independent of the QName; if 
> you're concerned about these issues, you can use that.

The language should not require implementations to match elements and
attributes using the prefixes used in the actual documents. XPath
expressions have a mapping of "statically known namespaces" [1] and the
default element namespace [2]. The fq:index could be the means of
setting up this mapping. Additionally, some extra syntax could be added
to support binding prefixes that are not bound in the fq:index.

I will throw out this suggestion for using a subset of XPath 2.0 as the
constraint language. 

Expr         ::= AndExpr  ( "or"  AndExpr )*
AndExpr      ::= CompExpr ( "and" CompExpr )* 
CompExpr     ::= Value ValueComp Value
               | FunctionCall
               | "(" Expr ")"
Comp		 ::= "eq" | "ne" | "lt" | "le" | "gt" | "ge"
Value        ::= Literal 
               | Path
               | "(" Value ")"
Path		 ::= QName
Literal      ::= NumericLiteral (as defined in XPath)
               | StringLiteral  (as defined in XPath)
FunctionCall ::= "matches" "(" Qname "," RegEx ")"
	         | "matches" "(" Qname "," RegEx "," "'i'" ")"
	         | "not" "(" FunctionCall ")"
RegEx 	 ::= "'" ".*"? CHAR* ".*"? "'"
Char		 ::= <any character except ".", "'", or """> | "\" <any
character>

I believe this language to be very similar to the language that you
specify in the draft, while simultaneously being a pure subset of XPath.
As you can see below, it isn't beautiful. But, I don't think that it is
so ugly that it requires a whole new language to replace it, either. 

The expression would always be considered to be a XPath predicate. That
is, an expression X would be evaluated as:
    atom:entry[X] 
and the resulting node list would be wrapped in an atom:feed element.
The default element namespace binding is the Atom namespace. Analogous
considerations apply to RSS. The default function namespace is
http://www.w3.org/2005/xpath-functions.

FIQL:
  title==foo*;(updated=lt=-P1D,title==*bar)
XPath:
 
(matches(title,'foo.*'))and((updated)lt('-P1D')or(matches(title,'.*bar')
))

FIQL:
  title==*new*,author==bob*
XPath:
  (matches(title,'.*new.*'))or(matches(author,'bob.*'))
  
FIQL:
  title==*great*;ex:rating=gt=4
XPath:
  matches(title,'.*great.*', 'i')or(ex:rating)gt(4)

Further, lets extend the syntax the subset to include a little more
XPath:

Value        ::= Literal 
               | Qname 
               | "(" Value ")"
               | "xs:dateTime" "(" Value ")"
               | "xs:duration" "(" Value ")"
               | "xs:decimal"  "(" Value ")"

Now, the client can explicitly request certain values to be treated as a
specific type in variables, regardless of what the fq:index elements do
or do not say. 

Further, we can expand the syntax of paths to allow us to select nested
elements and/or attributes or anything else that XPath allows. For
example, atom:content/@type.

Regards,
Brian




From owner-atom-syntax@mail.imc.org Wed Dec 19 03:32:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4uLz-00034r-MC
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 03:32:35 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4uLz-0006Ab-1O
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 03:32:35 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ8ICai088535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 01:18:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJ8ICF1088534;
	Wed, 19 Dec 2007 01:18:12 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJ8IBLJ088526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 01:18:11 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 92770D05A3
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 03:18:10 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com>
Subject: RE: Tombstones
Date: Wed, 19 Dec 2007 15:18:12 +0700
Message-ID: <009901c84217$b2cfe830$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4768A714.60703@gmail.com>
Thread-Index: AchB/Wb2NyK7yjeDRxyeYKjXjN7+wQAGG3Eg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88


James M Snell wrote:
> James Holderness wrote:
> > 
> > Brian Smith wrote:
> >> Ha. I already implemented it too, but I used the updated 
> >> syntax that James suggested on his blog
> >> (http://www.snellspace.com/wp/?p=818).
> > 
> > I chose the original syntax because for me it's an order of 
> > magnitude easier to implement. And since I doubt I'm going
> > to see any server support for this either way, I might as
> > well go with whatever is easiest.

I wouldn't be so pessimistic; I think eventually servers will all
implement something like this. 

> FWIW, I have no real preference for either of the two 
> syntaxes so long as we have a way of expressing the atom:id, 
> a timestamp and possibly a source.

Obviously this little detail isn't a deal-breaker, but I think it makes
sense to use the same syntax as <atom:feed>, <atom:entry>, and
<atom:source> (meaning an element instead of an attribute)--especially
if we are going to have <atom:updated> and/or <app:edited> and/or
<atom:source> nested within it.

> >> I think this way makes it clearer how to handle cases 
> >> where an entry was added, we saw it, the entry was deleted,
> >> we saw a tombstone, and then the entry was undeleted, and 
> >> we see the entry again. 
> >> In order to support undelete, we need to be able to order
> >> tombstones and entries by date.
> > 
> > If you're undeleting something, just remove the tombstone from the 
> > feed and add the entry back.
> +1. The timestamp can still be useful when dealing with more complex
> sync use cases.

In particular, without the timestamp(s) it is hard to see how the
tombstones fit in with feed paging and date-range-based queries.

> >> This new syntax also makes it possible to specify a 
> >> <source> of the tombstone, which is needed when dealing
> >> with aggregated feeds,
> > 
> > I was thinking about that too. I don't see how you can 
> > possibly trust a tombstone in an aggregate feed.

If you trust the aggregator, then you can have a policy of matching
tombstones and entries by (source, id). If you don't trust the
aggregator, and you really need to verify the entry was deleted, then
you can use the source metadata to look at the original feed to see if
it contains the tombstones or not.

> > Still, there's nothing stopping you including a source
> > element (or whatever other metadata) in the original syntax.
> > 
> > <x:deleted-entry id="xxx">
> >  <atom:source>
> >     ...
> >  </atom:source>
> > </x:deleted>
> 
> This works. Tombstones in aggregated feeds definitely need to 
> be carefully considered.

I agree the id attribute/element choice doesn't really affect what
atom:source means inside a tombstone.

- Brian




From owner-atom-syntax@mail.imc.org Wed Dec 19 06:52:38 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4xTZ-0004Wk-L9
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 06:52:38 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4xTY-000256-2d
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 06:52:37 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJBSHVv004388
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 04:28:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJBSH2t004387;
	Wed, 19 Dec 2007 04:28:17 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc2-s17.bay0.hotmail.com (bay0-omc2-s17.bay0.hotmail.com [65.54.246.153])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJBSGN0004381
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 04:28:17 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.27]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 19 Dec 2007 03:28:16 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 19 Dec 2007 03:28:16 -0800
Message-ID: <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl>
Received: from 85.211.248.249 by BAY141-DAV17.phx.gbl with DAV;
	Wed, 19 Dec 2007 11:28:15 +0000
X-Originating-IP: [85.211.248.249]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk>
Subject: Re: Tombstones
Date: Wed, 19 Dec 2007 11:28:09 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 19 Dec 2007 11:28:16.0335 (UTC) FILETIME=[3FA0A5F0:01C84232]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17


Brian Smith wrote:
> In particular, without the timestamp(s) it is hard to see how the
> tombstones fit in with feed paging and date-range-based queries.

I don't get this, but if you really need a date, I believe the original 
draft has a "when" attribute that should be suitable. Worst case you can add 
whatever you need as a child element.

> If you trust the aggregator, then you can have a policy of matching
> tombstones and entries by (source, id).

Bare in mind that the aggregator needs to propogate source elements from the 
aggregated feeds. So trusting the aggregator means trusting every feed that 
is aggregated, plus every future feed that might be aggregated. That's an 
awful lot of trust. And you're asking that of the user who is subscribing to 
the feed. I'd love to see the text for that checkbox.

> If you don't trust the
> aggregator, and you really need to verify the entry was deleted, then
> you can use the source metadata to look at the original feed to see if
> it contains the tombstones or not.

Theoretically, sure. Personally there's no way I'm going to download a whole 
new feed for each tombstone just to check if it's real. What if the 
tombstone isn't in the feed anymore? If the feed supports history do you 
start downloading archives to see the tombstone is in one of the archives? 
How many megabytes of data do you download before you give up?

This looks like a potential DOS attack to me. It's just not worth the 
effort, IMHO.

Regards
James




From owner-atom-syntax@mail.imc.org Wed Dec 19 07:17:56 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J4xs4-00017I-5u
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 07:17:56 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J4xs3-0003el-IT
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 07:17:56 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJBsJIt006243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 04:54:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJBsJkK006242;
	Wed, 19 Dec 2007 04:54:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from spunkymail-a11.g.dreamhost.com (sd-green-bigip-177.dreamhost.com [208.97.132.177])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJBsJns006236
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 04:54:19 -0700 (MST)
	(envelope-from macgirvi@uow.edu.au)
Received: from [192.168.0.104] (CPE-58-168-31-3.nsw.bigpond.net.au [58.168.31.3])
	by spunkymail-a11.g.dreamhost.com (Postfix) with ESMTP id CE90CB86E7;
	Wed, 19 Dec 2007 03:54:19 -0800 (PST)
Message-ID: <47690660.8000101@uow.edu.au>
Date: Wed, 19 Dec 2007 22:54:08 +1100
From: Mike Macgirvin <macgirvi@uow.edu.au>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <A13E18EF-D699-4A1C-BC68-98EF2726D3E6@mnot.net> <47562422.40408@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FE70416E@NA-EXMSG-C103.redmond.corp.microsoft.com> <47563598.3020108@gmail.com> <20071206124519.ik4txj8s2skkccs0@webmail.djpowell.net> <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk>
In-Reply-To: <009901c84217$b2cfe830$0701a8c0@Junk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c


>> +1. The timestamp can still be useful when dealing with more complex
>> > sync use cases.
> 
> In particular, without the timestamp(s) it is hard to see how the
> tombstones fit in with feed paging and date-range-based queries.
>

This concerned me as well. Without it, the end result is a server 
spitting out tombstones for every item that's ever been deleted on every 
   feed request - since it has no knowledge of what the client is 
holding and what the client is interested in holding/syncing.

I was also concerned about this during the prev/next discussions but bit 
my tongue when folks suggested that a page they've seen before shouldn't 
ever change. I don't agree. I just edited an entry from 1968. It might 
be buried on either page=279 or weblog/AUG-1968, but either way; it 
changed and a client that really wants to keep in sync should be made 
aware that a change was made. I also recently removed some copyrighted 
material from my site, but couldn't remove said items from the perma 
cache of a certain news reader whose company motto is 'Do No Evil'. 
Looks like a DMCA take-down is the only way to get them to flush the 
nuked entries.

How does one sync this stuff? The only thing that makes sense is for the 
client to tell the server what the client is holding and what it is 
interested in syncing. Then one can look at modification times and 
gather a list of changes to push out. In the case of a file from 1968 
that was modified, a collection of updated entries starting at a client 
specified time could be pushed.

In the case of deletions, there are a few possibilities. It would 
actually be a good idea in theory for the client to tell the server what 
ID's it already has. All of them. Then the server can respond saying 
that id 1234 was deleted. This is hardly efficient, but removes any need 
for the server to maintain state about deleted items.  So I can concede 
that the quick and dirty solution is for the server to keep a tombstone 
list, even if I find it personally disturbing for the server to maintain 
this state. Given these constraints the only thing that makes sense in 
terms of normal 'feeds' is to emit these in the proper 'order' with 
whatever other entries are being emitted. But there's no historical 
starting point. No knowledge of what the client is holding. So you've 
gotta' send out all deletions. All of them. Evey time a client connects. 
Forever. At least if they're in item order, you can limit the deleted 
item list to the range of items currently being emitted. This might work 
in the classic sense of 'working'; at least there's some means of 
communicating deletions, but it doesn't solve the copyright take-down 
problem for items that fall outside of the current requested feed range.

The right way to do it is to emit these via a 'sync' operation where the 
client specifies a start date of interest, and a date of the last 
request it made for changes.  Then you can figure out that the client's 
earliest cared about entry is in 1943, and you can send back the message 
from 1968 that was updated last week, as well as the deletion of a 
copyrighted message from 1982 that happened yesterday. When the client 
connects again next week, you'll have another set of changes that 
occurred since now. This is the most efficient way of doing it (ignoring 
the inefficiencies of protocol chatter).

So we're back to square one. To really do it right, it needs to be a 
client initiated operation because only the client knows what it has, 
what it cares about, and when it last checked. Anything else is a hack 
that will likely not survive.

mike




From owner-atom-syntax@mail.imc.org Wed Dec 19 10:20:53 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J50j7-0004uh-75
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 10:20:53 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J50j5-0008FL-PV
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 10:20:53 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJF4o16021666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 08:04:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJF4oM0021665;
	Wed, 19 Dec 2007 08:04:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBJF4ln4021657
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 08:04:48 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Dec 2007 15:04:47 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp053) with SMTP; 19 Dec 2007 16:04:47 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1833DAfekU31KK5P5vcJkFvsC+mM8OxyTzaYXTEBl
	JGsN/H+ExahVMj
Date: Wed, 19 Dec 2007 16:04:46 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom WG Syndication Format <atom-syntax@imc.org>
Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Message-ID: <20071219150446.GW15399@klangraum>
Mail-Followup-To: Atom WG Syndication Format <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2


* Mark Nottingham <mnot@mnot.net> [2007-12-18 23:45]:
>> From: Internet-Drafts@ietf.org
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt

Also http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00

(Opinion, if any, to follow later.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Dec 19 10:30:03 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J50rz-0006gT-SW
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 10:30:03 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J50ry-0008T9-G6
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 10:30:03 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJF21t3021539
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 08:02:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJF21mb021538;
	Wed, 19 Dec 2007 08:02:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBJF1xYV021527
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 08:02:00 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Dec 2007 15:01:58 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp058) with SMTP; 19 Dec 2007 16:01:58 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX181fZtg/bE1AXdYA13ftOkImdJvBV+xwHdQqK0MO0
	FWxNBiagrppLIz
Date: Wed, 19 Dec 2007 16:01:57 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
Message-ID: <20071219150157.GU15399@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBJF21t3021539
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


* James Holderness <j4_james@hotmail.com> [2007-12-19 12:45]:
> Brian Smith wrote:
>> In particular, without the timestamp(s) it is hard to see how
>> the tombstones fit in with feed paging and date-range-based
>> queries.
>
> I don't get this

Imagine a wiki where you can delete as well as undelete pages.
Atom IDs are associated with pages, not single versions of a
page. You want to represent the history of a page in an Atom
feed. If tombstones lack datetimestamps, you can=E2=80=99t.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Dec 19 11:04:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J51PY-0005yr-F8
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:04:44 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J51PY-0000et-1C
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:04:44 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJFjviU025228
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 08:45:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJFjvTN025227;
	Wed, 19 Dec 2007 08:45:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s31.bay0.hotmail.com (bay0-omc1-s31.bay0.hotmail.com [65.54.246.103])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJFju0q025221
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 08:45:56 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.22]) by bay0-omc1-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 19 Dec 2007 07:45:56 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 19 Dec 2007 07:45:56 -0800
Message-ID: <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
Received: from 85.211.248.249 by BAY141-DAV12.phx.gbl with DAV;
	Wed, 19 Dec 2007 15:45:55 +0000
X-Originating-IP: [85.211.248.249]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl> <20071219150157.GU15399@klangraum>
Subject: Re: Tombstones
Date: Wed, 19 Dec 2007 15:45:50 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 19 Dec 2007 15:45:56.0265 (UTC) FILETIME=[3E76C190:01C84256]
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBJFjviU025228
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f


A. Pagaltzis wrote:
> Imagine a wiki where you can delete as well as undelete pages.
> Atom IDs are associated with pages, not single versions of a
> page. You want to represent the history of a page in an Atom
> feed. If tombstones lack datetimestamps, you can=E2=80=99t.

Sure you could do that, but it would be completely useless to a typical f=
eed=20
reader, which is all I care about (and I thought that was Brian's interes=
t=20
too).

What would be useful (to a feed reader) is the kind of feed that Wikipedi=
a=20
already produces. That does a great job of representing wiki history and =
it=20
doesn't require tombstones of any kind.

I understand that there are all sorts of exciting things that people may=20
want to do with feeds. However, all I'm interested in is feeds that are o=
f=20
use to a general purpose feed reader. And the same goes for what I want i=
n a=20
tombstone spec.

If there are people that want to do other things with tombstones related =
to=20
publishing or two-way syncing or whatever, that's great. I just don't see=
=20
why we have to try and share the same protocol if it means making my life=
=20
more difficult.

Regards
James




From owner-atom-syntax@mail.imc.org Wed Dec 19 11:42:01 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J51zd-0006Oj-7V
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:42:01 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J51za-0001hH-1W
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:42:01 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJGGj2F028061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 09:16:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJGGjvn028060;
	Wed, 19 Dec 2007 09:16:45 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBJGGhW4028053
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 09:16:44 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Dec 2007 16:16:42 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp053) with SMTP; 19 Dec 2007 17:16:42 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1+T3/s3UQSTm19TD91IEWUba/+6knR85fEU5GNK/F
	kD2yX8g6CK0PBX
Date: Wed, 19 Dec 2007 17:16:41 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: Atom WG Syndication Format <atom-syntax@imc.org>
Subject: Re: Tombstones
Message-ID: <20071219161641.GZ15399@klangraum>
Mail-Followup-To: Atom WG Syndication Format <atom-syntax@imc.org>
References: <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl> <20071219150157.GU15399@klangraum> <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBJGGj2F028061
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


* James Holderness <j4_james@hotmail.com> [2007-12-19 17:00]:
> Sure you could do that, but it would be completely useless to a
> typical feed reader, which is all I care about (and I thought
> that was Brian's interest too).

Socialtext produces such feeds. I complained that they=E2=80=99re pretty
useless in Liferea and was told that they work great in
NetNewsWire, which all of the devs use, which is why no one felt
a pressing need to provide diff feeds.

Some feed readers are more typical than others.

> What would be useful (to a feed reader) is the kind of feed
> that Wikipedia already produces. That does a great job of
> representing wiki history and it doesn't require tombstones of
> any kind.

Ever subscribe the history of a page that got merged or renamed?
I wouldn=E2=80=99t say it does a great job, exactly. It conveys the
minimum information necessary to be useful to clients without
local change tracking and not really anything more.

> I just don't see why we have to try and share the same protocol
> if it means making my life more difficult.

The newer proposal uses attribute-less child elements where the
old one used attributes. I don=E2=80=99t see how that possibly makes your
life more difficult.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Dec 19 11:50:47 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5287-0007zs-0T
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:50:47 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5286-0001p8-GC
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 11:50:46 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJGXFH3029465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 09:33:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJGXFnu029464;
	Wed, 19 Dec 2007 09:33:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJGXEPZ029457
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 09:33:14 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Wed, 19 Dec 2007 08:33:13 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.8]) by
 tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) with mapi; Wed,
 19 Dec 2007 08:33:13 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James Holderness <j4_james@hotmail.com>,
        "'Atom-Syntax'"
	<atom-syntax@imc.org>
Date: Wed, 19 Dec 2007 08:33:10 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: AchCWQC8iuEoPGdJQ82Jdgen5vuEpwAApRXA
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
 <47676162.3050207@gmail.com>
 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
 <000901c841a2$63f64350$0701a8c0@Junk>
 <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl>
 <004f01c841d8$26a33270$0701a8c0@Junk>
 <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com>
 <009901c84217$b2cfe830$0701a8c0@Junk>
 <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl>
 <20071219150157.GU15399@klangraum>
 <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
In-Reply-To: <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lBJGXEPY029459
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d


James Holderness wrote:

> If there are people that want to do other things with tombstones related to
> publishing or two-way syncing or whatever, that's great. I just don't see
> why we have to try and share the same protocol if it means making my life
> more difficult.

Looking at the discussion over the past day, I've had the same feeling but from a different perspective.

In general, I agree with the principle from James Snell earlier in the thread:

> Which brings us back to one of my original points: it would make the
> most sense to have a single solution that works well across as many use
> cases as possible.

But there's definitely a balance to be achieved. It would be helpful to take a few steps back and spend some time discussing the scenarios, not just the technical details. From this thread, I've seen a few (not mutually exclusive) ideas described:

1) "hard" delete: delete an item and it's gone forever
2) "soft" delete: you can delete an item but the data and metadata are preserved so that you can un-delete the item
3) ability to delete comments from a blog for spam control
4) ability to delete posts from a blog
5) full two-way sync between nodes via feeds
6) ability to verify the source of an entry or tombstone

And there are probably more that I missed.

Steven




From owner-atom-syntax@mail.imc.org Wed Dec 19 12:29:21 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J52jQ-0002cx-VT
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 12:29:20 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J52jQ-0002Z5-Gy
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 12:29:20 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJH7FAq032171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 10:07:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJH7FvJ032170;
	Wed, 19 Dec 2007 10:07:15 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJH7Ebm032164
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 10:07:15 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by nz-out-0506.google.com with SMTP id n1so1532084nzf.4
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 09:07:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=4jtfZohXZA+bDcWNfZdozmj6tAVQsrbmLs/BGNjtOoI=;
        b=LARW9mBL1/mVhm8U46IlaetQv/QqyZDWRs5u0Kg6Oz07jMju1WBo/ry4Cb9JDazlZtEse/TpCKZPlAFETcXnsw9jO2ObEnC5YqWbQCHzv56k0mv3kzPlIQxeLpSQ+0l/7ujNn6/LZT7f0uGSE2dLGVonkmqnZ3iTxjvxRyIw7wc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=tYMmh5co4DINU2MOaXbccX0Tp80kX4GXaWqh6LT98Zem8MNXaBBg+9pDN71MVNSXAdo0GCRuCHcLBLv46VsCKWzK8YY3edrJ5JJe1qqlVBIBux2O0kxuz+uew5wLo4EVt0Rqp97E43115XWiy01avMnmgPIIVSEs2p8CQOoA4Cs=
Received: by 10.140.177.15 with SMTP id z15mr3369240rve.110.1198084033793;
        Wed, 19 Dec 2007 09:07:13 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id l32sm3542231rvb.2007.12.19.09.07.12
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 19 Dec 2007 09:07:12 -0800 (PST)
Message-ID: <47694FB7.7040100@gmail.com>
Date: Wed, 19 Dec 2007 09:07:03 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steven Lees <Steven.Lees@microsoft.com>
CC: James Holderness <j4_james@hotmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl> <20071219150157.GU15399@klangraum> <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com>
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 1.8 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228


Steven Lees wrote:
> James Holderness wrote:
> 
> [snip]
> But there's definitely a balance to be achieved. It would be helpful to take a few steps back and spend some time discussing the scenarios, not just the technical details. From this thread, I've seen a few (not mutually exclusive) ideas described:
> 
> 1) "hard" delete: delete an item and it's gone forever
> 2) "soft" delete: you can delete an item but the data and metadata are preserved so that you can un-delete the item
> 3) ability to delete comments from a blog for spam control
> 4) ability to delete posts from a blog
> 5) full two-way sync between nodes via feeds
> 6) ability to verify the source of an entry or tombstone
> 
> And there are probably more that I missed.
>

7. one way (master-replica) full and incremental sync.
8. ability to notify aggregators that content must be removed for legal
reasons (e.g. dmca... blech)

A common thread across all these scenarios is the need to explicitly
indicate the fact that an entry has been removed from a feed.  Given
that, it would make sense to have a commonly defined tombstone
mechanism.  It also seems clear that the representation of deleted items
is distinct from the ability to perform a sync, so it would make sense
to separate those as well.  Having a separate Tombstones spec is making
a whole lot of sense at this point.

- James




From owner-atom-syntax@mail.imc.org Wed Dec 19 13:04:03 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J53H1-0005OL-AM
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 13:04:03 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J53Gz-0003mx-Pm
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 13:04:03 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJHllex035778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 10:47:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJHll5W035775;
	Wed, 19 Dec 2007 10:47:47 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc2-s29.bay0.hotmail.com (bay0-omc2-s29.bay0.hotmail.com [65.54.246.165])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJHlkQ3035768
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 10:47:46 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.16]) by bay0-omc2-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 19 Dec 2007 09:47:46 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 19 Dec 2007 09:47:45 -0800
Message-ID: <BAY141-DAV6AD8509F49F4E06AAB33DBE5C0@phx.gbl>
Received: from 85.211.248.249 by BAY141-DAV6.phx.gbl with DAV;
	Wed, 19 Dec 2007 17:47:41 +0000
X-Originating-IP: [85.211.248.249]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "Atom WG Syndication Format" <atom-syntax@imc.org>
References: <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl> <20071219150157.GU15399@klangraum> <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl> <20071219161641.GZ15399@klangraum>
Subject: Re: Tombstones
Date: Wed, 19 Dec 2007 17:47:36 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="UTF-8";
	reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 19 Dec 2007 17:47:45.0951 (UTC) FILETIME=[436052F0:01C84267]
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBJHllex035778
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a


A. Pagaltzis wrote:
> The newer proposal uses attribute-less child elements where the
> old one used attributes. I don=E2=80=99t see how that possibly makes yo=
ur
> life more difficult.

I assure you I'm not making this up. Processing an attribute-less child=20
element would require considerably more code for me than the initial=20
attribute-based proposal. Blame it on poor design if you will.

Now I have no desire to limit other people's choices because of my proble=
ms,=20
but until someone is producing feeds that require such a format (and thos=
e=20
feeds are of some use to me), I'm not going to waste my time writing code=
 to=20
deal with them.

I really don't want to spend any more time arguing with anyone about this=
.=20
I've told you what I'm doing so that anyone that wants to do something=20
compatible can do so. If nobody does, then that's fine with me too.

Regards
James




From owner-atom-syntax@mail.imc.org Wed Dec 19 13:41:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J53rB-0007sF-6M
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 13:41:25 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J53rA-0004Wf-2T
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 13:41:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJIFSUv037974
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 11:15:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJIFS8M037973;
	Wed, 19 Dec 2007 11:15:28 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJIFRwm037966
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 11:15:27 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so755174anc.44
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 10:15:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=xxdAQwgd1ahEtsQc4H9QcSb0Xp/gMrX3KgYpDvtV2MU=;
        b=p1V2bjlXIuz4NvhsxP/Dyxd2n/0ICm21/RN3zfe777hyhigpR351f018L9jD6h4aKfTtAIhbYOHYIIn4QZ1tOuyqjb3HAeK00OP+69S75yFcaxrC32u9B8e8txbaw8uUDS/KW3bQGXQETiR/1jALlLZT1sMrHjo/Gpldgv3RCJU=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=Qz+iCqXnZo0v2LQ8riQ86HtPkSvK1SJNV/sR40VbvCA+hJvbHoMIFmHTiQ8v9eNA5gnMKJgo9gG5obvK7xdrZ9d7LsFfuCqkxbwQLCJDu2PxxGgKML4F6/ljDNEylnRJEw36Z9y8XfpUlUWiOB5Pqtk+iKoAZ3Nxaky0kY6sUmk=
Received: by 10.101.67.11 with SMTP id u11mr20960704ank.16.1198088126687;
        Wed, 19 Dec 2007 10:15:26 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id 34sm25498208agc.2007.12.19.10.15.25
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 19 Dec 2007 10:15:26 -0800 (PST)
Message-ID: <47695FB3.2030809@gmail.com>
Date: Wed, 19 Dec 2007 10:15:15 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
CC: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk>
In-Reply-To: <008601c84214$7674e2d0$0701a8c0@Junk>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07


While the xpath examples are definitely more complicated, I think in
this case I've got to agree with Brian.  Using an existing, known query
mechanism is better that inventing yet another one.  Also, given that
Atom is, in fact, XML, it makes a lot of sense to use a query language
designed for use with the XML Infoset.  It may not look as pretty and
compact as Mark's new syntax but it works, it already exists, there is
existing tool support, and it already covers many of the difficult
issues like namespaces and extensions.

If we do use xpath, I would suggest that the default namespace *always*
be mapped to the Atom namespace so users will never have to worry about
the namespace prefix.  In fact, all known *standardized* atom extensions
should have prefixes defined in the spec.  E.g. the query spec could say
that the prefix thr: always maps to the threading extension and that
xhtml: always maps to XHTML so that we don't have to worry as much about
 namespaces.  For more complicated cases, XPath provides the means of
specifying namespaces, even if it's not that pretty.

We would, however, likely need to provide coverage of things like
relative uri's.  For instance, if I submit a query like
"matches(link/@href,'http://example.org/foo')", it should be capable of
matching against elements like <link href="/foo"
xml:base="http://example.org/bar" />.  With base XPath, AFAIK, this is
not currently possible.

Also, if it is at all possible, it would be ideal if we could
automatically map the atom date elements (updated, published and
app:edited) to the xs:dateTime in XPath so we can simplify those
operations a bit, e.g.

  updated eq fn:current-dateTime

  as opposed to

  xs:dateTime(updated) eq fn:current-dateTime

Both should be possible but the former is definitely easier.

Regarding fq:interface, I'm not convinced the fq:index bit is necessary;
and I'd much rather see a more generic way of inserting URI Templates
into a feed.  For instance, this is an example of a syntax I've been
experimenting with:

  <x:link-template
    rel="search"
    pattern="/feed-search?{-join|&|expr,count}">
    <x:var name="expr" ref="http://.../feed-expression" />
    <x:var name="count" pattern="\d+" />
  </x:link-template>

Given this, assuming I understand that "http://.../feed-expression"
refers to the query spec, I could construct a query like:

/feed-search?expr=(matches(title,'.*new.*'))or(matches(author,'bob.*'))&count=10

There are several use cases for embedding link-templates within feeds
that would make having a generic mechanism ideal.

As for RSS feeds, I would suggest that a canonical mapping of RSS to
Atom be developed such that expressions written for one can be
applicable to the other.  I know that such a mapping would be imperfect,
difficult to produce, and likely be controversial, but it would be
certainly be helpful.  Not having this, however, would certainly not be
a show stopper.

- James

Brian Smith wrote:
> Mark Nottingham wrote:
>> On 19/12/2007, at 12:12 PM, Brian Smith wrote:
>>> Why not XPath or XQuery or SPARQL (with an Atom/RDF 
>>> mapping), or CSS selectors or some subset of one of those?
>> In a nutshell, there are two reasons;
>>
>> 1) Those query languages are optimised for data models that 
>> aren't feeds; respectively, XML Infosets, Infosets again, RDF 
>> graphs and CSS cascades. While it's possible to contort them 
>> to fit feeds, they don't really lend themselves to it. XQuery 
>> and SPARQL also present a fairly high barrier to adoption (if 
>> you're not a big XML vendor or a SW-head, respectively ;) 
>> Contorting them so that they're easy to fit into a URL isn't 
>> too attractive, either.
>>
>> 2) When you expose a query interface, you're allowing people 
>> to consume compute power on your servers. An arbitrary query 
>> language allows arbitrary queries, which is unacceptable when 
>> you're working across administrative domains. FIQL gives you 
>> tools to constrain how queries are shaped.
> 
> Developers are used to seeing subsets of XPath. Almost every XPath
> implementation I have seen has been a subset of XPath; Sometimes the
> explanation was avoidance of DoS (resource consumption) attacks; other
> times, the explanation was "we didn't have the resources to implement
> all of it." So, I think it is reasonable to attempt to use a subset of
> Xpath as a query language.
> 
>> Certainly there are use cases for using XQuery, etc.  
>> against feeds, but it's also become apparent that there's a 
>> place for something simple, reasonably flexible, and Web-friendly.
> 
> I agree. But, I'd rather borrow small parts from a well-specified,
> widely-deployed, well-understood language than deal with a brand new
> one. 
> 
>>> That is not acceptable. First, namespace handling in
>>> feed-consuming software is bad enough as it is.
>> While true, I don't see how that's relevant.
> 
> It creates confusion. We spend a lot of time explaining to people that
> they should always prefer to match elements by their namespace URI and
> never by their prefix. This is making an unnecessary exception to that
> rule.
> 
>> I'm open to other suggestions, but this seemed to be the 
>> simplest way to go about it. Note that the 'name' attribute 
>> on the fq:index element gives you a way to specify a stable 
>> name for a selector that's independent of the QName; if 
>> you're concerned about these issues, you can use that.
> 
> The language should not require implementations to match elements and
> attributes using the prefixes used in the actual documents. XPath
> expressions have a mapping of "statically known namespaces" [1] and the
> default element namespace [2]. The fq:index could be the means of
> setting up this mapping. Additionally, some extra syntax could be added
> to support binding prefixes that are not bound in the fq:index.
> 
> I will throw out this suggestion for using a subset of XPath 2.0 as the
> constraint language. 
> 
> Expr         ::= AndExpr  ( "or"  AndExpr )*
> AndExpr      ::= CompExpr ( "and" CompExpr )* 
> CompExpr     ::= Value ValueComp Value
>                | FunctionCall
>                | "(" Expr ")"
> Comp		 ::= "eq" | "ne" | "lt" | "le" | "gt" | "ge"
> Value        ::= Literal 
>                | Path
>                | "(" Value ")"
> Path		 ::= QName
> Literal      ::= NumericLiteral (as defined in XPath)
>                | StringLiteral  (as defined in XPath)
> FunctionCall ::= "matches" "(" Qname "," RegEx ")"
> 	         | "matches" "(" Qname "," RegEx "," "'i'" ")"
> 	         | "not" "(" FunctionCall ")"
> RegEx 	 ::= "'" ".*"? CHAR* ".*"? "'"
> Char		 ::= <any character except ".", "'", or """> | "\" <any
> character>
> 
> I believe this language to be very similar to the language that you
> specify in the draft, while simultaneously being a pure subset of XPath.
> As you can see below, it isn't beautiful. But, I don't think that it is
> so ugly that it requires a whole new language to replace it, either. 
> 
> The expression would always be considered to be a XPath predicate. That
> is, an expression X would be evaluated as:
>     atom:entry[X] 
> and the resulting node list would be wrapped in an atom:feed element.
> The default element namespace binding is the Atom namespace. Analogous
> considerations apply to RSS. The default function namespace is
> http://www.w3.org/2005/xpath-functions.
> 
> FIQL:
>   title==foo*;(updated=lt=-P1D,title==*bar)
> XPath:
>  
> (matches(title,'foo.*'))and((updated)lt('-P1D')or(matches(title,'.*bar')
> ))
> 
> FIQL:
>   title==*new*,author==bob*
> XPath:
>   (matches(title,'.*new.*'))or(matches(author,'bob.*'))
>   
> FIQL:
>   title==*great*;ex:rating=gt=4
> XPath:
>   matches(title,'.*great.*', 'i')or(ex:rating)gt(4)
> 
> Further, lets extend the syntax the subset to include a little more
> XPath:
> 
> Value        ::= Literal 
>                | Qname 
>                | "(" Value ")"
>                | "xs:dateTime" "(" Value ")"
>                | "xs:duration" "(" Value ")"
>                | "xs:decimal"  "(" Value ")"
> 
> Now, the client can explicitly request certain values to be treated as a
> specific type in variables, regardless of what the fq:index elements do
> or do not say. 
> 
> Further, we can expand the syntax of paths to allow us to select nested
> elements and/or attributes or anything else that XPath allows. For
> example, atom:content/@type.
> 
> Regards,
> Brian
> 
> 




From owner-atom-syntax@mail.imc.org Wed Dec 19 14:13:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J54Mf-0000lJ-OJ
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:13:57 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J54Mf-00055D-5B
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:13:57 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJIpGQB041914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 11:51:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJIpGel041913;
	Wed, 19 Dec 2007 11:51:16 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJIpEsb041905
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 11:51:15 -0700 (MST)
	(envelope-from danny.ayers@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so2395606rvf.34
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 10:51:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        bh=Mbk5aniOK5rj20UZ1ExO2tRGnImLQzKkI7xYqLHG+bk=;
        b=ac6p4aEYD/BM7uot0jZGgW5lU0yNQd9QI6aOFFCXcHggztaTpNgUtg/mmnYJxI9WpkDIaE/tEiUk3iacVwIxlS262pn/OMHXf9ys9QBctaFxqqrPGlW9mdAt+fFjPPQQ9+Ix/r4ER8TbYnGxAnPzFkTDvrNQrFnMdNxo9dsu7Uw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=v2rgH4+MisYTvbwvuefRYmHAntIrfhws9JGN36ApCQPSAyd9SMKfmMRhVg69fPki1fNogCAQFLXKLtDMtVaMEWcgQ+KCHMUExOqg9rPDHHoVdZqd/wBCjseHYPtcGWKswk54ApaDaZfv8+f8eUFlLcqrcYnE06NWVEYXIkCaHmw=
Received: by 10.140.180.13 with SMTP id c13mr2386995rvf.153.1198090274241;
        Wed, 19 Dec 2007 10:51:14 -0800 (PST)
Received: by 10.141.37.1 with HTTP; Wed, 19 Dec 2007 10:51:14 -0800 (PST)
Message-ID: <1f2ed5cd0712191051l7c0ecb96ld12f43f3667aad03@mail.gmail.com>
Date: Wed, 19 Dec 2007 19:51:14 +0100
From: "Danny Ayers" <danny.ayers@gmail.com>
To: "Mark Nottingham" <mnot@mnot.net>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Cc: "Brian Smith" <brian@briansmith.org>, Atom-Syntax <atom-syntax@imc.org>
In-Reply-To: <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
	 <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
	 <005901c841dc$3ac7c3c0$0701a8c0@Junk>
	 <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2


Coupla quick comments -

I accept most of your arguments for not making the language fully
generalised (despite being a fan of both SPARQL & XPath). But what I'd
caution though is making the language more specific than it needs to
be, the other points being equal.

To avoid reinvention, a selective reuse of XPath constructs would seem
to make sense, with added sugar for Atom. Can your proposal be
systematically mapped to XPath?

Having said that, although XML-orientation seems obvious given Atom
(and the possibility of using URI path parts..? ok, I only skimmed
your draft), I wouldn't entirely dismiss SPARQL-like features. Typed
links *are* important in Atom, so some kind of triple patterns could
be very useful.

As another ref, I'd suggest checking out Microsoft's Project Astoria -
it's essentially a RESTful front end on top of an entity-relation
backend model. Like RDF but without URIs as entity/relation
identifiers (baby...bathwater...hmm). But one thing I saw a demo of
which looked very promising was their query URI construction. I can't
find the spec proper, but there are some examples here:

http://alexbarnett.net/blog/archive/2007/04/30/microsoft-codename-quot-astoria-quot-data-services-for-the-web.aspx

Cheers,
Danny.
-- 

http://dannyayers.com




From owner-atom-syntax@mail.imc.org Wed Dec 19 14:25:41 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J54Y1-0000lc-Oa
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:25:41 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J54Y1-0005Hv-2p
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:25:41 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJJ5QQT043089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 12:05:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJJ5Qt2043087;
	Wed, 19 Dec 2007 12:05:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBJJ5MaB043078
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 12:05:22 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 19 Dec 2007 19:05:21 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp018) with SMTP; 19 Dec 2007 20:05:21 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1+h9VAQxBqhhdMaygvc7XlV/GxZN+RODWvePLBiAR
	tYNeIxRNhaKKbZ
Date: Wed, 19 Dec 2007 20:05:20 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Message-ID: <20071219190520.GB15399@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47695FB3.2030809@gmail.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199


* James M Snell <jasnell@gmail.com> [2007-12-19 19:30]:
> If we do use xpath, I would suggest that the default namespace
> *always* be mapped to the Atom namespace so users will never
> have to worry about the namespace prefix.

There is no notion of default namespace in XPath.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>




From owner-atom-syntax@mail.imc.org Wed Dec 19 14:44:16 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J54q0-0007SX-J2
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:44:16 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J54q0-0005du-31
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:44:16 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJJTk6L045017
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 12:29:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJJTkw3045016;
	Wed, 19 Dec 2007 12:29:46 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJJThPs045007
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 12:29:46 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by wr-out-0506.google.com with SMTP id 68so2094583wra.13
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 11:29:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=7bx7CTbRuXi3oi+X402Wk1Nt6467G4Nz62Mg2lEiS8c=;
        b=LxS7Rs1R7SLvaH+xMrQOtBONCcGmLkGH5wnEKTh2rm81H0bU2YUq/cis41T7DQXkBBhRLKzrCX+p4a6/nd/oSVIB9yuJU8kDlBbPCxyWUBDHCa1AtrgeXoCrLX82nIXJe/1GFN653eANAiDaVORaPlTR12MxiUI2R4w1ewB8OiI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=VAiQ5VtxMGfAyPlECbtelYWT/uWqgPzLKZU4a2DKcaVTfydWRqI1ZQIoq2YGfFBm/d8U9BlAH7RIovEP3eOMX/aEOnea0NSc4CzmsAPsfujcm0Iu+Uf8idGWooz4ZctmhRg5fOFJGy3BEiPwkQCo0EP0hw7vd+cmvMJgWvx1DbE=
Received: by 10.142.76.4 with SMTP id y4mr1622183wfa.110.1198092580889;
        Wed, 19 Dec 2007 11:29:40 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id h10sm9042987wxd.2007.12.19.11.29.37
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 19 Dec 2007 11:29:39 -0800 (PST)
Message-ID: <47697117.1050901@gmail.com>
Date: Wed, 19 Dec 2007 11:29:27 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <20071219190520.GB15399@klangraum>
In-Reply-To: <20071219190520.GB15399@klangraum>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


I meant only, for example, that regardless of whether the underlying
feed uses "a:feed", "atom:feed", "foobar:feed", etc the xpath query
would always just be "feed".

- James

A. Pagaltzis wrote:
> * James M Snell <jasnell@gmail.com> [2007-12-19 19:30]:
>> If we do use xpath, I would suggest that the default namespace
>> *always* be mapped to the Atom namespace so users will never
>> have to worry about the namespace prefix.
> 
> There is no notion of default namespace in XPath.
> 
> Regards,




From owner-atom-syntax@mail.imc.org Wed Dec 19 14:47:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J54tB-0000qG-J5
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:47:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J54tB-0005iL-5f
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 14:47:33 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJJL5op044434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 12:21:05 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJJL5JX044433;
	Wed, 19 Dec 2007 12:21:05 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJJL4YY044427
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 12:21:05 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 9EEB2D05A6
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 14:21:03 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <20071219190520.GB15399@klangraum>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Thu, 20 Dec 2007 02:21:00 +0700
Message-ID: <000001c84274$4d48b7f0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20071219190520.GB15399@klangraum>
Thread-Index: AchCcs8z4TZZZu1ESQmAv9Ebawh34gAAAehA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab


A. Pagaltzis wrote:
> Sent: Thursday, December 20, 2007 2:05 AM
> To: 'Atom-Syntax'
> Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
> 
> 
> * James M Snell <jasnell@gmail.com> [2007-12-19 19:30]:
> > If we do use xpath, I would suggest that the default namespace
> > *always* be mapped to the Atom namespace so users will 
> never have to 
> > worry about the namespace prefix.
> 
> There is no notion of default namespace in XPath.

Yes, there is in XPath 2.0:
  http://www.w3.org/TR/xpath20/#dt-def-elemtype-ns

Sorry I edited out the links in my original message.

- Brian




From owner-atom-syntax@mail.imc.org Wed Dec 19 17:15:38 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J57CT-0004Lp-Us
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:15:38 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J57CS-0001LM-F6
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:15:37 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJLqEbj057100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 14:52:14 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJLqEur057099;
	Wed, 19 Dec 2007 14:52:14 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJLqDgj057091
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 14:52:13 -0700 (MST)
	(envelope-from Steven.Lees@microsoft.com)
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by
 TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft
 SMTP Server (TLS) id 8.1.222.3; Wed, 19 Dec 2007 13:52:12 -0800
Received: from NA-EXMSG-C103.redmond.corp.microsoft.com ([157.54.53.8]) by
 tk1-exhub-c104.redmond.corp.microsoft.com ([157.56.116.117]) with mapi; Wed,
 19 Dec 2007 13:52:12 -0800
From: Steven Lees <Steven.Lees@microsoft.com>
To: James M Snell <jasnell@gmail.com>
CC: James Holderness <j4_james@hotmail.com>,
        "'Atom-Syntax'"
	<atom-syntax@imc.org>
Date: Wed, 19 Dec 2007 13:52:10 -0800
Subject: RE: Tombstones
Thread-Topic: Tombstones
Thread-Index: AchCYaEammin08QoR7yNt6VYcKF+qwAJtJXg
Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763FF60973B@NA-EXMSG-C103.redmond.corp.microsoft.com>
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com>
 <47676162.3050207@gmail.com>
 <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com>
 <000901c841a2$63f64350$0701a8c0@Junk>
 <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl>
 <004f01c841d8$26a33270$0701a8c0@Junk>
 <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com>
 <009901c84217$b2cfe830$0701a8c0@Junk>
 <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl>
 <20071219150157.GU15399@klangraum>
 <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl>
 <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com>
 <47694FB7.7040100@gmail.com>
In-Reply-To: <47694FB7.7040100@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lBJLqDgi057093
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


James Snell wrote:

> A common thread across all these scenarios is the need to explicitly
> indicate the fact that an entry has been removed from a feed.  Given
> that, it would make sense to have a commonly defined tombstone
> mechanism.

I agree that this is probably the case, but I'd be more confident about that if I were more clear on exactly what scenarios are most important to people. Things like ability to un-delete affect the tombstone design. I could see two separate designs making sense, although it would be nice if there was a super/subset relationship between them.

Steven





From owner-atom-syntax@mail.imc.org Wed Dec 19 17:27:05 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J57NZ-0000OR-4F
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:27:05 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J57NY-0001Z2-Nt
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:27:05 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMDgpc058879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 15:13:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJMDgiY058878;
	Wed, 19 Dec 2007 15:13:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMDc9t058851
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 15:13:41 -0700 (MST)
	(envelope-from joe.gregorio@gmail.com)
Received: by mu-out-0910.google.com with SMTP id i2so5742574mue.2
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 14:13:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        bh=bnmdkfO26U/o8FWC4EB5ET4dSLrvxCBNYk6siOqlt/E=;
        b=I7WGUPmoB7I7nf+znJHFudC3R83jG8IgFNLZoe8T6AktE3JuRtiL6dIWK/9MffWEQb1NsMGzOYvp8XAahIw2fnNKvlvUHLTwfSGwc9VAbicodpnxmhQlbsc0IsucVGFA5ulox1RBhyyOP15PeCbsPKgaSXbGL4p71LiM360WTqo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=I/Jd9ax3Rjj5QRwg+ZPpgahHAq0tsDoNoE8onyylIZfV343acrHgoZ9bv19vkzSCJSW5Gnql8XBvyxxsWqkhAR7KykS7SYG+yLL1IIcwUJgTsAHgVYW76UyGN1DDRYn1S1VpcerkFZXSreZ8bB9vqpvz9B0BvQ9PqX6jniOsaHo=
Received: by 10.86.30.9 with SMTP id d9mr9394312fgd.16.1198102417208;
        Wed, 19 Dec 2007 14:13:37 -0800 (PST)
Received: by 10.86.61.9 with HTTP; Wed, 19 Dec 2007 14:13:37 -0800 (PST)
Message-ID: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
Date: Wed, 19 Dec 2007 17:13:37 -0500
From: "Joe Gregorio" <joe@bitworking.org>
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Suggestions for extension namespace URIs
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Google-Sender-Auth: 3adefe7a8b93dc53
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


We (Google) are going to be producing I-Ds for
some extension elements in Atom. Anybody got
suggestions for picking a namespace URI?
We could use PURLs, or register our own
domain, but what are the options beyond that?

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org




From owner-atom-syntax@mail.imc.org Wed Dec 19 17:42:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J57cZ-0001kA-3J
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:42:35 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J57cY-0001rx-ML
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:42:35 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMRcJv059734
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 15:27:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJMRc3t059733;
	Wed, 19 Dec 2007 15:27:38 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rn-out-0102.google.com (rn-out-0910.google.com [64.233.170.184])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMRbG7059726
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 15:27:38 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rn-out-0102.google.com with SMTP id e21so691893rng.16
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 14:27:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=qwzv7xx6EQOFIFxNKgoxKZgEGpQZSQkvLoohsZc8lgM=;
        b=bv3Z9Ao+YTZydmxVzMA8n8JKI7Dd+jEY7m2QaZp58xxl3gD6PByrtKfafzW6cnRgTgcKFYmE91+e7O411EN34T1zcXl6cTegAby8DaFCJeVtEidpD2K3RakuqONmQtErLc/RLW9cRhVxOl2oGtJG1YiiigATEFOl7Bco8KGaUls=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=k6zAao/gkZ0sMalhtatLOClmb8lLataunlKk8I87T62aIaCKkhoKE3lrju58p5Yhy5b0+b8WOpWTlX0J8XeVBcmcmFdt2TK/t9YuHC42EcgwJlvf/F7sPWUZ4g1xNWZrACrxIj8RG+yEyrXxlCm24Ho7o3scxHf4bwZo/m5Udhc=
Received: by 10.150.137.8 with SMTP id k8mr3855938ybd.1.1198103256594;
        Wed, 19 Dec 2007 14:27:36 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id u62sm20778025pyb.2007.12.19.14.27.35
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 19 Dec 2007 14:27:35 -0800 (PST)
Message-ID: <47699ACD.3030402@gmail.com>
Date: Wed, 19 Dec 2007 14:27:25 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Joe Gregorio <joe@bitworking.org>
CC: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Suggestions for extension namespace URIs
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
In-Reply-To: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


I manage the http://purl.org/atompub/* domain.  Feel free to use that as
a base for new extension namespace URIs.  The naming pattern I've been
following is http://purl.org/atompub/{extension}/{version}.  e.g.,
http://purlorg/atompub/foo/1.0.

- James

Joe Gregorio wrote:
> We (Google) are going to be producing I-Ds for
> some extension elements in Atom. Anybody got
> suggestions for picking a namespace URI?
> We could use PURLs, or register our own
> domain, but what are the options beyond that?
> 
>     Thanks,
>     -joe
> 




From owner-atom-syntax@mail.imc.org Wed Dec 19 17:56:04 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J57pc-0000HL-JY
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:56:04 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J57pb-00027M-SW
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:56:04 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMgbUv060707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 15:42:37 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJMgaSW060706;
	Wed, 19 Dec 2007 15:42:36 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rsmtp2.corp.yahoo.com (rsmtp2.corp.yahoo.com [207.126.228.150])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMgY6T060693
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 15:42:36 -0700 (MST)
	(envelope-from addison@yahoo-inc.com)
Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80])
	by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lBJMgRdk055095;
	Wed, 19 Dec 2007 14:42:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject:
	references:in-reply-to:content-type:content-transfer-encoding;
	b=06/XwI9Yd7+sQV4yzcCZS0KdIdJKNJf0FDv4mPPaFqv9krxK71cbpGEtqWagTLam
Message-ID: <47699E52.5000709@yahoo-inc.com>
Date: Wed, 19 Dec 2007 14:42:26 -0800
From: Addison Phillips <addison@yahoo-inc.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7


Hi Mark,

I glanced through this document, which looks pretty good... but I have a 
concern that the ABNF doesn't permit Unicode characters, although the 
text does.

Specifically, you cite the 'unreserved' and 'pct-encoded' productions of 
RFC 3986 (URI). Here they are:

       unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
       pct-encoded   = "%" HEXDIG HEXDIG

Obviously, one *could* use the pct-encoded production to incorporate 
random byte values into queries. But I would tend to expect that the 
syntax would be better off if defined in terms of 'iunreserved' in RFC 
3987 (IRI) instead:

   iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

... and then mention the use of transfer encodings (provided in IRI) as 
needed (which you already do).

Best Regards,

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


Mark Nottingham wrote:
> 
> FYI; I'd love any feedback folks have on this.
> 
> Begin forwarded message:
> 
>> From: Internet-Drafts@ietf.org
>> Date: 19 December 2007 7:15:02 AM
>> To: i-d-announce@ietf.org
>> Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : FIQL: The Feed Item Query Language
>>     Author(s)    : M. Nottingham
>>     Filename    : draft-nottingham-atompub-fiql-00.txt
>>     Pages        : 16
>>     Date        : 2007-12-18
>>     
>>   The Feed Item Query Language is a simple but flexible, URI-friendly
>>   syntax for expressing filters across the entries in a Web feed.  It
>>   also specifies a mechanism to allow feeds to indicate what types of
>>   queries are supported.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-nottingham-atompub-fiql-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     mailserv@ietf.org.
>> In the body type:
>>     "FILE /internet-drafts/draft-nottingham-atompub-fiql-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2007-12-18145429.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 





From owner-atom-syntax@mail.imc.org Wed Dec 19 17:59:44 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J57tA-000495-73
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:59:44 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J57t9-0002Ac-If
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 17:59:44 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMk9To060997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 15:46:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBJMk9of060996;
	Wed, 19 Dec 2007 15:46:09 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.225])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBJMk8KT060989
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 15:46:09 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by nz-out-0506.google.com with SMTP id n1so1615665nzf.4
        for <atom-syntax@imc.org>; Wed, 19 Dec 2007 14:46:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=tEd8alGI+o3O/60nFXHc0n+1tc8TGJ/JPeoDYXYRl4E=;
        b=JB+vzbF+bALLcDKZHQRJBuJWEYYDXb4rMsGehPw91I/UJMg8Ue0ev4zBRAuKoeSgHJ7GngcXEUV3YHnIGib1Tg9fHHwJ+uGXLcpB/4hkgubmWkRSzrlP7bOTBnIwXCU2TguC7QubSHe9+bbg0bY6am1QbKgsIjqRYFdo7z6V6MQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=ncGlBUi+lYm/EaZEtxqqrutP7VFgcNm1LnN5E5BjlW8ukEUUsO0ZBDFYRAz6OeZcnnA3PhzWkrQ+x8Sfooos8j3MGiphdaqd+QisBN/zRRprxvSvKpuP2YgVv6whjhW3gCDvTMKrhlZ1AFQa3Yji6PL7fN6CdyUWCj637Futf+Q=
Received: by 10.141.20.7 with SMTP id x7mr3628337rvi.34.1198104367393;
        Wed, 19 Dec 2007 14:46:07 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id m8sm18297270roe.2007.12.19.14.46.05
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Wed, 19 Dec 2007 14:46:06 -0800 (PST)
Message-ID: <47699F24.9060701@gmail.com>
Date: Wed, 19 Dec 2007 14:45:56 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Steven Lees <Steven.Lees@microsoft.com>
CC: James Holderness <j4_james@hotmail.com>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Tombstones
References: <3f1451f50712171950s2e273740n7df78457f8af87aa@mail.gmail.com> <47676162.3050207@gmail.com> <3f1451f50712180939x37f998b5j72503525da8804e9@mail.gmail.com> <000901c841a2$63f64350$0701a8c0@Junk> <BAY141-DAV47B41C53FE66E89838465BE630@phx.gbl> <004f01c841d8$26a33270$0701a8c0@Junk> <BAY141-DAV82B55C8B4E4F7F94537C0BE5C0@phx.gbl> <4768A714.60703@gmail.com> <009901c84217$b2cfe830$0701a8c0@Junk> <BAY141-DAV17F69D1A0399036290E34ABE5C0@phx.gbl> <20071219150157.GU15399@klangraum> <BAY141-DAV1242F7CCDD1D053D92791FBE5C0@phx.gbl> <9F59E90E6E525B40BB7B59BD72271CF763FF60945A@NA-EXMSG-C103.redmond.corp.microsoft.com> <47694FB7.7040100@gmail.com> <9F59E90E6E525B40BB7B59BD72271CF763FF60973B@NA-EXMSG-C103.redmond.corp.microsoft.com>
In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763FF60973B@NA-EXMSG-C103.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5


From the use cases I've reviewed here...

> 1) "hard" delete: delete an item and it's gone forever
> 3) ability to delete comments from a blog for spam control
> 4) ability to delete posts from a blog

As far as I'm concerned, there's really no difference between these
cases.  Whether it blog entries, bookmarks, documents, etc, if an item
is permanently deleted, we need a way of explicitly indicating that
fact.  The main reason we need this is to support a number of
application scenarios including removing entries from local client
caches, letting search indexers know that entries should be removed from
their indexes, and keeping replicas in sync with a master.

> 2) "soft" delete: you can delete an item but the data and metadata are
>    preserved so that you can un-delete the item

Soft-delete is a special case.  With this, entries are moved to a trash
collection.  We need a way of indicating that the entry has been removed
from it's original feed, while at the same time indicating it's new
location in the trash feed, e.g., something along the lines of:

  <x:deleted>
    <id>tag:example.org,2007:foo</id>
    <link rel="trash"
          type="application/atom+xml"
          href="/trash/foo" />
  </x:deleted>

Entries in the trash collection can be undeleted or purged.  If they are
undeleted, they go back to the original feed and are removed from the
trash.  If they are purged, all of the metadata, save the id and perhaps
a timestamp, will be removed from the database.

> 5) full two-way sync between nodes via feeds

This could change but for now, this is not important to us at the
moment.  All of our sync scenarios follow a master-replica pattern where
sync is always one-way.

> 6) ability to verify the source of an entry or tombstone

This will definitely be important.

> 7) one way (master-replica) full and incremental sync.

This is a significant use case for us.  We must have a reliable and
performant one-way sync model that can support full and incremental
operation.  By incremental I mean we need to have the ability to request
a feed listing only changes that have occurred since the previous sync
operation.

Our internally deployed Atom collections are already working with
hundreds of thousands of entries each.

> 8) ability to notify aggregators that content must be removed for
> legal reasons (e.g. dmca... blech)

I'm not certain it's necessary for us to have the ability to specify why
an entry was deleted so this may fall under the same general category as
items 1, 3 and 4 above.

- James

Steven Lees wrote:
> James Snell wrote:
> 
>> A common thread across all these scenarios is the need to explicitly
>> indicate the fact that an entry has been removed from a feed.  Given
>> that, it would make sense to have a commonly defined tombstone
>> mechanism.
> 
> I agree that this is probably the case, but I'd be more confident about that if I were more clear on exactly what scenarios are most important to people. Things like ability to un-delete affect the tombstone design. I could see two separate designs making sense, although it would be nice if there was a super/subset relationship between them.
> 
> Steven
> 




From owner-atom-syntax@mail.imc.org Wed Dec 19 19:53:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J59fH-0002lh-7W
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 19:53:31 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J59fG-0004CU-N6
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 19:53:31 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK0dJo3069117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 17:39:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK0dJeO069116;
	Wed, 19 Dec 2007 17:39:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK0dCgJ069105
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 17:39:13 -0700 (MST)
	(envelope-from dave@djpowell.net)
Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout01-winn.ispmail.ntl.com with ESMTP
          id <20071220003948.BRJL6201.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>;
          Thu, 20 Dec 2007 00:39:48 +0000
Received: from DavePC ([86.4.235.85]) by aamtaout01-winn.ispmail.ntl.com
          with ESMTP
          id <20071220004005.LIPT219.aamtaout01-winn.ispmail.ntl.com@DavePC>;
          Thu, 20 Dec 2007 00:40:05 +0000
From: "David Powell" <djpowell@djpowell.net>
To: "'Mark Nottingham'" <mnot@mnot.net>,
        "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Thu, 20 Dec 2007 00:39:11 -0000
Message-ID: <016c01c842a0$bea082d0$3be18870$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchBxxEG4M2cvclbTdCp+q89zo+swQA1GAOA
Content-Language: en-gb
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4


Have you looked at "RFC 2254 - The String Representation of LDAP Search
Filters"?  I've used variants of that in URIs before.
Its use of &'s is probably asking for escaping bugs in URIs though.


Some questions and comments -


Attribute matching

  Matching atom:category would be useful, but atom:category depends on
attributes - is that
  supported at all?  Can we have a special element comparison type for
atom:category that supports
  attribute matching?


Existence checks

  RFC 2254 supports checks that a property (or element) exists or not.
  I'd think something like that would be pretty useful.  Eg: draft=*


Matching against QNames

  QNames are evil.  I'd rather have inexact *:name matches, than explicitly
  matching against a namespace prefix.

  Would it be possible to write qname match predicates, but have the prefix
in the
  predicate have no significance, and then optionally allow another type of
predicate,
  for the anal, to requre that the prefix to be mapped to a certain URI?

    ex:name=="Dave"                                  ; matches *:name, but
    ex:name=="Dave",xmlns:ex=="http://example.com/"  ; matches a specific
element.


Person constructs

  Do element match predicates only apply to direct children of atom:entry?
Does "email" match
  atom:author/atom:email?


Inheritance

  Are element match predicates supposed to apply to the logical properties
of the entry
  after things like author inheritance rules have been applied?


fq:index

  Is the default that no selectors can be used?  If you define fq:index
elements
  does that mean that only those selectors can be used?  Is there anyway to
say that
  any selectors can be used?


-- 
Dave





From owner-atom-syntax@mail.imc.org Wed Dec 19 19:54:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J59fs-0002vr-0H
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 19:54:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J59fr-0004Ct-IZ
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 19:54:07 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK0guZp069321
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 17:42:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK0gupO069320;
	Wed, 19 Dec 2007 17:42:56 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK0goig069307
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 17:42:55 -0700 (MST)
	(envelope-from dave@djpowell.net)
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout03-winn.ispmail.ntl.com with ESMTP
          id <20071220004340.XDAN20647.mtaout03-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
          Thu, 20 Dec 2007 00:43:40 +0000
Received: from DavePC ([86.4.235.85]) by aamtaout03-winn.ispmail.ntl.com
          with ESMTP
          id <20071220004414.ICEG26699.aamtaout03-winn.ispmail.ntl.com@DavePC>;
          Thu, 20 Dec 2007 00:44:14 +0000
From: "David Powell" <djpowell@djpowell.net>
To: "'Joe Gregorio'" <joe@bitworking.org>,
        "'Atom-Syntax'" <atom-syntax@imc.org>
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
In-Reply-To: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
Subject: RE: Suggestions for extension namespace URIs
Date: Thu, 20 Dec 2007 00:42:49 -0000
Message-ID: <018801c842a1$4043eb60$c0cbc220$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchCjW0zIy75V7tNQJGkRHgTD3wDHwAE6MVA
Content-Language: en-gb
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


> We (Google) are going to be producing I-Ds for
> some extension elements in Atom. Anybody got
> suggestions for picking a namespace URI?
> We could use PURLs, or register our own
> domain, but what are the options beyond that?

End the URIs with a '/'.  It is nicer.

-- 
Dave





From owner-atom-syntax@mail.imc.org Wed Dec 19 20:25:25 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5AA9-0004yo-EO
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 20:25:25 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5AA7-0004ia-Sc
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 20:25:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK1B7wG070824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 18:11:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK1B7u4070823;
	Wed, 19 Dec 2007 18:11:07 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK1B5Kx070816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 18:11:06 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 45799D059E;
	Wed, 19 Dec 2007 20:11:02 -0500 (EST)
Cc: Joe Gregorio <joe@bitworking.org>, Atom-Syntax <atom-syntax@imc.org>
Message-Id: <960EE9C7-0028-468E-8C39-A21661895354@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: James M Snell <jasnell@gmail.com>
In-Reply-To: <47699ACD.3030402@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Suggestions for extension namespace URIs
Date: Thu, 20 Dec 2007 12:11:00 +1100
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com> <47699ACD.3030402@gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


Likewise, I've got purl.org/syndication, and am happy to delegate  
portions of that to folks who are producing extensions that are  
(possibly) usable in Atom and RSS.

Cheers,

On 20/12/2007, at 9:27 AM, James M Snell wrote:

>
> I manage the http://purl.org/atompub/* domain.  Feel free to use  
> that as
> a base for new extension namespace URIs.  The naming pattern I've been
> following is http://purl.org/atompub/{extension}/{version}.  e.g.,
> http://purlorg/atompub/foo/1.0.
>
> - James
>
> Joe Gregorio wrote:
>> We (Google) are going to be producing I-Ds for
>> some extension elements in Atom. Anybody got
>> suggestions for picking a namespace URI?
>> We could use PURLs, or register our own
>> domain, but what are the options beyond that?
>>
>>    Thanks,
>>    -joe
>>
>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Wed Dec 19 21:14:24 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5AvY-0007Kh-AB
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:14:24 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5AvX-0005YG-UF
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:14:24 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK21M93074313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 19:01:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK21Mkc074312;
	Wed, 19 Dec 2007 19:01:22 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK21Lnb074304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 19:01:21 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id D9E48D05A8;
	Wed, 19 Dec 2007 21:01:19 -0500 (EST)
Cc: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Message-Id: <F232F66C-9016-419C-A874-7717F31E79E8@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: James M Snell <jasnell@gmail.com>
In-Reply-To: <47695FB3.2030809@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Thu, 20 Dec 2007 13:01:17 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f


Wow, really? Are all of your use cases behind a firewall / within the  
same administrative domain?

Cheers,


On 20/12/2007, at 5:15 AM, James M Snell wrote:

> Regarding fq:interface, I'm not convinced the fq:index bit is  
> necessary;
> and I'd much rather see a more generic way of inserting URI Templates
> into a feed


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Wed Dec 19 21:14:29 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5Avd-0007Lv-IP
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:14:29 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5Avc-0005YO-N0
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:14:29 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK1xYIh074156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 18:59:34 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK1xY51074155;
	Wed, 19 Dec 2007 18:59:34 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK1xW0w074148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 18:59:33 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id B0BEAD04FF;
	Wed, 19 Dec 2007 20:59:30 -0500 (EST)
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
Message-Id: <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Brian Smith <brian@briansmith.org>
In-Reply-To: <008601c84214$7674e2d0$0701a8c0@Junk>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Thu, 20 Dec 2007 12:59:28 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7



On 19/12/2007, at 6:54 PM, Brian Smith wrote:
> Developers are used to seeing subsets of XPath. Almost every XPath
> implementation I have seen has been a subset of XPath; Sometimes the
> explanation was avoidance of DoS (resource consumption) attacks; other
> times, the explanation was "we didn't have the resources to implement
> all of it." So, I think it is reasonable to attempt to use a subset of
> Xpath as a query language.

Hmm, I'm not sure the latter is a great advertisement for basing it  
upon XPath...

To my mind, XPath 2.0 (which you seem to be referring to) is too  
complex to base something like this on; printing the XQuery-related  
specs kills too many trees, and it takes a major investment to get up  
to speed with it as a user, much less an implementer. While it works  
if you're already invested in the XQuery world, my perception is that  
this group is still fairly small, and "enterprise" focused.

I don't keep up to date with the XQuery world, but last I checked,  
Perl, Python, PHP and Ruby all lacked implementations. What will they  
do?

In comparison, FIQL has been prototyped in a small amount of part-time  
effort by a single developer (yes, I'm trying to get that Open  
Sourced, but don't know when/if that'll happen).


>>> That is not acceptable. First, namespace handling in
>>> feed-consuming software is bad enough as it is.
>>
>> While true, I don't see how that's relevant.
>
> It creates confusion. We spend a lot of time explaining to people that
> they should always prefer to match elements by their namespace URI and
> never by their prefix. This is making an unnecessary exception to that
> rule.

Yes. I think the issue here is whether the convenience outweighs the  
confusion. Perhaps we could make the binding between selectors and  
QNames not on by default; instead, a feed would have to specifically  
say that it's in effect (e.g., in a fq:interface attribute)...


> I will throw out this suggestion for using a subset of XPath 2.0 as  
> the
> constraint language.
>
> Expr         ::= AndExpr  ( "or"  AndExpr )*
> AndExpr      ::= CompExpr ( "and" CompExpr )*
> CompExpr     ::= Value ValueComp Value
>               | FunctionCall
>               | "(" Expr ")"
> Comp		 ::= "eq" | "ne" | "lt" | "le" | "gt" | "ge"
> Value        ::= Literal
>               | Path
>               | "(" Value ")"
> Path		 ::= QName
> Literal      ::= NumericLiteral (as defined in XPath)
>               | StringLiteral  (as defined in XPath)
> FunctionCall ::= "matches" "(" Qname "," RegEx ")"
> 	         | "matches" "(" Qname "," RegEx "," "'i'" ")"
> 	         | "not" "(" FunctionCall ")"
> RegEx 	 ::= "'" ".*"? CHAR* ".*"? "'"
> Char		 ::= <any character except ".", "'", or """> | "\" <any
> character>
>
> I believe this language to be very similar to the language that you
> specify in the draft, while simultaneously being a pure subset of  
> XPath.
> As you can see below, it isn't beautiful. But, I don't think that it  
> is
> so ugly that it requires a whole new language to replace it, either.

Now that's interesting! I've had the XQuery/XPath 2.0 discussion with  
others before, and the resolution was that as long as it was possible  
to map it to XPath for implementation purposes, that's good enough --  
something that it looks like you've taken a step towards.

I'm not married to the current syntax, but I do want it to be URI- 
friendly and easy for humans to understand. If the syntax meets those  
goals and happens to be a subset of XPath, I'm fine, but I don't want  
to define it as an explicit subset; doing so will force people to  
learn XPath whether they want to or not, and IMO will lead to interop  
problems as people start relying on XPath features, rather than what  
the spec says.

Anyway, this is good; I'd be interested in hearing what other Atom  
folks have to say about the alternative syntax, and whether it's good  
enough to have an easy way to turn it into XPath if necessary.


> The expression would always be considered to be a XPath predicate.  
> That
> is, an expression X would be evaluated as:
>    atom:entry[X]
> and the resulting node list would be wrapped in an atom:feed element.
> The default element namespace binding is the Atom namespace. Analogous
> considerations apply to RSS. The default function namespace is
> http://www.w3.org/2005/xpath-functions.
>
> FIQL:
>  title==foo*;(updated=lt=-P1D,title==*bar)
> XPath:
>
> (matches(title,'foo.*'))and((updated)lt('- 
> P1D')or(matches(title,'.*bar')
> ))
>
> FIQL:
>  title==*new*,author==bob*
> XPath:
>  (matches(title,'.*new.*'))or(matches(author,'bob.*'))
>
> FIQL:
>  title==*great*;ex:rating=gt=4
> XPath:
>  matches(title,'.*great.*', 'i')or(ex:rating)gt(4)
>
> Further, lets extend the syntax the subset to include a little more
> XPath:
>
> Value        ::= Literal
>               | Qname
>               | "(" Value ")"
>               | "xs:dateTime" "(" Value ")"
>               | "xs:duration" "(" Value ")"
>               | "xs:decimal"  "(" Value ")"
>
> Now, the client can explicitly request certain values to be treated  
> as a
> specific type in variables, regardless of what the fq:index elements  
> do
> or do not say.

I wonder if that's a good thing or not...

> Further, we can expand the syntax of paths to allow us to select  
> nested
> elements and/or attributes or anything else that XPath allows. For
> example, atom:content/@type.

Again, hmm. The ability of fq:interface to constrain the shape of  
queries is a good thing.



--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Wed Dec 19 21:19:22 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5B0M-0004fE-DN
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:19:22 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5B0L-0005dL-SP
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:19:22 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK281VF074580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 19:08:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK281JR074579;
	Wed, 19 Dec 2007 19:08:01 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK27xjS074573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 19:08:00 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id E328CD04FF;
	Wed, 19 Dec 2007 21:07:57 -0500 (EST)
Cc: "'Atom-Syntax Syntax'" <atom-syntax@imc.org>
Message-Id: <23886A9E-E6AC-4351-B992-E7511663B068@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: David Powell <djpowell@djpowell.net>
In-Reply-To: <016c01c842a0$bea082d0$3be18870$@net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Thu, 20 Dec 2007 13:07:54 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <016c01c842a0$bea082d0$3be18870$@net>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4



On 20/12/2007, at 11:39 AM, David Powell wrote:

> Have you looked at "RFC 2254 - The String Representation of LDAP  
> Search
> Filters"?  I've used variants of that in URIs before.
> Its use of &'s is probably asking for escaping bugs in URIs though.

Yes, and that's the reason I moved on pretty early ;)

> Some questions and comments -
>
>
> Attribute matching
>
>  Matching atom:category would be useful, but atom:category depends on
> attributes - is that
>  supported at all?  Can we have a special element comparison type for
> atom:category that supports
>  attribute matching?

See @path on fq:index.


> Existence checks
>
>  RFC 2254 supports checks that a property (or element) exists or not.
>  I'd think something like that would be pretty useful.  Eg: draft=*

Yes; it's just a bare selector;

> A constraint with no comparison operator will yield True if the  
> selector matches any node.



> Matching against QNames
>
>  QNames are evil.

I've heard that... :)

>  I'd rather have inexact *:name matches, than explicitly
>  matching against a namespace prefix.
>
>  Would it be possible to write qname match predicates, but have the  
> prefix
> in the
>  predicate have no significance, and then optionally allow another  
> type of
> predicate,
>  for the anal, to requre that the prefix to be mapped to a certain  
> URI?
>
>    ex:name=="Dave"                                  ; matches  
> *:name, but
>    ex:name=="Dave",xmlns:ex=="http://example.com/"  ; matches a  
> specific
> element.

Hmm, possibly; perhaps something you declare on fq:interface?

> Person constructs
>
>  Do element match predicates only apply to direct children of  
> atom:entry?
> Does "email" match
>  atom:author/atom:email?

Respectively, yes and no.

> Inheritance
>
>  Are element match predicates supposed to apply to the logical  
> properties
> of the entry
>  after things like author inheritance rules have been applied?

Ah, good question. This needs to be clarified (and I think it should  
inherit, but it may be tricky to cleanly specify).

> fq:index
>
>  Is the default that no selectors can be used?  If you define fq:index
> elements
>  does that mean that only those selectors can be used?  Is there  
> anyway to
> say that
>  any selectors can be used?


The default is that the server hasn't explicitly told you about any  
selectors if there aren't any fq:index's, so you're happy to try them  
(the server can only say 'no').

Thanks!

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Wed Dec 19 21:25:16 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5B64-00021D-6s
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:25:16 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5B63-0005iy-KS
	for atompub-archive@lists.ietf.org; Wed, 19 Dec 2007 21:25:16 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK2Axx2074769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 19:10:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK2Ax7L074768;
	Wed, 19 Dec 2007 19:10:59 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK2AwP0074762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 19:10:59 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from localhost (unknown [216.145.54.158])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 2A14CD051E;
	Wed, 19 Dec 2007 21:10:56 -0500 (EST)
Cc: "Brian Smith" <brian@briansmith.org>, Atom-Syntax <atom-syntax@imc.org>
Message-Id: <FDC6C316-93F8-4124-B4ED-1387DDB7FF63@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Danny Ayers <danny.ayers@gmail.com>
In-Reply-To: <1f2ed5cd0712191051l7c0ecb96ld12f43f3667aad03@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Thu, 20 Dec 2007 13:10:53 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <1f2ed5cd0712191051l7c0ecb96ld12f43f3667aad03@mail.gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081



On 20/12/2007, at 5:51 AM, Danny Ayers wrote:

> Coupla quick comments -
>
> I accept most of your arguments for not making the language fully
> generalised (despite being a fan of both SPARQL & XPath). But what I'd
> caution though is making the language more specific than it needs to
> be, the other points being equal.
>
> To avoid reinvention, a selective reuse of XPath constructs would seem
> to make sense, with added sugar for Atom. Can your proposal be
> systematically mapped to XPath?

I believe so, although I haven't done the work; as I said in a  
response to Brian a few minutes ago, other folks who want to implement  
with XPath 2.0 have looked at it and believed that it's possible (and  
relatively easy). Brian's message seems to support that.

> Having said that, although XML-orientation seems obvious given Atom
> (and the possibility of using URI path parts..? ok, I only skimmed
> your draft), I wouldn't entirely dismiss SPARQL-like features. Typed
> links *are* important in Atom, so some kind of triple patterns could
> be very useful.

Yes, links are definitely not a strong point in the current draft (you  
can index them with @path, but it's fairly "dumb"). Do you have  
specific use cases in mind?

> As another ref, I'd suggest checking out Microsoft's Project Astoria -
> it's essentially a RESTful front end on top of an entity-relation
> backend model. Like RDF but without URIs as entity/relation
> identifiers (baby...bathwater...hmm). But one thing I saw a demo of
> which looked very promising was their query URI construction. I can't
> find the spec proper, but there are some examples here:
>
> http://alexbarnett.net/blog/archive/2007/04/30/microsoft-codename-quot-astoria-quot-data-services-for-the-web.aspx


Thanks, I've looked at it before, but I'll have another.

Cheers,


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Thu Dec 20 00:49:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5EHn-0000Vo-AF
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 00:49:35 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5EHl-00009D-HD
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 00:49:35 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK5Zgix085688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 22:35:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK5ZgEs085687;
	Wed, 19 Dec 2007 22:35:42 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK5ZeOF085680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 22:35:41 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id BF247D04FF
	for <atom-syntax@imc.org>; Thu, 20 Dec 2007 00:35:39 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Thu, 20 Dec 2007 12:35:31 +0700
Message-ID: <003f01c842ca$282e2940$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchCrF4Q9JcV93ciQbCkzp9c6UOKaQACoXsA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955


Mark Nottingham wrote:
> On 19/12/2007, at 6:54 PM, Brian Smith wrote:
> To my mind, XPath 2.0 (which you seem to be referring to) is 
> too complex to base something like this on; printing the 
> XQuery-related specs kills too many trees, and it takes a 
> major investment to get up to speed with it as a user, much 
> less an implementer. While it works if you're already 
> invested in the XQuery world, my perception is that this 
> group is still fairly small, and "enterprise" focused.
> 
> I don't keep up to date with the XQuery world, but last I 
> checked, Perl, Python, PHP and Ruby all lacked 
> implementations. What will they do?

Parsing that subset of XPath 2.0 might be a little harder than parsing
FIQL, but building parsers is trivial nowadays. Actually implementing
the semantics shouldn't be any harder than implementing FIQL's
semantics, though, since they are equally expressive.

> I'm not married to the current syntax, but I do want it to be 
> URI- friendly and easy for humans to understand.

In the syntax you proposed, how can I search for all entries that have a
title starting with an asterisk ('*')? Or, in other words, it isn't
clear to me how you deal with quoting/escaping issues. Is the processor
supposed to treat an percent-encoded asterisk differently from an
unencoded asterisk character? And, if so, how does this interact with
URI templates?

> If the syntax meets those goals and happens to be a
> subset of XPath, I'm fine, but I don't want to define it as
> an explicit subset; doing so will force people to learn
> XPath whether they want to or not, and IMO will lead to
> interop problems as people start relying on Xpath
> features, rather than what the spec says.

There is no point in reusing the XPath syntax if it isn't 100%
upwards-compatible with XPath. If I were to write a specification for
this, the normative text would be written purely in terms of XPath; I
would have a separate non-normative tutorial describing the subset, and
a non-normative XQuery mapping should be included as well.

XPath is incompatible with URI templates; because of the
quoting/escaping requirements for strings, it isn't possible to write a
URI template (as they are defined today) that is guaranteed to result in
a syntactically-valid XPath expression. To see why, try to construct a
URI template that generates an the XPath containing a single quote and a
double quote at the same time, or even just one or the other. This is a
significant limitation of URI templates, and one that is difficult to
solve. Another problem with URI templates is that there is no "listjoin"
operation for dictionaries; this makes it difficult to pass an arbitrary
number of namespace prefix bindings along with the query. Finally, URI
templates cannot deal with nested structures like those used in the
AND/OR expressions in XPath, FIQL, and Gdata.

Besides syntax, I'm also not yet convinced that such a mechanism like
this is really needed. It seems like we can get really far with URI
templates and an explicit enumeration of searchable fields like GData,
if we remove the logical OR operator. And, once you *need* a logical OR
operator, or when you need to be able to search an open-ended set of
fields, you will probably be in a situation where it is worthwhile to
use (a significant of) XPath 1.0, XPath 2.0, XQuery, and/or some other
advanced structured document search language, plus a set of
Atom-specific extension functions. Do you have any real-world motivating
examples of something where a GData-ish query mechanism is insufficient,
but XPath is too much?

- Brian




From Nikita-mayes@newlabournewlies.org.uk Thu Dec 20 01:08:13 2007
Return-path: <Nikita-mayes@newlabournewlies.org.uk>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5EZp-0006QQ-QY
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:08:13 -0500
Received: from [189.12.157.153] (helo=18912157153.user.veloxzone.com.br)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J5EZp-00014D-2l
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:08:13 -0500
Received: from cliente-6aa152a ([169.121.25.84]:20009 "EHLO cliente-6aa152a"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by 18912157153.user.veloxzone.com.br with ESMTP id S22XDKWMOJITHCKM (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Thu, 20 Dec 2007 04:08:01 -0200
Message-ID: <C4FCEEB2.B934F7C5@newlabournewlies.org.uk>
Date: Thu, 20 Dec 2007 04:07:51 -0200
From: "Nikita mayes" <Nikita-mayes@newlabournewlies.org.uk>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: summithi
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.1 (+++)
X-Scan-Signature: 08e48e05374109708c00c6208b534009

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Make your dig a monster! It'll have a tight fit when you'll bang some<br>
loose chicks! <a href="http://brienwich.com/">http://brienwich.com/</a><br>
</html>



From owner-atom-syntax@mail.imc.org Thu Dec 20 01:27:13 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5EsD-0004f8-Eu
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:27:13 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5EsA-0000hM-3V
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:27:12 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK6E5kx088081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 23:14:05 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK6E5eH088080;
	Wed, 19 Dec 2007 23:14:05 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK6E3kZ088072
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 23:14:04 -0700 (MST)
	(envelope-from duerst@it.aoyama.ac.jp)
Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id lBK6E2QZ004187
	for <atom-syntax@imc.org>; Thu, 20 Dec 2007 15:14:02 +0900 (JST)
Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp
	 id 23b2_c2969648_aec2_11dc_89f9_0014221f2a2d;
	Thu, 20 Dec 2007 15:14:02 +0900
X-AuthUser: duerst@it.aoyama.ac.jp
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33240)
	by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server]
	id <S28131D> for <atom-syntax@imc.org> from <duerst@it.aoyama.ac.jp>;
	Thu, 20 Dec 2007 15:09:57 +0900
Message-Id: <6.0.0.20.2.20071220143032.0c1cc740@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Thu, 20 Dec 2007 14:32:43 +0900
To: Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Cc: "'Atom-Syntax'" <atom-syntax@imc.org>
In-Reply-To: <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org>
 <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
 <005901c841dc$3ac7c3c0$0701a8c0@Junk>
 <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net>
 <008601c84214$7674e2d0$0701a8c0@Junk>
 <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034


At 10:59 07/12/20, Mark Nottingham wrote:
>
>
>On 19/12/2007, at 6:54 PM, Brian Smith wrote:
>> Developers are used to seeing subsets of XPath. Almost every XPath
>> implementation I have seen has been a subset of XPath; Sometimes the
>> explanation was avoidance of DoS (resource consumption) attacks; other
>> times, the explanation was "we didn't have the resources to implement
>> all of it." So, I think it is reasonable to attempt to use a subset of
>> Xpath as a query language.
>
>Hmm, I'm not sure the latter is a great advertisement for basing it  
>upon XPath...
>
>To my mind, XPath 2.0 (which you seem to be referring to) is too  
>complex to base something like this on; printing the XQuery-related  
>specs kills too many trees, and it takes a major investment to get up  
>to speed with it as a user, much less an implementer. While it works  
>if you're already invested in the XQuery world, my perception is that  
>this group is still fairly small, and "enterprise" focused.

I must admit that I haven't looked at the draft at all, but it seems
strange to me to propose XPath 2.0 for something simple when there is
XPath 1.0, and strange to reject any version of XPath based on the
fact/opition that XPath 2.0 is too complex.

Regards,   Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     




From owner-atom-syntax@mail.imc.org Thu Dec 20 01:40:04 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5F4e-0004OB-1q
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:40:04 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5F4d-0000ta-K6
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 01:40:03 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK6SpZM089135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Dec 2007 23:28:51 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBK6SpcT089134;
	Wed, 19 Dec 2007 23:28:51 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBK6SoIb089126
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Wed, 19 Dec 2007 23:28:51 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [68.116.217.108])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 24CFCD05A2
	for <atom-syntax@imc.org>; Thu, 20 Dec 2007 01:28:49 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net> <6.0.0.20.2.20071220143032.0c1cc740@localhost>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Thu, 20 Dec 2007 13:28:46 +0700
Message-ID: <004901c842d1$95b7ade0$0701a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchCz7ybzOo1LDiMTQekWcGvSVFTEQAAW7Eg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <6.0.0.20.2.20071220143032.0c1cc740@localhost>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370


Martin Duerst wrote:
> I must admit that I haven't looked at the draft at all, but 
> it seems strange to me to propose XPath 2.0 for something 
> simple when there is XPath 1.0, and strange to reject any 
> version of XPath based on the fact/opition that XPath 2.0 is 
> too complex.

I agree that XPath 1.0 is generally preferable to XPath 2.0. The only
reason I chose XPath 2.0 was because I could map FIQL to it without
needing any extension functions. You could do the same for XPath 1.0,
but you would need at least one extension function to do date
comparisons, and another extension function to do convenient
case-insensitive string matching.

- Brian




From owner-atom-syntax@mail.imc.org Thu Dec 20 06:14:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5JMg-0000yn-T2
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 06:14:58 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5JMg-00064q-28
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 06:14:58 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKAxoQI007610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Dec 2007 03:59:51 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBKAxode007609;
	Thu, 20 Dec 2007 03:59:50 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail1.webfaction.com (mail1.webfaction.com [67.15.2.85])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKAxm6x007602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Thu, 20 Dec 2007 03:59:49 -0700 (MST)
	(envelope-from sh@defuze.org)
Received: from [192.168.1.9] (localhost.localdomain [127.0.0.1])
	(authenticated bits=0)
	by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id lBKAxTHm027319;
	Thu, 20 Dec 2007 04:59:34 -0600
Message-ID: <476A4AE5.9010808@defuze.org>
Date: Thu, 20 Dec 2007 11:58:45 +0100
From: Sylvain Hellegouarch <sh@defuze.org>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027


Hi Mark,

I was following the discussion around this draft you've proposed and 
rather than focusing on the choice of the most appropriate query 
language used I wanted to ask you about the purpose of this draft? Who 
is the target? Since you use URI-like query, are you thinking of public 
services to query Atom feeds? In such case, shouldn't the draft have a 
large security section (it looks like creating yet another query syntax 
means that its security is by default nil until proven otherwise)? Are 
you planning on making the draft informational only or more?

No matter what, FIQL will never be able to describe all the use cases of 
querying an Atom document and therefore will create a stress in an 
application which will have to make the decision about either dropping 
FIQL entirely in favor of home made XPath/XQuery/etc. queries or will 
potentially extend FIQL.

Overall, I'm not convinced there is a need for such specification. It 
might be great as best practices on the Atom wiki however. Also, even 
though some topics need an IETF draft, I'm worried that by defining 
specialized ones for Atom when standard alternatives already exist (e.g. 
XPath) the community will attract concerns about its capacity to re-use 
existing solutions.

That being said I'm not criticizing your work Mark, as I said just as a 
best practices document such specification would be very valuable to the 
community. But trying to go the IETF way sometimes feel too heavy.

Anyway just some thoughts :)
- Sylvain




Mark Nottingham wrote:
>
> FYI; I'd love any feedback folks have on this.
>
> Begin forwarded message:
>
>> From: Internet-Drafts@ietf.org
>> Date: 19 December 2007 7:15:02 AM
>> To: i-d-announce@ietf.org
>> Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : FIQL: The Feed Item Query Language
>>     Author(s)    : M. Nottingham
>>     Filename    : draft-nottingham-atompub-fiql-00.txt
>>     Pages        : 16
>>     Date        : 2007-12-18
>>     
>>   The Feed Item Query Language is a simple but flexible, URI-friendly
>>   syntax for expressing filters across the entries in a Web feed.  It
>>   also specifies a mechanism to allow feeds to indicate what types of
>>   queries are supported.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-nottingham-atompub-fiql-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     mailserv@ietf.org.
>> In the body type:
>>     "FILE /internet-drafts/draft-nottingham-atompub-fiql-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2007-12-18145429.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
> -- 
> Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Thu Dec 20 08:03:59 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5L4B-0002Dk-3z
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 08:03:59 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5L48-00087u-Qu
	for atompub-archive@lists.ietf.org; Thu, 20 Dec 2007 08:03:59 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKCkQqT015861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Dec 2007 05:46:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBKCkQYj015860;
	Thu, 20 Dec 2007 05:46:26 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lBKCkOxo015852
	for <atom-syntax@imc.org>; Thu, 20 Dec 2007 05:46:24 -0700 (MST)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 20 Dec 2007 12:46:23 -0000
Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202]
  by mail.gmx.net (mp030) with SMTP; 20 Dec 2007 13:46:23 +0100
X-Authenticated: #163624
X-Provags-ID: V01U2FsdGVkX1/mXYEcyrXmqaBC/WgAvX+YkU0XmYyDUxd7jwUW+/
	BKuaJWwE7qIkNm
Date: Thu, 20 Dec 2007 13:46:21 +0100
From: "A. Pagaltzis" <pagaltzis@gmx.de>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Message-ID: <20071220124621.GC15399@klangraum>
Mail-Followup-To: 'Atom-Syntax' <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <20071219190520.GB15399@klangraum> <47697117.1050901@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <47697117.1050901@gmail.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
X-Y-GMX-Trusted: 0
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>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBKCkQqT015861
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199


* James M Snell <jasnell@gmail.com> [2007-12-19 20:40]:
> I meant only, for example, that regardless of whether the
> underlying feed uses "a:feed", "atom:feed", "foobar:feed",
> etc the xpath query would always just be "feed".

Yes, and I said you can=E2=80=99t do that in XPath, at least in 1.0.

Regards,
--=20
Aristotle Pagaltzis // <http://plasmasturm.org/>




From jefreyLitsardakis@chasecarey.com Fri Dec 21 04:39:47 2007
Return-path: <jefreyLitsardakis@chasecarey.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5eM7-00075y-4r
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 04:39:47 -0500
Received: from host210-100-static.49-88-b.business.telecomitalia.it ([88.49.100.210])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J5eM6-0003xE-GE
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 04:39:46 -0500
Received: by 10.142.25.211 with SMTP id CvQYKGMDBWrfP;
	Fri, 21 Dec 2007 10:39:54 +0100 (GMT)
Received: by 192.168.55.217 with SMTP id CdgaAQWitYwVKr.2662858825465;
	Fri, 21 Dec 2007 10:39:52 +0100 (GMT)
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 21 Dec 2007 10:39:49 +0100
To: atompub-archive@lists.ietf.org
From: "jefrey Litsardakis" <jefreyLitsardakis@chasecarey.com>
Subject: danossac
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.0 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

She moans louder and loves sex so much now that i have gained 3 full inches! http://www.sevvvoent.com/



From owner-atom-syntax@mail.imc.org Fri Dec 21 15:31:35 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5oWt-0002d1-Fl
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 15:31:35 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5oWr-0000aW-6w
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 15:31:35 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLK18Da055027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Dec 2007 13:01:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBLK18ew055026;
	Fri, 21 Dec 2007 13:01:08 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLK18RU055020
	for <atom-syntax@imc.org>; Fri, 21 Dec 2007 13:01:08 -0700 (MST)
	(envelope-from bill@dehora.net)
Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227])
	by chilco.textdrive.com (Postfix) with ESMTP id 70C02DD626
	for <atom-syntax@imc.org>; Fri, 21 Dec 2007 20:01:07 +0000 (UTC)
Message-ID: <476C1B82.7080000@dehora.net>
Date: Fri, 21 Dec 2007 20:01:06 +0000
From: Bill de hOra <bill@dehora.net>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>
Subject: Re: Suggestions for extension namespace URIs
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
In-Reply-To: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad


Joe Gregorio wrote:
> We (Google) are going to be producing I-Ds for
> some extension elements in Atom. Anybody got
> suggestions for picking a namespace URI?
> We could use PURLs, or register our own
> domain, but what are the options beyond that?

Use http:, end them in /, and don't use fragids.

cheers
Bill




From owner-atom-syntax@mail.imc.org Fri Dec 21 15:39:31 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5oeZ-0003Rh-Gw
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 15:39:31 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5oeY-0000kO-Ka
	for atompub-archive@lists.ietf.org; Fri, 21 Dec 2007 15:39:31 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLKOn4Q056447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Dec 2007 13:24:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBLKOn9f056446;
	Fri, 21 Dec 2007 13:24:49 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBLKOmeD056440
	for <atom-syntax@imc.org>; Fri, 21 Dec 2007 13:24:49 -0700 (MST)
	(envelope-from bill@dehora.net)
Received: from [192.168.2.166] (83-70-250-227.b-ras1.prp.dublin.eircom.net [83.70.250.227])
	by chilco.textdrive.com (Postfix) with ESMTP id 46D36DDC1C
	for <atom-syntax@imc.org>; Fri, 21 Dec 2007 20:24:47 +0000 (UTC)
Message-ID: <476C210E.6060104@dehora.net>
Date: Fri, 21 Dec 2007 20:24:46 +0000
From: Bill de hOra <bill@dehora.net>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Atom-Syntax Syntax <atom-syntax@imc.org>
Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
In-Reply-To: <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8



"updated=gt=2003-12-13T00:00:00Z"

use underscores instead for ranges, ie

  updated_gt==2003-12-13T00:00:00Z

I didn't understand why '==' is used as a token instead of '='. Perhaps 
the above suggestion helps with that.


"By default, a selector is treated as an XML QName 
[W3C.REC-xml-names-19990114] which selects any and all child elements 
of the entry element which share the same syntax (i.e., the same 
prefix and localname; the namespace URI is not considered), along   with 
their descendant content if any.
"

I'm no fan of Qnames/XMLNS, but that looks butchered to me. You at least 
need to figure out what to do with atom in the default ns and atom with 
atom:.

The spec doesn't say what should happen with acquired information or 
assumed values (ie, author). I have to assume since you're treating 
qnames literally, you're not catering for that either.


I'm not sold on the subset XPath arguments elsewhere btw. This language 
seems designed to match across branches not select subtrees.

cheers
Bill


Mark Nottingham wrote:
> 
> FYI; I'd love any feedback folks have on this.
> 
> Begin forwarded message:
> 
>> From: Internet-Drafts@ietf.org
>> Date: 19 December 2007 7:15:02 AM
>> To: i-d-announce@ietf.org
>> Subject: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
>> Reply-To: internet-drafts@ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : FIQL: The Feed Item Query Language
>>     Author(s)    : M. Nottingham
>>     Filename    : draft-nottingham-atompub-fiql-00.txt
>>     Pages        : 16
>>     Date        : 2007-12-18
>>     
>>   The Feed Item Query Language is a simple but flexible, URI-friendly
>>   syntax for expressing filters across the entries in a Web feed.  It
>>   also specifies a mechanism to allow feeds to indicate what types of
>>   queries are supported.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-fiql-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-nottingham-atompub-fiql-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     mailserv@ietf.org.
>> In the body type:
>>     "FILE /internet-drafts/draft-nottingham-atompub-fiql-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <2007-12-18145429.I-D@ietf.org>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 




From owner-atom-syntax@mail.imc.org Sat Dec 22 01:36:19 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J5xy7-0004p7-49
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 01:36:19 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J5xy4-00072R-Vw
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 01:36:19 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBM6K46u020098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Dec 2007 23:20:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBM6K4aG020097;
	Fri, 21 Dec 2007 23:20:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBM6K2ei020091
	for <atom-syntax@imc.org>; Fri, 21 Dec 2007 23:20:03 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by an-out-0708.google.com with SMTP id c23so136820anc.44
        for <atom-syntax@imc.org>; Fri, 21 Dec 2007 22:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=o8lwmC+/wlx6HriewgHDm5oYpZ4zVDdwVLq63Cqm0EM=;
        b=f8Jz4yLNyJTal7Gb/cqRpTu9rZE+oGjASCZhjceuUWRPkDG2xZop3sNxEsHQwn0tG43TYsWyEt49Yt9ajQnG2h9pVLgYWjHYyZh69H02ZIYIhLo0Qo5+pMZUjX8xbMCK0uVtO8M89myLVNyMGRCYDyQhA5jcimGi+D72Y426vM0=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=LcEqYFE2hVn+5cY1yV1+d2kMWuTb36i+N+wkvFaXcxN0JlFXT0HkVVv8Fmgb9s6th3aGvmuPLKpv5qgiA/PxmDtP3bxavzG/YeOa6J8aPf4mmTOkTmosHk/lgq53qxn3ftSYRZ4tbW2P8UuaxyNsjNXauqEdP4OkSc0tyj+oO5A=
Received: by 10.100.241.17 with SMTP id o17mr4379675anh.32.1198304402276;
        Fri, 21 Dec 2007 22:20:02 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id l31sm1491468hsa.0.2007.12.21.22.20.00
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 21 Dec 2007 22:20:01 -0800 (PST)
Message-ID: <476CAC8F.4020305@gmail.com>
Date: Fri, 21 Dec 2007 22:19:59 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Link-Template [was Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt]
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <F232F66C-9016-419C-A874-7717F31E79E8@mnot.net>
In-Reply-To: <F232F66C-9016-419C-A874-7717F31E79E8@mnot.net>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7


The issue I have with the fiql draft is not really the query syntax
itself, as much as it is with the poor definition of the qname-based
selectors and the definition of the fq:interface mechanism.  What I
think would be a significantly better approach, as I've mentioned, is a
more generic link-template mechanism that could be used for a broader
set of use cases.  Prior to the publication of fiql, I had already been
working on a syntax for the link-template, which would be simple to
extend to support the fiql requirements.  For instance,

<template xmlns="http://purl.org/atompub/templates/1.0"
  title="Search"
  rel="search" type="application/atom+xml" hreflang="en-US"
  template="http://example.org/{index=entries}?{-join|&amp;|filter,num}">
  <variable name="index" type="http://.../enum">
    <value>entries</value>
    <value>comments</value>
  </variable>
  <variable name="num" type="http://.../simple" pattern="\d+" />
  <variable name="filter" type="http://.../expression">
    <field name="title" />
    <field name="rating" type="http://.../numeric" />
    <field name="updated" type="http://.../date" />
  </variable>
</template>

With this, there is messing around with QNames.  There's just a URI
Template with a number of template variables that each map to some
distinct value definition.

The "index" variable is typed as an "enum" with two possible values,
"entries" and "comments"

The "num" variable is a simple string value matching the regex pattern
"\d+" (one or more alphanumeric digits).

The "filter" variable is an expression that would match the FIQL syntax.
 Within the filter variable definition are specific typed field
definitions that define the fields that can be used within the fiql
expression.

For example, given the values:

  index  = entries
  num    = 10
  filter = title==foo;rating=5

The URI Template expands to:

  http://example.org/entries?num=10&filter=title==foo;rating==5

Personally, I think this approach provides significantly more
flexibility than the fq:interface definition without adding too much
unnecessary complexity.  It's also something that can be reused easily
for other use cases beyond basic searching and filtering

For instance,

<template xmlns="http://purl.org/atompub/templates/1.0"
  title="Archive"
  rel="archive" type="application/atom+xml" hreflang="en-US"
  template="http://example.org/archives/{year}/{month}">
  <variable name="year"
            type="http://.../simple"
            pattern="\d{4}" />
  <variable name="month"
            type="http://.../simple"
            pattern="0[1-9]|1[0-2]" />
</template>

And another:

<template xmlns="http://purl.org/atompub/templates/1.0"
  title="Sync"
  rel="sync" type="application/atom+xml" hreflang="en-US"
  template="http://example.org/sync?{-join|&|start,end">
  <variable name="start" type="http://.../date" />
  <variable name="end" type="http://.../date" />
</template>

Getting back to the FIQL use case, however, let's break down the field
definition from earlier:

  <variable name="filter" type="http://.../expression">
    <field name="title" />
    <field name="rating" type="http://.../numeric" />
    <field name="updated" type="http://.../date" />
  </variable>

Given this, there is obviously no clear connection between each of the
fields and the elements in the Atom.  Personally, I think this is a good
thing, as it ought to be up to the server code to determine the
appropriate mapping between the fields and the elements.  However, if we
do need a means of explicitly connecting the two, that can be done via
the field element definition.  For instance, in order to avoid having to
mess with QNames, we could define a URI identifier for each of the Atom
elements, e.g.,

  <field name="title" ref="http://www.w3.org/2005/Atom/title" />

This would tell us that the title field maps to the atom:title element.

Perhaps I wanted to filter on title type (text, html, or xhtml). For
that I could do something like:

  <field name="title" ref="http://www.w3.org/2005/Atom/title" />
  <field name="type"
         type="http://.../enum"
         ref="http://www.w3.org/2005/Atom/title/type">
    <value>text</value>
    <value>html</value>
    <value>xhtml</value>
  </field>

This would allow me to create expressions like:

  title==foo;type==html
  title==bar;type==text

I'm not convinced it's necessary, but like the fq:index element, the
field element could have a path attribute as well:

  <field name="rating" path="snx:rating" type="http://.../numeric" />

The link-template mechanism has the benefit of being more generically
applicable to more scenarios that fq:interface; allows the use of any
URI Template, not just ones that contain {fiql-exp}; avoids the
inherently messy qname garbage; and is not prohibitively more
complicated than the fq:interface syntax.

- James

Mark Nottingham wrote:
> Wow, really? Are all of your use cases behind a firewall / within the
> same administrative domain?
> 
> Cheers,
> 
> 
> On 20/12/2007, at 5:15 AM, James M Snell wrote:
> 
>> Regarding fq:interface, I'm not convinced the fq:index bit is necessary;
>> and I'd much rather see a more generic way of inserting URI Templates
>> into a feed
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 




From owner-atom-syntax@mail.imc.org Sat Dec 22 17:27:02 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6CoA-0007dx-4b
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 17:27:02 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6Co8-0001QE-DV
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 17:27:02 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMM54G8006730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 15:05:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBMM54tw006729;
	Sat, 22 Dec 2007 15:05:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMM53RM006723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 15:05:03 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.110] (unknown [121.44.175.237])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 7DEEA23E4A0;
	Sat, 22 Dec 2007 17:05:00 -0500 (EST)
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-Id: <48C1007E-D875-420B-B257-B7EA60442F8B@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Bill de hOra <bill@dehora.net>
In-Reply-To: <476C210E.6060104@dehora.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Sun, 23 Dec 2007 09:04:50 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <476C210E.6060104@dehora.net>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca



On 22/12/2007, at 7:24 AM, Bill de hOra wrote:

> "updated=gt=2003-12-13T00:00:00Z"
>
> use underscores instead for ranges, ie
>
> updated_gt==2003-12-13T00:00:00Z
>
> I didn't understand why '==' is used as a token instead of '='.  
> Perhaps the above suggestion helps with that.

Comparison operators are delimited with '=' so extension comparisons  
can be easily added down the road. "==" is necessary so that you don't  
confuse content with operator.

> "By default, a selector is treated as an XML QName [W3C.REC-xml- 
> names-19990114] which selects any and all child elements of the  
> entry element which share the same syntax (i.e., the same prefix and  
> localname; the namespace URI is not considered), along   with their  
> descendant content if any.
> "
>
> I'm no fan of Qnames/XMLNS, but that looks butchered to me. You at  
> least need to figure out what to do with atom in the default ns and  
> atom with atom:.

Yes, that seems to be where a lot of the pushback on the spec is  
centred. Let me ask explicitly: does anyone like the namespace binding  
between the URI and the document? I personally think it's not pretty,  
but better than some other attempts at referring to QNames in URIs.  
The alternatives, as I see them, are:

1) Specify this binding better (as you allude to)
2) Get rid of it completely, and require any non-Atom selectors to be  
defined in fq:interface.

> The spec doesn't say what should happen with acquired information or  
> assumed values (ie, author). I have to assume since you're treating  
> qnames literally, you're not catering for that either.

No, just haven't got to it yet.

> I'm not sold on the subset XPath arguments elsewhere btw. This  
> language seems designed to match across branches not select subtrees.



--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Sat Dec 22 18:12:20 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6DW0-00052P-Bo
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:12:20 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6DVz-0002Fp-JR
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:12:20 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMN14N1011022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 16:01:05 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBMN14fR011021;
	Sat, 22 Dec 2007 16:01:04 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMN13iJ011015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 16:01:04 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.110] (unknown [121.44.175.237])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 1E1C623E4A0;
	Sat, 22 Dec 2007 18:01:01 -0500 (EST)
Cc: Atom-Syntax Syntax <atom-syntax@imc.org>
Message-Id: <8482D8B8-1603-4EC6-9BC9-D11CE2A05BE4@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Sylvain Hellegouarch <sh@defuze.org>
In-Reply-To: <476A4AE5.9010808@defuze.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Sun, 23 Dec 2007 10:00:51 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <476A4AE5.9010808@defuze.org>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81


On 20/12/2007, at 9:58 PM, Sylvain Hellegouarch wrote:

> Hi Mark,
>
> I was following the discussion around this draft you've proposed and  
> rather than focusing on the choice of the most appropriate query  
> language used I wanted to ask you about the purpose of this draft?  
> Who is the target? Since you use URI-like query, are you thinking of  
> public services to query Atom feeds? In such case, shouldn't the  
> draft have a large security section (it looks like creating yet  
> another query syntax means that its security is by default nil until  
> proven otherwise)? Are you planning on making the draft  
> informational only or more?

Great questions.

I started this after looking at GData, which is really just APP +  
proprietary auth + proprietary feed-focused query.  Auth is a hard and  
luckily separable, but looking at the query portion of things, I  
thought we could do better.

So, yes, I'm thinking of public services, definitely. Yes, security  
considerations need to be filled out. Informational is the most I'd  
aspire to (unless there's *significant* interest in going further),  
and that may be too far.

> No matter what, FIQL will never be able to describe all the use  
> cases of querying an Atom document and therefore will create a  
> stress in an application which will have to make the decision about  
> either dropping FIQL entirely in favor of home made XPath/XQuery/ 
> etc. queries or will potentially extend FIQL.

Nor should it try to do everything; it's all about making the most  
common 80% as easy as possible to implement and use. That said, I  
tried to make sure that it is extensible in the right places.

> Overall, I'm not convinced there is a need for such specification.  
> It might be great as best practices on the Atom wiki however. Also,  
> even though some topics need an IETF draft, I'm worried that by  
> defining specialized ones for Atom when standard alternatives  
> already exist (e.g. XPath) the community will attract concerns about  
> its capacity to re-use existing solutions.

Perhaps, but if that's the case, why aren't people slapping generic  
XPath engines in front of their feeds? Why did Google choose to go for  
their own syntax instead of using XPath? Yes, FIQL is a new syntax,  
but it's one that people can understand after sitting down and playing  
with it for a few minutes. XPath 2.0 doesn't have the same property.

A lot of the discussion to date has been around the query language  
itself. To me, the most important part of FIQL is fq:interface; having  
a way to declare that there is a query interface -- whatever the query  
syntax -- is IMO necessary if people are going to be exposing these  
things.


> That being said I'm not criticizing your work Mark, as I said just  
> as a best practices document such specification would be very  
> valuable to the community. But trying to go the IETF way sometimes  
> feel too heavy.


To be clear, I submitted this not because I'm sure I want to  
standardise it; I did so because I want feedback from this community  
on this particular proposal, and to generally gauge interest in an  
openly defined feed query language.

Thanks!

--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Sat Dec 22 18:14:30 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6DY6-0007uN-JQ
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:14:30 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6DY6-0002I4-5d
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:14:30 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMMuRGn010660
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 15:56:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBMMuRQ5010659;
	Sat, 22 Dec 2007 15:56:27 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMMuQ33010650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 15:56:27 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.110] (unknown [121.44.175.237])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id E815923E4A0;
	Sat, 22 Dec 2007 17:56:24 -0500 (EST)
Cc: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Message-Id: <E8EFA075-F77F-4F6B-9422-2080D8D54339@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Martin Duerst <duerst@it.aoyama.ac.jp>
In-Reply-To: <6.0.0.20.2.20071220143032.0c1cc740@localhost>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt 
Date: Sun, 23 Dec 2007 09:56:13 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <3AEB3D5A-4C18-4BC0-9668-23D6C743B9CC@mnot.net> <6.0.0.20.2.20071220143032.0c1cc740@localhost>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126


I discounted XPath 1.0 pretty quickly not only because of lack of  
datatyping, but also because it's inherently not URI-friendly (one of  
my bigger design goals).

Cheers,


On 20/12/2007, at 4:32 PM, Martin Duerst wrote:

> I must admit that I haven't looked at the draft at all, but it seems
> strange to me to propose XPath 2.0 for something simple when there is
> XPath 1.0, and strange to reject any version of XPath based on the
> fact/opition that XPath 2.0 is too complex.


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Sat Dec 22 18:15:09 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6DYj-0008Al-FP
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:15:09 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6DYh-0002Ij-Hi
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 18:15:09 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMN4JjS011256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 16:04:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBMN4J9p011254;
	Sat, 22 Dec 2007 16:04:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBMN4FMQ011244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 16:04:16 -0700 (MST)
	(envelope-from mnot@mnot.net)
Received: from [192.168.1.110] (unknown [121.44.175.237])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id A994923E4A1;
	Sat, 22 Dec 2007 18:04:12 -0500 (EST)
Cc: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Message-Id: <9A4D5150-440A-465E-9093-BFAA1DC2B925@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: James M Snell <jasnell@gmail.com>
In-Reply-To: <476CAC8F.4020305@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Link-Template [was Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt]
Date: Sun, 23 Dec 2007 10:04:01 +1100
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <F232F66C-9016-419C-A874-7717F31E79E8@mnot.net> <476CAC8F.4020305@gmail.com>
X-Mailer: Apple Mail (2.915)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610


Sure, if we can get forward motion on a template-based analogy of the  
link element, I'm all for it; I just didn't want to try to boil the  
ocean in this one case. Seems like we have to settle on what a link  
template is first, however...

Cheers,


On 22/12/2007, at 5:19 PM, James M Snell wrote:

> The issue I have with the fiql draft is not really the query syntax
> itself, as much as it is with the poor definition of the qname-based
> selectors and the definition of the fq:interface mechanism.  What I
> think would be a significantly better approach, as I've mentioned,  
> is a
> more generic link-template mechanism that could be used for a broader
> set of use cases.  Prior to the publication of fiql, I had already  
> been
> working on a syntax for the link-template, which would be simple to
> extend to support the fiql requirements.  For instance,
>
> <template xmlns="http://purl.org/atompub/templates/1.0"
>  title="Search"
>  rel="search" type="application/atom+xml" hreflang="en-US"
>  template="http://example.org/{index=entries}?{-join|&amp;| 
> filter,num}">
>  <variable name="index" type="http://.../enum">
>    <value>entries</value>
>    <value>comments</value>
>  </variable>
>  <variable name="num" type="http://.../simple" pattern="\d+" />
>  <variable name="filter" type="http://.../expression">
>    <field name="title" />
>    <field name="rating" type="http://.../numeric" />
>    <field name="updated" type="http://.../date" />
>  </variable>
> </template>
>
> With this, there is messing around with QNames.  There's just a URI
> Template with a number of template variables that each map to some
> distinct value definition.
>
> The "index" variable is typed as an "enum" with two possible values,
> "entries" and "comments"
>
> The "num" variable is a simple string value matching the regex pattern
> "\d+" (one or more alphanumeric digits).
>
> The "filter" variable is an expression that would match the FIQL  
> syntax.
> Within the filter variable definition are specific typed field
> definitions that define the fields that can be used within the fiql
> expression.
>
> For example, given the values:
>
>  index  = entries
>  num    = 10
>  filter = title==foo;rating=5
>
> The URI Template expands to:
>
>  http://example.org/entries?num=10&filter=title==foo;rating==5
>
> Personally, I think this approach provides significantly more
> flexibility than the fq:interface definition without adding too much
> unnecessary complexity.  It's also something that can be reused easily
> for other use cases beyond basic searching and filtering
>
> For instance,
>
> <template xmlns="http://purl.org/atompub/templates/1.0"
>  title="Archive"
>  rel="archive" type="application/atom+xml" hreflang="en-US"
>  template="http://example.org/archives/{year}/{month}">
>  <variable name="year"
>            type="http://.../simple"
>            pattern="\d{4}" />
>  <variable name="month"
>            type="http://.../simple"
>            pattern="0[1-9]|1[0-2]" />
> </template>
>
> And another:
>
> <template xmlns="http://purl.org/atompub/templates/1.0"
>  title="Sync"
>  rel="sync" type="application/atom+xml" hreflang="en-US"
>  template="http://example.org/sync?{-join|&|start,end">
>  <variable name="start" type="http://.../date" />
>  <variable name="end" type="http://.../date" />
> </template>
>
> Getting back to the FIQL use case, however, let's break down the field
> definition from earlier:
>
>  <variable name="filter" type="http://.../expression">
>    <field name="title" />
>    <field name="rating" type="http://.../numeric" />
>    <field name="updated" type="http://.../date" />
>  </variable>
>
> Given this, there is obviously no clear connection between each of the
> fields and the elements in the Atom.  Personally, I think this is a  
> good
> thing, as it ought to be up to the server code to determine the
> appropriate mapping between the fields and the elements.  However,  
> if we
> do need a means of explicitly connecting the two, that can be done via
> the field element definition.  For instance, in order to avoid  
> having to
> mess with QNames, we could define a URI identifier for each of the  
> Atom
> elements, e.g.,
>
>  <field name="title" ref="http://www.w3.org/2005/Atom/title" />
>
> This would tell us that the title field maps to the atom:title  
> element.
>
> Perhaps I wanted to filter on title type (text, html, or xhtml). For
> that I could do something like:
>
>  <field name="title" ref="http://www.w3.org/2005/Atom/title" />
>  <field name="type"
>         type="http://.../enum"
>         ref="http://www.w3.org/2005/Atom/title/type">
>    <value>text</value>
>    <value>html</value>
>    <value>xhtml</value>
>  </field>
>
> This would allow me to create expressions like:
>
>  title==foo;type==html
>  title==bar;type==text
>
> I'm not convinced it's necessary, but like the fq:index element, the
> field element could have a path attribute as well:
>
>  <field name="rating" path="snx:rating" type="http://.../numeric" />
>
> The link-template mechanism has the benefit of being more generically
> applicable to more scenarios that fq:interface; allows the use of any
> URI Template, not just ones that contain {fiql-exp}; avoids the
> inherently messy qname garbage; and is not prohibitively more
> complicated than the fq:interface syntax.
>
> - James
>
> Mark Nottingham wrote:
>> Wow, really? Are all of your use cases behind a firewall / within the
>> same administrative domain?
>>
>> Cheers,
>>
>>
>> On 20/12/2007, at 5:15 AM, James M Snell wrote:
>>
>>> Regarding fq:interface, I'm not convinced the fq:index bit is  
>>> necessary;
>>> and I'd much rather see a more generic way of inserting URI  
>>> Templates
>>> into a feed
>>
>>
>> -- 
>> Mark Nottingham     http://www.mnot.net/
>>
>>


--
Mark Nottingham     http://www.mnot.net/




From owner-atom-syntax@mail.imc.org Sat Dec 22 19:14:12 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6ETs-0002xc-6d
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 19:14:12 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6ETr-0003Hx-OR
	for atompub-archive@lists.ietf.org; Sat, 22 Dec 2007 19:14:12 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBN01Iv3016983
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 17:01:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBN01Iev016982;
	Sat, 22 Dec 2007 17:01:18 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mxout-04.mxes.net (mxout-04.mxes.net [216.86.168.179])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBN01Hk2016976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 17:01:18 -0700 (MST)
	(envelope-from brian@briansmith.org)
Received: from Junk (unknown [209.169.80.164])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id E7853D0501
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 19:01:15 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Atom-Syntax'" <atom-syntax@imc.org>
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <476A4AE5.9010808@defuze.org> <8482D8B8-1603-4EC6-9BC9-D11CE2A05BE4@mnot.net>
Subject: RE: I-D ACTION:draft-nottingham-atompub-fiql-00.txt
Date: Sun, 23 Dec 2007 07:01:04 +0700
Message-ID: <000301c844f6$efba80c0$2301a8c0@Junk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <8482D8B8-1603-4EC6-9BC9-D11CE2A05BE4@mnot.net>
Thread-Index: AchE7rr7mtcJOL8iQV2RNjsL3EZlMgABEU4w
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb


Mark Nottingham wrote:
> A lot of the discussion to date has been around the query 
> language itself. To me, the most important part of FIQL is 
> fq:interface; having a way to declare that there is a query 
> interface -- whatever the query syntax -- is IMO necessary if 
> people are going to be exposing these things.

<snip>

> To be clear, I submitted this not because I'm sure I want to 
> standardise it; I did so because I want feedback from this 
> community on this particular proposal, and to generally gauge 
> interest in an openly defined feed query language.

I suggest trying to define it as an extension to OpenSearch. OpenSearch
already has been implemented many times by many people, and it already
is an "80%" solution since it is about full text search. 

No matter what you do, URLs are always going to be hard to read. I
suggest giving up on the readability of the URL so that you can gain
readability in non-URL contexts. In particular, I recommend the
end-user-friendly syntax used by Google, Yahoo, Live Search, Lucene, and
many other existing systems: 

	keyword (keyword OR keyword) operator:"operator parameter"

Where operators are like:

	tag:HTTP tag:Standards tag:Web tag:"Web Services"
	updated:2007 
	updated:2007-12
	updated:2007-12-09
	author:Mark
	title:Foo

This ends up being pretty unreadable in URIs due to percent-encoding of
spaces, but some groups have been pretty successful with it.

- Brian




From owner-atom-syntax@mail.imc.org Sun Dec 23 00:25:08 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6JKm-0005Dd-Ju
	for atompub-archive@lists.ietf.org; Sun, 23 Dec 2007 00:25:08 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J6JKk-0001DK-Gz
	for atompub-archive@lists.ietf.org; Sun, 23 Dec 2007 00:25:08 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBN5AeQj035777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 22 Dec 2007 22:10:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBN5AeCK035776;
	Sat, 22 Dec 2007 22:10:40 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBN5AcCV035769
	for <atom-syntax@imc.org>; Sat, 22 Dec 2007 22:10:39 -0700 (MST)
	(envelope-from jasnell@gmail.com)
Received: by rv-out-0910.google.com with SMTP id c27so678161rvf.34
        for <atom-syntax@imc.org>; Sat, 22 Dec 2007 21:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=s69A57NykKCan3UE684PBlPboPwHPNz1SgQjPvaKimY=;
        b=oitgpX79S/s6A5MLFSaH5eaPmGduwnUc/u2sm4pqUK5D63Y49ceF6CHtLKAxhpIbgnaKw3yEoQVhfDgbNM0GUokF75HWhqdGg61YRINZ+Pn8+VWg7j3g58gfVscrtMhjj1TEsdLY1xKCccnBgxVxz6a26EH40rikbUa5BHYwiHo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=NI+UdCmeKvy+VtXnV4FUvedtGVZ7TF03PhhRzHyudp3iADbBjQZPdH9uy7Dnbo4WFjNJswEbT4rh4/UgO9joX3tkt7ttu6gaCunoXLicugBj/9cqj+O0afIq2CY66VaVyNLGOakVKglR/fun3XO0eeGcCeggAb7hWuS3MtVHCjM=
Received: by 10.141.43.5 with SMTP id v5mr1680413rvj.216.1198386638513;
        Sat, 22 Dec 2007 21:10:38 -0800 (PST)
Received: from ?192.168.1.2? ( [67.181.218.96])
        by mx.google.com with ESMTPS id f42sm3562878rvb.13.2007.12.22.21.10.36
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Sat, 22 Dec 2007 21:10:37 -0800 (PST)
Message-ID: <476DEDC3.90301@gmail.com>
Date: Sat, 22 Dec 2007 21:10:27 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: Brian Smith <brian@briansmith.org>, "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: Re: Link-Template [was Re: I-D ACTION:draft-nottingham-atompub-fiql-00.txt]
References: <E1J4iqE-0005jo-JM@stiedprstage1.ietf.org> <5F74F209-465F-4E61-9B22-E657353DADA7@mnot.net> <005901c841dc$3ac7c3c0$0701a8c0@Junk> <75E33D80-62FF-4220-A6B6-5DD78BB73106@mnot.net> <008601c84214$7674e2d0$0701a8c0@Junk> <47695FB3.2030809@gmail.com> <F232F66C-9016-419C-A874-7717F31E79E8@mnot.net> <476CAC8F.4020305@gmail.com> <9A4D5150-440A-465E-9093-BFAA1DC2B925@mnot.net>
In-Reply-To: <9A4D5150-440A-465E-9093-BFAA1DC2B925@mnot.net>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783


I think the "what" is pretty simple: a link-template is essentially just
a parameterized atom:link built around a URI Template.  It shouldn't be
all that complicated.

A link-template would have the same basic attributes as an atom:link,
but would have a template in place of the the href.  Associated with
each are one or more variable definitions; each of which have a defined
type.  The type can be a simple value, a number, a date, an enum, or an
expression.  Simple values can optionally be defined to adhere to a
regex pattern.  Numbers and dates can have min/max values. Enums provide
a listing of static values. An expression could be a FIQL expression
which would have a set of field definitions that would basically echo
the variable definitions.

The link-template's rel attribute would identify the purpose of the
template.  There are a number of rel values we can very easily identify
now without much effort.  "search", "sync", "archives", etc.

Other than the definition of the expression language, which you've
already covered, there's really nothing else to it.  I'd be more than
happy to write up the necessary spec text.

- James

Mark Nottingham wrote:
> Sure, if we can get forward motion on a template-based analogy of the
> link element, I'm all for it; I just didn't want to try to boil the
> ocean in this one case. Seems like we have to settle on what a link
> template is first, however...
> 
> Cheers,
> 
> 
> On 22/12/2007, at 5:19 PM, James M Snell wrote:
> 
>> The issue I have with the fiql draft is not really the query syntax
>> itself, as much as it is with the poor definition of the qname-based
>> selectors and the definition of the fq:interface mechanism.  What I
>> think would be a significantly better approach, as I've mentioned, is a
>> more generic link-template mechanism that could be used for a broader
>> set of use cases.  Prior to the publication of fiql, I had already been
>> working on a syntax for the link-template, which would be simple to
>> extend to support the fiql requirements.  For instance,
>>
>> <template xmlns="http://purl.org/atompub/templates/1.0"
>>  title="Search"
>>  rel="search" type="application/atom+xml" hreflang="en-US"
>>  template="http://example.org/{index=entries}?{-join|&amp;|filter,num}">
>>  <variable name="index" type="http://.../enum">
>>    <value>entries</value>
>>    <value>comments</value>
>>  </variable>
>>  <variable name="num" type="http://.../simple" pattern="\d+" />
>>  <variable name="filter" type="http://.../expression">
>>    <field name="title" />
>>    <field name="rating" type="http://.../numeric" />
>>    <field name="updated" type="http://.../date" />
>>  </variable>
>> </template>
>>
>> With this, there is messing around with QNames.  There's just a URI
>> Template with a number of template variables that each map to some
>> distinct value definition.
>>
>> The "index" variable is typed as an "enum" with two possible values,
>> "entries" and "comments"
>>
>> The "num" variable is a simple string value matching the regex pattern
>> "\d+" (one or more alphanumeric digits).
>>
>> The "filter" variable is an expression that would match the FIQL syntax.
>> Within the filter variable definition are specific typed field
>> definitions that define the fields that can be used within the fiql
>> expression.
>>
>> For example, given the values:
>>
>>  index  = entries
>>  num    = 10
>>  filter = title==foo;rating=5
>>
>> The URI Template expands to:
>>
>>  http://example.org/entries?num=10&filter=title==foo;rating==5
>>
>> Personally, I think this approach provides significantly more
>> flexibility than the fq:interface definition without adding too much
>> unnecessary complexity.  It's also something that can be reused easily
>> for other use cases beyond basic searching and filtering
>>
>> For instance,
>>
>> <template xmlns="http://purl.org/atompub/templates/1.0"
>>  title="Archive"
>>  rel="archive" type="application/atom+xml" hreflang="en-US"
>>  template="http://example.org/archives/{year}/{month}">
>>  <variable name="year"
>>            type="http://.../simple"
>>            pattern="\d{4}" />
>>  <variable name="month"
>>            type="http://.../simple"
>>            pattern="0[1-9]|1[0-2]" />
>> </template>
>>
>> And another:
>>
>> <template xmlns="http://purl.org/atompub/templates/1.0"
>>  title="Sync"
>>  rel="sync" type="application/atom+xml" hreflang="en-US"
>>  template="http://example.org/sync?{-join|&|start,end">
>>  <variable name="start" type="http://.../date" />
>>  <variable name="end" type="http://.../date" />
>> </template>
>>
>> Getting back to the FIQL use case, however, let's break down the field
>> definition from earlier:
>>
>>  <variable name="filter" type="http://.../expression">
>>    <field name="title" />
>>    <field name="rating" type="http://.../numeric" />
>>    <field name="updated" type="http://.../date" />
>>  </variable>
>>
>> Given this, there is obviously no clear connection between each of the
>> fields and the elements in the Atom.  Personally, I think this is a good
>> thing, as it ought to be up to the server code to determine the
>> appropriate mapping between the fields and the elements.  However, if we
>> do need a means of explicitly connecting the two, that can be done via
>> the field element definition.  For instance, in order to avoid having to
>> mess with QNames, we could define a URI identifier for each of the Atom
>> elements, e.g.,
>>
>>  <field name="title" ref="http://www.w3.org/2005/Atom/title" />
>>
>> This would tell us that the title field maps to the atom:title element.
>>
>> Perhaps I wanted to filter on title type (text, html, or xhtml). For
>> that I could do something like:
>>
>>  <field name="title" ref="http://www.w3.org/2005/Atom/title" />
>>  <field name="type"
>>         type="http://.../enum"
>>         ref="http://www.w3.org/2005/Atom/title/type">
>>    <value>text</value>
>>    <value>html</value>
>>    <value>xhtml</value>
>>  </field>
>>
>> This would allow me to create expressions like:
>>
>>  title==foo;type==html
>>  title==bar;type==text
>>
>> I'm not convinced it's necessary, but like the fq:index element, the
>> field element could have a path attribute as well:
>>
>>  <field name="rating" path="snx:rating" type="http://.../numeric" />
>>
>> The link-template mechanism has the benefit of being more generically
>> applicable to more scenarios that fq:interface; allows the use of any
>> URI Template, not just ones that contain {fiql-exp}; avoids the
>> inherently messy qname garbage; and is not prohibitively more
>> complicated than the fq:interface syntax.
>>
>> - James
>>
>> Mark Nottingham wrote:
>>> Wow, really? Are all of your use cases behind a firewall / within the
>>> same administrative domain?
>>>
>>> Cheers,
>>>
>>>
>>> On 20/12/2007, at 5:15 AM, James M Snell wrote:
>>>
>>>> Regarding fq:interface, I'm not convinced the fq:index bit is
>>>> necessary;
>>>> and I'd much rather see a more generic way of inserting URI Templates
>>>> into a feed
>>>
>>>
>>> -- 
>>> Mark Nottingham     http://www.mnot.net/
>>>
>>>
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/
> 
> 




From Padgett@kijkenvergelijk.com Sun Dec 23 02:38:37 2007
Return-path: <Padgett@kijkenvergelijk.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6LPx-0006iA-2H
	for atompub-archive@lists.ietf.org; Sun, 23 Dec 2007 02:38:37 -0500
Received: from cust-83-143-142-177.flashnet.pl ([83.143.142.177])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J6LPw-00006b-6K
	for atompub-archive@lists.ietf.org; Sun, 23 Dec 2007 02:38:36 -0500
Received: from KUBA ([160.120.175.143] helo=KUBA)
	by cust-83-143-142-177.flashnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1rvCzd-000AFQ-ZD
	for atompub-archive@lists.ietf.org; Sun, 23 Dec 2007 08:39:08 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 23 Dec 2007 08:38:47 +0100
To: atompub-archive@lists.ietf.org
From: "reni Padgett" <Padgett@kijkenvergelijk.com>
Subject: isiekkah
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.5 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

Incredible, humongous, size - when sharon saw how big I had become, she was speechless http://www.ouwertus.com/



From harmony_Eagle@nujaidi.com Mon Dec 24 13:20:40 2007
Return-path: <harmony_Eagle@nujaidi.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J6ruq-0006zj-20
	for atompub-archive@lists.ietf.org; Mon, 24 Dec 2007 13:20:40 -0500
Received: from [89.152.218.18] (helo=[89.152.218.18])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J6ruo-0006yP-Ds
	for atompub-archive@lists.ietf.org; Mon, 24 Dec 2007 13:20:39 -0500
Received: from asus ([184.149.6.111] helo=asus)
	by [89.152.218.18] ( sendmail 8.13.3/8.13.1) with esmtpa id 1Gfqps-000COD-Ta
	for atompub-archive@lists.ietf.org; Mon, 24 Dec 2007 18:21:17 -0000
Message-ID: <43420A97.397C5BED@nujaidi.com>
Date: Mon, 24 Dec 2007 18:20:39 -0000
From: "harmony Eagle" <harmony_Eagle@nujaidi.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: rosonawu
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 08e48e05374109708c00c6208b534009

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
"Unbelievable gains in 3 short months" - Jason from Florida, USA.<br>
What works for him has worked for thousands others as well! <a href="http://smalrincess.com/">http://smalrincess.com/</a><br>
</html>



From Gatornfhd@baltechno.se Tue Dec 25 09:42:08 2007
Return-path: <Gatornfhd@baltechno.se>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J7Ayu-0000te-3F
	for atompub-archive@lists.ietf.org; Tue, 25 Dec 2007 09:42:08 -0500
Received: from host179-252-dynamic.15-87-r.retail.telecomitalia.it ([87.15.252.179] helo=host204-118-dynamic.54-82-r.retail.telecomitalia.it)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J7Ayt-000729-5Z
	for atompub-archive@lists.ietf.org; Tue, 25 Dec 2007 09:42:07 -0500
Received: from PC ([182.175.80.100] helo=PC)
	by host204-118-dynamic.54-82-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZfQKX-000NSU-Xx
	for atompub-archive@lists.ietf.org; Tue, 25 Dec 2007 15:42:42 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 25 Dec 2007 15:42:14 +0100
To: atompub-archive@lists.ietf.org
From: "Jelle Gator" <Gatornfhd@baltechno.se>
Subject: seatteto
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.1 (++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

Your stunning blonde will find you a stunner! http://www.tyrdpq.com/



From shawnette-Parlette@angiw.com Wed Dec 26 16:09:41 2007
Return-path: <shawnette-Parlette@angiw.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J7dVV-0000Z3-BE
	for atompub-archive@lists.ietf.org; Wed, 26 Dec 2007 16:09:41 -0500
Received: from aclf9.neoplus.adsl.tpnet.pl ([83.10.107.9] helo=acmc91.neoplus.adsl.tpnet.pl)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J7dVQ-0006GG-EU
	for atompub-archive@lists.ietf.org; Wed, 26 Dec 2007 16:09:36 -0500
Received: from anio³ ([144.127.170.0]:30679 "EHLO anio³"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by acmc91.neoplus.adsl.tpnet.pl with ESMTP id S22CXLYEWYVXNVAA (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Wed, 26 Dec 2007 22:09:56 +0100
Message-ID: <C690A2DF.66FB5AE5@angiw.com>
Date: Wed, 26 Dec 2007 22:09:33 +0100
From: "shawnette Parlette" <shawnette-Parlette@angiw.com>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: nisaanmy
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Why live life miserably with a tiny dick? Get a massive 
schlong<br>
easily! <a href="http://vuensit.com/">http://vuensit.com/</a><br>
</html>



From owner-atom-syntax@mail.imc.org Thu Dec 27 01:51:39 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J7mag-00088N-TT
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 01:51:38 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J7maf-0001G6-2w
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 01:51:38 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR6XJla070144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Dec 2007 23:33:20 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBR6XJi5070143;
	Wed, 26 Dec 2007 23:33:19 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironmaiden.mail.utexas.edu (ironmaiden.mail.utexas.edu [128.83.32.53])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR6XIGh070137
	for <atom-syntax@imc.org>; Wed, 26 Dec 2007 23:33:19 -0700 (MST)
	(envelope-from pkeane@mail.utexas.edu)
DomainKey-Signature: s=main; d=mail.utexas.edu; c=nofws; q=dns;
    h=Received:Received:Received:Date:From:X-X-Sender:To:
      Subject:Message-ID:User-Agent:MIME-Version:
      Content-Type;
    b=C0U/SS/YeINRKWdTWcwJ4FQwtQcguMUu/GzFAR6vxk+37/RIOso+v
      CkbHb5clc3xzv9UV7XLWkvHhv2sg3yFM4ls+UCBIcq9i3KXKDb62M
      n1yOhMmDdjYimSI5YnUMH0UmkxVcpZvXOYx/fhkhHSjpZLXisPg2G
      PjszOfs7//us=;
Received: from wb3-a.mail.utexas.edu ([128.83.126.138])
  by ironmaiden.mail.utexas.edu with ESMTP; 27 Dec 2007 00:33:18 -0600
Received: (qmail 87647 invoked from network); 27 Dec 2007 06:33:18 -0000
Received: from harpo.laits.utexas.edu (pkeane@128.83.27.7)
  by wb3.mail.utexas.edu with (RC4-SHA encrypted) ESMTPSA; 27 Dec 2007 06:33:18 -0000
Date: Thu, 27 Dec 2007 00:33:18 -0600 (CST)
From: Peter Keane <pkeane@mail.utexas.edu>
X-X-Sender: pkeane@harpo.laits.utexas.edu
To: "'Atom-Syntax'" <atom-syntax@imc.org>
Subject: OAI-ORE Resource Map Implementation in Atom
Message-ID: <alpine.BSO.1.00.0712270018060.25630@harpo.laits.utexas.edu>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d


Hi Folks-

Open Archives Initiative Object Reuse and Exchange figures to be a VERY 
important standard in the digital library/archives world.  From the 
documentation:

"OAI-ORE defines standards for the description and exchange of 
aggregations of Web resources.  the OAI-ORE introduces the notion of a 
Resource Map, which is a specialization of a named graph that asserts a 
finite set of resources (the Aggregated Resources), their types, 
intra-relationships, and relationships with resources external to this 
finite set (the external resources). A Resource Map Document is a 
machine-readable representation of a Resource Map. Although multiple 
serializations of Resource Maps are possible, the initial serialization is 
done using the Atom Syndication Format [RFC4287]."

I'll be very curious to know what the Atom-erati think about the Resource 
Map Implentation in Atom:
(http://www.openarchives.org/ore/0.1/atom-implementation).

It looks to me to be a well-considered and thorough implementation of the 
Atom Syndication Format in an area well-outside the blogging domain. 
Perhaps this is a (welcome and anticipated) sign of the power and utility 
of Atom/AtomPub?

-Peter Keane
daseproject.org




From JaneHankins@adviceforlawyers.co.uk Thu Dec 27 06:32:22 2007
Return-path: <JaneHankins@adviceforlawyers.co.uk>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J7qyM-00032N-3l
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 06:32:22 -0500
Received: from host180-85-static.107-82-b.business.telecomitalia.it ([82.107.85.180])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J7qyL-0008AE-5e
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 06:32:22 -0500
Received: from companys-f8db9e
	by adviceforlawyers.co.uk with ASMTP id 1E4DA948
	for <atompub-archive@lists.ietf.org>; Thu, 27 Dec 2007 12:32:46 +0100
Received: from companys-f8db9e ([151.155.16.3])
	by adviceforlawyers.co.uk with ESMTP id 38443D1AD235
	for <atompub-archive@lists.ietf.org>; Thu, 27 Dec 2007 12:32:46 +0100
Message-ID: <184556B9.5C687A53@adviceforlawyers.co.uk>
Date: Thu, 27 Dec 2007 12:32:17 +0100
From: "Jane Hankins" <JaneHankins@adviceforlawyers.co.uk>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: apoplect
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.5 (++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Real growth, real man! <a href="http://www.huteeine.com/">http://www.huteeine.com/</a><br>
</html>



From chaDauncey@chrisrodgers.co.uk Thu Dec 27 14:48:43 2007
Return-path: <chaDauncey@chrisrodgers.co.uk>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J7yih-00045W-FW
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 14:48:43 -0500
Received: from p549fd127.dip.t-dialin.net ([84.159.209.39] helo=p549FC3D7.dip.t-dialin.net)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J7yig-0004w0-Ja
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 14:48:43 -0500
Received: from miststück ([139.195.62.159] helo=miststück)
	by p549FC3D7.dip.t-dialin.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1DXBRM-000TVW-lE
	for atompub-archive@lists.ietf.org; Thu, 27 Dec 2007 20:51:38 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 27 Dec 2007 20:51:13 +0100
To: atompub-archive@lists.ietf.org
From: "cha Dauncey" <chaDauncey@chrisrodgers.co.uk>
Subject: wotslwof
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

Check out the product created for the good of all men! http://buyteuu.com/



From Joak_Elmundo@armundo.de Fri Dec 28 12:19:46 2007
Return-path: <Joak_Elmundo@armundo.de>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8Is5-0006pe-W7
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 12:19:46 -0500
Received: from aas141.neoplus.adsl.tpnet.pl ([83.25.18.141] helo=abj218.neoplus.adsl.tpnet.pl)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J8Iry-0005VR-Ai
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 12:19:45 -0500
Received: from emi ([125.144.12.121] helo=emi)
	by abj218.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1kZnEn-000LDC-sl
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 18:19:52 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 28 Dec 2007 18:19:29 +0100
To: atompub-archive@lists.ietf.org
From: "Joak Elmundo" <Joak_Elmundo@armundo.de>
Subject: ttisarja
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 1.7 (+)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

You can screw Pamela Anderson too, with your 9 inch dick. http://werkstop.com/



From owner-atom-syntax@mail.imc.org Fri Dec 28 13:08:57 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8Jdh-0007nx-MJ
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 13:08:57 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J8Jdg-0001sG-6P
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 13:08:57 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBSHoviW051714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Dec 2007 10:50:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBSHov3f051713;
	Fri, 28 Dec 2007 10:50:57 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBSHorjp051699
	for <atom-syntax@imc.org>; Fri, 28 Dec 2007 10:50:54 -0700 (MST)
	(envelope-from Tim.Bray@Sun.COM)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBSHor8F007866
	for <atom-syntax@imc.org>; Fri, 28 Dec 2007 17:50:53 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JTR00701T650M00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM)
 for atom-syntax@imc.org; Fri, 28 Dec 2007 10:50:53 -0700 (MST)
Received: from [192.168.1.57] (fatwire-203-217.uniserve.ca [216.113.203.218])
 by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JTR00FPXTKSUP20@mail-amer.sun.com>; Fri,
 28 Dec 2007 10:50:53 -0700 (MST)
Date: Fri, 28 Dec 2007 09:50:41 -0800
From: Tim Bray <Tim.Bray@Sun.COM>
Subject: Re: Suggestions for extension namespace URIs
In-reply-to: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
To: Joe Gregorio <joe@bitworking.org>
Cc: Atom-Syntax <atom-syntax@imc.org>
Message-id: <45840707-CCCD-4250-96AC-1285D1999635@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.915)
Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2



On Dec 19, 2007, at 2:13 PM, Joe Gregorio wrote:

> We (Google) are going to be producing I-Ds for
> some extension elements in Atom. Anybody got
> suggestions for picking a namespace URI?
> We could use PURLs, or register our own
> domain, but what are the options beyond that?

If you're going to use an http: URI, which I recommend, use one where  
you can put some helpful supporting info.  So grab reverse-atom- 
frobnostication.net or some such.  -Tim




From owner-atom-syntax@mail.imc.org Fri Dec 28 13:45:33 2007
Return-path: <owner-atom-syntax@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8KD7-0003yq-0I
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 13:45:33 -0500
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1J8KD6-0002ty-Id
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 13:45:32 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBSILBWZ054415
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Dec 2007 11:21:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBSILBif054414;
	Fri, 28 Dec 2007 11:21:11 -0700 (MST)
	(envelope-from owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from bay0-omc1-s21.bay0.hotmail.com (bay0-omc1-s21.bay0.hotmail.com [65.54.246.93])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBSILAdY054405
	for <atom-syntax@imc.org>; Fri, 28 Dec 2007 11:21:11 -0700 (MST)
	(envelope-from j4_james@hotmail.com)
Received: from hotmail.com ([65.55.152.24]) by bay0-omc1-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Fri, 28 Dec 2007 10:21:10 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 28 Dec 2007 10:21:10 -0800
Message-ID: <BAY141-DAV140603714BD825F5A0B79ABE550@phx.gbl>
Received: from 85.211.248.115 by BAY141-DAV14.phx.gbl with DAV;
	Fri, 28 Dec 2007 18:21:07 +0000
X-Originating-IP: [85.211.248.115]
X-Originating-Email: [j4_james@hotmail.com]
X-Sender: j4_james@hotmail.com
From: "James Holderness" <j4_james@hotmail.com>
To: "Joe Gregorio" <joe@bitworking.org>, "Atom-Syntax" <atom-syntax@imc.org>
References: <3f1451f50712191413k6eeb3d06sd772adcd2642b3b6@mail.gmail.com>
Subject: Re: Suggestions for extension namespace URIs
Date: Fri, 28 Dec 2007 18:21:06 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 28 Dec 2007 18:21:10.0424 (UTC) FILETIME=[6BDA6180:01C8497E]
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25


Joe Gregorio wrote:
> We (Google) are going to be producing I-Ds for
> some extension elements in Atom. Anybody got
> suggestions for picking a namespace URI?

I'm sorry this is slightly off topic, but would the extensions used in the 
Google Reader "shared items" feeds be one of the things you're planning to 
document? And if so, will the current namespace URI change? Or are those 
proprietary feeds that are only meant to be accessible to Google Reader?

I understand if you're not at liberty to disclose that kind of information.

Regards
James




From Scooter@fantasyisland.de Fri Dec 28 23:39:24 2007
Return-path: <Scooter@fantasyisland.de>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J8TTo-0003Ed-B2
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 23:39:24 -0500
Received: from host157-90-dynamic.9-87-r.retail.telecomitalia.it ([87.9.90.157] helo=host249-20-dynamic.60-82-r.retail.telecomitalia.it)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J8TTn-0001HG-JZ
	for atompub-archive@lists.ietf.org; Fri, 28 Dec 2007 23:39:24 -0500
Received: from sere-cd2lbjl2lc ([199.181.52.168]:10306 "EHLO sere-cd2lbjl2lc"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by host249-20-dynamic.60-82-r.retail.telecomitalia.it with ESMTP id S22TRTNFPVPMJNRC (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Sat, 29 Dec 2007 05:34:10 +0100
Message-ID: <B283829E.578C1D84@fantasyisland.de>
Date: Sat, 29 Dec 2007 05:33:53 +0100
From: "Scooter Cavallari" <Scooter@fantasyisland.de>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: talviaik
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 4.5 (++++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
What type of pants do you wear to house the largest dick in town? <a href="http://mayliane.com/">http://mayliane.com/</a><br>
</html>



From Marsland@tierklinik-zeissler.de Sun Dec 30 10:34:39 2007
Return-path: <Marsland@tierklinik-zeissler.de>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1J90BT-0003Xm-BR
	for atompub-archive@lists.ietf.org; Sun, 30 Dec 2007 10:34:39 -0500
Received: from bce99.neoplus.adsl.tpnet.pl ([83.27.220.99])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1J90BS-00027u-Q2
	for atompub-archive@lists.ietf.org; Sun, 30 Dec 2007 10:34:39 -0500
Received: from system ([159.110.88.124]:17905 "EHLO system"
	smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
	by bce99.neoplus.adsl.tpnet.pl with ESMTP id S22VHOABUOYSTSZC (ORCPT
	<rfc822;atompub-archive%lists.ietf.org@chiedprmail1.ietf.org>);
	Sun, 30 Dec 2007 16:44:04 +0100
Message-ID: <BF75BBED.7D6088C9@tierklinik-zeissler.de>
Date: Sun, 30 Dec 2007 16:43:50 +0100
From: "Kristeen Marsland" <Marsland@tierklinik-zeissler.de>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: atompub-archive@lists.ietf.org
Subject: kamikaze
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 071229-0, 2007-12-29), Outbound message
X-Antivirus-Status: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4

Big Dicks, Big Egos, No Risk!  VPXL Herbal! http://menainpot.com/