From owner-atom-syntax@mail.imc.org Thu Aug 02 10:27:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbdx-0003Vg-SM for atompub-archive@lists.ietf.org; Thu, 02 Aug 2007 10:27:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGbdw-0001C8-GH for atompub-archive@lists.ietf.org; Thu, 02 Aug 2007 10:27:13 -0400 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 l72E1AvC090016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 07:01: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 l72E1AZ8090015; Thu, 2 Aug 2007 07:01: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 out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l72E19sF090008 for ; Thu, 2 Aug 2007 07:01:09 -0700 (MST) (envelope-from jtauber@jtauber.com) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 85345BA28 for ; Thu, 2 Aug 2007 10:01:08 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 02 Aug 2007 10:01:08 -0400 X-Sasl-enc: UYqT+pcJBIExevoBVa0joWj8eeBTB4Toln4rJP0Jbe/o 1186063268 Received: from [192.168.1.65] (host86-145-54-127.range86-145.btcentralplus.com [86.145.54.127]) by mail.messagingengine.com (Postfix) with ESMTP id 2316B1EBC6 for ; Thu, 2 Aug 2007 10:01:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2FDF26D1-13C3-43E0-9202-A47A2BC26CF7@jtauber.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: James Tauber Subject: django-atompub Date: Thu, 2 Aug 2007 15:01:09 +0100 X-Mailer: Apple Mail (2.752.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Although the Django web framework[1] has had Atom support for a while, it is incomplete and, for the most part, covers only those fields that Atom and RSS have in common. So I offered to implement full support for RFC 4287 in Django. The result is available at django-atompub[2] on Google Code. The atom.py module is actually independent of Django and so can be used as a general Python library for Atom feed generation. Support for the Atom Publishing Protocol (which is the main project) is next. James [1] http://www.djangoproject.com/ [2] http://code.google.com/p/django-atompub/ -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Wed Aug 08 19:18:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIunI-0005sP-Rs for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 19:18:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIunH-0004st-Di for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 19:18:24 -0400 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 l78MwSYj001996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 15:58: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 l78MwSIB001995; Wed, 8 Aug 2007 15:58: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 ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l78MwPcH001987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 8 Aug 2007 15:58:27 -0700 (MST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IIuTv-0000tN-Om for atom-syntax@imc.org; Thu, 09 Aug 2007 00:58:23 +0200 Received: from franklin.dieselpoint.com ([75.5.156.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 00:58:23 +0200 Received: from shef31 by franklin.dieselpoint.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 00:58:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Chris Subject: Handling updated or deleted entries Date: Wed, 08 Aug 2007 17:58:18 -0500 Lines: 10 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: franklin.dieselpoint.com User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.4 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Is there a standard way to indicate that an entry has been updated or deleted? Note that I'm not asking how to update or delete an entry; that's what APP does. I'm just looking for a flag in the read-only feed that indicates that the author made a change to an entry that was previously published. (Apologies if this message shows up twice. Couldn't quite get the email/gmane connection to work correctly). From owner-atom-syntax@mail.imc.org Wed Aug 08 22:35:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIxrt-0001gZ-Qi for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 22:35:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIxrs-0007b5-CT for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 22:35:21 -0400 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 l792E4NS018138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 19:14: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 l792E4J4018137; Wed, 8 Aug 2007 19:14: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 el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l792E17x018126 for ; Wed, 8 Aug 2007 19:14:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by el-out-1112.google.com with SMTP id s27so89652ele for ; Wed, 08 Aug 2007 19:14:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hjulVXzWzKzwtXOf+urPlM3Kw+A3xtv6NPEGBJI3kML/HAvthBxvTMRDG+wq4c2QCVw2yKl1SToRQ2xm7TKBtbVll/gvqnvjuuNIvZQVMHBthgCG4sTv6J9JOGq7axc2BGJJ8U/sjpXDz7PILzgOs7QFey8nIcP1kiF+dpMpcEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OLnciZC3uzENesRvgtHiBV8ryL5kDFik9Y0Ym83rRT9rK9cW30imP2PdL3gK3d3g3tcyxd/08h4KWyXYeG7GQOTUyYXsUKTgWjOd/2EMR+9Af1lbWwjg7isMNVv0ayyaENIP7kP4w+RtLdmfyyxl+3zQCJHVSZMk49CsWvVMixw= Received: by 10.70.49.1 with SMTP id w1mr1762869wxw.1186625640906; Wed, 08 Aug 2007 19:14:00 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id l48sm1331968wrl.2007.08.08.19.13.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Aug 2007 19:13:59 -0700 (PDT) Message-ID: <46BA7864.2020108@gmail.com> Date: Wed, 08 Aug 2007 19:13:56 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Chris CC: atom-syntax@imc.org Subject: Re: Handling updated or deleted entries References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 There's no standard. I have toyed with this in the past and had come up with a x:deleted-entry stand in for a deleted entry. e.g., {id of deleted entry} ... ... ... The challenge is knowing how long to keep the x:deleted-entry things around in the feed. - James Chris wrote: > > Is there a standard way to indicate that an entry has been updated or > deleted? > > Note that I'm not asking how to update or delete an entry; that's what > APP does. I'm just looking for a flag in the read-only feed that > indicates that the author made a change to an entry that was previously > published. > > (Apologies if this message shows up twice. Couldn't quite get the > email/gmane connection to work correctly). > > From owner-atom-syntax@mail.imc.org Wed Aug 08 23:02:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIyII-0005fE-KZ for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 23:02:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIyIH-0007yR-8z for atompub-archive@lists.ietf.org; Wed, 08 Aug 2007 23:02:38 -0400 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 l792k769019860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 19:46: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 l792k7Lh019859; Wed, 8 Aug 2007 19:46: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 brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l792k5CP019852 for ; Wed, 8 Aug 2007 19:46:06 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l792k5sG001540 for ; Thu, 9 Aug 2007 02:46:05 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMH00901JOO7G00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Wed, 08 Aug 2007 20:46:04 -0600 (MDT) Received: from [192.168.1.56] (fatwire-204-92.uniserve.ca [216.113.204.93]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH00CCFJOQBO00@mail-amer.sun.com>; Wed, 08 Aug 2007 20:46:04 -0600 (MDT) Date: Wed, 08 Aug 2007 19:45:35 -0700 From: Tim Bray Subject: Re: Handling updated or deleted entries In-reply-to: <46BA7864.2020108@gmail.com> To: James M Snell Cc: Chris , atom-syntax@imc.org Message-id: <2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <46BA7864.2020108@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Aug 8, 2007, at 7:13 PM, James M Snell wrote: > > There's no standard. I have toyed with this in the past and had > come up > with a x:deleted-entry stand in for a deleted entry. I was chatting with Steven Lees of Microsoft about this during the interop. One of the thing that makes me nervous about SSE is the sse:deleted element which says "This element isn't here any more"... this is going to be mega-confusing to a non-SEE-savvy client. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 09 01:11:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ0J5-0006jJ-7o for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 01:11:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ0J4-0001DJ-PN for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 01:11:35 -0400 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 l794otFh027108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 21:50:55 -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 l794otHR027107; Wed, 8 Aug 2007 21:50:55 -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 nlpi029.prodigy.net (nlpi029.sbcis.sbc.com [207.115.36.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l794orMl027089 for ; Wed, 8 Aug 2007 21:50:54 -0700 (MST) (envelope-from jpanzeracm@johnpanzer.com) X-ORBL: [70.231.250.230] Received: from [192.168.1.3] (adsl-70-231-250-230.dsl.snfc21.sbcglobal.net [70.231.250.230]) by nlpi029.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id l794ofpw020614; Wed, 8 Aug 2007 23:50:41 -0500 Message-ID: <46BAAB91.1040708@johnpanzer.com> Date: Wed, 08 Aug 2007 22:52:17 -0700 From: John Panzer Reply-To: jpanzer@acm.org User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James M Snell CC: Chris , atom-syntax@imc.org Subject: Re: Handling updated or deleted entries References: <46BA7864.2020108@gmail.com> In-Reply-To: <46BA7864.2020108@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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 James M Snell wrote: > There's no standard. I have toyed with this in the past and had come up > with a x:deleted-entry stand in for a deleted entry. > > e.g., > > > > {id of deleted entry} > > ... > ... > ... > > > The challenge is knowing how long to keep the x:deleted-entry things > around in the feed. Perhaps it's sufficient in many cases for the feed to indicate to consumers how long it keeps deleted-entry items around. Then a consumer who checks back, finds that they may have missed a tombstone, has the option of doing a complete sync by paging back through the feed history. > > - James > > Chris wrote: > >>Is there a standard way to indicate that an entry has been updated or >>deleted? >> >>Note that I'm not asking how to update or delete an entry; that's what >>APP does. I'm just looking for a flag in the read-only feed that >>indicates that the author made a change to an entry that was previously >>published. >> >>(Apologies if this message shows up twice. Couldn't quite get the >>email/gmane connection to work correctly). >> >> > > > From owner-atom-syntax@mail.imc.org Thu Aug 09 01:19:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ0Qg-0003wS-8V for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 01:19:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ0Qf-0001JF-Qg for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 01:19:26 -0400 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 l794xsPY027605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2007 21:59: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 l794xs8K027604; Wed, 8 Aug 2007 21:59: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 py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l794xqqv027597 for ; Wed, 8 Aug 2007 21:59:53 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id d32so632298pye for ; Wed, 08 Aug 2007 21:59:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LTMcJVJsEf+68NlaoLVm9C2fBJek/LLVoclkzObj1JdYHMg/IuMtxCi6f/6RIGFj37TV+eiSG59ykM2dvzeqnNNm2Sp04wimpAY6ZOBB19q6Pl0puJyeD0Kbxrh7ZsVmkUh9FqWJsB770RGY0CV6+hQ1sUoqJj4mRUtXxhbpe48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UaOkiruyTNa1dGs2xqSzdJMYqG7qHc/Imq23wyuqJLDnV8QZJatMU3IV9aiLydVVomIBU4TSKPvzKtWxfLXEueFgn29ri4XEqYs/8MO4SAQSGOVCie4hXU8dRInD5RJJLBpNkrO7Nu8QFBtuBNtLmHBmRGHmuRP3YPnOMVN3pw8= Received: by 10.70.129.6 with SMTP id b6mr1985208wxd.1186635590974; Wed, 08 Aug 2007 21:59:50 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id m6sm166430wrm.2007.08.08.21.59.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Aug 2007 21:59:48 -0700 (PDT) Message-ID: <46BA9F42.5020207@gmail.com> Date: Wed, 08 Aug 2007 21:59:46 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: jpanzer@acm.org CC: Chris , atom-syntax@imc.org Subject: Re: Handling updated or deleted entries References: <46BA7864.2020108@gmail.com> <46BAAB91.1040708@johnpanzer.com> In-Reply-To: <46BAAB91.1040708@johnpanzer.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 John Panzer wrote: >>[snip] >> The challenge is knowing how long to keep the x:deleted-entry things >> around in the feed. > > Perhaps it's sufficient in many cases for the feed to indicate to > consumers how long it keeps deleted-entry items around. Then a consumer > who checks back, finds that they may have missed a tombstone, has the > option of doing a complete sync by paging back through the feed history. > One idea I had was that a feed would only contain deleted-entry elements for entries that fall within the same atom:updated date range as the atom:entry's in the feed. That is, if the deleted entry *would* have appeared in a particular feed page based on it's app:edited or atom:updated value, then there would be a deleted-entry element. The downside of this would be that deleted-entry elements would be spread out across multiple feed pages. I'm not sure if that's a really bad thing or not. - James From owner-atom-syntax@mail.imc.org Thu Aug 09 03:26:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2PD-0003B5-T4 for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:26:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2PC-00039b-DY for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:26:03 -0400 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 l797544E006814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 00: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 l79754DV006813; Thu, 9 Aug 2007 00: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 smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79750x3006786 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Aug 2007 00:05:01 -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.0.700.0; Thu, 9 Aug 2007 00:04:59 -0700 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; Thu, 9 Aug 2007 00:04:59 -0700 From: Steven Lees To: James M Snell , "jpanzer@acm.org" CC: Chris , "atom-syntax@imc.org" Date: Thu, 9 Aug 2007 00:04:59 -0700 Subject: RE: Handling updated or deleted entries Thread-Topic: Handling updated or deleted entries Thread-Index: AcfaRO4+pyy3gpQ9SdK60vRcl2ek9gADa5Bt Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763020A3994@NA-EXMSG-C103.redmond.corp.microsoft.com> References: <46BA7864.2020108@gmail.com> <46BAAB91.1040708@johnpanzer.com>,<46BA9F42.5020207@gmail.com> In-Reply-To: <46BA9F42.5020207@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 l79751x2006806 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d James Snell wrote: >John Panzer wrote: >>>[snip] >>> The challenge is knowing how long to keep the x:deleted-entry things >>> around in the feed. >> >> Perhaps it's sufficient in many cases for the feed to indicate to >> consumers how long it keeps deleted-entry items around. Then a consumer >> who checks back, finds that they may have missed a tombstone, has the >> option of doing a complete sync by paging back through the feed history. >> > >One idea I had was that a feed would only contain deleted-entry elements >for entries that fall within the same atom:updated date range as the >atom:entry's in the feed. That is, if the deleted entry *would* have >appeared in a particular feed page based on it's app:edited or >atom:updated value, then there would be a deleted-entry element. The >downside of this would be that deleted-entry elements would be spread >out across multiple feed pages. I'm not sure if that's a really bad >thing or not. That actually seems like a good thing, because it means that the deleted items will be in the "right" place in the feed. Anyone who wants the complete update will need to read all of those pages eventually. For SSE (spec is on http://msdn.microsoft.com/xml/rss/sse), we've been thinking that a sync client would use ETag headers on a GET to the feed as a way to ask the server for all of the changes since the last sync, but I'm not sure how well that would mix with paging. Regarding John's comment about about missing the tombstones--we have a mechanism for this in SSE. You can have an optional feed-level sx:sharing element with an "expires" attribute that gives the client guidance about how often to sync. Steven From owner-atom-syntax@mail.imc.org Thu Aug 09 03:31:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2Ur-0008G8-Cl for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:31:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2Uq-0003FI-0d for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:31:53 -0400 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 l797FkrL008425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 00:15: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 l797Fkvn008422; Thu, 9 Aug 2007 00:15: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 (mailb.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l797Fg2Z008410 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Aug 2007 00:15:43 -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.0.700.0; Thu, 9 Aug 2007 00:15:41 -0700 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; Thu, 9 Aug 2007 00:15:41 -0700 From: Steven Lees To: Tim Bray , James M Snell CC: Chris , "atom-syntax@imc.org" Date: Thu, 9 Aug 2007 00:15:41 -0700 Subject: RE: Handling updated or deleted entries Thread-Topic: Handling updated or deleted entries Thread-Index: AcfaMcxJ9GICTYX0TkWJCs9r+pRRxAAIdZlM Message-ID: <9F59E90E6E525B40BB7B59BD72271CF763020A3995@NA-EXMSG-C103.redmond.corp.microsoft.com> References: <46BA7864.2020108@gmail.com>,<2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.com> In-Reply-To: <2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.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 l797Fh2Y008412 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Tim Bray wrote: >I was chatting with Steven Lees of Microsoft about this during the >interop. One of the thing that makes me nervous about SSE is the >sse:deleted element which says "This element isn't here any more"... >this is going to be mega-confusing to a non-SEE-savvy client. That concern makes sense to me, given the way that we're used to using feeds and feed readers today. It would be strange if a blog post was gone when viewed from the web page of the blog, but the post was still present in the feed. I think the deleted entry issue will come up more often as people start to use Atom and AtomPub for exchanging and syncing data. There may never be a web page at all in that case, and the feed becomes a way (or the only way?) for the server to hand state changes out to clients. In that case, you must have a way to represent deleted items, otherwise the clients will never know that they're gone. This could be useful even in the typical feed reader case today. It doesn't happen very often, but if someone actually deleted a post, I'd be happy to have my reader keep the cached copy around, but still give me some indication that the post was deleted by the publisher. As we discussed on IRC during the interop, there are some ways to make the two schemes coexist. You could have different URIs depending on whether the client understood deleted items; or you could have the client provide some HTTP header indicating whether or not it wanted deleted items to appear in the feed. Steven From owner-atom-syntax@mail.imc.org Thu Aug 09 03:43:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ2fu-0007YL-KA for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:43:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ2ft-0003W1-8Z for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 03:43:18 -0400 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 l797PfZJ009559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 00:25:41 -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 l797Pf4q009558; Thu, 9 Aug 2007 00:25:41 -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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l797PeKr009552 for ; Thu, 9 Aug 2007 00:25:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0506.google.com with SMTP id h29so297142wxd for ; Thu, 09 Aug 2007 00:25:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=o6dueBHfT926Kvb17vBaWJjpaHkIfFvyP1gc5vgprqFroQveTPgLrVa5bo7tkt8sZ0rAkqa+y6O85PQf7eS7HrDOu/YK+9uPhFRxxCYBv4XGQSm91yGa6tNcYJrDPE9qLBcfbvNCY/ORJQFFdnk6HOKpDtPAUO8Ry/UioIYkLDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=flhdzX2owZTRC8kw9c5IJ5miEJL6nVKZYr3JLLE3XE2Ye/u35RjKmzEwBErb0b7UoS77FpCi1o33oRsokM+9f8B6jx4pMGBXv7pbwZLvEMr3HhTgNaJn0CelzAbunjH7C5h49ZxafLYxQIfeIWDD8P8RITu/Jb9UOG0J426fNmI= Received: by 10.70.65.8 with SMTP id n8mr2199594wxa.1186644339472; Thu, 09 Aug 2007 00:25:39 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id 7sm1542116wrh.2007.08.09.00.25.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Aug 2007 00:25:37 -0700 (PDT) Message-ID: <46BAC16E.3010406@gmail.com> Date: Thu, 09 Aug 2007 00:25:34 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Steven Lees CC: Tim Bray , Chris , "atom-syntax@imc.org" Subject: Re: Handling updated or deleted entries References: <46BA7864.2020108@gmail.com>,<2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.com> <9F59E90E6E525B40BB7B59BD72271CF763020A3995@NA-EXMSG-C103.redmond.corp.microsoft.com> In-Reply-To: <9F59E90E6E525B40BB7B59BD72271CF763020A3995@NA-EXMSG-C103.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Another approach that we use in the Lotus Connections Activities component is to have a Trash collection. When an item is deleted from an Activity (Collection) it is moved to the Trash. It's url changes, it is removed completely from the original feed, and it shows up in the Trash feed. The item can be undeleted and moved back to the original or it can be purged from the trash. There are no tombstones at all. A user can determine whether or not a previously existing entry has been deleted either by doing a HEAD on it (and getting a redirect to the trash url) or by checking for it in the trash collection. - James Steven Lees wrote: > Tim Bray wrote: > >> I was chatting with Steven Lees of Microsoft about this during the >> interop. One of the thing that makes me nervous about SSE is the >> sse:deleted element which says "This element isn't here any more"... >> this is going to be mega-confusing to a non-SEE-savvy client. > > That concern makes sense to me, given the way that we're used to using feeds and feed readers today. It would be strange if a blog post was gone when viewed from the web page of the blog, but the post was still present in the feed. > > I think the deleted entry issue will come up more often as people start to use Atom and AtomPub for exchanging and syncing data. There may never be a web page at all in that case, and the feed becomes a way (or the only way?) for the server to hand state changes out to clients. In that case, you must have a way to represent deleted items, otherwise the clients will never know that they're gone. This could be useful even in the typical feed reader case today. It doesn't happen very often, but if someone actually deleted a post, I'd be happy to have my reader keep the cached copy around, but still give me some indication that the post was deleted by the publisher. > > As we discussed on IRC during the interop, there are some ways to make the two schemes coexist. You could have different URIs depending on whether the client understood deleted items; or you could have the client provide some HTTP header indicating whether or not it wanted deleted items to appear in the feed. > > Steven > From owner-atom-syntax@mail.imc.org Thu Aug 09 09:27:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ83B-0006Iq-RK for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 09:27:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ83A-0001jG-BE for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 09:27:41 -0400 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 l79D166F042206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 06:01: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 l79D16ft042205; Thu, 9 Aug 2007 06:01: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 fepv01.charter.net (fepv01.charter.net [209.225.8.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79D15ar042197 for ; Thu, 9 Aug 2007 06:01:06 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from aa10.charter.net ([10.20.200.162]) by fepv01.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070809130105.VTVH13416.fepv01.charter.net@aa10.charter.net> for ; Thu, 9 Aug 2007 09:01:05 -0400 Received: from G-Force.local ([71.87.92.92]) by aa10.charter.net with ESMTP id <20070809130105.VSNW1265.aa10.charter.net@G-Force.local> for ; Thu, 9 Aug 2007 09:01:05 -0400 Message-ID: <46BB100C.6000303@geckotribe.com> Date: Thu, 09 Aug 2007 08:01:00 -0500 From: Antone Roundy Reply-To: antone@geckotribe.com User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070618) MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: Handling updated or deleted entries References: <46BA7864.2020108@gmail.com>,<2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.com> <9F59E90E6E525B40BB7B59BD72271CF763020A3995@NA-EXMSG-C103.redmond.corp.microsoft.com> <46BAC16E.3010406@gmail.com> In-Reply-To: <46BAC16E.3010406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 James M Snell wrote: > Another approach that we use in the Lotus Connections Activities > component is to have a Trash collection. When an item is deleted from > an Activity (Collection) it is moved to the Trash. I was imagining something like this: ... That would point to a document listing deleted entries. It could of course be a set of linked documents with tombstones for the most recently deleted entries appearing first. ext:updated is the timestamp marking when the most recent deletion occurred. To avoid creating a new document type, perhaps the document could be an Atom feed document containing only tombstones and not live entries. Antone Roundy From owner-atom-syntax@mail.imc.org Thu Aug 09 10:00:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8Yg-0008E5-Cp for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 10:00:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ8Yf-0002P5-1E for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 10:00:14 -0400 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 l79DcLfr046501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 06:38: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 l79DcL2T046500; Thu, 9 Aug 2007 06:38: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 bay0-omc2-s35.bay0.hotmail.com (bay0-omc2-s35.bay0.hotmail.com [65.54.246.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79DcKlK046492 for ; Thu, 9 Aug 2007 06:38:20 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.15]) by bay0-omc2-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 9 Aug 2007 06:38:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 9 Aug 2007 06:38:15 -0700 Message-ID: Received: from 85.211.239.181 by BAY141-DAV5.phx.gbl with DAV; Thu, 09 Aug 2007 13:38:11 +0000 X-Originating-IP: [85.211.239.181] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <46BA7864.2020108@gmail.com> Subject: Re: Handling updated or deleted entries Date: Thu, 9 Aug 2007 14:40:11 +0100 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.3138 X-OriginalArrivalTime: 09 Aug 2007 13:38:15.0614 (UTC) FILETIME=[89D52DE0:01C7DA8A] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c James M Snell wrote: > There's no standard. I have toyed with this in the past and had come up > with a x:deleted-entry stand in for a deleted entry. If you could get some server implementers interested in supporting this I'd love to add it to Snarfer (in fact I've been wanting to do this for a long time). It would be really useful for comment feeds and public forums that get a lot of spam. I tend to set my refresh interval very low on forums, so I'm almost guaranteed to receive any spam that is posted, no matter how diligent the moderators are about deleting it. Tombstones could fix that. Regards James From owner-atom-syntax@mail.imc.org Thu Aug 09 11:19:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9n7-0005jE-Ts for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 11:19:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ9n6-00044x-JL for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 11:19:13 -0400 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 l79EpGpC055749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 07: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 l79EpG8F055748; Thu, 9 Aug 2007 07: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 mwest.oreilly.com (mwest.oreilly.com [209.204.146.24]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79EpGQ8055742 for ; Thu, 9 Aug 2007 07:51:16 -0700 (MST) (envelope-from keith@oreilly.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mwest.oreilly.com (Postfix) with ESMTP id E475F1B8460B; Thu, 9 Aug 2007 07:46:26 -0700 (PDT) X-Quarantine-ID: 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 hk1bsK7Vkg1T; Thu, 9 Aug 2007 07:46:26 -0700 (PDT) Received: from MacKeith.local (unknown [172.24.41.14]) by mwest.oreilly.com (Postfix) with ESMTP id 376881B8460A; Thu, 9 Aug 2007 07:46:25 -0700 (PDT) Message-ID: <46BB29E0.7040504@oreilly.com> Date: Thu, 09 Aug 2007 07:51:12 -0700 From: Keith Fahlgren User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: James M Snell CC: "atom-syntax@imc.org" Subject: Re: Handling updated or deleted entries References: <46BA7864.2020108@gmail.com>,<2B541DD5-541B-43EC-AD6E-9369BD96D04F@sun.com> <9F59E90E6E525B40BB7B59BD72271CF763020A3995@NA-EXMSG-C103.redmond.corp.microsoft.com> <46BAC16E.3010406@gmail.com> In-Reply-To: <46BAC16E.3010406@gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On 8/9/07 12:25 AM, James M Snell wrote: > Another approach that we use in the Lotus Connections Activities > component is to have a Trash collection. When an item is deleted from > an Activity (Collection) it is moved to the Trash. It's url changes, it > is removed completely from the original feed, and it shows up in the > Trash feed. The Trash collection/feed is exactly the solution we've used (though we don't have an un-delete mechanism).  HTH, Keith From owner-atom-syntax@mail.imc.org Thu Aug 09 15:20:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDYH-0000qe-It for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 15:20:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJDYG-0002l1-1D for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 15:20:09 -0400 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 l79ItXRn086455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 11:55:33 -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 l79ItXEc086454; Thu, 9 Aug 2007 11:55:33 -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 ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79ItReV086433 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2007 11:55:31 -0700 (MST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IJDAH-0003V0-Rk for atom-syntax@imc.org; Thu, 09 Aug 2007 20:55:21 +0200 Received: from franklin.dieselpoint.com ([75.5.156.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 20:55:21 +0200 Received: from shef31 by franklin.dieselpoint.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 20:55:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Chris Subject: Re: Handling updated or deleted entries Date: Thu, 09 Aug 2007 13:54:49 -0500 Lines: 53 Message-ID: <46BB62F9.5060204@yahoo.com> References: <46BA7864.2020108@gmail.com> <46BAAB91.1040708@johnpanzer.com> <46BA9F42.5020207@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org Cc: public-jpanzer-HInyCGIudOg@ciao.gmane.org, Chris , public-atom-syntax-O6w3ZxSwtmQ@ciao.gmane.org X-Gmane-NNTP-Posting-Host: franklin.dieselpoint.com User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <46BA9F42.5020207@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.4 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 James M Snell wrote: > > John Panzer wrote: >>> [snip] >>> The challenge is knowing how long to keep the x:deleted-entry things >>> around in the feed. >> Perhaps it's sufficient in many cases for the feed to indicate to >> consumers how long it keeps deleted-entry items around. Then a consumer >> who checks back, finds that they may have missed a tombstone, has the >> option of doing a complete sync by paging back through the feed history. >> > > One idea I had was that a feed would only contain deleted-entry elements > for entries that fall within the same atom:updated date range as the > atom:entry's in the feed. That is, if the deleted entry *would* have > appeared in a particular feed page based on it's app:edited or > atom:updated value, then there would be a deleted-entry element. The > downside of this would be that deleted-entry elements would be spread > out across multiple feed pages. I'm not sure if that's a really bad > thing or not. > > - James This problem isn't confined to just deletes; we also need a way to signal updates. This problem is also related to Brian Smith's post "How to implement the "Give me all the new & updated entries" use case" on 7/13. It's a more general issue. The general problem is how to keeping two databases in sync via a feed. The normal way to do it is with something akin to a transaction log. A log has a timestamp, and then it has record of the change that happened, which is always an insert, an update, or a delete. An Atom feed can look like a transaction log if we just add a flag to indicate an update or a delete. If the flag is not present, it's an insert. The timestamp is the value. The flag could look like this: delete or possibly or I like the "action" tag because it's more obvious. If we combine this with a mechanism to get every entry since a certain timestamp (per Brian Smith's request), then we have a reliable way to support simple transactions, and Atom can be a general mechanism for data distribution. I suggest adding a "since" parameter to the feed's URL: http://mydomain/myfeed?since=2007-08-09T14:00:00 From owner-atom-syntax@mail.imc.org Thu Aug 09 15:20:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDYz-0001h2-Dy for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 15:20:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJDYx-0002lu-Rg for atompub-archive@lists.ietf.org; Thu, 09 Aug 2007 15:20:53 -0400 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 l79J1h5L087047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2007 12:01: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 l79J1h1J087046; Thu, 9 Aug 2007 12:01: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 ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l79J1f5h087032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2007 12:01:42 -0700 (MST) (envelope-from ga-atom-syntax@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IJDGJ-00047n-Vg for atom-syntax@imc.org; Thu, 09 Aug 2007 21:01:36 +0200 Received: from franklin.dieselpoint.com ([75.5.156.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 21:01:35 +0200 Received: from shef31 by franklin.dieselpoint.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Aug 2007 21:01:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Chris Subject: Re: Handling updated or deleted entries Date: Thu, 09 Aug 2007 14:01:20 -0500 Lines: 54 Message-ID: References: <46BA7864.2020108@gmail.com> <46BAAB91.1040708@johnpanzer.com> <46BA9F42.5020207@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: franklin.dieselpoint.com User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <46BA9F42.5020207@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.4 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 James M Snell wrote: > > John Panzer wrote: >>> [snip] >>> The challenge is knowing how long to keep the x:deleted-entry things >>> around in the feed. >> Perhaps it's sufficient in many cases for the feed to indicate to >> consumers how long it keeps deleted-entry items around. Then a consumer >> who checks back, finds that they may have missed a tombstone, has the >> option of doing a complete sync by paging back through the feed history. >> > > One idea I had was that a feed would only contain deleted-entry elements > for entries that fall within the same atom:updated date range as the > atom:entry's in the feed. That is, if the deleted entry *would* have > appeared in a particular feed page based on it's app:edited or > atom:updated value, then there would be a deleted-entry element. The > downside of this would be that deleted-entry elements would be spread > out across multiple feed pages. I'm not sure if that's a really bad > thing or not. > > - James > > This problem isn't confined to just deletes; we also need a way to signal updates. This problem is also related to Brian Smith's post "How to implement the "Give me all the new & updated entries" use case" on 7/13. It's a more general issue. The general problem is how to keeping two databases in sync via a feed. The normal way to do it is with something akin to a transaction log. A log has a timestamp, and then it has record of the change that happened, which is always an insert, an update, or a delete. An Atom feed can look like a transaction log if we just add a flag to indicate an update or a delete. If the flag is not present, it's an insert. The timestamp is the value. The flag could look like this: delete or possibly or I like the "action" tag because it's more obvious. If we combine this with a mechanism to get every entry since a certain timestamp (per Brian Smith's request), then we have a reliable way to support simple transactions, and Atom can be a general mechanism for data distribution. I suggest adding a "since" parameter to the feed's URL: http://mydomain/myfeed?since=2007-08-09T14:00:00 From owner-atom-syntax@mail.imc.org Sun Aug 12 09:15:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKDIB-0003Yy-KQ for atompub-archive@lists.ietf.org; Sun, 12 Aug 2007 09:15:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKDIA-00030A-4T for atompub-archive@lists.ietf.org; Sun, 12 Aug 2007 09:15:39 -0400 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 l7CCrnkq078309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 05:53: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 l7CCrnqA078308; Sun, 12 Aug 2007 05:53: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 csmtp2.b-one.net (csmtp2.b-one.net [195.47.247.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7CCrmJZ078301 for ; Sun, 12 Aug 2007 05:53:49 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (161.84-48-114.nextgentel.com [84.48.114.161]) by csmtp2.b-one.net (Postfix) with ESMTP id 774C11F939BDE for ; Sun, 12 Aug 2007 14:53:46 +0200 (CEST) To: "Atom WG" Subject: Copyright information From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: Date: Sun, 12 Aug 2007 14:53:46 +0200 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.23 (Win32) X-Antivirus: avast! (VPS 000764-6, 11.08.2007), Outbound message X-Antivirus-Status: Clean Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7CCrnkq078309 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I'm wondering how to assess different copyright information on the textua= l =20 content and an associated picture in an entry. The textual content is =20 written by entity A and the picture is bought from entity B. Both entitie= s =20 should have copyright information in the entry. How would I best express = =20 this with RFC 4287? I could of course just cram it all into the atom:rights element, but the = =20 optimal thing would be to separate the copyright information on the text = =20 and the picture. Another option is to use XHTML to mark up the different = =20 bits of information with its copyright statements, but that feels like a = =20 dirty solution to a seemingly trivial problem. Got any ideas? --=20 Asbj=F8rn Ulsberg -=3D|=3D- http://virtuelvis.com/quark/ =ABHe's a loathsome offensive brute, yet I can't look away=BB From nobody@host.1nmc.com Tue Aug 14 03:35:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKqwT-0008M3-Vu for atompub-archive@megatron.ietf.org; Tue, 14 Aug 2007 03:35:54 -0400 Received: from mail.1nmc.com ([66.147.239.205] helo=host.1nmc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKqwT-0000bH-Gb for atompub-archive@megatron.ietf.org; Tue, 14 Aug 2007 03:35:53 -0400 Received: from nobody by host.1nmc.com with local (Exim 4.66) (envelope-from ) id 1IKqwR-00050v-AW for atompub-archive@megatron.ietf.org; Tue, 14 Aug 2007 01:35:51 -0600 To: atompub-archive@megatron.ietf.org Subject: You have received a card from a family member! From: webmaster@postcards.org Content-Type: text/html Message-Id: Date: Tue, 14 Aug 2007 01:35:51 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.1nmc.com X-AntiAbuse: Original Domain - megatron.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - host.1nmc.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e


You have received a card from a family member!

If you can‘t click on the web address above, you can also
visit 1001 Postcards
http://www.postcards.org/postcards/ and enter your pickup code, which is: a91-valets-cloud-mad
Oh -- and if you‘d like to reply with a postcard, you can do so by visiting this web address:
http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!)
Regards, 1001 Postcards
http://www.postcards.org/postcards/
   

You can pick up your postcard at the following web address:

http://www2.postcards.org/?a91-valets-cloud-31337

 

1001 Postcards and postcards.org are service marks of 1001 Media Group.
Copyright © 1997-2006 1001 Media Group.
From owner-atom-syntax@mail.imc.org Tue Aug 21 12:45:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWqu-0005LM-R5 for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 12:45:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INWqt-0000Mf-BB for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 12:45:12 -0400 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 l7LGK2q6078978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 09:20: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 l7LGK256078977; Tue, 21 Aug 2007 09:20: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 rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LGJxui078955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 09:20:00 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l7LGJvfA031269; Tue, 21 Aug 2007 10:19:58 -0600 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l7LFX3pl008077; Tue, 21 Aug 2007 10:19:57 -0600 Received: from dhcp-1op3-1op4-west-144-25-166-194.us.oracle.com by acsmt350.oracle.com with ESMTP id 3145124901187713125; Tue, 21 Aug 2007 09:18:45 -0700 Message-ID: <46CB1063.7000109@oracle.com> Date: Tue, 21 Aug 2007 09:18:43 -0700 From: Nikunj Mehta Organization: Oracle User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: atom-protocol Protocol , atom-syntax@imc.org Subject: Possibly contrary statements in Atompub and feed history I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7LGK2q6078978 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 =A710.1 of AtomPub I-D expects collection partial lists aka pages to be=20 /lossless/. In addition, partial list feeds MAY contain link elements with "rel" attribute values of "next", "previous", "first" and "last" that can be used to navigate through the complete set of entries in the Collection. =A73 of Feed history I-D expects paged feeds to be lossy Paged feeds are lossy; that is, it is not possible to guarantee that clients will be able to reconstruct the contents of the logical feed at a particular time. Entries may be added or changed as the pages of the feed are accessed, without the client becoming aware of them. Therefore, clients SHOULD NOT present paged feeds as coherent or complete, or make assumptions to that effect. Further, in the same section, the same link "rel" attribute values are=20 used in paged feeds for feed history The feed documents in a paged feed are tied together with the followi= ng link relations: o "first" - A URI that refers to the furthest preceding document = in a series of documents. o "last" - A URI that refers to the furthest following document i= n a series of documents. o "previous" - A URI that refers to the immediately preceding document in a series of documents. o "next" - A URI that refers to the immediately following documen= t in a series of documents. First obvious question - Is the feed history I-D being contradictory to=20 the AtomPub I-D? Second question - which I-D is the specification for the above link=20 "rel" attribute values? Thanks, Nikunj From owner-atom-syntax@mail.imc.org Tue Aug 21 14:43:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYhZ-00023F-Ki for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 14:43:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INYhZ-0003j5-6X for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 14:43:41 -0400 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 l7LINBfM094555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 11:23: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 l7LINBCx094554; Tue, 21 Aug 2007 11:23: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 wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LIN9v4094538 for ; Tue, 21 Aug 2007 11:23:10 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so1238729waf for ; Tue, 21 Aug 2007 11:23:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nP/jkcLMDlXJB50YXDKhWatkV85miOeIteOdBYKYEJi5VTS8c0YmBt45Np+ZUerI24tlaS/GbrXjAgmnXjp4WySn3BXC1pIKXN2HmIYDE69fA8tYOZf0U36swF/nhS/JA34J+AolzI4dufbRa0YOt9esdWu2umVKuE0t/hPGdqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SNXkDl1uYtiSfl/8Tw+ouR8nOxOwJ373ETioPtHwz8P4p3mrTVEgkNMXIxPz34KEzNov95PJFFmigDAaDaKrKCANVab50QBGdHGh02GlQPhbQai7i9EVTOLFcJueni6pnrXvKHVXFTJiRjIr/DA2iwJ171Upo+lPySBMUyK2Kvo= Received: by 10.114.178.1 with SMTP id a1mr1039918waf.1187720589134; Tue, 21 Aug 2007 11:23:09 -0700 (PDT) Received: by 10.114.184.18 with HTTP; Tue, 21 Aug 2007 11:23:09 -0700 (PDT) Message-ID: Date: Tue, 21 Aug 2007 20:23:09 +0200 From: "Thomas Broyer" To: atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds In-Reply-To: <46CB1063.7000109@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline References: <46CB1063.7000109@oracle.com> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l7LINAv4094547 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7LINBfM094555 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 2007/8/21, Nikunj Mehta: > > =C2=A710.1 of AtomPub I-D expects collection partial lists aka pages to= be > /lossless/. Seems like we don't have the same definition of lossless then... Partial lists in AtomPub are subject to the following constraint: The first such partial list returned MUST contain the most recently edited member Resources and MUST have an atom:link with a "next" relation whose "href" value is the URI of the next partial list of th= e Collection. This next partial list will contain the next most recentl= y edited set of Member Resources (and an atom:link to the following partial list if it exists). So by definition, they are lossy, by the following definition of lossy: > =C2=A73 of Feed history I-D expects paged feeds to be lossy > > Paged feeds are lossy; that is, it is not possible to guarantee that > clients will be able to reconstruct the contents of the logical feed > at a particular time. Entries may be added or changed as the pages > of the feed are accessed, without the client becoming aware of them. Conclusion: I don't see any conflict their. --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Aug 21 17:15:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INb4l-0000Ju-Ku for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 17:15:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INb4k-0007sX-59 for atompub-archive@lists.ietf.org; Tue, 21 Aug 2007 17:15:47 -0400 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 l7LKob16010403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 13:50: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 l7LKobJa010402; Tue, 21 Aug 2007 13:50: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 agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LKoaT4010390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 13:50:36 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l7LKoYcT025002; Tue, 21 Aug 2007 15:50:34 -0500 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l7L4Xw9I007938; Tue, 21 Aug 2007 14:50:34 -0600 Received: from dhcp-1op3-1op4-west-144-25-166-194.us.oracle.com by acsmt350.oracle.com with ESMTP id 3146952251187729402; Tue, 21 Aug 2007 13:50:02 -0700 Message-ID: <46CB4FFB.8010200@oracle.com> Date: Tue, 21 Aug 2007 13:50:03 -0700 From: Nikunj Mehta Organization: Oracle User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7LKob16010403 X-Spam-Score: 1.6 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Thomas Broyer wrote: > 2007/8/21, Nikunj Mehta: > =20 >> =C2=A710.1 of AtomPub I-D expects collection partial lists aka pages t= o be >> /lossless/. >> =20 > Seems like we don't have the same definition of lossless then... > =20 Allow me to clarify. A lossless paging is the following (this is my=20 interpretation of =C2=A710.1 of AtomPub I-D): The partial list of entries obtained by GETting the collection's URI combined with partial lists obtained by following the rel=3D"next" links in each of those partial lists MUST provide the snapshot of all of a collection's entries *as of the time *when the server responded to the GET request on the collection URI. Per =C2=A73 of the feed history I-D, it is not possible to guarantee that clients will be able to reconst= ruct=20 the contents of the logical feed /at a particular time/ (emphasis mine) On the contrary lossy paging occurs when there is no such guarantee,=20 i.e., navigating between partial lists might produce the same entry=20 twice or more, might skip an entry completely because it "disappeared in=20 the boundary between pages". > Partial lists in AtomPub are subject to the following constraint: > The first such partial list returned MUST contain the most recently > edited member Resources and MUST have an atom:link with a "next" > relation whose "href" value is the URI of the next partial list of = the > Collection. This next partial list will contain the next most recen= tly > edited set of Member Resources (and an atom:link to the following > partial list if it exists). > =20 If I am interpreting this right (without any formal model of course),=20 then "next" implies the immediately "next most recently edited". To me,=20 that means lossless. > So by definition, they are lossy, by the following definition of lossy: > > =20 >> =C2=A73 of Feed history I-D expects paged feeds to be lossy >> >> Paged feeds are lossy; that is, it is not possible to guarantee tha= t >> clients will be able to reconstruct the contents of the logical fee= d >> at a particular time. Entries may be added or changed as the pages >> of the feed are accessed, without the client becoming aware of them. >> =20 I respectfully disagree with this interpretation per my argument above.=20 If the definition of partial lists and paging results in collection=20 feeds being lossy, then how would we guarantee any synchronization of=20 paged collections? > Conclusion: I don't see any conflict their. > =20 Sorry I have come a little late to the feed history I-D party, but it=20 looks like this spec is not strongly consistent with AtomPub (and the=20 fact that the two don't even refer to each other's existence stinks, IMHO= ). Furthermore, can someone point out which RFC or I-D defines link=20 rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D"previ= ous"? From owner-atom-syntax@mail.imc.org Wed Aug 22 03:02:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INkEo-0002ZG-Jk for atompub-archive@lists.ietf.org; Wed, 22 Aug 2007 03:02:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INkEn-0003if-QH for atompub-archive@lists.ietf.org; Wed, 22 Aug 2007 03:02:46 -0400 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 l7M6i9di051228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 23:44: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 l7M6i943051227; Tue, 21 Aug 2007 23:44: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 wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7M6i7gs051220 for ; Tue, 21 Aug 2007 23:44:08 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by wa-out-1112.google.com with SMTP id j5so97218wah for ; Tue, 21 Aug 2007 23:44:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M8Ef6ku2qbvxzI2UgQZe5Pyl1sjlKu3ipU/AWDHF3kSrLvA654s4d6P2o5/J11QZ/rHdFz2kaZfXk4V8DxEu/vCc7VNirEBHXf67ul92lRqZqKMhslniGQmEjtLCL3sJ8QKJyMjKKe56xoano7moi+QEQyfKNFlpDtCS5EFjvwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BXiLKQ6DASJ9QL1uWF71j/Gi8EHpuROUQldItucNbzxLvjkP2sm/+Lb2SmcXsERVVroeDbSmAUktj/nOQ9WEIO8jlNEqXVluNjKZEue5Ehgg8LGEkMjaH3DiUoQHP5iIZpf1C9oR1YwjrnKkJ8p5j3uGTRwX1Uy8QlwXsLLLJ7w= Received: by 10.114.106.1 with SMTP id e1mr332721wac.1187765045483; Tue, 21 Aug 2007 23:44:05 -0700 (PDT) Received: by 10.114.184.18 with HTTP; Tue, 21 Aug 2007 23:44:05 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 08:44:05 +0200 From: "Thomas Broyer" To: atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds In-Reply-To: <46CB4FFB.8010200@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id l7M6i9gs051222 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7M6i9di051228 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 2007/8/21, Nikunj Mehta: > > Thomas Broyer wrote: > > 2007/8/21, Nikunj Mehta: > > > >> =C2=A710.1 of AtomPub I-D expects collection partial lists aka pages= to be > >> /lossless/. > >> > > Seems like we don't have the same definition of lossless then... > > > Allow me to clarify. A lossless paging is the following (this is my > interpretation of =C2=A710.1 of AtomPub I-D): > > The partial list of entries obtained by GETting the collection's UR= I > combined with partial lists obtained by following the rel=3D"next" > links in each of those partial lists MUST provide the snapshot of > all of a collection's entries *as of the time *when the server > responded to the GET request on the collection URI. OK, so we don't have the same interpretation. It means this means clarification in the spec (is it too late?). > On the contrary lossy paging occurs when there is no such guarantee, > i.e., navigating between partial lists might produce the same entry > twice or more, might skip an entry completely because it "disappeared i= n > the boundary between pages". Yup. > > Partial lists in AtomPub are subject to the following constraint: > > The first such partial list returned MUST contain the most recent= ly > > edited member Resources and MUST have an atom:link with a "next" > > relation whose "href" value is the URI of the next partial list o= f the > > Collection. This next partial list will contain the next most rec= ently > > edited set of Member Resources (and an atom:link to the following > > partial list if it exists). > > > If I am interpreting this right (without any formal model of course), > then "next" implies the immediately "next most recently edited". To me, > that means lossless. As partial lists are not defined to be "stable", they might be changing over time. At the time you retrieve the first partial list, the second partial list contains the "next most recently edited". But between the retrieval of the first partial list and the time you retrieve the second one, this one might have changed. > I respectfully disagree with this interpretation per my argument above. > If the definition of partial lists and paging results in collection > feeds being lossy, then how would we guarantee any synchronization of > paged collections? You cannot guarantee synchronization without an atomic operation or paging a snapshot. Requiring servers to create "paged snapshots" (i.e. as per your interpretation of atompub-protocol-17) would have too much implications: servers would need to remember each and every "edit" (app:edited) of all the entries. The "partial list" thing is the Simplest Thing That Could Possibly Work. If you want a reliable synchronization, then either: 1. use another mechanism (RFC3229 w/ Feeds?) 2. re-start synchronization from the Collection URI partial list until you no longer need to follow the rel=3D"next" link > Sorry I have come a little late to the feed history I-D party, but it > looks like this spec is not strongly consistent with AtomPub (and the > fact that the two don't even refer to each other's existence stinks, IM= HO). > > Furthermore, can someone point out which RFC or I-D defines link > rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D"pre= vious"? http://www.iana.org/assignments/link-relations.html says its Feed History. --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Aug 22 08:29:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INpLT-00073Q-EE for atompub-archive@lists.ietf.org; Wed, 22 Aug 2007 08:29:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INpLR-0001nw-Li for atompub-archive@lists.ietf.org; Wed, 22 Aug 2007 08:29:59 -0400 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 l7MCCX4Q087009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 05:12:33 -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 l7MCCX6W087008; Wed, 22 Aug 2007 05:12:33 -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-s25.bay0.hotmail.com (bay0-omc2-s25.bay0.hotmail.com [65.54.246.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7MCCVP8086992; Wed, 22 Aug 2007 05:12:31 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([65.55.152.14]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 22 Aug 2007 05:12:30 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Aug 2007 05:12:30 -0700 Message-ID: Received: from 85.211.238.137 by BAY141-DAV4.phx.gbl with DAV; Wed, 22 Aug 2007 12:12:27 +0000 X-Originating-IP: [85.211.238.137] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-protocol" , "Atom-Syntax" References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds Date: Wed, 22 Aug 2007 13:14:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; 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.3138 X-OriginalArrivalTime: 22 Aug 2007 12:12:30.0303 (UTC) FILETIME=[B65BC6F0:01C7E4B5] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Thomas Broyer wrote: >> Furthermore, can someone point out which RFC or I-D defines link >> rel="first", link rel="last", link rel="next" and link rel="previous"? > > http://www.iana.org/assignments/link-relations.html says its Feed History. I've been meaning to ask about that. When those link relations were first defined, I thought the idea was that they would be fairly generic so that they could be used in various situations. The link definitions themselves make no reference to things like sort order or the stability of the documents to which they point. That should be up to the spec that uses them - for example AtomPub partial lists are typically ordered by app:edited, but feed history paged feeds make no recommendation either way. However, having the IANA registration point to the feed history draft implies things about those relations which were never intended. IMHO that's a bad thing. The feed history draft describes one possible use of those links, but certainly not the only one. There should be no obligation for other specs to be semantically identical in their usage. Regards James From owner-atom-syntax@mail.imc.org Thu Aug 23 11:30:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEdH-0007w0-6I for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 11:30:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOEdG-0000J3-8L for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 11:30:03 -0400 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 l7NF6gwM022725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 08:06: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 l7NF6gJI022724; Thu, 23 Aug 2007 08:06: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 py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7NF6fr3022706 for ; Thu, 23 Aug 2007 08:06:41 -0700 (MST) (envelope-from duck1123@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so988627pyb for ; Thu, 23 Aug 2007 08:06:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:from:sender; b=X3CLZVYScf3R4UK82IS9Nm52sI8nYO78GyR7BtKnpevatm86gOkX5KEXm67HL6QSKFYn3eOsmDBBex2QeJ0ByHiULvKM1TMDcZILfXHRJsziTF82IZewxjH0rZGun9uvJGwi+7WBWY4x3E8LYdywHZG41XiVWdiFRIXErogPU8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:from:sender; b=h0Cbzb+iBwewanqnks4QEkT3AE5lhLwb9lD6sCtSitvT3igonp1pZtH9vLnaIjClErwt1TubcP58RzzvTu3gw4BTUZ016cltC/THYII2Zf9Rn8fbc2M26H+4W/hXGc95BK4VjB1+Svkvi7PrQWke6d8wbWfrJkLswFX4xB3bOHo= Received: by 10.35.75.15 with SMTP id c15mr2217187pyl.1187881598184; Thu, 23 Aug 2007 08:06:38 -0700 (PDT) Received: from ?192.168.15.23? ( [68.42.123.89]) by mx.google.com with ESMTPS id a70sm2994428pye.2007.08.23.08.06.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Aug 2007 08:06:36 -0700 (PDT) Message-ID: <46CDA259.3040603@kronkltd.net> Date: Thu, 23 Aug 2007 11:06:01 -0400 User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Broyer CC: atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig66ACAA6C65715AA71673500B" From: "Daniel E. Renfer" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.7 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66ACAA6C65715AA71673500B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be safe to assume that if I retrieve two pages of a paged feed, and the atom:updated element for the feed is unchanged then I am indeed seeing a complete history of that feed? If I retrieve page 1, record the updated time, and retrieve page 2 and the updated time has changed, then I know new entries have been added to the feed since I got page 1. There may be some entries in page 2 that I previously saw in page 1. (The ones that have overflown to the next page) I'll have to re-retrieve page 1 to get the new entries. If I retrieve page 2 first, and then get page 1, and the updated value has changed, I know that I am missing some entries. They were on page 1 when I first got page 2, but are now on page 2. (or higher) I will have to re-retrieve the next page(s) until I find an entry I recognize. If the updated value is unchanged, then nothing has been added, removed, or modified in the feed. I can consider my view of the feed to be complet= e. Am I correct in this assumption? Thomas Broyer wrote: > 2007/8/21, Nikunj Mehta: >> Thomas Broyer wrote: >>> 2007/8/21, Nikunj Mehta: >>> >>>> =C2=A710.1 of AtomPub I-D expects collection partial lists aka pages= to be >>>> /lossless/. >>>> >>> Seems like we don't have the same definition of lossless then... >>> >> Allow me to clarify. A lossless paging is the following (this is my >> interpretation of =C2=A710.1 of AtomPub I-D): >> >> The partial list of entries obtained by GETting the collection's U= RI >> combined with partial lists obtained by following the rel=3D"next"= >> links in each of those partial lists MUST provide the snapshot of >> all of a collection's entries *as of the time *when the server >> responded to the GET request on the collection URI. >=20 > OK, so we don't have the same interpretation. It means this means > clarification in the spec (is it too late?). >=20 >> On the contrary lossy paging occurs when there is no such guarantee, >> i.e., navigating between partial lists might produce the same entry >> twice or more, might skip an entry completely because it "disappeared = in >> the boundary between pages". >=20 > Yup. >=20 >>> Partial lists in AtomPub are subject to the following constraint: >>> The first such partial list returned MUST contain the most recent= ly >>> edited member Resources and MUST have an atom:link with a "next" >>> relation whose "href" value is the URI of the next partial list o= f the >>> Collection. This next partial list will contain the next most rec= ently >>> edited set of Member Resources (and an atom:link to the following= >>> partial list if it exists). >>> >> If I am interpreting this right (without any formal model of course), >> then "next" implies the immediately "next most recently edited". To me= , >> that means lossless. >=20 > As partial lists are not defined to be "stable", they might be > changing over time. At the time you retrieve the first partial list, > the second partial list contains the "next most recently edited". But > between the retrieval of the first partial list and the time you > retrieve the second one, this one might have changed. >=20 >> I respectfully disagree with this interpretation per my argument above= =2E >> If the definition of partial lists and paging results in collection >> feeds being lossy, then how would we guarantee any synchronization of >> paged collections? >=20 > You cannot guarantee synchronization without an atomic operation or > paging a snapshot. Requiring servers to create "paged snapshots" (i.e. > as per your interpretation of atompub-protocol-17) would have too much > implications: servers would need to remember each and every "edit" > (app:edited) of all the entries. >=20 > The "partial list" thing is the Simplest Thing That Could Possibly > Work. If you want a reliable synchronization, then either: > 1. use another mechanism (RFC3229 w/ Feeds?) > 2. re-start synchronization from the Collection URI partial list > until you no longer need to follow the rel=3D"next" link >=20 >> Sorry I have come a little late to the feed history I-D party, but it >> looks like this spec is not strongly consistent with AtomPub (and the >> fact that the two don't even refer to each other's existence stinks, I= MHO). >> >> Furthermore, can someone point out which RFC or I-D defines link >> rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D"pr= evious"? >=20 > http://www.iana.org/assignments/link-relations.html says its Feed Histo= ry. >=20 --------------enig66ACAA6C65715AA71673500B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzaJdWorbjR01Cx4RAhTMAJsFNsGGwnBwDpj7o/rFDFQEq3EmjQCePkPA C+PIJkEm6ZJWjSG1oy2A+Sg= =Qh7+ -----END PGP SIGNATURE----- --------------enig66ACAA6C65715AA71673500B-- From owner-atom-syntax@mail.imc.org Thu Aug 23 13:36:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGbW-0006lP-8Y for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 13:36:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGbU-0004WT-Si for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 13:36:22 -0400 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 l7NHH3pH035566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 10:17: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 l7NHH3SO035565; Thu, 23 Aug 2007 10:17: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 ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7NHH1s8035499 for ; Thu, 23 Aug 2007 10:17:02 -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.1903080992 for ; Fri, 24 Aug 2007 03:16:15 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 24 Aug 2007 03:16:19 +1000 Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <46CDA259.3040603@kronkltd.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: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On 24/8/07 1:06 AM, "Daniel E. Renfer" wrote: > Am I correct in this assumption? sounds about right. unless the server doesn't generate the paged feed dynamically, instead simply archiving the pages as they accumulate (but still generating the top-most page dynamically) ... in which case they might serve up the page as it was when it was archived, including the as it was then atom:updated value for the feed. e. From owner-atom-syntax@mail.imc.org Thu Aug 23 20:27:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ION1O-0001Fj-VC for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 20:27:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ION1N-0000q4-Ad for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 20:27:30 -0400 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 l7O09mRi080044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 17: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 l7O09mQv080043; Thu, 23 Aug 2007 17: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 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 l7O09k3f080030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 17:09:47 -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 C62445194C; Thu, 23 Aug 2007 20:09:43 -0400 (EDT) In-Reply-To: <46CDA259.3040603@kronkltd.net> References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Thomas Broyer , atom-protocol , Atom-Syntax From: Mark Nottingham Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds Date: Fri, 24 Aug 2007 10:09:32 +1000 To: "Daniel E. Renfer" X-Mailer: Apple Mail (2.752.3) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7O09l3e080032 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7O09mRi080044 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Does atom:updated apply to *this* feed document, or the whole, =20 logical feed? On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote: > Would it be safe to assume that if I retrieve two pages of a paged =20 > feed, > and the atom:updated element for the feed is unchanged then I am =20 > indeed > seeing a complete history of that feed? > > If I retrieve page 1, record the updated time, and retrieve page 2 and > the updated time has changed, then I know new entries have been =20 > added to > the feed since I got page 1. There may be some entries in page 2 =20 > that I > previously saw in page 1. (The ones that have overflown to the next > page) I'll have to re-retrieve page 1 to get the new entries. > > If I retrieve page 2 first, and then get page 1, and the updated value > has changed, I know that I am missing some entries. They were on =20 > page 1 > when I first got page 2, but are now on page 2. (or higher) I will =20 > have > to re-retrieve the next page(s) until I find an entry I recognize. > > If the updated value is unchanged, then nothing has been added, =20 > removed, > or modified in the feed. I can consider my view of the feed to be =20 > complete. > > Am I correct in this assumption? > > Thomas Broyer wrote: >> 2007/8/21, Nikunj Mehta: >>> Thomas Broyer wrote: >>>> 2007/8/21, Nikunj Mehta: >>>> >>>>> =A710.1 of AtomPub I-D expects collection partial lists aka pages =20 >>>>> to be >>>>> /lossless/. >>>>> >>>> Seems like we don't have the same definition of lossless then... >>>> >>> Allow me to clarify. A lossless paging is the following (this is my >>> interpretation of =A710.1 of AtomPub I-D): >>> >>> The partial list of entries obtained by GETting the =20 >>> collection's URI >>> combined with partial lists obtained by following the rel=3D"next= " >>> links in each of those partial lists MUST provide the =20 >>> snapshot of >>> all of a collection's entries *as of the time *when the server >>> responded to the GET request on the collection URI. >> >> OK, so we don't have the same interpretation. It means this means >> clarification in the spec (is it too late?). >> >>> On the contrary lossy paging occurs when there is no such guarantee, >>> i.e., navigating between partial lists might produce the same entry >>> twice or more, might skip an entry completely because it =20 >>> "disappeared in >>> the boundary between pages". >> >> Yup. >> >>>> Partial lists in AtomPub are subject to the following constraint: >>>> The first such partial list returned MUST contain the most =20 >>>> recently >>>> edited member Resources and MUST have an atom:link with a =20 >>>> "next" >>>> relation whose "href" value is the URI of the next partial =20 >>>> list of the >>>> Collection. This next partial list will contain the next =20 >>>> most recently >>>> edited set of Member Resources (and an atom:link to the =20 >>>> following >>>> partial list if it exists). >>>> >>> If I am interpreting this right (without any formal model of =20 >>> course), >>> then "next" implies the immediately "next most recently edited". =20 >>> To me, >>> that means lossless. >> >> As partial lists are not defined to be "stable", they might be >> changing over time. At the time you retrieve the first partial list, >> the second partial list contains the "next most recently edited". But >> between the retrieval of the first partial list and the time you >> retrieve the second one, this one might have changed. >> >>> I respectfully disagree with this interpretation per my argument =20 >>> above. >>> If the definition of partial lists and paging results in collection >>> feeds being lossy, then how would we guarantee any =20 >>> synchronization of >>> paged collections? >> >> You cannot guarantee synchronization without an atomic operation or >> paging a snapshot. Requiring servers to create "paged =20 >> snapshots" (i.e. >> as per your interpretation of atompub-protocol-17) would have too =20 >> much >> implications: servers would need to remember each and every "edit" >> (app:edited) of all the entries. >> >> The "partial list" thing is the Simplest Thing That Could Possibly >> Work. If you want a reliable synchronization, then either: >> 1. use another mechanism (RFC3229 w/ Feeds?) >> 2. re-start synchronization from the Collection URI partial list >> until you no longer need to follow the rel=3D"next" link >> >>> Sorry I have come a little late to the feed history I-D party, =20 >>> but it >>> looks like this spec is not strongly consistent with AtomPub (and =20 >>> the >>> fact that the two don't even refer to each other's existence =20 >>> stinks, IMHO). >>> >>> Furthermore, can someone point out which RFC or I-D defines link >>> rel=3D"first", link rel=3D"last", link rel=3D"next" and link =20 >>> rel=3D"previous"? >> >> http://www.iana.org/assignments/link-relations.html says its Feed =20 >> History. >> > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 23 21:24:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IONuY-0006FA-Fz for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 21:24:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IONuX-00025F-Ey for atompub-archive@lists.ietf.org; Thu, 23 Aug 2007 21:24:30 -0400 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 l7O17bgb083468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 18:07: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 l7O17b4W083467; Thu, 23 Aug 2007 18:07: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7O17XOq083451 for ; Thu, 23 Aug 2007 18:07:36 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so497175wra for ; Thu, 23 Aug 2007 18:07:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=Y2uiMvTL7Va/ABv4GVYiG4mv90oo878bgO99zKAw29EAuZQOaqefiySIE6CAXg3GnDLfkZC/8cyhws1m1skHUpFzmdT4vtu78x63XNSnz5ZbIzrIxA+6OphtWplp8ZXmXDUL1OIZmWx4PVZYPaAizdmG/RLEPF6zB1nvPFiLaA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=EglFVsw/3YESdyRHde0IZbzwHKUXOmx+zFDqksHsDZs6cwrjqeZ6xsQryLtzN6TjIx+6CXWEAlXRLLRhhNef6VSTiVyvPMXXO/g5l5OdqXPSIQwh/ZbVa0PQ3ClW2ip79e8ZRtlnldW5Vi5PIjKXi0NsSlICvVpYizjIGcoo18A= Received: by 10.90.25.3 with SMTP id 3mr7685363agy.1187917651302; Thu, 23 Aug 2007 18:07:31 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id l22sm4248844wrl.2007.08.23.18.07.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Aug 2007 18:07:30 -0700 (PDT) Message-ID: <46CE2F4F.8020601@gmail.com> Date: Thu, 23 Aug 2007 18:07:27 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Mark Nottingham CC: "Daniel E. Renfer" , Thomas Broyer , atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7O17bgb083468 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Good question. Unfortunately the spec does not give a very clear answer. The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant Given that the RFC does not really have any notion of a "logical feed", the only reasonable interpretation I think we can make is that it applies only to *this* feed document. - James Mark Nottingham wrote: >=20 > Does atom:updated apply to *this* feed document, or the whole, logical > feed? >=20 >=20 > On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote: >=20 >> Would it be safe to assume that if I retrieve two pages of a paged fee= d, >> and the atom:updated element for the feed is unchanged then I am indee= d >> seeing a complete history of that feed? >> >> If I retrieve page 1, record the updated time, and retrieve page 2 and >> the updated time has changed, then I know new entries have been added = to >> the feed since I got page 1. There may be some entries in page 2 that = I >> previously saw in page 1. (The ones that have overflown to the next >> page) I'll have to re-retrieve page 1 to get the new entries. >> >> If I retrieve page 2 first, and then get page 1, and the updated value >> has changed, I know that I am missing some entries. They were on page = 1 >> when I first got page 2, but are now on page 2. (or higher) I will hav= e >> to re-retrieve the next page(s) until I find an entry I recognize. >> >> If the updated value is unchanged, then nothing has been added, remove= d, >> or modified in the feed. I can consider my view of the feed to be >> complete. >> >> Am I correct in this assumption? >> >> Thomas Broyer wrote: >>> 2007/8/21, Nikunj Mehta: >>>> Thomas Broyer wrote: >>>>> 2007/8/21, Nikunj Mehta: >>>>> >>>>>> =A710.1 of AtomPub I-D expects collection partial lists aka pages = to be >>>>>> /lossless/. >>>>>> >>>>> Seems like we don't have the same definition of lossless then... >>>>> >>>> Allow me to clarify. A lossless paging is the following (this is my >>>> interpretation of =A710.1 of AtomPub I-D): >>>> >>>> The partial list of entries obtained by GETting the collection's >>>> URI >>>> combined with partial lists obtained by following the rel=3D"nex= t" >>>> links in each of those partial lists MUST provide the snapshot o= f >>>> all of a collection's entries *as of the time *when the server >>>> responded to the GET request on the collection URI. >>> >>> OK, so we don't have the same interpretation. It means this means >>> clarification in the spec (is it too late?). >>> >>>> On the contrary lossy paging occurs when there is no such guarantee, >>>> i.e., navigating between partial lists might produce the same entry >>>> twice or more, might skip an entry completely because it >>>> "disappeared in >>>> the boundary between pages". >>> >>> Yup. >>> >>>>> Partial lists in AtomPub are subject to the following constraint: >>>>> The first such partial list returned MUST contain the most >>>>> recently >>>>> edited member Resources and MUST have an atom:link with a "next= " >>>>> relation whose "href" value is the URI of the next partial list >>>>> of the >>>>> Collection. This next partial list will contain the next most >>>>> recently >>>>> edited set of Member Resources (and an atom:link to the followi= ng >>>>> partial list if it exists). >>>>> >>>> If I am interpreting this right (without any formal model of course)= , >>>> then "next" implies the immediately "next most recently edited". To = me, >>>> that means lossless. >>> >>> As partial lists are not defined to be "stable", they might be >>> changing over time. At the time you retrieve the first partial list, >>> the second partial list contains the "next most recently edited". But >>> between the retrieval of the first partial list and the time you >>> retrieve the second one, this one might have changed. >>> >>>> I respectfully disagree with this interpretation per my argument abo= ve. >>>> If the definition of partial lists and paging results in collection >>>> feeds being lossy, then how would we guarantee any synchronization o= f >>>> paged collections? >>> >>> You cannot guarantee synchronization without an atomic operation or >>> paging a snapshot. Requiring servers to create "paged snapshots" (i.e. >>> as per your interpretation of atompub-protocol-17) would have too muc= h >>> implications: servers would need to remember each and every "edit" >>> (app:edited) of all the entries. >>> >>> The "partial list" thing is the Simplest Thing That Could Possibly >>> Work. If you want a reliable synchronization, then either: >>> 1. use another mechanism (RFC3229 w/ Feeds?) >>> 2. re-start synchronization from the Collection URI partial list >>> until you no longer need to follow the rel=3D"next" link >>> >>>> Sorry I have come a little late to the feed history I-D party, but i= t >>>> looks like this spec is not strongly consistent with AtomPub (and th= e >>>> fact that the two don't even refer to each other's existence stinks, >>>> IMHO). >>>> >>>> Furthermore, can someone point out which RFC or I-D defines link >>>> rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D"= previous"? >>> >>> http://www.iana.org/assignments/link-relations.html says its Feed >>> History. >>> >> >=20 >=20 > --=20 > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 From owner-atom-syntax@mail.imc.org Fri Aug 24 02:02:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSFJ-0008AA-0g for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 02:02:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOSFH-0007D5-D5 for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 02:02:12 -0400 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 l7O5jQdj002366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 22:45: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 l7O5jQr3002365; Thu, 23 Aug 2007 22:45: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7O5jOLu002358 for ; Thu, 23 Aug 2007 22:45:25 -0700 (MST) (envelope-from ionrock@gmail.com) Received: by nf-out-0910.google.com with SMTP id c10so502930nfd for ; Thu, 23 Aug 2007 22:45:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=oxM8Sd09BbYN3fUrRatVFcthn/A5oI06rN/8hNOkL0cyy/jGTz7WfR24eDFN3L6Knv8i8X6gp7VsE+kP2uDI3M+I3TtStVxJ2U0Mgf6ApL+QSYlFziJ5NXE1BKO8hOsaTh/44fKpYqKTGaIjxttic29B2KNT7f4jCa7aynHTJ1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WHJeORIghTu85DUTzxVs+4kqoElXy+6bJ5RBzQeTFHjlyWqQwTtHamTVoZePtH9T8WBvula09YeZDQ5vZ6x4Fcf2wqaOxiLTw6d8L5D8PfYp4tikk0ilk4WuaNfyXR8+Q6mCBI3+dAoL8Zw/80Mm5130vDNcUdsWKTbItuvIppI= Received: by 10.78.200.20 with SMTP id x20mr1699853huf.1187934323272; Thu, 23 Aug 2007 22:45:23 -0700 (PDT) Received: by 10.78.152.10 with HTTP; Thu, 23 Aug 2007 22:45:23 -0700 (PDT) Message-ID: <6e46dd1e0708232245t7d2bb83as59a6dfd5b3fa08af@mail.gmail.com> Date: Fri, 24 Aug 2007 00:45:23 -0500 From: "Eric Larson" To: "James M Snell" Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds Cc: "Mark Nottingham" , "Daniel E. Renfer" , "Thomas Broyer" , atom-protocol , Atom-Syntax In-Reply-To: <46CE2F4F.8020601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l7O5jQLu002360 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7O5jQdj002366 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Hi, On 8/23/07, James M Snell wrote: > > Good question. Unfortunately the spec does not give a very clear answer. > > The "atom:updated" element is a Date construct indicating the most > recent instant in time when an entry or feed was modified in a way > the publisher considers significant > > Given that the RFC does not really have any notion of a "logical feed", > the only reasonable interpretation I think we can make is that it > applies only to *this* feed document. > I would actually assume that it means the last time the collection as a whole was updated. Simply from a logical perspective, if I want to see when the specific feed was updated, it seems the atom:updated elements in the entries can tell me that. Also, the atom:updated in the in the feed seems to be similar to the atom:title of the feed, which I would assume would have meaning relative to the collection and not simply the current feed. For example, if I were implementing paging and the using a GET variable: http://host.com/blog/feed/index.atom?page=3D3&limit=3D10 It seems logical that the collection information found in the feed would be consistent across each paged entry. I mention all this simply b/c as James says, it is not entirely clear, so my suggestions above are really just my two cents as to what folks should do as a best practice. What do you all think? Eric > - James > > Mark Nottingham wrote: > > > > Does atom:updated apply to *this* feed document, or the whole, logica= l > > feed? > > > > > > On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote: > > > >> Would it be safe to assume that if I retrieve two pages of a paged f= eed, > >> and the atom:updated element for the feed is unchanged then I am ind= eed > >> seeing a complete history of that feed? > >> > >> If I retrieve page 1, record the updated time, and retrieve page 2 a= nd > >> the updated time has changed, then I know new entries have been adde= d to > >> the feed since I got page 1. There may be some entries in page 2 tha= t I > >> previously saw in page 1. (The ones that have overflown to the next > >> page) I'll have to re-retrieve page 1 to get the new entries. > >> > >> If I retrieve page 2 first, and then get page 1, and the updated val= ue > >> has changed, I know that I am missing some entries. They were on pag= e 1 > >> when I first got page 2, but are now on page 2. (or higher) I will h= ave > >> to re-retrieve the next page(s) until I find an entry I recognize. > >> > >> If the updated value is unchanged, then nothing has been added, remo= ved, > >> or modified in the feed. I can consider my view of the feed to be > >> complete. > >> > >> Am I correct in this assumption? > >> > >> Thomas Broyer wrote: > >>> 2007/8/21, Nikunj Mehta: > >>>> Thomas Broyer wrote: > >>>>> 2007/8/21, Nikunj Mehta: > >>>>> > >>>>>> =A710.1 of AtomPub I-D expects collection partial lists aka page= s to be > >>>>>> /lossless/. > >>>>>> > >>>>> Seems like we don't have the same definition of lossless then... > >>>>> > >>>> Allow me to clarify. A lossless paging is the following (this is m= y > >>>> interpretation of =A710.1 of AtomPub I-D): > >>>> > >>>> The partial list of entries obtained by GETting the collection= 's > >>>> URI > >>>> combined with partial lists obtained by following the rel=3D"n= ext" > >>>> links in each of those partial lists MUST provide the snapshot= of > >>>> all of a collection's entries *as of the time *when the server > >>>> responded to the GET request on the collection URI. > >>> > >>> OK, so we don't have the same interpretation. It means this means > >>> clarification in the spec (is it too late?). > >>> > >>>> On the contrary lossy paging occurs when there is no such guarante= e, > >>>> i.e., navigating between partial lists might produce the same entr= y > >>>> twice or more, might skip an entry completely because it > >>>> "disappeared in > >>>> the boundary between pages". > >>> > >>> Yup. > >>> > >>>>> Partial lists in AtomPub are subject to the following constraint: > >>>>> The first such partial list returned MUST contain the most > >>>>> recently > >>>>> edited member Resources and MUST have an atom:link with a "ne= xt" > >>>>> relation whose "href" value is the URI of the next partial li= st > >>>>> of the > >>>>> Collection. This next partial list will contain the next most > >>>>> recently > >>>>> edited set of Member Resources (and an atom:link to the follo= wing > >>>>> partial list if it exists). > >>>>> > >>>> If I am interpreting this right (without any formal model of cours= e), > >>>> then "next" implies the immediately "next most recently edited". T= o me, > >>>> that means lossless. > >>> > >>> As partial lists are not defined to be "stable", they might be > >>> changing over time. At the time you retrieve the first partial list= , > >>> the second partial list contains the "next most recently edited". B= ut > >>> between the retrieval of the first partial list and the time you > >>> retrieve the second one, this one might have changed. > >>> > >>>> I respectfully disagree with this interpretation per my argument a= bove. > >>>> If the definition of partial lists and paging results in collectio= n > >>>> feeds being lossy, then how would we guarantee any synchronization= of > >>>> paged collections? > >>> > >>> You cannot guarantee synchronization without an atomic operation or > >>> paging a snapshot. Requiring servers to create "paged snapshots" (i= .e. > >>> as per your interpretation of atompub-protocol-17) would have too m= uch > >>> implications: servers would need to remember each and every "edit" > >>> (app:edited) of all the entries. > >>> > >>> The "partial list" thing is the Simplest Thing That Could Possibly > >>> Work. If you want a reliable synchronization, then either: > >>> 1. use another mechanism (RFC3229 w/ Feeds?) > >>> 2. re-start synchronization from the Collection URI partial list > >>> until you no longer need to follow the rel=3D"next" link > >>> > >>>> Sorry I have come a little late to the feed history I-D party, but= it > >>>> looks like this spec is not strongly consistent with AtomPub (and = the > >>>> fact that the two don't even refer to each other's existence stink= s, > >>>> IMHO). > >>>> > >>>> Furthermore, can someone point out which RFC or I-D defines link > >>>> rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D= "previous"? > >>> > >>> http://www.iana.org/assignments/link-relations.html says its Feed > >>> History. > >>> > >> > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > From owner-atom-syntax@mail.imc.org Fri Aug 24 02:15:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSSK-0007WC-TB for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 02:15:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOSSJ-0007VD-BY for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 02:15:40 -0400 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 l7O5oAqG002569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Aug 2007 22:50: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 l7O5oA8l002568; Thu, 23 Aug 2007 22:50: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 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 l7O5o9Gu002561 for ; Thu, 23 Aug 2007 22:50:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so500529rvf for ; Thu, 23 Aug 2007 22:50:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=XeVL/FgU0gMWWmQ5HTw/h7rGx1ouRVrC/Bh846zSBP3KmsbdpPOUMOLktaR+F2D3MXoKWRUSQtNpE6JFQy36AI0KHVyHxE3p/dNExZYlgTMre04YJtE+SG5T6xl/AbuL1FS61TRp5M4RVOTR+0WiJexx7P07WkVxByhbqXnSh8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=VfjbtDU14i7X3qynaAMxNk7TyW3uVYj6LVbBCJWMeLu4234z9044cG/Pke3n0XvEAAluJuo8D4yIJiUzZoCr1q5NeaqetBh4BwRoYf1nJOYcqAuhnXRI5UOQGXnbeiwCtJGAHBuHhhbD3QAiG8WnzkmWZ78rSdofFTaANLGtDws= Received: by 10.141.108.21 with SMTP id k21mr1260393rvm.1187934608865; Thu, 23 Aug 2007 22:50:08 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id f42sm6152363rvb.2007.08.23.22.50.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Aug 2007 22:50:07 -0700 (PDT) Message-ID: <46CE7185.70601@gmail.com> Date: Thu, 23 Aug 2007 22:49:57 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Eric Larson CC: Mark Nottingham , "Daniel E. Renfer" , Thomas Broyer , atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> <6e46dd1e0708232245t7d2bb83as59a6dfd5b3fa08af@mail.gmail.com> In-Reply-To: <6e46dd1e0708232245t7d2bb83as59a6dfd5b3fa08af@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7O5oAqG002569 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 RFC4287 has no concept of a "Collection". Collections are only introduced by Atompub. And if you look at the Atompub spec, there's no mention of atom:updated at all, so it's still entirely up in the air and subject to individual interpretation. - James Eric Larson wrote: > Hi, >=20 > On 8/23/07, James M Snell wrote: >> Good question. Unfortunately the spec does not give a very clear answe= r. >> >> The "atom:updated" element is a Date construct indicating the most >> recent instant in time when an entry or feed was modified in a way >> the publisher considers significant >> >> Given that the RFC does not really have any notion of a "logical feed"= , >> the only reasonable interpretation I think we can make is that it >> applies only to *this* feed document. >> >=20 > I would actually assume that it means the last time the collection as > a whole was updated. >=20 > Simply from a logical perspective, if I want to see when the specific > feed was updated, it seems the atom:updated elements in the entries > can tell me that. Also, the atom:updated in the in the feed seems to > be similar to the atom:title of the feed, which I would assume would > have meaning relative to the collection and not simply the current > feed. For example, if I were implementing paging and the using a GET > variable: >=20 > http://host.com/blog/feed/index.atom?page=3D3&limit=3D10 >=20 > It seems logical that the collection information found in the feed > would be consistent across each paged entry. >=20 > I mention all this simply b/c as James says, it is not entirely clear, > so my suggestions above are really just my two cents as to what folks > should do as a best practice. >=20 > What do you all think? >=20 > Eric >=20 >> - James >> >> Mark Nottingham wrote: >>> Does atom:updated apply to *this* feed document, or the whole, logica= l >>> feed? >>> >>> >>> On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote: >>> >>>> Would it be safe to assume that if I retrieve two pages of a paged f= eed, >>>> and the atom:updated element for the feed is unchanged then I am ind= eed >>>> seeing a complete history of that feed? >>>> >>>> If I retrieve page 1, record the updated time, and retrieve page 2 a= nd >>>> the updated time has changed, then I know new entries have been adde= d to >>>> the feed since I got page 1. There may be some entries in page 2 tha= t I >>>> previously saw in page 1. (The ones that have overflown to the next >>>> page) I'll have to re-retrieve page 1 to get the new entries. >>>> >>>> If I retrieve page 2 first, and then get page 1, and the updated val= ue >>>> has changed, I know that I am missing some entries. They were on pag= e 1 >>>> when I first got page 2, but are now on page 2. (or higher) I will h= ave >>>> to re-retrieve the next page(s) until I find an entry I recognize. >>>> >>>> If the updated value is unchanged, then nothing has been added, remo= ved, >>>> or modified in the feed. I can consider my view of the feed to be >>>> complete. >>>> >>>> Am I correct in this assumption? >>>> >>>> Thomas Broyer wrote: >>>>> 2007/8/21, Nikunj Mehta: >>>>>> Thomas Broyer wrote: >>>>>>> 2007/8/21, Nikunj Mehta: >>>>>>> >>>>>>>> =A710.1 of AtomPub I-D expects collection partial lists aka page= s to be >>>>>>>> /lossless/. >>>>>>>> >>>>>>> Seems like we don't have the same definition of lossless then... >>>>>>> >>>>>> Allow me to clarify. A lossless paging is the following (this is m= y >>>>>> interpretation of =A710.1 of AtomPub I-D): >>>>>> >>>>>> The partial list of entries obtained by GETting the collection= 's >>>>>> URI >>>>>> combined with partial lists obtained by following the rel=3D"n= ext" >>>>>> links in each of those partial lists MUST provide the snapshot= of >>>>>> all of a collection's entries *as of the time *when the server >>>>>> responded to the GET request on the collection URI. >>>>> OK, so we don't have the same interpretation. It means this means >>>>> clarification in the spec (is it too late?). >>>>> >>>>>> On the contrary lossy paging occurs when there is no such guarante= e, >>>>>> i.e., navigating between partial lists might produce the same entr= y >>>>>> twice or more, might skip an entry completely because it >>>>>> "disappeared in >>>>>> the boundary between pages". >>>>> Yup. >>>>> >>>>>>> Partial lists in AtomPub are subject to the following constraint: >>>>>>> The first such partial list returned MUST contain the most >>>>>>> recently >>>>>>> edited member Resources and MUST have an atom:link with a "ne= xt" >>>>>>> relation whose "href" value is the URI of the next partial li= st >>>>>>> of the >>>>>>> Collection. This next partial list will contain the next most >>>>>>> recently >>>>>>> edited set of Member Resources (and an atom:link to the follo= wing >>>>>>> partial list if it exists). >>>>>>> >>>>>> If I am interpreting this right (without any formal model of cours= e), >>>>>> then "next" implies the immediately "next most recently edited". T= o me, >>>>>> that means lossless. >>>>> As partial lists are not defined to be "stable", they might be >>>>> changing over time. At the time you retrieve the first partial list= , >>>>> the second partial list contains the "next most recently edited". B= ut >>>>> between the retrieval of the first partial list and the time you >>>>> retrieve the second one, this one might have changed. >>>>> >>>>>> I respectfully disagree with this interpretation per my argument a= bove. >>>>>> If the definition of partial lists and paging results in collectio= n >>>>>> feeds being lossy, then how would we guarantee any synchronization= of >>>>>> paged collections? >>>>> You cannot guarantee synchronization without an atomic operation or >>>>> paging a snapshot. Requiring servers to create "paged snapshots" (i= .e. >>>>> as per your interpretation of atompub-protocol-17) would have too m= uch >>>>> implications: servers would need to remember each and every "edit" >>>>> (app:edited) of all the entries. >>>>> >>>>> The "partial list" thing is the Simplest Thing That Could Possibly >>>>> Work. If you want a reliable synchronization, then either: >>>>> 1. use another mechanism (RFC3229 w/ Feeds?) >>>>> 2. re-start synchronization from the Collection URI partial list >>>>> until you no longer need to follow the rel=3D"next" link >>>>> >>>>>> Sorry I have come a little late to the feed history I-D party, but= it >>>>>> looks like this spec is not strongly consistent with AtomPub (and = the >>>>>> fact that the two don't even refer to each other's existence stink= s, >>>>>> IMHO). >>>>>> >>>>>> Furthermore, can someone point out which RFC or I-D defines link >>>>>> rel=3D"first", link rel=3D"last", link rel=3D"next" and link rel=3D= "previous"? >>>>> http://www.iana.org/assignments/link-relations.html says its Feed >>>>> History. >>>>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >> >=20 From owner-atom-syntax@mail.imc.org Fri Aug 24 14:42:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOe6h-0007eN-Tr for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 14:42:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOe6g-0002Sr-JR for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 14:42:07 -0400 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 l7OIBnEq079611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 11:11: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 l7OIBnPc079610; Fri, 24 Aug 2007 11:11: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 mailwasher-b.lanl.gov (mailwasher.lanl.gov [192.65.95.54]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OIBlYi079603 for ; Fri, 24 Aug 2007 11:11:48 -0700 (MST) (envelope-from zxie@lanl.gov) Received: from mailrelay3.lanl.gov (mailrelay3.lanl.gov [128.165.4.104]) by mailwasher-b.lanl.gov (8.13.8/8.13.6/(ccn-5)) with ESMTP id l7OIBkRh011034 for ; Fri, 24 Aug 2007 12:11:46 -0600 Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay3.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id l7OIBiAQ020547 for ; Fri, 24 Aug 2007 12:11:44 -0600 Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id l7OIBijW021385 for ; Fri, 24 Aug 2007 12:11:44 -0600 Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id l7OIBiLW021383; Fri, 24 Aug 2007 12:11:44 -0600 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to zxie@lanl.gov using -f Received: from 128.165.0.81 (SquirrelMail authenticated user 212513) by webmail.lanl.gov with HTTP; Fri, 24 Aug 2007 12:11:44 -0600 (MDT) Message-ID: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> Date: Fri, 24 Aug 2007 12:11:44 -0600 (MDT) Subject: vs. From: "Zhiwu Xie" To: atom-syntax@imc.org Reply-To: zxie@lanl.gov User-Agent: SquirrelMail/1.4.8-6.el3.2lanl MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-CTN-5-MailScanner-Information: Please see http://network.lanl.gov/email/virus-scan.php X-CTN-5-MailScanner: Found to be clean X-CTN-5-MailScanner-From: zxie@lanl.gov X-Spam-Status: No Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 The spec says if I don't have a then I must have a . Can I assume the later is a substitution of the former if I don't want to provide any ? The reason I don't want to provide is due to its nature of human consumption (while in my application I'm mainly targeting at machine processing, so I don't want to parse but prefer to just have an HTTP address to retrieve the content), also there's a "no composite MIME type" clause for that may potentially limit the resources I can include in as content. But then it can also be confusing if I don't have a element but have multiple . I can't be sure which resource should be treated as the real content or they should all be treated equally as the contents. Thanks, Zhiwu Xie From owner-atom-syntax@mail.imc.org Fri Aug 24 15:27:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeom-0000Z6-55 for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 15:27:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOeok-00046j-Qi for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 15:27:40 -0400 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 l7OJAN77084480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 12:10: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 l7OJANQl084479; Fri, 24 Aug 2007 12:10: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7OJALrO084464 for ; Fri, 24 Aug 2007 12:10:22 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 Aug 2007 19:10:20 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp050) with SMTP; 24 Aug 2007 21:10:20 +0200 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX19Lw85Zq5xL42KYovXUG+G0L1+PfEy+/7Wdj/Jtlm ynnckaIoqPClTN Date: Fri, 24 Aug 2007 21:10:19 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: vs. Message-ID: <20070824191019.GE26939@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Hi Zhiwu, you probably want to use ``. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 24 15:27:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeoo-0000dg-NJ for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 15:27:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOeon-00046p-CD for atompub-archive@lists.ietf.org; Fri, 24 Aug 2007 15:27:42 -0400 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 l7OJBkUv084675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 12:11: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 l7OJBksf084674; Fri, 24 Aug 2007 12:11: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7OJBiqE084664 for ; Fri, 24 Aug 2007 12:11:44 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 Aug 2007 19:11:43 -0000 Received: from static-87-79-236-202.netcologne.de (EHLO klangraum) [87.79.236.202] by mail.gmx.net (mp042) with SMTP; 24 Aug 2007 21:11:43 +0200 X-Authenticated: #163624 X-Provags-ID: V01U2FsdGVkX18PoIkOWssPjMTqrc5Fya8ICbGJ7m+Sc72Ed9+upy Xa4K9qWI7c4BEn Date: Fri, 24 Aug 2007 21:11:43 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: vs. Message-ID: <20070824191143.GF26939@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> <20070824191019.GE26939@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20070824191019.GE26939@klangraum> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7OJBkUv084675 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi Zhiwu, * A. Pagaltzis [2007-08-24 21:10]: > you probably want to use ``. err I meant =E2=80=9Cwith no `@type` attribute.=E2=80=9D The restrictions apply to the type given in the `@type` attribute, but it=E2=80=99s fine to omit that. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat Aug 25 10:46:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOwu1-0003D8-V6 for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 10:46:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOwu0-00076C-D8 for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 10:46:17 -0400 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 l7PEUHnq072000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 07:30: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 l7PEUH7p071999; Sat, 25 Aug 2007 07:30: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PEUGxh071990 for ; Sat, 25 Aug 2007 07:30:17 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by wx-out-0506.google.com with SMTP id r21so1010103wxc for ; Sat, 25 Aug 2007 07:30:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=kje6if/RQlCz6RUYLO9Fwk3kFWoNBlg6xPN8Fb23LssHYIRLFsTLEt0ZN/ShVRdv3Dq4YnaHMsdEG9cJuwOpW2IcIiWtC8Ks+PftZ4X4ynpDG/N9xC6m2eujZHXfQ4/R4yA0XGoOzOXhz/6jyyKmT5mwlFVr3JlmapNyi9H5zZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=ZkAjICpZTD2hadedU4FBKiMu0aKVlKxg88XGZGC09wkX5PsyJ6XsuqDmnRntqD88wZtggGafIIlKM6k9yjlbRse01pvbfG+Amq17kF8x7DDb+oYOACY6FcRFnRMUM8LcP46ZR6RarWA4G6iAIRexLNNl2SUoRxCIsxK4Ey8b3MI= Received: by 10.70.80.14 with SMTP id d14mr6862086wxb.1188052215956; Sat, 25 Aug 2007 07:30:15 -0700 (PDT) Received: by 10.70.51.10 with HTTP; Sat, 25 Aug 2007 07:30:15 -0700 (PDT) Message-ID: <3f1451f50708250730l2f28ddecx68a786685a9b84b4@mail.gmail.com> Date: Sat, 25 Aug 2007 10:30:15 -0400 From: "Joe Gregorio" To: "James M Snell" Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds Cc: "Mark Nottingham" , "Daniel E. Renfer" , "Thomas Broyer" , atom-protocol , Atom-Syntax In-Reply-To: <46CE2F4F.8020601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> X-Google-Sender-Auth: 9d0d30c499feced9 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 8/23/07, James M Snell wrote: > > Good question. Unfortunately the spec does not give a very clear answer. What are you talking about? http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#listing-collections """ The first such partial list returned MUST contain the most recently edited member Resources and MUST have an atom:link with a "next" relation whose "href" value is the URI of the next partial list of the Collection. This next partial list will contain the next most recently edited set of Member Resources (and an atom:link to the following partial list if it exists).""" -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sat Aug 25 12:46:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOylx-0008SU-0j for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 12:46:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOylv-00025K-Ls for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 12:46:04 -0400 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 l7PGTVZ1080696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 09:29: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 l7PGTVr1080695; Sat, 25 Aug 2007 09:29: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 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 l7PGTUdE080687 for ; Sat, 25 Aug 2007 09:29:31 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0506.google.com with SMTP id n1so728261nzf for ; Sat, 25 Aug 2007 09:29:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=esCE7UEQh6SmeILMBkCP+8e7GXhG+5e4QG9oZWfTuhV2Ep7+7m2vosrFw5nNH3c3pL6z+AWMHDsQHVEWWCa1iKuTGYQlSn/GBz9Xx4mXs74L7sDirVP+XNN4/sfPo4fUXuk3/aVKrLT7mkN0OA6GN0sAAL4x5lN3HTxqwsZmKoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; 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=ovnZqltL1qYAMGqGM/YJsYHx3IR9VHJLNMVqVi0uVAi9QdJSgwofBjWXmiVJbtZJSzBB/5jQ0yC4Bwhs+hBWde3I3UPFdus2k+LQB4jJFMfuGaTZoUy2UfcH5FtKLeqbVd8iKQaIuA1TrbgisjKpc31wLXCRqtnxrXDUFv71B/g= Received: by 10.141.159.13 with SMTP id l13mr2050667rvo.1188059369634; Sat, 25 Aug 2007 09:29:29 -0700 (PDT) Received: from ?192.168.1.108? ( [67.181.218.96]) by mx.google.com with ESMTPS id g31sm10524800rvb.2007.08.25.09.29.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Aug 2007 09:29:28 -0700 (PDT) Message-ID: <46D058E6.4030409@gmail.com> Date: Sat, 25 Aug 2007 09:29:26 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Joe Gregorio CC: Mark Nottingham , "Daniel E. Renfer" , Thomas Broyer , atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> <3f1451f50708250730l2f28ddecx68a786685a9b84b4@mail.gmail.com> In-Reply-To: <3f1451f50708250730l2f28ddecx68a786685a9b84b4@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Yes, I'm very familiar with that part of the spec. The quote you provide still does not answer the question: "Does atom:updated apply to *this* feed document, or the whole, logical feed?" Neither RFC4287 or Atompub provide a clear answer to this question. - James Joe Gregorio wrote: > On 8/23/07, James M Snell wrote: >> Good question. Unfortunately the spec does not give a very clear answer. > > What are you talking about? > > http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#listing-collections > > """ The first such partial list returned MUST contain the most > recently edited member Resources and MUST have an atom:link with a > "next" relation whose "href" value is the URI of the next partial list > of the Collection. This next partial list will contain the next most > recently edited set of Member Resources (and an atom:link to the > following partial list if it exists).""" > > > -joe > From owner-atom-syntax@mail.imc.org Sat Aug 25 14:03:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOzye-00043R-B4 for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 14:03:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOzyc-0004Lc-TE for atompub-archive@lists.ietf.org; Sat, 25 Aug 2007 14:03:16 -0400 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 l7PHisd7085056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 10:44: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 l7PHisa1085055; Sat, 25 Aug 2007 10:44: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 wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PHiqhF085047 for ; Sat, 25 Aug 2007 10:44:53 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by wx-out-0506.google.com with SMTP id r21so1047755wxc for ; Sat, 25 Aug 2007 10:44:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=i7lNNGoAcB2/Z+TbbqufIyn2FQPjAluI/Gt5zW+BlCw8jTc+MEFAlRzsLAfzOCBagdjr63rn3A/228VuwOjwoaSxNRLFIcqpb7bm7FVAn7c9+EJ611zgL63HD6nh/KFaMLwpxUi7P90WSmLFhmpHefPMxxD7LybInQpr2IsK/5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=XY1U8/J9wWutLmc/lWPFKMJZfZUHBIoJN9VOOJMNleSdc6jGjZAb/fc0uqQ1C06DnecR8udRjoIFCAizMj3sufakKbAeD6OlY1tUS+tUdLd9Hm9U9YEbRfuUcM5d6O9NFbiXHiD587z6Oevgg2DtooILgJdjAJY+3K7Dw8cTPLo= Received: by 10.70.57.8 with SMTP id f8mr7131322wxa.1188063889933; Sat, 25 Aug 2007 10:44:49 -0700 (PDT) Received: by 10.70.51.10 with HTTP; Sat, 25 Aug 2007 10:44:49 -0700 (PDT) Message-ID: <3f1451f50708251044i2799e22aoefb276b2836bbcab@mail.gmail.com> Date: Sat, 25 Aug 2007 13:44:49 -0400 From: "Joe Gregorio" To: "James M Snell" Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds Cc: "Mark Nottingham" , "Daniel E. Renfer" , "Thomas Broyer" , atom-protocol , Atom-Syntax In-Reply-To: <46D058E6.4030409@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> <3f1451f50708250730l2f28ddecx68a786685a9b84b4@mail.gmail.com> <46D058E6.4030409@gmail.com> X-Google-Sender-Auth: 753e2e1757564623 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c On 8/25/07, James M Snell wrote: > Yes, I'm very familiar with that part of the spec. The quote you > provide still does not answer the question: > > "Does atom:updated apply to *this* feed document, > or the whole, logical feed?" Ah, we might be talking past each other about two different scenarios. This question is answered for "app:edited" in a Collection Feed, i.e. in the context of an AtomPub Collection Feed only. It does not answer the question for "atom:updated" in an 'Archived Feed'. http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html#listing-collections """The Entries in the returned Atom Feed SHOULD be ordered by their "app:edited" property, with the most recently edited Entries coming first in the document order. """ So every Feed Document that makes up a collection has it's entries ordered via "app:edited", and the quote I gave earlier states that: """This next partial list will contain the next most recently edited set of Member Resources (and an atom:link to the following partial list if it exists).""" So there is a total ordering of entries across all the partial feed documents of entries by "app:edited". Would it have been clearer if all the text were located in one place in the spec? Yes. Does it matter that we didn't use the term "logical feed"? No. Is there a conflict with the Feed History I-D? No, since the rel term "next", and others are defined in terms of a "Paged Feed" and not an "Archived Feed". The former having "some kind" of order, the second having an explicit ordering by "atom:updated". Is there ambiguity in the Feed History I-D as to whether the entries in each feed document are ordered by atom:updated? Yes, but I'm not sure that it matters. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 27 11:02:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg73-0006H2-2D for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 11:02:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPg70-0003Gn-RN for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 11:02:44 -0400 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 l7REfFPb098655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 07:41: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 l7REfFDb098653; Mon, 27 Aug 2007 07:41: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 rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7REfDKo098640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 07:41:14 -0700 (MST) (envelope-from nikunj.mehta@oracle.com) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l7REf58c025192; Mon, 27 Aug 2007 08:41:05 -0600 Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l7RDDi2P023755; Mon, 27 Aug 2007 08:41:04 -0600 Received: from dhcp-amer-whq-csvpn-gw3-141-144-84-62.vpn.oracle.com by acsmt352.oracle.com with ESMTP id 3158305341188225589; Mon, 27 Aug 2007 07:39:49 -0700 Message-ID: <46D2E233.7040009@oracle.com> Date: Mon, 27 Aug 2007 07:39:47 -0700 From: Nikunj Mehta Organization: Oracle User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Gregorio CC: Mark Nottingham , atom-protocol , Atom-Syntax Subject: Re: Possibly contrary statements in Atompub and feed history I-Ds References: <46CB1063.7000109@oracle.com> <46CB4FFB.8010200@oracle.com> <46CDA259.3040603@kronkltd.net> <46CE2F4F.8020601@gmail.com> <3f1451f50708250730l2f28ddecx68a786685a9b84b4@mail.gmail.com> <46D058E6.4030409@gmail.com> <3f1451f50708251044i2799e22aoefb276b2836bbcab@mail.gmail.com> In-Reply-To: <3f1451f50708251044i2799e22aoefb276b2836bbcab@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Joe Gregorio wrote: > Is there a conflict with the Feed History I-D? No, since the > rel term "next", and others are defined in terms of a "Paged Feed" > and not an "Archived Feed". The former having "some kind" of > order, the second having an explicit ordering by "atom:updated". > When you see a feed can you tell whether it is a "paged feed" or a "collection feed"? I can't. In that case, how can you correctly interpret rel="next" as "paged feed" allows lossy feed paging and "collection feed" requires lossless paging? From owner-atom-syntax@mail.imc.org Mon Aug 27 12:28:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhRu-00056W-Jr for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 12:28:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhRt-0005gI-8H for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 12:28:22 -0400 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 l7RG9KEs008344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 09:09: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 l7RG9KQY008343; Mon, 27 Aug 2007 09:09: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 mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RG9IfH008335 for ; Mon, 27 Aug 2007 09:09:19 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so1829256mue for ; Mon, 27 Aug 2007 09:09:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UwKr01AHJksgl24BGJxBh/UqlCOyUXhYS4YUaxF6NwMnQpJuogdHoGEPQgTqh1M30eP11SecSQIRn++p8evnB8Hn0v3JBYLTYwNVvHwXBh/55Gud1ZnvvNBbGeXv6NlCzIhzFdQ1VbsAxPz8uKO8MMXgyol7rrZjgSKdwJHeMhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GWpZdiGpCfVcz7VUBM7aauZIy28NzAKvavS1cQ3ceUC76GMslQ69aYATi2mGCTX3Jfsiq92UGAN5zWpJkYd31DVk/CKor/TrggujMzT+/ZpIywermbjuN/eBh08sx60mn4EflBkS8+Uahmzfw1kg1PJzQENc1h95RujRamhlIp8= Received: by 10.82.189.6 with SMTP id m6mr14479016buf.1188230957168; Mon, 27 Aug 2007 09:09:17 -0700 (PDT) Received: by 10.82.160.18 with HTTP; Mon, 27 Aug 2007 09:09:17 -0700 (PDT) Message-ID: <45be5cd40708270909r2913066cmddbc3e46941d103b@mail.gmail.com> Date: Mon, 27 Aug 2007 12:09:17 -0400 From: "Bob Wyman" To: "Zhiwu Xie" Subject: Re: who is the entry author? Cc: atom-syntax@imc.org In-Reply-To: <46AE1778.40201@lanl.gov> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_171238_2736737.1188230957127" References: <46AE1778.40201@lanl.gov> X-Google-Sender-Auth: e986783d5293181d Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c ------=_Part_171238_2736737.1188230957127 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/30/07, Zhiwu Xie wrote: > e.g., if atom:right says do not copy, does it mean this > atom entry cannot be aggregated by other Atom feed > aggregator or the contents cannot be distributed within > the atom:content? It would not be sensible to say "do not copy" since copying would be necessary if only to read the "do not copy" statement. The situation is just as it is with web pages and other bits of distributed data -- copying which is facilitative cannot be prevented and is permitted under an implicit license. In the case of a web page, the implicitly permitted copying is that needed to display the page in a browser. For a syndication format like Atom, the implicitly permitted copying is that which is required to permit syndication to be performed. (i.e. reading of feeds, temporary storage in aggregators, etc.) Nothing in the feed document can diminish this implicit license to copy a syndicated item. However, in the absence of a statement that grants additional rights, one should assume that syndication and display is the ONLY thing you're allowed to do with syndicated content. The purpose of the various "rights" elements is to define under what conditions readers have *expanded* rights to work with syndicated content. For instance, without a statement granting you appropriate rights, you must assume that you can't produce derivative works or do various forms of copying that are not related to the process of syndication or display. As for your specific questions: * Whether or not there is a rights statement, you have an implied license to aggregate syndicated data. * Unless explicitly granted, you have no right to copy the content of one entry into the atom:content of another entry. Doing that would be the production of a derivative work. bob wyman ------=_Part_171238_2736737.1188230957127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/30/07, Zhiwu Xie <zxie@lanl.gov> wrote:
> e.g., if atom:right says do not copy, does it mean this
> atom entry cannot be aggregated by other Atom feed
> aggregator or the contents cannot be distributed within
> the atom:content?
It would not be sensible to say "do not copy" since copying would be necessary if only to read the "do not copy" statement. The situation is just as it is with web pages and other bits of distributed data -- copying which is facilitative cannot be prevented and is permitted under an implicit license. In the case of a web page, the implicitly permitted copying is that needed to display the page in a browser. For a syndication format like Atom, the implicitly permitted copying is that which is required to permit syndication to be performed. ( i.e. reading of feeds, temporary storage in aggregators, etc.) Nothing in the feed document can diminish this implicit license to copy a syndicated item. However, in the absence of a statement that grants additional rights, one should assume that syndication and display is the ONLY thing you're allowed to do with syndicated content. The purpose of the various "rights" elements is to define under what conditions readers have *expanded* rights to work with syndicated content. For instance, without a statement granting you appropriate rights, you must assume that you can't produce derivative works or do various forms of copying that are not related to the process of syndication or display.

As for your specific questions:
* Whether or not there is a rights statement, you have an implied license to aggregate syndicated data.
* Unless explicitly granted, you have no right to copy the content of one entry into the atom:content of another entry. Doing that would be the production of a derivative work.

bob wyman

------=_Part_171238_2736737.1188230957127-- From owner-atom-syntax@mail.imc.org Mon Aug 27 12:34:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhXR-0001Vx-EK for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 12:34:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhXQ-0005tN-3I for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 12:34:05 -0400 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 l7RGFvul009123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 09:15: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 l7RGFv6R009122; Mon, 27 Aug 2007 09:15: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 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 l7RGFtYf009106 for ; Mon, 27 Aug 2007 09:15:56 -0700 (MST) (envelope-from bobwyman@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so1831245mue for ; Mon, 27 Aug 2007 09:15:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=P6Neto+zgjsLRAKvvib2sXFFim3nyp6Dt33E8zcHFK/rkwjLJuQrUYyhXDAMy7FWs80baKGJacy64+SEgkis6EmDjDZdZ3gZQJrxa5hqe3AfOsNmPzTlk93UeJKJa3/AeeEMAGrEUrR3dIRAS8H0RfCCAeRMiXKbYal6z1+leRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=LB6llLHVGEpFqZiplWN0fe/SNJsvEGpLBG5GD90mVn0QwoOnwHYsiDuMlcZWRwzpsz6fi/6nJZEiY0v6hnWotj56FjXY+RrfZ7w/SirKMT0/zGW239EzE3P82RUgdl4D1Fx5/hwRFPsF6LRhE4dY9ay5UbN2wLtBxYM6IQRDdxY= Received: by 10.82.114.3 with SMTP id m3mr14446916buc.1188231352376; Mon, 27 Aug 2007 09:15:52 -0700 (PDT) Received: by 10.82.160.18 with HTTP; Mon, 27 Aug 2007 09:15:52 -0700 (PDT) Message-ID: <45be5cd40708270915p28d00b29t5143812a21b20c4@mail.gmail.com> Date: Mon, 27 Aug 2007 12:15:52 -0400 From: "Bob Wyman" To: "Brian Smith" Subject: Re: How to implement the "Give me all the new & updated entries" use case Cc: "Atom WG" In-Reply-To: <000001c7c5c1$4e593e60$6501a8c0@Junk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_171302_7510534.1188231352330" References: <000001c7c5c1$4e593e60$6501a8c0@Junk> X-Google-Sender-Auth: 3649d18ce9311acd Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ------=_Part_171302_7510534.1188231352330 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/13/07, Brian Smith wrote: > I didn't find anything that allows the client to tell the server what > entries it (the client) already has, so that the server can send > just the new and/or updated entries. If you're just talking to an HTTP server (not something that implements APP), then consider using "RFC3229+feeds" which has been implemented by large number of servers and clients. See: http://www.wyman.us/main/2004/09/using_rfc3229_w.html bob wyman ------=_Part_171302_7510534.1188231352330 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/13/07, Brian Smith <brian@briansmith.org> wrote:
> I didn't find anything that allows the client to tell the server what
> entries it (the client) already has, so that the server can send
> just the new and/or updated entries.

If you're just talking to an HTTP server (not something that implements APP), then consider using "RFC3229+feeds" which has been implemented by large number of servers and clients. See:

http://www.wyman.us/main/2004/09/using_rfc3229_w.html


bob wyman

------=_Part_171302_7510534.1188231352330-- From owner-atom-syntax@mail.imc.org Mon Aug 27 17:54:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmXK-0005xG-8V for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 17:54:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPmXI-0006sg-PY for atompub-archive@lists.ietf.org; Mon, 27 Aug 2007 17:54:18 -0400 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 l7RLRT5C034264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 14:27: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 l7RLRTfV034263; Mon, 27 Aug 2007 14:27: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-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 l7RLRR7j034257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Aug 2007 14:27:29 -0700 (MST) (envelope-from brian@briansmith.org) Received: from Junk (unknown [12.217.178.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C3F93A323B for ; Mon, 27 Aug 2007 17:27:25 -0400 (EDT) From: "Brian Smith" To: "'Atom WG'" References: <000001c7c5c1$4e593e60$6501a8c0@Junk> <45be5cd40708270915p28d00b29t5143812a21b20c4@mail.gmail.com> Subject: RE: How to implement the "Give me all the new & updated entries" use case Date: Tue, 28 Aug 2007 04:27:25 +0700 Message-ID: <001801c7e8f1$11dd0bd0$6401a8c0@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: <45be5cd40708270915p28d00b29t5143812a21b20c4@mail.gmail.com> Thread-Index: AcfoxY3i1llK+7acTWa+02X8hdCRcwAJ4pvw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Bob Wyman wrote: > On 7/13/07, Brian Smith wrote: > > I didn't find anything that allows the client to tell the server what > > entries it (the client) already has, so that the server can send > > just the new and/or updated entries. > If you're just talking to an HTTP server (not something that implements > APP), then consider using "RFC3229+feeds" which has been implemented by > large number of servers and clients. See: > > http://www.wyman.us/main/2004/09/using_rfc3229_w.html I am aware of that. There is also an "Vary: If-None-Match" proposal, and a proposed link relation (paraphrased): I think that the link-based one is the easiest to understand, because It is easy to understand and seems to fit in well with the feed paging stuff. For example, what should happen when the client is, say, 100 entries behind the server? With the link-based solution, we can split the response up into pages as we see fit. Using RFC3229+feeds, if the client is 100 entries behind the server, would the server be required to send all 100 entries in the response? Regards, Brian From owner-atom-syntax@mail.imc.org Wed Aug 29 17:23:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQV08-0005db-KI for atompub-archive@lists.ietf.org; Wed, 29 Aug 2007 17:23:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQV07-00038V-9S for atompub-archive@lists.ietf.org; Wed, 29 Aug 2007 17:23:00 -0400 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 l7TKxVwx053574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 13:59: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 l7TKxVnJ053573; Wed, 29 Aug 2007 13:59: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 mailwasher-b.lanl.gov (mailwasher.lanl.gov [192.65.95.54]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TKxTGJ053562 for ; Wed, 29 Aug 2007 13:59:30 -0700 (MST) (envelope-from zxie@lanl.gov) Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.13.8/8.13.6/(ccn-5)) with ESMTP id l7TKxOlD017021 for ; Wed, 29 Aug 2007 14:59:24 -0600 Received: from pobox1663.lanl.gov (pobox1663.lanl.gov [128.165.4.124]) by mailrelay1.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id l7TKxNtj006580 for ; Wed, 29 Aug 2007 14:59:23 -0600 Received: from localhost.localdomain (elephant.lanl.gov [128.165.10.112]) by pobox1663.lanl.gov (8.13.8/8.13.8/(ccn-5)) with ESMTP id l7TKxKXE009098; Wed, 29 Aug 2007 14:59:20 -0600 Message-ID: <46D5DE27.9020301@lanl.gov> Date: Wed, 29 Aug 2007 14:59:19 -0600 From: Zhiwu Xie User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: vs. References: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> <20070824191019.GE26939@klangraum> <20070824191143.GF26939@klangraum> In-Reply-To: <20070824191143.GF26939@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed X-CTN-5-MailScanner-Information: Please see http://network.lanl.gov/email/virus-scan.php X-CTN-5-MailScanner: Found to be clean X-CTN-5-MailScanner-From: zxie@lanl.gov X-Spam-Status: No Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7TKxVwx053574 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Thanks a lot for the reply. But going this way I'll also have to supply=20 , which serves no apparent use in my application. I surely can=20 leave it empty but then it still feels like an intentional twist to the=20 's original purpose. Does this matter? Or can I interpret as the same as = ? Thanks, Zhiwu Xie A. Pagaltzis wrote: > Hi Zhiwu, >=20 > * A. Pagaltzis [2007-08-24 21:10]: >> you probably want to use ``. >=20 > err I meant =E2=80=9Cwith no `@type` attribute.=E2=80=9D >=20 > The restrictions apply to the type given in the `@type` > attribute, but it=E2=80=99s fine to omit that. >=20 > Regards, From owner-atom-syntax@mail.imc.org Wed Aug 29 18:19:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQVsc-0003E5-BI for atompub-archive@lists.ietf.org; Wed, 29 Aug 2007 18:19:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQVsa-0004X8-VR for atompub-archive@lists.ietf.org; Wed, 29 Aug 2007 18:19:18 -0400 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 l7TLt4Tr059242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 14:55: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 l7TLt4em059241; Wed, 29 Aug 2007 14:55: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 csmtp2.b-one.net (csmtp2.b-one.net [195.47.247.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TLt3Jd059233 for ; Wed, 29 Aug 2007 14:55:04 -0700 (MST) (envelope-from asbjorn@tigerstaden.no) Received: from quark (161.84-48-114.nextgentel.com [84.48.114.161]) by csmtp2.b-one.net (Postfix) with ESMTP id BB55A1F807832; Wed, 29 Aug 2007 23:54:46 +0200 (CEST) Date: Wed, 29 Aug 2007 23:54:48 +0200 To: "Zhiwu Xie" , atom-syntax@imc.org Subject: Re: vs. From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <45963.128.165.0.81.1187979104.squirrel@webmail.lanl.gov> <20070824191019.GE26939@klangraum> <20070824191143.GF26939@klangraum> <46D5DE27.9020301@lanl.gov> Message-ID: In-Reply-To: <46D5DE27.9020301@lanl.gov> User-Agent: Opera Mail/9.23 (Win32) X-Antivirus: avast! (VPS 000769-2, 29.08.2007), Outbound message X-Antivirus-Status: Clean Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id l7TLt4Tr059242 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Wed, 29 Aug 2007 22:59:19 +0200, Zhiwu Xie wrote: > Or can I interpret as the same as ? I would not say that they are semantically equivalent. With =20 link[@rel=3D'alternate']/@href, I'd expect some of the metadata inside =20 and to be available in the alternative representation. =20 With content/@src, I wouldn't expect that. To be more precise, I see =20 content/@src to be a smaller "unit" of information than the atom:entry an= d =20 whatever alternate representations it may have. Did that make sense? :-) --=20 Asbj=F8rn Ulsberg -=3D|=3D- http://virtuelvis.com/quark/ =ABHe's a loathsome offensive brute, yet I can't look away=BB From flugturkei@freenet.de Fri Aug 31 06:53:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR47m-000136-8n for atompub-archive@megatron.ietf.org; Fri, 31 Aug 2007 06:53:14 -0400 Received: from [2002:556e:f470::556e:f470] (helo=stadelmann) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IR47k-0000I6-95 for atompub-archive@megatron.ietf.org; Fri, 31 Aug 2007 06:53:14 -0400 Received: from stadelmann[127.0.0.1] by stadelmann[127.0.0.1] (SMTPD32); Fri, 31 Aug 2007 13:53:12 +0300 Organization: Air Turkey Reply-To: flug@doruk.net Message-ID: <82596a2d9cb7c0816012f588001e1bfc@freenet.de> From: "Air Turkey" To: Subject: Air Turkey. Date: Fri, 31 Aug 2007 13:48:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Sehr geehrte Damen und Herren=2E Air Turkey ist in Istanbul-Izmir-Antalya ein = Spezialveranstalter.www.air-turkey.com=20 Air Turkey spezialisiert f=FCr ihre = Fluege-Chartermiete,Spezialreisen,Hotels-Gruppenreisen von Kultur und=20 Bildungsreisen.Fuer Vereinen,Sportgruppen,Kirchen=2E Wir sind spezialisiert auch auf Individualreisen f=FCr Familien und = Familiefreizeiten=2E ANBEI FINDEN SIE UNSEREN HERBST SONDERANGEBOT=2E *Kultur Reisen f=FCr alle Gebiete Tuerkei=2E *Badeurlaub Hotel,s fuer Familien,Nur 5 Sterne All Inclusiv Hotels=2E *Istanbul Reisen f=FCr die Gruppen=2E *Nur Flug fuer alle Destination der Tuerkei=2E *Sport Reisen als Trainingslagern=2E Wir w=FCrden auch gern ihre Anfragen beantworten=2E Mit herzlichen Gr=FCssen=2E Air Turkey Team=2E mail@air-turkey.com ********************************* S O N D E R A N G E B O T ********************************** F=FCr Herbst 2007 offerieren wir Ihnen ein preislich unschlagbares Angebot an der t=FCrkischen Riviera Side-Antalya und Belek. In 5 * Sterne-Hotel mit = All ultra inclusive Service. S=E4mtlich Hotels im Angebot sind feine Strandhotels = direkt am Meer und mit denselben Preisen. Alle Zimmer haben Meerblick.=20 Unsere Fluege sind ab Frankfurt-Muenchen-Hamburg-Wien-Basel, Z=FCrich und = Friedrichshafen=2E Im Falle Ihrer Reservation bitten wir Sie h=F6flich, uns die Namen und = Anschriften der Reiseteilnehmer genau mitzuteilen=2E =20 Lassen Sie sich in einem der aufgef=FChrten 5* Hotel verw=F6hnen und = geniessen Sie Ihren Urlaub ohne grossen Touristenrummel=2E =20 Folgende Hotels stehen zur Verf=FCgung: S=FCral Saray Hotel Colakli-Side www.sural.com.tr Lares Park Hotel Antalya Lara www.laresparkhotel.com Fame Residence Antalya Lara www.famehotels.com Club Hotel Sera Antalya Lara www.clubhotelsera.com.tr Aydin Bey Famous Resort-Belek www.aydinbeyresorts.com/ Belek Beach Resort-Belek www.belekbeach.com/=20 Unsere Inklusive-Leistungen: - Hin- und Rueckflug - Flughaftentaxen und Sicherheitsgebuehren - Transfers Flughafen - Hotel - Flughafen - Uebernachtungen in5* Sterne Hotel Ihrer Wahl (All inklusive) - Begruessungs-Cocktail und fakultativer Antalya Ausflug - Deutschsprachige Reiseleitung=20 Reisetermine: 29. September bis 6. Oktober 2007 Euro 595 6. Oktober bis 13. Oktober 2007 Euro 595 13. Oktober bis 20. Oktober 2007 Euro 595 20. Oktober bis 27. Oktober 2007 Euro 595 27. Oktober bis 3. November 2007 Euro 545=20 03.November bis 10.November 2007 Euro 545=20 10.November bis 17.November 2007 Euro 545=20 17.November bis 24.November 2007 Euro 545=20 24.November bis 01.Dezember 2007 Euro 545=20 Kinder von 0 - 2 Jahren sind frei, 2 - 14 Jahren 70 % des Preises Sie haben diese Email unaufgefordert bekommen=2E Wenn Sie keine Mails von uns moechten klicken Sie bitte auf den Link: www.air-turkey.com/unsubscribe.htm