From owner-atom-syntax@mail.imc.org Mon Aug 01 03:45:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUz1-0002FL-1R for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 03:45:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02095 for ; Mon, 1 Aug 2005 03:45:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j717dNFJ009978; Mon, 1 Aug 2005 00:39:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j717dNEX009977; Mon, 1 Aug 2005 00:39:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j717dLcG009928 for ; Mon, 1 Aug 2005 00:39:22 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050801073915.QXQY21602.mta07-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>; Mon, 1 Aug 2005 08:39:15 +0100 Received: from cpc3-stok1-5-0-cust143.bagu.cable.ntl.com ([82.11.128.143]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20050801073915.OVDF24042.aamta11-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust143.bagu.cable.ntl.com>; Mon, 1 Aug 2005 08:39:15 +0100 Date: Mon, 1 Aug 2005 08:39:12 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <607337559.20050801083912@djpowell.net> To: Robert Sayre CC: Atom Syntax Subject: Re: Proposed changes for format-11 In-Reply-To: <68fba5c50507311634d5e7a32@mail.gmail.com> References: <68fba5c50507311634d5e7a32@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit draft-11: > This specification does not place any restrictions on what elements > may be used as Metadata Extensions, but the RelaxNG grammar > explicitly excludes elements in the Atom namespace. The Atom > namespace is reserved for future forwards-compatable revisions of > Atom. I'm not sure I like this paragraph. It starts by saying that it places no restriction on the elements, then mentions the RelaxNG, then in the final sentence, it says that actually there is a restriction after all. I don't know - perhaps I'm not reading it right, but it sounds contradictory. It would make more sense to me if everything was dropped except the last sentence. Also, Section 6.4 still doesn't permit Extension Elements in atom:source. I thought that we were going to fix this: http://www.imc.org/atom-syntax/mail-archive/msg15916.html And, did we ever get a resolution to the composite MIME types thing (I'm guessing that we didn't): http://www.imc.org/atom-syntax/mail-archive/msg15911.html -- Dave From owner-atom-syntax@mail.imc.org Mon Aug 01 06:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzX5g-0003HT-UG for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 06:00:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15586 for ; Mon, 1 Aug 2005 06:00:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j719qNdu056921; Mon, 1 Aug 2005 02:52:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j719qNIe056919; Mon, 1 Aug 2005 02:52:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j719qLHX056905 for ; Mon, 1 Aug 2005 02:52:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 1 Aug 2005 18:52:01 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 01 Aug 2005 18:50:55 +1000 Subject: Re: Proposed changes for format-11 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <607337559.20050801083912@djpowell.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: Content-Transfer-Encoding: 7bit On 1/8/05 5:39 PM, "David Powell" wrote: > >> This specification does not place any restrictions on what elements >> may be used as Metadata Extensions, but the RelaxNG grammar >> explicitly excludes elements in the Atom namespace. The Atom >> namespace is reserved for future forwards-compatable revisions of >> Atom. > > I'm not sure I like this paragraph. It starts by saying that it places > no restriction on the elements, then mentions the RelaxNG, then in the > final sentence, it says that actually there is a restriction after > all. I don't know - perhaps I'm not reading it right, but it sounds > contradictory. It would make more sense to me if everything was > dropped except the last sentence. I agree, especially since elsewhere the RelaxNG is noted to be Informative, not Normative. e. From owner-atom-syntax@mail.imc.org Mon Aug 01 10:27:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbGG-0002v8-W0 for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 10:27:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12623 for ; Mon, 1 Aug 2005 10:27:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71EJaAT050870; Mon, 1 Aug 2005 07:19:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71EJaIB050869; Mon, 1 Aug 2005 07:19:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71EJZhq050862 for ; Mon, 1 Aug 2005 07:19:35 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.109] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j71EJVY4021909 for ; Mon, 1 Aug 2005 10:19:32 -0400 (EDT) Message-ID: <42EE2F73.9040904@intertwingly.net> Date: Mon, 01 Aug 2005 10:19:31 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Proposed changes for format-11 References: In-Reply-To: X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 1/8/05 5:39 PM, "David Powell" wrote: > >>>This specification does not place any restrictions on what elements >>>may be used as Metadata Extensions, but the RelaxNG grammar >>>explicitly excludes elements in the Atom namespace. The Atom >>>namespace is reserved for future forwards-compatable revisions of >>>Atom. >> >>I'm not sure I like this paragraph. It starts by saying that it places >>no restriction on the elements, then mentions the RelaxNG, then in the >>final sentence, it says that actually there is a restriction after >>all. I don't know - perhaps I'm not reading it right, but it sounds >>contradictory. It would make more sense to me if everything was >>dropped except the last sentence. > > I agree, especially since elsewhere the RelaxNG is noted to be Informative, > not Normative. This paragraph appears to be expressing two separate thoughts. Perhaps the solution is to separate the thoughts into separate paragraphs. Perhaps the following could be added to section 6.2: The Atom namespace is reserved for future forwards-compatable revisions of Atom. Which would enable the text in appendix B to simply state: The RelaxNG grammar explicitly excludes elements in the Atom namespace which are not defined in this revision of the specification. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 01 11:17:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzc2c-0005Dc-TB for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:17:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15444 for ; Mon, 1 Aug 2005 11:17:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71FCIXe054697; Mon, 1 Aug 2005 08:12:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71FCIQe054696; Mon, 1 Aug 2005 08:12:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71FCHcU054677 for ; Mon, 1 Aug 2005 08:12:17 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1029970wra for ; Mon, 01 Aug 2005 08:12:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nFJSO2u6m2lB0hJEZdBm1tm+CTJi9hr+7DmLpi+lsyOwR8QXRvdtSQJ9Ki33UJruLP1U/13T6ZSMABiepGBejY2hvJOS9A4X2q7JQphV2XhjhInjgg13h7ftMEE+XqKLaGpqr8kWK1Jh2mix/F3pNjnvPqN/TyRFlWSQujx2JmI= Received: by 10.54.121.8 with SMTP id t8mr1994053wrc; Mon, 01 Aug 2005 08:12:11 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 1 Aug 2005 08:12:11 -0700 (PDT) Message-ID: <68fba5c505080108123c031f56@mail.gmail.com> Date: Mon, 1 Aug 2005 11:12:11 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: Proposed changes for format-11 Cc: Atom Syntax In-Reply-To: <42EE2F73.9040904@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EE2F73.9040904@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j71FCHcU054690 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/1/05, Sam Ruby wrote: > > Eric Scheid wrote: > > On 1/8/05 5:39 PM, "David Powell" wrote: > > > >>>This specification does not place any restrictions on what elements > >>>may be used as Metadata Extensions, but the RelaxNG grammar > >>>explicitly excludes elements in the Atom namespace. The Atom > >>>namespace is reserved for future forwards-compatable revisions of > >>>Atom. > >> > >>I'm not sure I like this paragraph. It starts by saying that it places > >>no restriction on the elements, then mentions the RelaxNG, then in the > >>final sentence, it says that actually there is a restriction after > >>all. I don't know - perhaps I'm not reading it right, but it sounds > >>contradictory. It would make more sense to me if everything was > >>dropped except the last sentence. > > > > I agree, especially since elsewhere the RelaxNG is noted to be Informative, > > not Normative. > > This paragraph appears to be expressing two separate thoughts. Perhaps > the solution is to separate the thoughts into separate paragraphs. That's a good rule of thumb. > > Perhaps the following could be added to section 6.2: > > The Atom namespace is reserved for future forwards-compatable > revisions of Atom. Sounds OK to me, but I recall squawking about this. > Which would enable the text in appendix B to simply state: > > The RelaxNG grammar explicitly excludes elements in the Atom > namespace which are not defined in this revision of the specification. Sounds good. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 01 11:55:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcdp-0002pG-Ro for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:55:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20047 for ; Mon, 1 Aug 2005 11:55:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71FoRCV058629; Mon, 1 Aug 2005 08:50:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71FoRQm058628; Mon, 1 Aug 2005 08:50:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j71FoPGS058609 for ; Mon, 1 Aug 2005 08:50:26 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 Aug 2005 15:50:19 -0000 Received: from xdsl-213-196-251-54.netcologne.de (EHLO klangraum) [213.196.251.54] by mail.gmx.net (mp008) with SMTP; 01 Aug 2005 17:50:19 +0200 X-Authenticated: #163624 Date: Mon, 1 Aug 2005 17:55:45 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Proposed changes for format-11 Message-ID: <20050801155545.GB31760@klangraum> Mail-Followup-To: Atom Syntax References: <42EE2F73.9040904@intertwingly.net> <68fba5c505080108123c031f56@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c505080108123c031f56@mail.gmail.com> 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 ietf.org id LAA20047 * Robert Sayre [2005-08-01 17:25]: > On 8/1/05, Sam Ruby wrote: > > Perhaps the following could be added to section 6.2: > >=20 > > The Atom namespace is reserved for future > > forwards-compatable revisions of Atom. s/compatable/compatible/ > Sounds OK to me, but I recall squawking about this. There wasn=E2=80=99t any squawking about the rule as such, I think. A minor amount of squawking was about what a consumer should do when it encounters Atom-namespaced elements in locations it didn=E2=80=99t expect them. Per spec: it should simply treat them as unknown foreign markup. Intent: this allows old consumers to continue working with future revisions of the spec, so long as changes are not so drastic that a new namespace is warranted to prevent existing consumers from doing anything with new documents. (You probably know this, of course=E2=80=A6) I think that specification of behaviour is a wise choice. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 01 12:26:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd7t-00084o-JS for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 12:26:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22083 for ; Mon, 1 Aug 2005 12:26:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GKD9q061682; Mon, 1 Aug 2005 09:20:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71GKD8f061681; Mon, 1 Aug 2005 09:20:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GKD76061675 for ; Mon, 1 Aug 2005 09:20:13 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc11) with SMTP id <2005080116200701100i4j9qe>; Mon, 1 Aug 2005 16:20:07 +0000 Date: Mon, 1 Aug 2005 10:20:05 -0600 Subject: Re: Comments Draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20050731162400.GE25925@klangraum> Message-Id: <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote: > * Antone Roundy [2005-07-31 01:15]: >> I could add more, but instead, here's my suggestion for >> replacing that sentence: >> >> If the resource being replied to is an atom:entry, the >> value of the href attribute MUST be the atom:id of the >> atom:entry. If the value of the type attribute is >> "application/atom+xml" then the href attribute MUST be the >> (URL/URI/IRI) of an Atom Entry Document containing the >> atom:entry being replied to. > > This undermines the purpose of the link. I'd say that not being able to tell whether @href in link[@rel="in-reply-to"] is dereferencable or not is what undermines link. The primary purpose of link[@rel="in-reply-to"] is to identify the resource (which may be an atom:entry) being replied to. If that resource is an atom:entry, then the appropriate identifier for it is it's atom:id. If "If the resource being replied to is an atom:entry, the value of the href attribute MUST be the atom:id of the atom:entry" doesn't sound like a good rule, then I'd argue that using atom:link to identify the resource being replied to is a bad idea. As I've said before, I think that stuffing data that happens to be a URI but may not be dereferencable into link/@href is a bad idea. If we ARE going to do it, then I think we need a way to at least hint at whether it's a dereferencable link or some other data stuffed into a link element. Here's what the spec says @type is for: On the link element, the "type" attribute's value is an advisory media type; it is a hint about the type of the representation that is expected to be returned when the value of the href attribute is dereferenced. If @href isn't dereferenable, then the existence of @type is deceptive. I suppose it could mean "when I saw it, it was in some kind of Atom document", but so what? What if the feed gets converted to RSS 2.0, the atom:id is put into guid, and I find the entry in the RSS feed? > Atom Entry Documents can move around; their IDs are eternal. True, so you could just omit @type from this link if you're concerned that your entry document might move. Or we could go with something like this: Or we could just stick with what has been proposed, perhaps including what I proposed in my last message, and if they entry document moves, then oh well, the web has another broken link just as it would in what I proposed just above here or in any case where a dereferencable link was published, but the atom:id would still be valid. If after moving the entry document, one were to publish the in-reply-to link again, it would be appropriate to remove the @type attribute. ...okay, that last sentence suggests that what I propose just above here is a superior way to having possibly-derefencable atom:links, because you could update the found-in-entry-document link if it got out of sync with the location of the document. Otherwise, we'll have to be limited to linking to the feed in which the entry is found. From owner-atom-syntax@mail.imc.org Mon Aug 01 12:34:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdFE-0005x4-Cl for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 12:34:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22478 for ; Mon, 1 Aug 2005 12:34:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GTV3x062466; Mon, 1 Aug 2005 09:29:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71GTVDa062465; Mon, 1 Aug 2005 09:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71GTULP062455 for ; Mon, 1 Aug 2005 09:29:30 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc12) with SMTP id <20050801162923012006d516e>; Mon, 1 Aug 2005 16:29:23 +0000 Date: Mon, 1 Aug 2005 10:29:21 -0600 Subject: Re: Proposed changes for format-11 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <20050801155545.GB31760@klangraum> Message-Id: <6A60E602-02A9-11DA-8129-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j71GTULP062460 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 ietf.org id MAA22478 On Monday, August 1, 2005, at 09:55 AM, A. Pagaltzis wrote: > * Robert Sayre [2005-08-01 17:25]: >> On 8/1/05, Sam Ruby wrote: >>> Perhaps the following could be added to section 6.2: >>> >>> The Atom namespace is reserved for future >>> forwards-compatable revisions of Atom. > > s/compatable/compatible/ > >> Sounds OK to me, but I recall squawking about this. > > There wasn=92t any squawking about the rule as such, I think. A > minor amount of squawking was about what a consumer should do > when it encounters Atom-namespaced elements in locations it > didn=92t expect them. > > Per spec: it should simply treat them as unknown foreign markup. > Intent: this allows old consumers to continue working with future > revisions of the spec, so long as changes are not so drastic that > a new namespace is warranted to prevent existing consumers from > doing anything with new documents. > It sounds to me like we might benefit from adding language specifying=20 that elements in the Atom namespace can appear as children of elements=20 from other namespaces, but may not appear as children of elements in=20 the Atom namespace except as specified by the spec (or from wording the=20 language to be added so that it says that). ...I am correct about our intent to allow Atom elements to be used as=20 children of extension elements, right? For example, that one be able=20 to do this: My title ...rather than having to do this: My title ...right? From owner-atom-syntax@mail.imc.org Mon Aug 01 13:33:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dze9t-00052y-7g for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 13:33:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26161 for ; Mon, 1 Aug 2005 13:32:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j71HMNS7067295; Mon, 1 Aug 2005 10:22:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j71HMNxN067294; Mon, 1 Aug 2005 10:22:23 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j71HMLka067280 for ; Mon, 1 Aug 2005 10:22:22 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 Aug 2005 17:22:15 -0000 Received: from xdsl-213-196-251-54.netcologne.de (EHLO klangraum) [213.196.251.54] by mail.gmx.net (mp011) with SMTP; 01 Aug 2005 19:22:15 +0200 X-Authenticated: #163624 Date: Mon, 1 Aug 2005 19:27:40 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Comments Draft Message-ID: <20050801172740.GA32587@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050731162400.GE25925@klangraum> <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> 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 ietf.org id NAA26161 * Antone Roundy [2005-08-01 18:30]: > On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote: > >This undermines the purpose of the link. >=20 > I'd say that not being able to tell whether @href in > link[@rel=3D"in-reply-to"] is dereferencable or not is what > undermines link. It undermines the purpose of the link insofar as IMO the entry being replied to MUST ALWAYS be identified by its atom:id. I am strongly -1 on letting the producer choose to identify it by its network location in any way or shape. Such a location is valuable as additional information to provide, but it=E2=80=99s strictly optional. > If "If the resource being replied to is an atom:entry, the > value of the href attribute MUST be the atom:id of the > atom:entry" doesn't sound like a good rule, then I'd argue that > using atom:link to identify the resource being replied to is a > bad idea. I have already agreed about the fact that atom:link is not the right vehicle for carrying the atom:id, so there=E2=80=99s no need for you to preach to the choir. See my "Thread/comment extension refactoring" post about my current stance. As for overloading @rel=3D'in-reply-to' to carry either dereferencable URIs or atom:ids, that would just needlessly require conditional checks on the consumer end. And because I=E2=80=99m strongly -1 on omitting the atom:id but also no longer consider atom:link to be the right place for it, the idea is triply wrong. > >Atom Entry Documents can move around; their IDs are eternal. > True, so you could just omit @type from this link if you're > concerned that your entry document might move. Or we could go > with something like this: >=20 > > > > That makes the information in the nested atom:link elements inaccessible to compliant clients without threading support, and it also requires new relationships to boot. Also, note that entry-sources vs replied-to-entries is an 1:N relationship, so it would make sense to group replied-to-entries by entry-source, rather than vice versa. So then you have urn:foo:1 urn:foo:2 which properly reuses a known relationship, so that even a non-thread-aware consumer can do something interesting with the information, even if it does not understand it quite as precisely as a client with proper thread awareness. Again, see my "Thread/comment extension refactoring" post about my current thinking. > ...okay, that last sentence suggests that what I propose just > above here is a superior way to having possibly-derefencable > atom:links, because you could update the > found-in-entry-document link if it got out of sync with the > location of the document. Otherwise, we'll have to be limited > to linking to the feed in which the entry is found. I don=E2=80=99t see why that is an advantage specific to using the @type attribute on atom:link in the way you proposed, rather than a benefit that *any* approach for including a source URL would provide. Again, please see my other post. The approach we started with (relying mostly on @rel=3D'in-reply-to' which I proposed) was hackish, which was okay as long as it was minimal, but is no longer tenable now that we are trying to accomplish even a bit more. My new proposition deals with all of your objections and several other issues I ran across on my own. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 01 22:51:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzmsY-0000w1-7k for atompub-archive@megatron.ietf.org; Mon, 01 Aug 2005 22:51:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14632 for ; Mon, 1 Aug 2005 22:51:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j722cxmq013203; Mon, 1 Aug 2005 19:38:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j722cxV9013202; Mon, 1 Aug 2005 19:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j722cwog013195 for ; Mon, 1 Aug 2005 19:38:58 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j722ctCA005875 for ; Mon, 1 Aug 2005 22:38:56 -0400 (EDT) Message-ID: <42EEDCBF.6010405@intertwingly.net> Date: Mon, 01 Aug 2005 22:38:55 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Introduction to The Atom Syndication Format X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.atomenabled.org/developers/syndication/ Feedback welcome. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 02 00:51:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzoka-0006Ta-FY for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 00:51:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27170 for ; Tue, 2 Aug 2005 00:51:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j724fSem024139; Mon, 1 Aug 2005 21:41:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j724fSEV024138; Mon, 1 Aug 2005 21:41:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42204.mail.yahoo.com (web42204.mail.yahoo.com [66.218.93.205]) by above.proper.com (8.12.11/8.12.9) with SMTP id j724fSVA024125 for ; Mon, 1 Aug 2005 21:41:28 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 14151 invoked by uid 60001); 2 Aug 2005 04:41:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4JIUhVQv/RYpCdUSz6lq25/3jL0VgNCKWBrUQzXkYYoygPBzeeEgWWGabAbON1XcwHOTVgtqLO4+TuBpUVJy4qATeQmnYeGH0daAVb50uzJpQ5oG17ZxH9m9g7cv5k97xwFnguxibyGHhCCmiQQV1gecrj1bchclUoJlDJZm1i8= ; Message-ID: <20050802044123.14149.qmail@web42204.mail.yahoo.com> Received: from [4.155.69.60] by web42204.mail.yahoo.com via HTTP; Mon, 01 Aug 2005 21:41:22 PDT Date: Mon, 1 Aug 2005 21:41:22 -0700 (PDT) From: James Cerra Subject: Oversights? (Re: Introduction to The Atom Syndication Format) To: Sam Ruby , atom-syntax@imc.org In-Reply-To: <42EEDCBF.6010405@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Sam Ruby annoyed us with: > > http://www.atomenabled.org/developers/syndication/ > > Feedback welcome. Interesting examples. I'm probably missing a few things, so any clarifications filling the gaps in my head would be appreciated! :-) From the Atom spec that I scanned (10) it is unclear if white space in atom:id and atom:updated elements (among others) is significant. The only mention is where the type attribute is allowed, where white space is sometimes normalizable. Strictly following the spec, then the following would be different atom:ids right? http://example.com/ http://example.com/ Of course that's not what's wanted. What is reasonable is that they are the same atom:id. However normalizing the whitespace is not enough, or even wanted. What is required is specifying that leading and trailing whitespaces are not significant. Also, the atom:content Processing Model specifies that new lines must be U+000A. What about Mac/Windows/other new line conventions? P.S. Just kidding about the annoying thing. I actually thought it was insightful! -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-atom-syntax@mail.imc.org Tue Aug 02 01:01:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzotw-0003bZ-Ih for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 01:01:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28361 for ; Tue, 2 Aug 2005 01:01:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j724kg2u024345; Mon, 1 Aug 2005 21:46:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j724kgEL024344; Mon, 1 Aug 2005 21:46:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j724kfHF024337 for ; Mon, 1 Aug 2005 21:46:41 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so1091885wra for ; Mon, 01 Aug 2005 21:46:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fYqlyT1qlnnakwzMRa9rqpidHHH3+jAXFlM3YS+xiGnLLh6IsFeJwzhhbRcJ5LpEjC9bQvRH8lVFwOI3bmEwEbMTbYQCVIQkz9v+5aQn9gzA7pnXimJjFywXWUUw/XgqCi1Nr083wv8z6gKswNKF5isfXr+nIw5pNAiSg3pMFxQ= Received: by 10.54.137.14 with SMTP id k14mr1238970wrd; Mon, 01 Aug 2005 21:46:35 -0700 (PDT) Received: by 10.54.104.20 with HTTP; Mon, 1 Aug 2005 21:46:35 -0700 (PDT) Message-ID: <540e373205080121464a4f2bed@mail.gmail.com> Date: Mon, 1 Aug 2005 23:46:35 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: Introduction to The Atom Syndication Format In-Reply-To: <42EEDCBF.6010405@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EEDCBF.6010405@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j724kfHF024339 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sam: I've only given it a quick skim, but at first blush, I think it looks great. -- Roger Benningfield On 8/1/05, Sam Ruby wrote: > > http://www.atomenabled.org/developers/syndication/ > > Feedback welcome. > > - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 02 02:34:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzqLy-0000wA-5H for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 02:34:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23347 for ; Tue, 2 Aug 2005 02:34:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j726LINE082578; Mon, 1 Aug 2005 23:21:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j726LIdM082577; Mon, 1 Aug 2005 23:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j726LF82082537 for ; Mon, 1 Aug 2005 23:21:17 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 2 Aug 2005 16:22:15 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 02 Aug 2005 16:21:11 +1000 Subject: Re: Introduction to The Atom Syndication Format From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42EEDCBF.6010405@intertwingly.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: Content-Transfer-Encoding: 7bit On 2/8/05 12:38 PM, "Sam Ruby" wrote: > http://www.atomenabled.org/developers/syndication/ > > Feedback welcome. " is patterned after html's link element. " [...] "rel indicates the link relationship type. " It would be good to indicate that atom:rel is different from html's rel in that only one value is allowed, not a space-delimited list. e. From owner-atom-syntax@mail.imc.org Tue Aug 02 04:27:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzs7T-00054m-PL for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 04:27:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29435 for ; Tue, 2 Aug 2005 04:27:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j728FQZN028973; Tue, 2 Aug 2005 01:15:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j728FQW2028972; Tue, 2 Aug 2005 01:15:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j728FP17028958 for ; Tue, 2 Aug 2005 01:15:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [Ap@IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id 5B8CF106DA; Tue, 2 Aug 2005 09:15:24 +0100 (BST) In-Reply-To: <20050802044123.14149.qmail@web42204.mail.yahoo.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Oversights? (Re: Introduction to The Atom Syndication Format) Date: Tue, 2 Aug 2005 09:15:24 +0100 To: James Cerra X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Aug 2005, at 5:41 am, James Cerra wrote: > > http://example.com/ > > > http://example.com/ > Those are different ids ("Processors MUST compare atom:id elements on a character-by-character basis"), and the first is just plain invalid. Why on earth would you think otherwise? (oh, apparently because the feed validator is broken) Graham From owner-atom-syntax@mail.imc.org Tue Aug 02 05:17:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzstg-0005sw-3O for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 05:17:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01714 for ; Tue, 2 Aug 2005 05:17:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7297Xqa046566; Tue, 2 Aug 2005 02:07:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7297XC1046565; Tue, 2 Aug 2005 02:07:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7297W7K046522 for ; Tue, 2 Aug 2005 02:07:33 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 84058 messnum 6393124 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 09:07:26 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail00.svc.cra.dublin.eircom.net (qp 84058) with SMTP; 2 Aug 2005 09:07:26 -0000 Message-ID: <42EF37CD.4030405@dehora.net> Date: Tue, 02 Aug 2005 10:07:25 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Graham wrote: > > On 2 Aug 2005, at 5:41 am, James Cerra wrote: > > >> >> http://example.com/ >> >> >> http://example.com/ >> > > Those are different ids ("Processors MUST compare atom:id elements on a > character-by-character basis"), and the first is just plain invalid. > Why on earth would you think otherwise? The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. It's unreasonable to expect people to think they're not the same id and this will be a souce of needless problems unless we fix it. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 05:59:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztY3-0001uK-Py for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 05:59:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03936 for ; Tue, 2 Aug 2005 05:58:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j729plFj061416; Tue, 2 Aug 2005 02:51:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j729pluH061415; Tue, 2 Aug 2005 02:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j729plcq061406 for ; Tue, 2 Aug 2005 02:51:47 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [a?@IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id E31BD106DA; Tue, 2 Aug 2005 10:51:45 +0100 (BST) In-Reply-To: <42EF37CD.4030405@dehora.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> Cc: atom-syntax From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 2 Aug 2005 10:51:42 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j729plcq061409 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 ietf.org id FAA03936 On 2 Aug 2005, at 10:07 am, Bill de h=D3ra wrote: > The design intent of character-by-character cmp as I understood was =20 > for > the URI contained by the element. I think confusing the element =20 > content > with the URI is a spec bug. From atompub-format-10, 4.2.6: "Its content MUST be an IRI" That to me is demonstrates a very clear intention of the working =20 group that the content must be exactly equal to the IRI. Changing =20 this to allow whitespace would represent a major technical change to =20 the format. I will figuratively lie down in the road if anyone =20 suggests whitespace should be allowed around any machine-read content =20 (uris, @type, @rel, etc). Graham From owner-atom-syntax@mail.imc.org Tue Aug 02 06:35:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu7E-0000UY-Jy for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:35:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07147 for ; Tue, 2 Aug 2005 06:35:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72ANePV072584; Tue, 2 Aug 2005 03:23:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72ANeM0072583; Tue, 2 Aug 2005 03:23:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72ANd0i072542 for ; Tue, 2 Aug 2005 03:23:40 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 971 messnum 5251426 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 10:23:33 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail02.svc.cra.dublin.eircom.net (qp 971) with SMTP; 2 Aug 2005 10:23:33 -0000 Message-ID: <42EF49A4.5050904@dehora.net> Date: Tue, 02 Aug 2005 11:23:32 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> In-Reply-To: <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> X-Enigmail-Version: 0.92.0.0 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 ietf.org id GAA07147 Graham wrote: >=20 > On 2 Aug 2005, at 10:07 am, Bill de h=D3ra wrote: >=20 >> The design intent of character-by-character cmp as I understood was f= or >> the URI contained by the element. I think confusing the element conte= nt >> with the URI is a spec bug. >=20 >=20 > From atompub-format-10, 4.2.6: "Its content MUST be an IRI" >=20 > That to me is demonstrates a very clear intention of the working group > that the content must be exactly equal to the IRI. Changing this to > allow whitespace would represent a major technical change to the > format. I will figuratively lie down in the road if anyone suggests > whitespace should be allowed around any machine-read content (uris, > @type, @rel, etc). I don't want to allow whitespace. But this urn:foo is going to happen, is going to cause problems, and working around it does not strike me as being something you can foist entirely onto the spec's end-users. Assuming everything you said above is true, we're responsible for specifying that XML element content that cannot contain leading or trailing whitespace (to be pedantic, a subset of what XML allows). When we say MUST above, we need to be clear on how we're supposed to deal with cases where someone does not follow the spec. For example, being clear whether the the above fragment is illegal or requires pre-processing would be useful. [You capture the essence when you mention machine-readable content. Really, that stuff should go into attributes not element content for exactly these kinds of reasons.] cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 06:35:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzu7D-0000UX-Vp for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:35:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07144 for ; Tue, 2 Aug 2005 06:35:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AP9XC073107; Tue, 2 Aug 2005 03:25:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72AP9k0073106; Tue, 2 Aug 2005 03:25:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AP8F0073091 for ; Tue, 2 Aug 2005 03:25:08 -0700 (PDT) (envelope-from sc@itst.net) Received: from webmail.cat-proof.de (localhost [127.0.0.1]) by cat-proof.de (Postfix) with SMTP id C88DE340B66D for ; Tue, 2 Aug 2005 12:20:34 +0200 (CEST) Received: from 195.243.113.249 (SquirrelMail authenticated user sc@itst.net) by webmail.cat-proof.de with HTTP; Tue, 2 Aug 2005 12:20:34 +0200 (CEST) Message-ID: <52108.195.243.113.249.1122978034.squirrel@webmail.cat-proof.de> In-Reply-To: <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> Date: Tue, 2 Aug 2005 12:20:34 +0200 (CEST) Subject: Re: spec bug: can we fix for draft-11? From: "Sascha Carlin" To: "atom-syntax" Reply-To: sc@itst.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham said: > the format. I will figuratively lie down in the road if anyone > suggests whitespace should be allowed around any machine-read content > (uris, @type, @rel, etc). +1. Possible whitespace would add general check & removal calls to any processor. When you process 100 items, thats not a problem. Staring with 10.000 is begins tu hurt, and will blow it up when you reach 100.000 items. Sascha From owner-atom-syntax@mail.imc.org Tue Aug 02 06:45:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuHS-0005mM-Vq for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:45:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08793 for ; Tue, 2 Aug 2005 06:45:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AdJtb078241; Tue, 2 Aug 2005 03:39:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72AdJHb078240; Tue, 2 Aug 2005 03:39:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72AdIii078201 for ; Tue, 2 Aug 2005 03:39:18 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 23732 messnum 4222607 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 10:39:12 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail13.svc.cra.dublin.eircom.net (qp 23732) with SMTP; 2 Aug 2005 10:39:12 -0000 Message-ID: <42EF4D4E.3010702@dehora.net> Date: Tue, 02 Aug 2005 11:39:10 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sc@itst.net CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <52108.195.243.113.249.1122978034.squirrel@webmail.cat-proof.de> In-Reply-To: <52108.195.243.113.249.1122978034.squirrel@webmail.cat-proof.de> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Sascha Carlin wrote: > Graham said: > >>the format. I will figuratively lie down in the road if anyone >>suggests whitespace should be allowed around any machine-read content >>(uris, @type, @rel, etc). > > > +1. Possible whitespace would add general check & removal calls to any > processor. When you process 100 items, thats not a problem. Staring with > 10.000 is begins tu hurt, and will blow it up when you reach 100.000 items. Interesting. 1. What should I do when I see this: urn:foo 2. What should I do when I see this: urn:foo 100,000 times? Again to make it clear: I am not arguing for whitespace in atom:id. I am arguing that whitespace is inevitable in atom:id and I think in that regard the spec is buggy, one way or another. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 06:47:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuIp-0007bM-52 for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:47:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08972 for ; Tue, 2 Aug 2005 06:47:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AYQ1p076475; Tue, 2 Aug 2005 03:34:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72AYQA1076474; Tue, 2 Aug 2005 03:34:26 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j72AYPDL076433 for ; Tue, 2 Aug 2005 03:34:25 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 10:34:19 -0000 Received: from pD95B7D02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp015) with SMTP; 02 Aug 2005 12:34:19 +0200 X-Authenticated: #1915285 Message-ID: <42EF4C2A.2020003@gmx.de> Date: Tue, 02 Aug 2005 12:34:18 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> In-Reply-To: <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ietf.org id GAA08972 Graham wrote: >=20 > On 2 Aug 2005, at 10:07 am, Bill de h=D3ra wrote: >=20 >> The design intent of character-by-character cmp as I understood was f= or >> the URI contained by the element. I think confusing the element conte= nt >> with the URI is a spec bug. >=20 >=20 > From atompub-format-10, 4.2.6: "Its content MUST be an IRI" >=20 > That to me is demonstrates a very clear intention of the working group= =20 > that the content must be exactly equal to the IRI. Changing this to=20 > allow whitespace would represent a major technical change to the=20 > format. I will figuratively lie down in the road if anyone suggests=20 > whitespace should be allowed around any machine-read content (uris,=20 > @type, @rel, etc). +1 A potential enhancement would be to explicitly state that whitespace=20 *is=DC significant here (and of course to make the feedvalidator check it= ). Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Aug 02 06:51:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuMj-0008P6-L9 for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:51:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09210 for ; Tue, 2 Aug 2005 06:51:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72Ajffg080512; Tue, 2 Aug 2005 03:45:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72Ajf2w080511; Tue, 2 Aug 2005 03:45:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72Ajeps080475 for ; Tue, 2 Aug 2005 03:45:41 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 82563 messnum 269966 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 10:45:34 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail03.svc.cra.dublin.eircom.net (qp 82563) with SMTP; 2 Aug 2005 10:45:34 -0000 Message-ID: <42EF4ECD.4000205@dehora.net> Date: Tue, 02 Aug 2005 11:45:33 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF4C2A.2020003@gmx.de> In-Reply-To: <42EF4C2A.2020003@gmx.de> X-Enigmail-Version: 0.92.0.0 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 ietf.org id GAA09210 Julian Reschke wrote: >=20 > Graham wrote: >=20 >> >> On 2 Aug 2005, at 10:07 am, Bill de h=D3ra wrote: >> >>> The design intent of character-by-character cmp as I understood was = for >>> the URI contained by the element. I think confusing the element cont= ent >>> with the URI is a spec bug. >> >> >> >> From atompub-format-10, 4.2.6: "Its content MUST be an IRI" >> >> That to me is demonstrates a very clear intention of the working=20 >> group that the content must be exactly equal to the IRI. Changing=20 >> this to allow whitespace would represent a major technical change to=20 >> the format. I will figuratively lie down in the road if anyone=20 >> suggests whitespace should be allowed around any machine-read content=20 >> (uris, @type, @rel, etc). >=20 >=20 > +1 >=20 > A potential enhancement would be to explicitly state that whitespace > *is=DC significant here (and of course to make the feedvalidator check = it). That still leaves things unsaid - significant in what way? What does "make the feedvalidator check it" entail? And assuming we did this enhancement how does whitespace square with our MUST be an IRI. Somebody please convince me the spec is adequate here; I'm not seeing it. I'm feeling an urge to go through all the elements for any other machine readable tokens living inside element content and filing bugs against the lot of them. Then I'll do the same with APP constructs like 'draft'. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 07:04:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuZl-0005jR-Tt for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 07:04:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10158 for ; Tue, 2 Aug 2005 07:04:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AxVlH085589; Tue, 2 Aug 2005 03:59:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72AxVi3085588; Tue, 2 Aug 2005 03:59:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cat-proof.de (cat.cat-proof.de [213.239.198.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72AxUhA085577 for ; Tue, 2 Aug 2005 03:59:30 -0700 (PDT) (envelope-from sc@itst.net) Received: from webmail.cat-proof.de (localhost [127.0.0.1]) by cat-proof.de (Postfix) with SMTP id 33C7E340B66C; Tue, 2 Aug 2005 12:54:57 +0200 (CEST) Received: from 195.243.113.249 (SquirrelMail authenticated user sc@itst.net) by webmail.cat-proof.de with HTTP; Tue, 2 Aug 2005 12:54:57 +0200 (CEST) Message-ID: <51946.195.243.113.249.1122980097.squirrel@webmail.cat-proof.de> In-Reply-To: <42EF49A4.5050904@dehora.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> Date: Tue, 2 Aug 2005 12:54:57 +0200 (CEST) Subject: Re: spec bug: can we fix for draft-11? From: "Sascha Carlin" To: Bill de =?iso-8859-1?Q?h=D3ra?= Cc: "Graham" , "atom-syntax" Reply-To: sc@itst.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I don't want to allow whitespace. But this > > > urn:foo > > > is going to happen, is going to cause problems, and working around it > does not strike me as being something you can foist entirely onto the > spec's end-users. [...] When we say MUST above, we need to be clear on how > we're supposed to deal with cases where someone does not follow the spec. > For example, being clear whether the the above fragment is illegal or > requires pre-processing would be useful. All of this will just be work-arounds, as pointed out. > [You capture the essence when you mention machine-readable content. > Really, that stuff should go into attributes not element content for > exactly these kinds of reasons.] Agreed. Why not do it? Instead of some-uri ... it could read ... As being said, this should have to be applied to all directly machine-generated or machine-readable data. Sascha PS: Please accept my apologies for the strange orthography in my last post - I couldn't get my four espressos this morning :-) From owner-atom-syntax@mail.imc.org Tue Aug 02 07:06:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzuaw-0007hc-NG for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 07:06:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10419 for ; Tue, 2 Aug 2005 07:05:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72B0Wja085909; Tue, 2 Aug 2005 04:00:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72B0WAJ085908; Tue, 2 Aug 2005 04:00:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72B0UHp085869 for ; Tue, 2 Aug 2005 04:00:31 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 11:00:23 -0000 Received: from pD95B7D02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp024) with SMTP; 02 Aug 2005 13:00:23 +0200 X-Authenticated: #1915285 Message-ID: <42EF5245.6010203@gmx.de> Date: Tue, 02 Aug 2005 13:00:21 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF4C2A.2020003@gmx.de> <42EF4ECD.4000205@dehora.net> In-Reply-To: <42EF4ECD.4000205@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ietf.org id HAA10419 Bill de h=D3ra wrote: > Julian Reschke wrote: >=20 >>Graham wrote: >> >> >>>On 2 Aug 2005, at 10:07 am, Bill de h=D3ra wrote: >>> >>> >>>>The design intent of character-by-character cmp as I understood was = for >>>>the URI contained by the element. I think confusing the element cont= ent >>>>with the URI is a spec bug. >>> >>> >>> >>> From atompub-format-10, 4.2.6: "Its content MUST be an IRI" >>> >>>That to me is demonstrates a very clear intention of the working=20 >>>group that the content must be exactly equal to the IRI. Changing=20 >>>this to allow whitespace would represent a major technical change to=20 >>>the format. I will figuratively lie down in the road if anyone=20 >>>suggests whitespace should be allowed around any machine-read content=20 >>>(uris, @type, @rel, etc). >> >> >>+1 >> >>A potential enhancement would be to explicitly state that whitespace >>*is=DC significant here (and of course to make the feedvalidator check = it). >=20 >=20 > That still leaves things unsaid - significant in what way? What does > "make the feedvalidator check it" entail? And assuming we did this > enhancement how does whitespace square with our MUST be an IRI. If you put whitespace inside, it's part of the to-be-IRI. As an IRI can=20 not contain whitespace, it's an invalid IRI. > Somebody please convince me the spec is adequate here; I'm not seeing > it. I'm feeling an urge to go through all the elements for any other > machine readable tokens living inside element content and filing bugs > against the lot of them. Then I'll do the same with APP constructs like > 'draft'. Seems that the spec may need to define once what it means to say that=20 the content of an element must be something specific, such as an IRI. Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Aug 02 07:56:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvNv-0000AK-FX for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 07:56:39 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13355 for ; Tue, 2 Aug 2005 07:56:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72BoNvT003516; Tue, 2 Aug 2005 04:50:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72BoNlG003515; Tue, 2 Aug 2005 04:50:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72BoNvn003501 for ; Tue, 2 Aug 2005 04:50:23 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 79335 invoked from network); 2 Aug 2005 11:50:22 -0000 Received: from unknown (HELO ?172.30.2.20?) (unknown) by unknown with SMTP; 2 Aug 2005 11:50:22 -0000 X-pair-Authenticated: 62.172.77.82 Message-ID: <42EF5DFD.8070308@internetalchemy.org> Date: Tue, 02 Aug 2005 12:50:21 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> In-Reply-To: <8959E900-6ABE-495D-AE13-846B38BB175F@mac.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: Content-Transfer-Encoding: 7bit On 02/08/2005 10:51, Graham wrote: > That to me is demonstrates a very clear intention of the working group > that the content must be exactly equal to the IRI. Changing this to > allow whitespace would represent a major technical change to the > format. I will figuratively lie down in the road if anyone suggests > whitespace should be allowed around any machine-read content (uris, > @type, @rel, etc). Leading and trailing whitespace should be stripped from the content of an atom:id element. The two examples that Bill gave WILL happen in the wild and Atom consumers will just deal with it by stripping the whitespace anyway despite what the spec says now. I think this should be endorsed in the spec for interoperability. Ian -- http://internetalchemy.org | http://purl.org/NET/iand Working on... Silkworm From owner-atom-syntax@mail.imc.org Tue Aug 02 08:17:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvi8-0005oW-NY for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 08:17:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14843 for ; Tue, 2 Aug 2005 08:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72C9XJ7009932; Tue, 2 Aug 2005 05:09:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72C9XWs009930; Tue, 2 Aug 2005 05:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72C9Wjb009888 for ; Tue, 2 Aug 2005 05:09:33 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 87439 messnum 5267087 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 12:09:26 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail04.svc.cra.dublin.eircom.net (qp 87439) with SMTP; 2 Aug 2005 12:09:26 -0000 Message-ID: <42EF6274.8040201@dehora.net> Date: Tue, 02 Aug 2005 13:09:24 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <51946.195.243.113.249.1122980097.squirrel@webmail.cat-proof.de> In-Reply-To: <51946.195.243.113.249.1122980097.squirrel@webmail.cat-proof.de> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Sascha Carlin wrote: >>[You capture the essence when you mention machine-readable content. >>Really, that stuff should go into attributes not element content for >>exactly these kinds of reasons.] > > > Agreed. Why not do it? I Probably because it trades a spec text fix for a design fix. Not that there's anything wrong with your design, but it would set a WG precedent that wouldn't be helpful at this point (Bray and Hoffman would come round our houses...) cheers Bil From owner-atom-syntax@mail.imc.org Tue Aug 02 08:45:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzw9X-0006xK-6A for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 08:45:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16123 for ; Tue, 2 Aug 2005 08:45:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72CeFrW020770; Tue, 2 Aug 2005 05:40:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72CeFeR020769; Tue, 2 Aug 2005 05:40:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42207.mail.yahoo.com (web42207.mail.yahoo.com [66.218.93.208]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72CeDCF020723 for ; Tue, 2 Aug 2005 05:40:13 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 87182 invoked by uid 60001); 2 Aug 2005 12:40:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=29wrvyLIDRQF2rfzqlsTHGRG88YOx0tQbGl9e6A+CeqAPXoZWs/v+9CA8tV9Rqn4JiscfrFT8k7ilTFB9PaPREX3/fOcNSIFDFrbvmVxqZ2KZSyEdGbk5ntOfBTgsjFo5xoOZ2E4c6+ht416FI/Cb+0EW2wBVb/Z6/nbyy8LOA8= ; Message-ID: <20050802124008.87180.qmail@web42207.mail.yahoo.com> Received: from [4.155.99.85] by web42207.mail.yahoo.com via HTTP; Tue, 02 Aug 2005 05:40:08 PDT Date: Tue, 2 Aug 2005 05:40:08 -0700 (PDT) From: James Cerra Subject: Re: spec bug: can we fix for draft-11? To: Ian Davis , Graham Cc: Bill de "hÓra" , atom-syntax In-Reply-To: <42EF5DFD.8070308@internetalchemy.org> MIME-Version: 1.0 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: 8bit > Ian Davis wrote: > > Graham wrote: > > That to me is demonstrates a very clear intention of the working group > > that the content must be exactly equal to the IRI. Changing this to > > allow whitespace would represent a major technical change to the > > format. I will figuratively lie down in the road if anyone suggests > > whitespace should be allowed around any machine-read content (uris, > > @type, @rel, etc). > > Leading and trailing whitespace should be stripped from the content of > an atom:id element. > > The two examples that Bill gave WILL happen in the wild and Atom > consumers will just deal with it by stripping the whitespace anyway > despite what the spec says now. I think this should be endorsed in the > spec for interoperability. +1. But Sam Ruby's first draft at [1] demostrated more than just atom:id. (He changed it now so that the examples don't have white space showing! lol!) They also included things like: http://example.com/ 2003-12-13T18:30:02Z Neither of those are strictly legal, since white space is illegal in both IRI and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer used. I think that it also be should be noted for atom:person/* constructs (except for atom:name) and atom:date constructs that white space is illegal. Or that for them and atomURI constructs that leading and trailing whitespace is legal but should be stripped away. I'm not sure which is best. Then there is atom:person/atom:name constructs. Should leading and trailing whiespace be stripped or should it be considered significant? Certainly it is significant and legal in the middle of a person's name. [1] http://www.atomenabled.org/developers/syndication/ -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From owner-atom-syntax@mail.imc.org Tue Aug 02 09:16:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzwct-0000R9-P9 for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:16:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17776 for ; Tue, 2 Aug 2005 09:16:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DBleq032845; Tue, 2 Aug 2005 06:11:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DBlu9032843; Tue, 2 Aug 2005 06:11:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DBk8V032831 for ; Tue, 2 Aug 2005 06:11:46 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [0P@IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id 88F33106DA for ; Tue, 2 Aug 2005 14:11:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <42EF5DFD.8070308@internetalchemy.org> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 2 Aug 2005 14:11:41 +0100 To: atom-syntax X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Aug 2005, at 12:50 pm, Ian Davis wrote: > The two examples that Bill gave WILL happen in the wild and Atom > consumers will just deal with it by stripping the whitespace anyway > despite what the spec says now. I think this should be endorsed in > the spec for interoperability. I (and probably others) have already put code out into the wild in the assumption there is no whitespace. As I said before, it's too late for a solution that changes the meaning of the spec. Graham From owner-atom-syntax@mail.imc.org Tue Aug 02 09:16:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwdL-0000p1-Fp for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:16:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17806 for ; Tue, 2 Aug 2005 09:16:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72D9Djj031903; Tue, 2 Aug 2005 06:09:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72D9Cus031902; Tue, 2 Aug 2005 06:09:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72D9A7c031649 for ; Tue, 2 Aug 2005 06:09:11 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so352676nzi for ; Tue, 02 Aug 2005 06:09:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=odsJmtuqdoUdQuLxS4O2SML9gIdyMRuNrmnteXavKq6U2uzZ+NbDitYg2vevmavt1NdHFc39LBcSzVi34t+zeL3DHDUL2a5Bn1M8YUtpO6GMofKntzjxkFuiUSS1x0eFMEGk2IDfv/6aXY7YIrZAgpSRm374MBh07fzI2IrIVoo= Received: by 10.36.220.40 with SMTP id s40mr6089214nzg; Tue, 02 Aug 2005 06:09:03 -0700 (PDT) Received: by 10.36.157.4 with HTTP; Tue, 2 Aug 2005 06:09:02 -0700 (PDT) Message-ID: <1f2ed5cd05080206095a60dbd@mail.gmail.com> Date: Tue, 2 Aug 2005 15:09:02 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: Introduction to The Atom Syndication Format Cc: atom-syntax@imc.org In-Reply-To: <42EEDCBF.6010405@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EEDCBF.6010405@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72D9B7c031860 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Looks great. My only suggestion would be to expose the MUSTs etc. little more, especially where Atom differees from RSS. E.g. right now it would be easy for someone coming from RSS 2.0 to think that was the same as . So in this case maybe: Identifies the feed in a universally unique and permanent way. => Identifies the feed in a universally unique and permanent way, using an IRI. or perhaps Identifies the feed in a universally unique and permanent way, according to rfc3987. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Aug 02 09:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwuI-0006S2-PY for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:34:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18959 for ; Tue, 2 Aug 2005 09:34:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DRVbl038709; Tue, 2 Aug 2005 06:27:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DRVPr038708; Tue, 2 Aug 2005 06:27:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72DRTYt038664 for ; Tue, 2 Aug 2005 06:27:30 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 13:27:23 -0000 Received: from pD95B7D02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp009) with SMTP; 02 Aug 2005 15:27:23 +0200 X-Authenticated: #1915285 Message-ID: <42EF74B9.3010705@gmx.de> Date: Tue, 02 Aug 2005 15:27:21 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Cerra CC: Ian Davis , Graham , =?ISO-8859-1?Q?=22Bill_de_=5C=22h=D3ra=5C=22=22?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802124008.87180.qmail@web42207.mail.yahoo.com> In-Reply-To: <20050802124008.87180.qmail@web42207.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Cerra wrote: >>Ian Davis wrote: >> >>>Graham wrote: >>>That to me is demonstrates a very clear intention of the working group >>>that the content must be exactly equal to the IRI. Changing this to >>>allow whitespace would represent a major technical change to the >>>format. I will figuratively lie down in the road if anyone suggests >>>whitespace should be allowed around any machine-read content (uris, >>>@type, @rel, etc). >> >>Leading and trailing whitespace should be stripped from the content of >>an atom:id element. >> >>The two examples that Bill gave WILL happen in the wild and Atom >>consumers will just deal with it by stripping the whitespace anyway >>despite what the spec says now. I think this should be endorsed in the >>spec for interoperability. > > > +1. But Sam Ruby's first draft at [1] demostrated more than just atom:id. (He > changed it now so that the examples don't have white space showing! lol!) They > also included things like: > > > http://example.com/ > > > > 2003-12-13T18:30:02Z > > > Neither of those are strictly legal, since white space is illegal in both IRI > and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer > used. Why would they be legal with the RNG grammar???? > ... Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Aug 02 09:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzwuI-0006S3-PZ for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:34:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18960 for ; Tue, 2 Aug 2005 09:34:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DTMne039365; Tue, 2 Aug 2005 06:29:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DTMTl039364; Tue, 2 Aug 2005 06:29:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72DTL5h039344 for ; Tue, 2 Aug 2005 06:29:21 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 58284 invoked from network); 2 Aug 2005 13:29:20 -0000 Received: from unknown (HELO ?172.30.2.20?) (unknown) by unknown with SMTP; 2 Aug 2005 13:29:20 -0000 X-pair-Authenticated: 62.172.77.82 Message-ID: <42EF752F.8090806@internetalchemy.org> Date: Tue, 02 Aug 2005 14:29:19 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> In-Reply-To: <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.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: Content-Transfer-Encoding: 7bit On 02/08/2005 14:11, Graham wrote: > I (and probably others) have already put code out into the wild in the > assumption there is no whitespace. As I said before, it's too late for > a solution that changes the meaning of the spec. Does your code reject the content of atom:id if it doesn't conform to the IRI spec? i.e. does it flag the feed as invalid. If so, then at least it mitigates the problem by reducing the number of feeds that will inadvertently include whitespace. If not, and you're treating the element content as opaque content, then you're going to be inadvertently processing invalid feeds. I guess the primary consequence is that your users are going to get duplicate items. Ian From owner-atom-syntax@mail.imc.org Tue Aug 02 09:43:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzx3b-0001R1-3B for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:43:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19506 for ; Tue, 2 Aug 2005 09:43:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DY5fN041094; Tue, 2 Aug 2005 06:34:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DY5Jj041093; Tue, 2 Aug 2005 06:34:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DY4IH041022 for ; Tue, 2 Aug 2005 06:34:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1227822wra for ; Tue, 02 Aug 2005 06:33:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b1tv/9x0mbYbXKcoJTbsVP/VxiGi12QG+LC7jzw/jqZ4Bqm5+0CIEroqiTHrp6voJBkImKECfPt+UrX+TAsIm8stDpywftfh8lYZifrwClynPDcsVo08kJIchxywHZYYozRZ3G0aO3zmYM6YoKn8W5e0+rU5ZjTbm+I1eGePYiA= Received: by 10.54.37.51 with SMTP id k51mr3542408wrk; Tue, 02 Aug 2005 06:33:58 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 2 Aug 2005 06:33:58 -0700 (PDT) Message-ID: <68fba5c50508020633663dadca@mail.gmail.com> Date: Tue, 2 Aug 2005 09:33:58 -0400 From: Robert Sayre Reply-To: Robert Sayre To: James Cerra Subject: Re: spec bug: can we fix for draft-11? Cc: Ian Davis , Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax In-Reply-To: <20050802124008.87180.qmail@web42207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <20050802124008.87180.qmail@web42207.mail.yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72DY4IH041073 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/2/05, James Cerra wrote: > Neither of those are strictly legal, since white space is illegal in both IRI > and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer > used. Yes, they are. Relax NG regex matching strips leading and trailing whitespace. Atom Processors will do the same, so we should fix it. "Comparison operations MUST be based solely on the IRI character strings", and the URI specs have always suggested that you should strip leading and trailing space. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 02 09:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxDn-0005RE-8n for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:54:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19990 for ; Tue, 2 Aug 2005 09:54:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DnUNb047227; Tue, 2 Aug 2005 06:49:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DnUwv047226; Tue, 2 Aug 2005 06:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DnTQs047213 for ; Tue, 2 Aug 2005 06:49:30 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j72DnLL4007501; Tue, 2 Aug 2005 09:49:22 -0400 (EDT) Message-ID: <42EF79E1.7060004@intertwingly.net> Date: Tue, 02 Aug 2005 09:49:21 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: James Cerra , Ian Davis , Graham , =?ISO-8859-1?Q?=22Bill_de_=5C=22h=D3ra=5C=22=22?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802124008.87180.qmail@web42207.mail.yahoo.com> <42EF74B9.3010705@gmx.de> In-Reply-To: <42EF74B9.3010705@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Symantec AntiVirus Scan Engine 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 ietf.org id JAA19990 Julian Reschke wrote: >=20 > James Cerra wrote: >=20 >>> Ian Davis wrote: >>> >>>> Graham wrote: >>>> That to me is demonstrates a very clear intention of the working gro= up >>>> that the content must be exactly equal to the IRI. Changing this to >>>> allow whitespace would represent a major technical change to the >>>> format. I will figuratively lie down in the road if anyone suggests >>>> whitespace should be allowed around any machine-read content (uris, >>>> @type, @rel, etc). >>> >>> Leading and trailing whitespace should be stripped from the content >>> of an atom:id element. >>> >>> The two examples that Bill gave WILL happen in the wild and Atom >>> consumers will just deal with it by stripping the whitespace anyway >>> despite what the spec says now. I think this should be endorsed in >>> the spec for interoperability. >> >> +1. But Sam Ruby's first draft at [1] demostrated more than just >> atom:id. (He >> changed it now so that the examples don't have white space showing! >> lol!) They >> also included things like: >> >> >> http://example.com/ >> >> >> >> 2003-12-13T18:30:02Z >> >> >> Neither of those are strictly legal, since white space is illegal in >> both IRI >> and RFC 3339 (dates) I think. However they are legal with the Relax >> NG grammer >> used. >=20 > Why would they be legal with the RNG grammar???? From : For all =B7atomic=B7 datatypes other than string (and types =B7derive= d=B7 by =B7restriction=B7 from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type =B7derived=B7 by =B7restriction=B7= from string the value of whiteSpace can be any of the three legal values. That being said, the RNC grammar for atom contains: atomId =3D element atom:id { atomCommonAttributes, (atomUri) } # Unconstrained; it's not entirely clear how IRI fit into # xsd:anyURI so let's not try to constrain it here atomUri =3D text - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 02 09:57:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxGe-00068k-Ea for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 09:57:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20198 for ; Tue, 2 Aug 2005 09:57:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72Dmwsd047021; Tue, 2 Aug 2005 06:48:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DmwwN047020; Tue, 2 Aug 2005 06:48:58 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j72DmuUH046976 for ; Tue, 2 Aug 2005 06:48:57 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 13:48:50 -0000 Received: from pD95B7D02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp010) with SMTP; 02 Aug 2005 15:48:50 +0200 X-Authenticated: #1915285 Message-ID: <42EF79BF.4080600@gmx.de> Date: Tue, 02 Aug 2005 15:48:47 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: James Cerra , Ian Davis , Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <20050802124008.87180.qmail@web42207.mail.yahoo.com> <68fba5c50508020633663dadca@mail.gmail.com> In-Reply-To: <68fba5c50508020633663dadca@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 8/2/05, James Cerra wrote: > >>Neither of those are strictly legal, since white space is illegal in both IRI >>and RFC 3339 (dates) I think. However they are legal with the Relax NG grammer >>used. > > > Yes, they are. Relax NG regex matching strips leading and trailing > whitespace. Atom Processors will do the same, so we should fix it. > "Comparison operations MUST be based solely on the IRI character > strings", and the URI specs have always suggested that you should > strip leading and trailing space. > > Robert Sayre Me confused. In atomDateConstruct = atomCommonAttributes, xsd:dateTime (), how exactly does this allow whitespace around the xsd:datetime value??? Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Aug 02 10:04:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxNR-0007Sy-3u for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:04:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20681 for ; Tue, 2 Aug 2005 10:04:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DuJu0049859; Tue, 2 Aug 2005 06:56:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72DuJIQ049858; Tue, 2 Aug 2005 06:56:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72DuJRj049845 for ; Tue, 2 Aug 2005 06:56:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j72DuGCA011340; Tue, 2 Aug 2005 09:56:16 -0400 (EDT) Message-ID: <42EF7B7F.6090906@intertwingly.net> Date: Tue, 02 Aug 2005 09:56:15 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> In-Reply-To: <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 2 Aug 2005, at 12:50 pm, Ian Davis wrote: > >> The two examples that Bill gave WILL happen in the wild and Atom >> consumers will just deal with it by stripping the whitespace anyway >> despite what the spec says now. I think this should be endorsed in >> the spec for interoperability. > > I (and probably others) have already put code out into the wild in the > assumption there is no whitespace. As I said before, it's too late for > a solution that changes the meaning of the spec. I have put code out in the wild based on the assumption that whitespace is not significant. One or more of us have a bug, and potentially the spec does too. Note: the code in the feedvalidators consists entirely of a single line, and that line was put in there intentionally, and test cases were coded to ensure that this code behaved as intended. Note: from an XML point of view, the following are all distinct: http://example.com http://example.com However, from the point of view of a tool that expects a xsd:anyURI, they are the same. I'm not yet sure what the right thing to do here is, but lets to do the right thing. Even if we decide that whitespace is not significant, I do believe that having the feedvalidator issue a warning in such cases is appropriate. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 02 10:04:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxNe-0007WL-8R for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:04:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20721 for ; Tue, 2 Aug 2005 10:04:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E0gNU052044; Tue, 2 Aug 2005 07:00:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72E0gEU052043; Tue, 2 Aug 2005 07:00:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72E0f8l051996 for ; Tue, 2 Aug 2005 07:00:41 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 14:00:31 -0000 Received: from xdsl-81-173-168-199.netcologne.de (EHLO klangraum) [81.173.168.199] by mail.gmx.net (mp016) with SMTP; 02 Aug 2005 16:00:31 +0200 X-Authenticated: #163624 Date: Tue, 2 Aug 2005 16:05:25 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050802140525.GA4929@klangraum> Mail-Followup-To: atom-syntax References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <51946.195.243.113.249.1122980097.squirrel@webmail.cat-proof.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51946.195.243.113.249.1122980097.squirrel@webmail.cat-proof.de> 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 ietf.org id KAA20721 * Sascha Carlin [2005-08-02 13:10]: > Agreed. Why not do it? Instead of >=20 > > some-uri > ... > >=20 > it could read >=20 > > ... > I have always wondered why it wasn=E2=80=99t done this way. Another reason this would have been good is that it would have enabled addressing specific entries in a feed document via a URI fragment. (Sure, the is an IRI, so the fragment would be verbose and would need escaping; but it would have been possible.) Maybe I should have spoken up before=E2=80=A6 I just assumed that There Are Sound Reasons for the design as chosen. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 02 10:04:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxNs-0007go-OV for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:04:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20761 for ; Tue, 2 Aug 2005 10:04:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E0jjT052067; Tue, 2 Aug 2005 07:00:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72E0jkM052066; Tue, 2 Aug 2005 07:00:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E0iNP052020 for ; Tue, 2 Aug 2005 07:00:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1232887wra for ; Tue, 02 Aug 2005 07:00:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JjcQ2KUg+PPntqiyoqo6sjH2YmzwbyXx/Q8xufpaUUMXnkyecGCe2IFlWuxYRt4NSr6f9gbsmlF91NED3qmJaAlQc+3xn/ZAPIDdPO6yqcr1tudmY9/xbyGd0YRydsii4txMCaI6teafEQEVdYO9LQN1plHs2vlzr37QTvUDkLg= Received: by 10.54.52.55 with SMTP id z55mr3175517wrz; Tue, 02 Aug 2005 07:00:39 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 2 Aug 2005 07:00:39 -0700 (PDT) Message-ID: <68fba5c50508020700164fa6e3@mail.gmail.com> Date: Tue, 2 Aug 2005 10:00:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Julian Reschke Subject: Re: spec bug: can we fix for draft-11? Cc: James Cerra , Ian Davis , Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax In-Reply-To: <42EF79BF.4080600@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <20050802124008.87180.qmail@web42207.mail.yahoo.com> <68fba5c50508020633663dadca@mail.gmail.com> <42EF79BF.4080600@gmx.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72E0iNP052059 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/2/05, Julian Reschke wrote: > Me confused. > > (), > how exactly does this allow whitespace around the xsd:datetime value??? http://lists.xml.org/archives/xml-dev/200309/msg00434.html I'm not an expert, but I verifed that it was happening here with Jing and nxml-mode. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 02 10:11:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxUI-0006pX-Tg for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:11:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21565 for ; Tue, 2 Aug 2005 10:11:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E62WN053184; Tue, 2 Aug 2005 07:06:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72E62pn053182; Tue, 2 Aug 2005 07:06:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E61pd053164 for ; Tue, 2 Aug 2005 07:06:01 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j72E5sL4025646; Tue, 2 Aug 2005 10:05:54 -0400 (EDT) Message-ID: <42EF7DC1.5080200@intertwingly.net> Date: Tue, 02 Aug 2005 10:05:53 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Robert Sayre , James Cerra , Ian Davis , Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <20050802124008.87180.qmail@web42207.mail.yahoo.com> <68fba5c50508020633663dadca@mail.gmail.com> <42EF79BF.4080600@gmx.de> In-Reply-To: <42EF79BF.4080600@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Robert Sayre wrote: > >> On 8/2/05, James Cerra wrote: >> >>> Neither of those are strictly legal, since white space is illegal in >>> both IRI >>> and RFC 3339 (dates) I think. However they are legal with the Relax >>> NG grammer >>> used. >> >> Yes, they are. Relax NG regex matching strips leading and trailing >> whitespace. Atom Processors will do the same, so we should fix it. >> "Comparison operations MUST be based solely on the IRI character >> strings", and the URI specs have always suggested that you should >> strip leading and trailing space. >> >> Robert Sayre > > Me confused. > > In > > atomDateConstruct = > atomCommonAttributes, > xsd:dateTime > > (), > how exactly does this allow whitespace around the xsd:datetime value??? Take a look at sections 3.2.7.6 and 4.3.6 of XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 02 10:18:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxb7-0005dk-Qx for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:18:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22471 for ; Tue, 2 Aug 2005 10:18:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72E7GqP053395; Tue, 2 Aug 2005 07:07:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72E7GBx053394; Tue, 2 Aug 2005 07:07:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72E7F53053380 for ; Tue, 2 Aug 2005 07:07:15 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 14:07:08 -0000 Received: from pD95B7D02.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.125.2] by mail.gmx.net (mp031) with SMTP; 02 Aug 2005 16:07:08 +0200 X-Authenticated: #1915285 Message-ID: <42EF7E09.3060109@gmx.de> Date: Tue, 02 Aug 2005 16:07:05 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: James Cerra , Ian Davis , Graham , =?ISO-8859-1?Q?=22Bill_de_=5C=22h=D3ra=5C=22=22?= , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802124008.87180.qmail@web42207.mail.yahoo.com> <42EF74B9.3010705@gmx.de> <42EF79E1.7060004@intertwingly.net> In-Reply-To: <42EF79E1.7060004@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ietf.org id KAA22471 Sam Ruby wrote: > ... >>Why would they be legal with the RNG grammar???? >=20 >=20 >>From : >=20 > For all =B7atomic=B7 datatypes other than string (and types =B7deri= ved=B7 by > =B7restriction=B7 from it) the value of whiteSpace is collapse and > cannot be changed by a schema author; for string the value of > whiteSpace is preserve; for any type =B7derived=B7 by =B7restrictio= n=B7 from > string the value of whiteSpace can be any of the three legal values. Thanks for the XML Schema lesson. I wasn't aware of that. > That being said, the RNC grammar for atom contains: >=20 > atomId =3D element atom:id { > atomCommonAttributes, > (atomUri) > } >=20 > # Unconstrained; it's not entirely clear how IRI fit into > # xsd:anyURI so let's not try to constrain it here > atomUri =3D text Well, *now* it seems that we really need to clarify. Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Aug 02 10:30:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxn2-0002Zd-4F for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:30:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24022 for ; Tue, 2 Aug 2005 10:30:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72EPdPw055310; Tue, 2 Aug 2005 07:25:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72EPdNE055309; Tue, 2 Aug 2005 07:25:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72EPbhW055298 for ; Tue, 2 Aug 2005 07:25:38 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 Aug 2005 14:25:29 -0000 Received: from xdsl-81-173-168-199.netcologne.de (EHLO klangraum) [81.173.168.199] by mail.gmx.net (mp006) with SMTP; 02 Aug 2005 16:25:29 +0200 X-Authenticated: #163624 Date: Tue, 2 Aug 2005 16:30:36 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050802143036.GB4929@klangraum> Mail-Followup-To: atom-syntax References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42EF7B7F.6090906@intertwingly.net> 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 ietf.org id KAA24022 * Sam Ruby [2005-08-02 16:05]: > I'm not yet sure what the right thing to do here is, but lets > to do the right thing. The spec as defined already leans in the direction of favouring simplicity in consumers in many areas, but does so particularly heavily when it comes to IDs. Cf. RECOMMENDED normalization and all. It seems natural to extend the assumptions about dumb clients that should be catered to by outlawing whitespace. I believe the spirit of the spec as it currently stands already outlaws whitespace. The spec just isn=E2=80=99t explicit about it, hence the problem we=E2=80=99re facing now. > Even if we decide that whitespace is not significant, I do > believe that having the feedvalidator issue a warning in such > cases is appropriate. Yes. At the very least, the normalization procedure that the spec RECOMMENDS should contain language about stripping surrounding whitespace. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 02 10:30:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxnC-0002iX-0x for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 10:30:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24037 for ; Tue, 2 Aug 2005 10:30:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72EP1Rr055253; Tue, 2 Aug 2005 07:25:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72EP1BY055252; Tue, 2 Aug 2005 07:25:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72EP0F0055228 for ; Tue, 2 Aug 2005 07:25:00 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 39172 messnum 5276189 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 14:24:54 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail04.svc.cra.dublin.eircom.net (qp 39172) with SMTP; 2 Aug 2005 14:24:54 -0000 Message-ID: <42EF8234.7050605@dehora.net> Date: Tue, 02 Aug 2005 15:24:52 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> In-Reply-To: <42EF7B7F.6090906@intertwingly.net> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Even if we decide that whitespace is not significant, I do believe that > having the feedvalidator issue a warning in such cases is appropriate. +1 cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 12:56:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0041-0004Jc-EJ for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 12:56:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05125 for ; Tue, 2 Aug 2005 12:56:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72GkvLW067088; Tue, 2 Aug 2005 09:46:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72Gkvwg067087; Tue, 2 Aug 2005 09:46:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72Gkuia067079 for ; Tue, 2 Aug 2005 09:46:57 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j72GkqL4001181; Tue, 2 Aug 2005 12:46:52 -0400 (EDT) Message-ID: <42EFA37F.70401@intertwingly.net> Date: Tue, 02 Aug 2005 12:46:55 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> In-Reply-To: <20050802143036.GB4929@klangraum> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: > > At the very least, the normalization procedure that the spec > RECOMMENDS should contain language about stripping surrounding > whitespace. I too would like to see that added to the recommended normalization rules in section 4.2.6. That would make my job easier if somebody were to challenge why I produced a warning in such a situation. As it stands now, the spec does NOT clearly outlaw leading and trailing whitespace from ids, and DOES require anybody the string to be kept character by character equivalent whenever an entry is "relocated, migrated, syndicated, republished, exported or imported". If Graham was truly serious about wanting to do his part[1] to ensure that atom:id is implemented properly, I would expect any atom:ids that he mints from here on out to contain leading and trailing spaces, tabs, and newlines (in a variety of Mac, DOS, and Unix styles). But I wouldn't recommend it. To me, doing so would be akin to mailing fragile equipment and paying for insurance, in the hopes of getting the opportunity to express indignation at the post office. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg16243.html From owner-atom-syntax@mail.imc.org Tue Aug 02 13:07:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00EK-00085a-6Y for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 13:07:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06092 for ; Tue, 2 Aug 2005 13:07:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72H26CH068808; Tue, 2 Aug 2005 10:02:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72H26Ep068807; Tue, 2 Aug 2005 10:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72H25I3068800 for ; Tue, 2 Aug 2005 10:02:06 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 12791 invoked from network); 2 Aug 2005 17:02:04 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 2 Aug 2005 17:02:04 -0000 Subject: Re: spec bug: can we fix for draft-11? From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Bill de =?ISO-8859-1?Q?h=D3ra?= Cc: atom-syntax In-Reply-To: <42EF8234.7050605@dehora.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <42EF8234.7050605@dehora.net> Content-Type: text/plain; charset=utf-8 Date: Tue, 02 Aug 2005 18:02:03 +0100 Message-Id: <1123002123.3401.13.camel@marge> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) 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 ietf.org id NAA06092 On Tue, 2005-08-02 at 15:24 +0100, Bill de h=C3=93ra wrote: > Sam Ruby wrote: >=20 > > Even if we decide that whitespace is not significant, I do believe th= at > > having the feedvalidator issue a warning in such cases is appropriate. >=20 > +1 What is the IETF version of an errata sheet? Is that the right place to tackle this? I'm with Bill, I'm sure we'll see many instances which have whitespace included, with a simplistic assumption that the element contains an IRI, and nothing more. James makes a good point about whitespace stripping in=20 the other elements. Looking at http://relaxng.org/spec-20011203.html The anyURI symbol has the same meaning as the anyURI datatype of [W3C XML Schema Datatypes]: it indicates a string that, after escaping of disallowed values as described in Section 5.4 of [XLink], is a URI reference as defined in [RFC 2396] (as modified by [RFC 2732]). I can't see how the anyURI fits with element content; all the examples I've seen use it as an attribute value which I think is clearer due to XML 1.0 regards DaveP From owner-atom-syntax@mail.imc.org Tue Aug 02 13:09:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Gu-0003gp-Hi for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 13:09:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06202 for ; Tue, 2 Aug 2005 13:09:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72H3AjQ068998; Tue, 2 Aug 2005 10:03:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72H3AqZ068997; Tue, 2 Aug 2005 10:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72H38nw068896 for ; Tue, 2 Aug 2005 10:03:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so1208610wra for ; Tue, 02 Aug 2005 10:03:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HFOrXfdB1QXx9qkXadeK6FHnseU8cxxkilzS6UblAn2OUqlhT9X5zkAtusGZOaPYI7H9dWLaywNEjuJ0Vd+DPAKEgFxPNC2xZ0eaezdFOFfsXWWQ239PhEsFI4eA70li12UbaGhdfw03h3AVa+mYVC+CXXYp1nj+DfffaWNiw9M= Received: by 10.54.116.20 with SMTP id o20mr3893773wrc; Tue, 02 Aug 2005 10:02:38 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 2 Aug 2005 10:02:38 -0700 (PDT) Message-ID: <68fba5c5050802100246a8a8ad@mail.gmail.com> Date: Tue, 2 Aug 2005 13:02:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax , Mark Nottingham , Tim Bray , Paul Hoffman Subject: round 2: Proposed Changes for format-11 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72H38nw068978 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The diffs linked below should reflect comments on the first round. No effort has been made to resolve the ambiguity discovered around leading and trailing whitespace. Awaiting chairs' instructions for that. http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11-from-10.diff.html http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.html http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 02 13:16:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00NZ-0006xl-D0 for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 13:16:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06455 for ; Tue, 2 Aug 2005 13:16:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72HBj2H069973; Tue, 2 Aug 2005 10:11:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72HBjmk069972; Tue, 2 Aug 2005 10:11:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72HBiFA069960 for ; Tue, 2 Aug 2005 10:11:44 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 02 Aug 2005 17:11:38 -0000 Received: from dsl-084-056-236-117.arcor-ip.net (EHLO localhost) [84.56.236.117] by mail.gmx.net (mp006) with SMTP; 02 Aug 2005 19:11:38 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: davep@dpawson.co.uk Cc: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 02 Aug 2005 19:11:33 +0200 Message-ID: <42ffa914.480621890@smtp.bjoern.hoehrmann.de> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <42EF8234.7050605@dehora.net> <1123002123.3401.13.camel@marge> In-Reply-To: <1123002123.3401.13.camel@marge> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id NAA06455 * Dave Pawson wrote: >> > Even if we decide that whitespace is not significant, I do believe t= hat >> > having the feedvalidator issue a warning in such cases is appropriat= e. >>=20 >> +1 > >What is the IETF version of an errata sheet? Is that the right >place to tackle this? For RFCs see . --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Tue Aug 02 13:36:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00hE-0005lF-Tz for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 13:36:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07516 for ; Tue, 2 Aug 2005 13:36:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72HWcfS071971; Tue, 2 Aug 2005 10:32:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72HWcZc071970; Tue, 2 Aug 2005 10:32:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72HWaHI071962 for ; Tue, 2 Aug 2005 10:32:37 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 28084 invoked from network); 2 Aug 2005 17:32:36 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 2 Aug 2005 17:32:36 -0000 Subject: Re: spec bug: can we fix for draft-11? From: Dave Pawson Reply-To: davep@dpawson.co.uk To: atom-syntax In-Reply-To: <42ffa914.480621890@smtp.bjoern.hoehrmann.de> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <42EF8234.7050605@dehora.net> <1123002123.3401.13.camel@marge> <42ffa914.480621890@smtp.bjoern.hoehrmann.de> Content-Type: text/plain Date: Tue, 02 Aug 2005 18:32:14 +0100 Message-Id: <1123003934.3401.22.camel@marge> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2005-08-02 at 19:11 +0200, Bjoern Hoehrmann wrote: > For RFCs see . Thanks. Just playing. With schema The example below parses well with James Clarks relax tools and the sun validator. http://example.com http://www.example.com regards DaveP From owner-atom-syntax@mail.imc.org Tue Aug 02 14:00:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0148-0006Ol-IX for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 14:00:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08646 for ; Tue, 2 Aug 2005 14:00:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72HqTa3073940; Tue, 2 Aug 2005 10:52:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72HqTiE073939; Tue, 2 Aug 2005 10:52:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72HqS3L073932 for ; Tue, 2 Aug 2005 10:52:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id B3A4E106DA; Tue, 2 Aug 2005 18:52:25 +0100 (BST) In-Reply-To: <42EFA37F.70401@intertwingly.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 2 Aug 2005 18:52:21 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote: > As it stands now, the spec does NOT clearly outlaw leading and > trailing > whitespace from ids > I've been trying to argue with this but I can't find a normative reference that explains what the "content" of an element is. This is perhaps a bigger problem. Graham From owner-atom-syntax@mail.imc.org Tue Aug 02 16:12:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E038E-00057c-Jb for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 16:12:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15264 for ; Tue, 2 Aug 2005 16:12:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72K7c4M088103; Tue, 2 Aug 2005 13:07:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72K7cKJ088102; Tue, 2 Aug 2005 13:07:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72K7brc088095 for ; Tue, 2 Aug 2005 13:07:37 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1427956wra for ; Tue, 02 Aug 2005 13:07:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=artFWHFWlJOCFk2oeyeueEEGBOsWBJJLpXDethp7p04WyfHiQSbQYtAQzpFbfE9PqzIohAnwBtfNwx04+W9OxSiQtZu8ER+rsa1Vwl0H1tnnog6dkD2EReFEP77AnaTnDA8M3h2ApRo41r/drrng7pHUCQd5/PPbltEV8SA2cXY= Received: by 10.54.18.2 with SMTP id 2mr4052706wrr; Tue, 02 Aug 2005 13:07:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 2 Aug 2005 13:07:31 -0700 (PDT) Message-ID: <68fba5c505080213075dea847@mail.gmail.com> Date: Tue, 2 Aug 2005 16:07:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: spec bug: can we fix for draft-11? Cc: Sam Ruby , atom-syntax In-Reply-To: <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72K7brc088097 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/2/05, Graham wrote: > > On 2 Aug 2005, at 5:46 pm, Sam Ruby wrote: > > > > As it stands now, the spec does NOT clearly outlaw leading and > > trailing > > whitespace from ids > > > > I've been trying to argue with this but I can't find a normative > reference that explains what the "content" of an element is. This is > perhaps a bigger problem. Depends how deeply we want to naval gaze. The normative Infoset term would be "children", but that includes lots of things we don't care about. For example, text constructs with a type attribute of "xhtml" are supposed to a single div as their content. An XML handler listening closely would notice whitespace characters before and after the divs in the examples. It's my belief that the "character-by-character" comparison mentioned in the atom:id section could reference section "6.2.1. Simple String Comparison" in RFC3986. In fact, it's a MUST-level requirement of RFC3987 that they be compared that way. Of course, these comparisons are based on having a URI/IRI to begin with, and URI/IRIs don't begin with whitespace. For me, the most disturbing aspect of this debate is that any resolution will provide very, very little interoperability gain. URIs, like XML Elements, cannot begin or end with whitespace. I don't believe it's worth mentioning in the spec, and I think we're off in the weeds. That said, I certainly wouldn't object to any text warning people not to do it, or explicitly mentioning that you have to call the equivalent of String.trim(). Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 02 16:48:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E03h3-0006Sd-2Z for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 16:48:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16774 for ; Tue, 2 Aug 2005 16:48:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72Khwpp090643; Tue, 2 Aug 2005 13:43:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72KhwiY090642; Tue, 2 Aug 2005 13:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j72KhvLj090631 for ; Tue, 2 Aug 2005 13:43:58 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 86677 messnum 2897565 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 2 Aug 2005 20:43:51 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail07.svc.cra.dublin.eircom.net (qp 86677) with SMTP; 2 Aug 2005 20:43:51 -0000 Message-ID: <42EFDB03.1060604@dehora.net> Date: Tue, 02 Aug 2005 21:43:47 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> In-Reply-To: <68fba5c505080213075dea847@mail.gmail.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > For me, the most disturbing aspect of this debate is that any > resolution will provide very, very little interoperability gain. URIs, > like XML Elements, cannot begin or end with whitespace. I don't > believe it's worth mentioning in the spec, and I think we're off in > the weeds. That said, I certainly wouldn't object to any text warning > people not to do it, or explicitly mentioning that you have to call > the equivalent of String.trim(). I respectfully disagree. After a day's worth of posting, no-one here has been able to present a compelling argument one way or another as to whether urn:example.org is illegal and if so, how software should behave in the light of that. Mentioning things like this the why Atom has to exist at all, imvho. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 02 17:25:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04GS-0004Sl-3S for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 17:25:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18045 for ; Tue, 2 Aug 2005 17:25:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72LK1PT094269; Tue, 2 Aug 2005 14:20:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72LK1ah094268; Tue, 2 Aug 2005 14:20:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72LK0hx094243 for ; Tue, 2 Aug 2005 14:20:00 -0700 (PDT) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by ptb-relay01.plus.net with esmtp (Exim) id 1E04Ay-00026f-F0 for atom-syntax@imc.org; Tue, 02 Aug 2005 22:19:53 +0100 To: atom-syntax@imc.org (Atom Syntax) In-Reply-To: <68fba5c5050802100246a8a8ad@mail.gmail.com> Subject: Re: round 2: Proposed Changes for format-11 From: pmrobinson@gmx.net (Peter Robinson) Date: Tue, 2 Aug 2005 22:19:51 +0100 Message-ID: <1h0otag.5zw1hw27w3r1M%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.9) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Robert Sayre wrote: > The diffs linked below should reflect comments on the first round. A few more minor nits I'm afraid. (I don't think I've seen these discussed before.) > http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt | Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also | an IRI, so a URI may be used wherever below an IRI is named. s/ below// You've replaced 'is needed.' with 'is named.' in the last clause. I'm not sure that's an improvement, or what was wrong with 'is needed.' in the first place. But if you don't like that, what about 'is required.' or 'is called for.'? You've also replaced 'a URI can' with 'a URI may'. Do you mean 'a URI MAY'? I suppose it depends on whether you see that sentence as a statement of fact or as part of the spec. Regards, Peter From owner-atom-syntax@mail.imc.org Tue Aug 02 17:27:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04I5-0004uU-G8 for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 17:27:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18136 for ; Tue, 2 Aug 2005 17:27:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72LNSwn094495; Tue, 2 Aug 2005 14:23:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72LNSc6094494; Tue, 2 Aug 2005 14:23:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72LNSIP094485 for ; Tue, 2 Aug 2005 14:23:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id E3FDC106DA; Tue, 2 Aug 2005 22:23:25 +0100 (BST) In-Reply-To: <68fba5c505080213075dea847@mail.gmail.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 2 Aug 2005 22:23:21 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote: > For me, the most disturbing aspect of this debate is that any > resolution will provide very, very little interoperability gain. Agreed. All we need to do is decide one way or the other what the spec should say. > That said, I certainly wouldn't object to any text warning > people not to do it, or explicitly mentioning that you have to call > the equivalent of String.trim(). Recommending the former would draw attention to the issue and perhaps encourage the latter. (Or make both explicit, with SHOULD and MAY). Graham From owner-atom-syntax@mail.imc.org Tue Aug 02 19:48:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E06UK-0008I2-SD for atompub-archive@megatron.ietf.org; Tue, 02 Aug 2005 19:48:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25717 for ; Tue, 2 Aug 2005 19:47:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72NbY57005687; Tue, 2 Aug 2005 16:37:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j72NbYEh005686; Tue, 2 Aug 2005 16:37:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j72NbXFu005675 for ; Tue, 2 Aug 2005 16:37:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so5404wra for ; Tue, 02 Aug 2005 16:37:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M0FEhPwc8VXVveVLXEi3QvzP/fOMAc7p53WevRTtUAEZ8LKe6O8iCt9A5Qh9Y9xH60tMySIjh9uErD4r/5Wr5d4J2Sv9SjIsODxAviC/zkcvixbYua3THK3HO9A9caQMCZEuuEZTFAsDHGGfkJRwCU8bXRBAB0I5OVkevPX8Vj4= Received: by 10.54.116.12 with SMTP id o12mr58626wrc; Tue, 02 Aug 2005 16:37:28 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 2 Aug 2005 16:37:26 -0700 (PDT) Message-ID: <68fba5c505080216371c20f5b3@mail.gmail.com> Date: Tue, 2 Aug 2005 19:37:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: spec bug: can we fix for draft-11? Cc: atom-syntax In-Reply-To: <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j72NbYFu005681 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/2/05, Graham wrote: > On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote: > > > For me, the most disturbing aspect of this debate is that any > > resolution will provide very, very little interoperability gain. > > Agreed. All we need to do is decide one way or the other what the > spec should say. Right. This is not a big deal. Since everyone but me seems to think it needs fixing, let's do so. > > That said, I certainly wouldn't object to any text warning > > people not to do it, or explicitly mentioning that you have to call > > the equivalent of String.trim(). > > Recommending the former would draw attention to the issue and perhaps > encourage the latter. (Or make both explicit, with SHOULD and MAY). One way of saying this would be "Atom Processors MAY ignore leading and trailing whitespace in _____________." That is, no existing software is buggy, but if you want to be sure your document is processed accurately, you should trim the space yourself. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Aug 03 00:21:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0AlE-0002Tx-Nx for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 00:21:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06241 for ; Wed, 3 Aug 2005 00:21:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j734Fg6m035815; Tue, 2 Aug 2005 21:15:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j734Fg3S035814; Tue, 2 Aug 2005 21:15:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j734FfgC035807 for ; Tue, 2 Aug 2005 21:15:41 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j734Ffr3000578 for ; Tue, 2 Aug 2005 22:15:41 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKM00MDDP64L6@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 02 Aug 2005 22:15:41 -0600 (MDT) Received: from [192.168.1.100] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKM0038ZP63YO@mail.sun.net> for atom-syntax@imc.org; Tue, 02 Aug 2005 22:15:40 -0600 (MDT) Date: Tue, 02 Aug 2005 21:15:54 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <68fba5c505080216371c20f5b3@mail.gmail.com> To: Robert Sayre Cc: Graham , atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: > One way of saying this would be "Atom Processors MAY ignore leading > and trailing whitespace in _____________." That is, no existing > software is buggy, but if you want to be sure your document is > processed accurately, you should trim the space yourself. Ecch. Blecch. Barf. I suppose. I personally think the framework of specifications is crystal-clear, and per the letter of the law http://example.com/foo is totally illegal because the string \nhttp://example.com/foo\n does not conform to the productions for either URI or IRI. I am less convinced that people are actually going to do this, but I do agree that if a substantial number *do* do this, implementors will simply ignore us and code around it. So if the WG really thinks this is a sensible clarification I won't scream too much. -Tim From owner-atom-syntax@mail.imc.org Wed Aug 03 05:08:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0FEa-0004WE-Uj for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 05:08:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26708 for ; Wed, 3 Aug 2005 05:08:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7390830035696; Wed, 3 Aug 2005 02:00:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j739086a035695; Wed, 3 Aug 2005 02:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j73906YY035644 for ; Wed, 3 Aug 2005 02:00:07 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 Aug 2005 09:00:00 -0000 Received: from xdsl-81-173-168-117.netcologne.de (EHLO klangraum) [81.173.168.117] by mail.gmx.net (mp023) with SMTP; 03 Aug 2005 11:00:00 +0200 X-Authenticated: #163624 Date: Wed, 3 Aug 2005 11:05:28 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050803090528.GA24396@klangraum> Mail-Followup-To: atom-syntax References: <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id FAA26708 * Tim Bray [2005-08-03 06:30]: > I personally think the framework of specifications is > crystal-clear, and per the letter of the law >=20 > > http://example.com/foo > >=20 > is totally illegal because the string > \nhttp://example.com/foo\n does not conform to the productions > for either URI or IRI. That is the way I thought of it also. > I am less convinced that people are actually going to do this, > but I do agree that if a substantial number *do* do this, > implementors will simply ignore us and code around it. So if > the WG really thinks this is a sensible clarification I won't > scream too much. I would say the fact that we=E2=80=99ve had a three-day, 40-message thread about what the spec really says here is sufficient precedent to conclude that this needs to be explicit. The ambivalent comment in the relevant section of the RNC grammar is not helping matters either; that one *must* be fixed, informal or no. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Aug 03 06:45:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gkm-00025g-J4 for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 06:45:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03933 for ; Wed, 3 Aug 2005 06:45:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73Abk6I072499; Wed, 3 Aug 2005 03:37:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73AbkVP072497; Wed, 3 Aug 2005 03:37:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hermes-ldn.macmillan.co.uk (hermes-ldn.macmillan.co.uk [194.129.50.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73Abj0V072455 for ; Wed, 3 Aug 2005 03:37:45 -0700 (PDT) (envelope-from T.Hammond@nature.com) Received: from uk1apps2.mpl.root-domain.org (172.25.0.10) by hermes-ldn.macmillan.co.uk with ESMTP; 03 Aug 2005 11:37:39 +0100 X-IronPort-AV: i="3.95,163,1120431600"; d="scan'208"; a="55274197:sNHT14329436" Received: by UK1APPS2.mpl.root-domain.org with Internet Mail Service (5.5.2653.19) id <33LFL1LD>; Wed, 3 Aug 2005 11:37:39 +0100 Message-ID: <125F7834E11A5741A7D79412EE3504F91D08C898@UK1APPS2.mpl.root-domain.org> From: "Hammond, Tony" To: Sam Ruby Cc: atom-syntax@imc.org Subject: RE: Introduction to The Atom Syndication Format Date: Wed, 3 Aug 2005 11:37:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Sam: This is very a nice summary. Would just query the words: "If you own your own Internet domain," Was my understanding that domain names were leased, not owned. One of the Internet's dirty little secrets. Cheers, Tony > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Danny Ayers > Sent: 02 August 2005 14:09 > To: Sam Ruby > Cc: atom-syntax@imc.org > Subject: Re: Introduction to The Atom Syndication Format > > > > Looks great. > > My only suggestion would be to expose the MUSTs etc. little > more, especially where Atom differees from RSS. E.g. right > now it would be easy for someone coming from RSS 2.0 to think > that was the same as . > > So in this case maybe: > Identifies the feed in a universally unique and permanent > way. => Identifies the feed in a universally unique and > permanent way, using an IRI. or perhaps Identifies the feed > in a universally unique and permanent way, according to rfc3987. > > Cheers, > Danny. > > > -- > > http://dannyayers.com > ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** From owner-atom-syntax@mail.imc.org Wed Aug 03 09:12:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0J3H-0000xb-T2 for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 09:12:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13957 for ; Wed, 3 Aug 2005 09:12:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73D4sDr026751; Wed, 3 Aug 2005 06:04:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73D4sa5026750; Wed, 3 Aug 2005 06:04:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73D4q83026731 for ; Wed, 3 Aug 2005 06:04:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [172.28.173.59] ([12.154.211.2]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j73DBnCf007216; Wed, 3 Aug 2005 09:11:49 -0400 Message-ID: <42F0C0C6.8090802@intertwingly.net> Date: Wed, 03 Aug 2005 09:04:06 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Robert Sayre , Graham , atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote: > >> One way of saying this would be "Atom Processors MAY ignore leading >> and trailing whitespace in _____________." That is, no existing >> software is buggy, but if you want to be sure your document is >> processed accurately, you should trim the space yourself. > > Ecch. Blecch. Barf. I think we all feel that way. > I suppose. That way too. > I personally think the framework of specifications is crystal-clear, > and per the letter of the law > > > http://example.com/foo > > > is totally illegal because the string \nhttp://example.com/foo\n does > not conform to the productions for either URI or IRI. As Graham noted, the issue is that differing persons approach this with differing notions of what the term "content" means in this context. "Document" and "Data" people approach these things with different filters. To an Infoset person, this following is a completely different stream from the example above (please ignore any line breaks that your email client may insert): http://example.com/foo Infoset views the below two examples as different: http://example.com/foo RelaxNG views all of the above as the same. > I am less convinced that people are actually going to do this, but I do > agree that if a substantial number *do* do this, implementors will > simply ignore us and code around it. So if the WG really thinks this > is a sensible clarification I won't scream too much. -Tim The reason that one line of code exists in the feedvalidator is because somebody did do it, existing feed readers supported it, and I couldn't defend the statement that the RSS 2.0 spec unambiguously prohibited it. A note that Atom processors may consider leading and trailing space as significant in attribute and element values would be enough to alert people to the interoperability issues. Disallowing leading and trailing whitespace in IRI references (including the isegment-nz-nc production), MIME media types, language tags, lengths, addr-spec, and date-time productions would lead to improved interoperability. I'm fine with either. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Aug 03 09:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0J9U-0005Ic-UT for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 09:19:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14737 for ; Wed, 3 Aug 2005 09:19:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73DBtR1029329; Wed, 3 Aug 2005 06:11:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73DBt1A029328; Wed, 3 Aug 2005 06:11:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73DBt0r029307 for ; Wed, 3 Aug 2005 06:11:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [8`@IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id 2E828106DA; Wed, 3 Aug 2005 14:11:51 +0100 (BST) In-Reply-To: <42F0C0C6.8090802@intertwingly.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <42F0C0C6.8090802@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <165560CE-6EBF-40CA-B4C6-9684D87F60FE@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Wed, 3 Aug 2005 14:11:48 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Aug 2005, at 2:04 pm, Sam Ruby wrote: > A note that Atom processors may consider leading and trailing space as > significant in attribute and element values would be enough to alert > people to the interoperability issues. > +1 Graham From owner-atom-syntax@mail.imc.org Wed Aug 03 14:40:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0OAJ-0000ss-VW for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 14:40:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05818 for ; Wed, 3 Aug 2005 14:40:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73IWM1m073354; Wed, 3 Aug 2005 11:32:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73IWMVc073353; Wed, 3 Aug 2005 11:32:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73IWLn1073343 for ; Wed, 3 Aug 2005 11:32:22 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so23779wra for ; Wed, 03 Aug 2005 11:32:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=ZIdVbuLtfmXxur6RE2pKVUtMfi/linYyDPEpfCsZeYz8ayc88bssotaSKDGn1yvyfR7h5G1+lxoXL7KPd/8T5uXSRatej2GlmHN9gmqlxQ6shUwc+W2bozx9hdWZBcWIwkixnN6POn5ZTUKH5VFgThqXZV2ujFjZJgmpRZCOTP4= Received: by 10.54.31.63 with SMTP id e63mr823337wre; Wed, 03 Aug 2005 11:32:13 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 65sm906578wra.2005.08.03.11.31.32; Wed, 03 Aug 2005 11:32:13 -0700 (PDT) Message-ID: <42F10D7F.4050509@gmail.com> Date: Wed, 03 Aug 2005 11:31:27 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: FYI: An Overview of the Atom 1.0 Syndication Format 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: Content-Transfer-Encoding: 7bit Published yesterday on developerWorks. http://www-128.ibm.com/developerworks/xml/library/x-atom10.html Comments welcome.. I'll publish clarifications/corrections on my developerWorks blog. From owner-atom-syntax@mail.imc.org Wed Aug 03 21:45:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Unt-0004F7-Ny for atompub-archive@megatron.ietf.org; Wed, 03 Aug 2005 21:45:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01705 for ; Wed, 3 Aug 2005 21:45:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j741blw3006008; Wed, 3 Aug 2005 18:37:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j741blqq006007; Wed, 3 Aug 2005 18:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j741bkcH005999 for ; Wed, 3 Aug 2005 18:37:46 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.173.134]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 7BED1A34CD; Wed, 3 Aug 2005 21:37:44 -0400 (EDT) In-Reply-To: References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4792A3DA-2154-40DB-AC70-E958E58749E3@mnot.net> Cc: Robert Sayre , Graham , atom-syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: spec bug: can we fix for draft-11? Date: Wed, 3 Aug 2005 18:37:38 -0700 To: Tim Bray X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 02/08/2005, at 9:15 PM, Tim Bray wrote: > So if the WG really thinks this is a sensible clarification I won't > scream too much. It's probably necessary any way, because RFC3470/BCP70 Section 4.16 encourages specs to give guidelines about white space; > Implementers might safely assume that they can ignore the white > space > in the example above, but white space used for pretty-printing > can be > a source of confusion in other situations. Consider a minor change > to the element: > > > 10.1.2.3 > > > where white space is found on both sides of the IP address. XML > processors treat the white space surrounding "10.1.2.3" as an > integral part of the element. A failure to recognize this > behavior can lead to confusion and errors in both design and > implementation. > > All white space is considered significant in XML instances. As a > consequence, it is recommended that protocol designers provide > specific guidelines to address white space handling within > protocols > that use XML. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 04 00:33:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0XQA-00055R-AJ for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 00:33:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07580 for ; Thu, 4 Aug 2005 00:33:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j744RZEO019099; Wed, 3 Aug 2005 21:27:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j744RZJN019098; Wed, 3 Aug 2005 21:27:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j744RYbR019091 for ; Wed, 3 Aug 2005 21:27:34 -0700 (PDT) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j744RWpx008614; Wed, 3 Aug 2005 21:27:32 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Aug 2005 21:27:32 -0700 Received: from [172.16.1.2] ([172.24.28.105]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Aug 2005 21:27:31 -0700 In-Reply-To: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> Cc: Eric Scheid , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -02 Date: Wed, 3 Aug 2005 21:27:29 -0700 To: Henry Story X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 04 Aug 2005 04:27:31.0185 (UTC) FILETIME=[D4333610:01C598AC] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.7.29.22 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit So, if I read you correctly, it sounds like you have a method whereby a 'top20' feed wouldn't need history:prev to give the kind of history that you're thinking of, right? If that's the case, I'm tempted to just tweak the draft so that history:stateful is optional if history:prev is present. I was considering dropping stateful altogether, but I think something is necessary to explicitly say "don't try to keep a history of my feed." My latest use case for this is the RSS feed that Netflix provides to let you keep an eye on your queue (sort of like top20, but more specialised). Sound good? On 29/07/2005, at 6:39 AM, Henry Story wrote: > > Below I think I have worked out how one can in fact have a top20 > feed, and > I show how this can be combined without trouble with the > > link... > > > On 29 Jul 2005, at 13:12, Eric Scheid wrote: > >> >> On 29/7/05 7:57 PM, "Henry Story" wrote: >> >> >> >>> 1- The top 20 list: here one wants to move to the previous top >>> 20 list and >>> think of them as one thing. The link to the next feed is not >>> meant to be >>> additive. Each feed is to be seen as a whole. I have a little >>> trouble still >>> thinking of these as feeds, but ... >>> >>> >> >> What happens if the publisher realises they have a typo and need >> to emit an >> update to an entry? Would the set of 20 entries (with one entry >> updated) be >> seen as a complete replacement set? >> > > Well if it is a typo and this is considered to be an insignificant > change then > they can change the typo in the feed document and not need to > change any updated > time stamps. > > >> The way I see it, maybe a better way would be to have a sliding >> window feed >> where each entry points to another Atom Feed Document with it's >> own URI, and >> it is that second Feed Document which contains the individual >> items (the top >> 20 list). >> > > This is certainly closer to my intuitions too. A top 20 something > is *not* a feed. > Feed entries are not ordered, and are not meant to be thought of > as a closed > collection. At least this is my initial intuition. BUT.... > > I can think of a solution like the following: Let us imagine a top > 20 feed where > the resources being described by the entries are the position in > the top list. So > we have entries with ids such as > > http://TopOfThePops.co.uk/top20/Number1 > http://TopOfThePops.co.uk/top20/Number2 > http://TopOfThePops.co.uk/top20/Number3 > ... > > Each of these resources describes the songs that is at a certain > rank in the top of > the pops chart. Each week the song in that rank may change. When a > change occurs in the > song at a certain rank the top 20 feed with id > > http://TopOfThePops.co.uk/top20/Feed > > will contain a new entry such as > > > Top of the pops entry number 1 > > http://TopOfThePops.co.uk/top20/Number1 > 2005-07-05T18:30:00Z > Top of the pops winner for the week starting 5 July > 2005 > > > A client that would subscribe to such a feed would automatically > get updates every > week for each of the top 20 resources. But the feed could be > structured exactly like > I suggest in 2. > > So for a top 2 feed (20 is a bit to long for me) > > > My top 2 Software Books > http://bblfish.net/blog/top2 > http://bblfish.net/blog/top2/ > Archive-2005-07-18.atom > ... > > My Top 1 book > > http://bblfish.net/blog/top2/Number1 > 2005-07-25T18:30:00Z > My top 1 book is Service Oriented Computing by Wiley summary> > > > My Top 2 book > > http://bblfish.net/blog/top2/Number2 > 2005-07-25T18:30:00Z > My second top book is "xml in a Nutshell" > > > > The above representation of the http://bblfish.net/blog/top2 feed > points to the > archive feed http://bblfish.net/blog/top2/Archive-2005-07-18.atom > > > My top 2 Software Books > http://bblfish.net/blog/top2 > ... > > My Top 1 book > > http://bblfish.net/blog/top2/Number1 > 2005-07-18T18:30:00Z > My top 1 book is Java 2D Graphics > > > My Top 2 book > > http://bblfish.net/blog/top2/Number2 > 2005-07-18T18:30:00Z > My second top book is "xml in a Nutshell" > > > > As you notice only the top1 has changed from the first week but > not the > second, and yet in both feeds there is an entry for both. A non > change can > sometimes be an important event. But this is really up to the feed > creator > to choose how to present his feeds. He could easily have had only > had the > entry for http://bblfish.net/blog/top2/Number1 in the first feed. > > Looking at it this way, there really seems to be no incompatibility > between > a top 20 feed and the link. My talk about > archives not > changing should be more precisely about archives not changing in any > significant way. And this advice could be moved to an implementors > section > and be encoded in HTTP by simply giving archive pages an infinitely > long > expiry date. > > >> Someone could subscribe to that second feed and poll for updates, >> and all >> they'll ever see are updates to the 20 items there, not the 20 >> items from >> the next week/whatever. >> >> The idea of feeds linked to feeds has lots of utility -- feeds of >> comments >> for one, and even a feed of feeds available on the site. >> > > I completely agree. And remember for any two things there is at > least one way they > are related. And there are many different ways feeds can be related > to each other. > A feed may be an archival continuation of one - which is what the > > link in my opinion addresses, but there are many other ways one can > relate feeds. > > > >> For example: this HTML page has an >> equivalent >> feed document , where >> each item >> links to the individual feeds for each publication. That feed >> doesn't update >> often, mostly because NPG doesn't add many new feeds to their site >> all that >> often. The URIs the entries of that feed link to are redirected to >> the >> permanent URIs of the current issue (each issue has it's own feed >> which is >> the table of contents for that issue, with a distinct and separate >> URI for >> each issue). >> > > Yes a feed can itself be an entry in another feed. > > >> It's conceivable they could also provide a feed for each publication >> pointing to the table of contents feeds of each issue. That is, a >> feed with >> an entry for each issue. >> > > yes. > > >> Of the above, the mechanism of a single URI which redirects to the >> current >> issue is a situation which would still need a flag indicating that >> the >> appropriate thing to do is to not persist older entries. >> > > I am starting to wonder whether this is really needed now that I > have looked > at the top20 example I gave above. > > >> >> The other structure of feeds linking to feeds would require the >> aggregator >> be able to do something useful with such links, but this can be >> generalised >> and thus be useful for many purposes. As it is, right now with NNW >> I can do >> something useful with such a feed: drag & drop the item headline >> link to my >> subscriptions pane to subscribe to that feed and view the entries >> therein. >> > > I myself have no problem with feeds being entries, feeds pointing > to other > feeds, or anything like that. A feed is a resource. It can change. > A feed > is simply a set of state changes to resources. It is that general. > > >> >> Both require coding effort. >> >> e. >> >> > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Thu Aug 04 05:42:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cF3-0005V0-Vz for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 05:42:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16952 for ; Thu, 4 Aug 2005 05:42:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j749Y6hv032670; Thu, 4 Aug 2005 02:34:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j749Y6wE032669; Thu, 4 Aug 2005 02:34:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j749Y4A9032611 for ; Thu, 4 Aug 2005 02:34:05 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29140 messnum 5275363 invoked from network[213.94.211.166/mail2.newbay.com]); 4 Aug 2005 09:33:58 -0000 Received: from mail2.newbay.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 29140) with SMTP; 4 Aug 2005 09:33:58 -0000 Message-ID: <42F1E105.8070308@dehora.net> Date: Thu, 04 Aug 2005 10:33:57 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <42F0C0C6.8090802@intertwingly.net> In-Reply-To: <42F0C0C6.8090802@intertwingly.net> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > A note that Atom processors may consider leading and trailing space as > significant in attribute and element values would be enough to alert > people to the interoperability issues. But it wouldn't cater for them. That note would need to be a MUST to be effective. > Disallowing leading and trailing whitespace in IRI references (including > the isegment-nz-nc production), MIME media types, language tags, > lengths, addr-spec, and date-time productions would lead to improved > interoperability. > > I'm fine with either. My best guess is that given the choice to either reject a feed or call trim(), people will call trim(). But some clarity either way would be welcome and would need to be presented as a general processing directive, and not just specific to the element we're talking about. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 04 06:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d2G-0002E3-1w for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:33:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23815 for ; Thu, 4 Aug 2005 06:33:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74APof8054611; Thu, 4 Aug 2005 03:25:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74APoEI054610; Thu, 4 Aug 2005 03:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [86.255.19.201] (wired-6-94.ietf63.ietf.org [86.255.6.94]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74APm6C054590 for ; Thu, 4 Aug 2005 03:25:49 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c505080216371c20f5b3@mail.gmail.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Date: Thu, 4 Aug 2005 12:25:50 +0200 To: Atom WG From: Paul Hoffman Subject: Re: spec bug: can we fix for draft-11? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: >One way of saying this would be "Atom Processors MAY ignore leading >and trailing whitespace in _____________." That works for me. Another idea is "Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and ________." --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 04 06:48:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dGx-0008Dg-K4 for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:48:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26086 for ; Thu, 4 Aug 2005 06:48:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74AdTmg059835; Thu, 4 Aug 2005 03:39:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74AdT01059831; Thu, 4 Aug 2005 03:39:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.fondantfancies.com ([69.10.132.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74AdTVx059816; Thu, 4 Aug 2005 03:39:29 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [X?@IPv6:::1] (69.10.132.130 [69.10.132.130]) by mail.fondantfancies.com (Postfix) with ESMTP id C1ABD106DA; Thu, 4 Aug 2005 11:39:27 +0100 (BST) In-Reply-To: References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: spec bug: can we fix for draft-11? Date: Thu, 4 Aug 2005 11:39:22 +0100 To: Paul Hoffman X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Aug 2005, at 11:25 am, Paul Hoffman wrote: > That works for me. Another idea is "Atom Processors MAY ignore > leading and/or trailing whitespace in elements whose content does > not allow leading and/or trailing whitespace, such as IRIs and > ________." > This doesn't describe an interoperable model. Either all processors must remove whitespace, or whitespace is not allowed at all (Note the latter still allows processors to remove whitespace anyway). Graham From owner-atom-syntax@mail.imc.org Thu Aug 04 06:52:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0dLM-000154-HB for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:52:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26539 for ; Thu, 4 Aug 2005 06:52:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74AhqNt061262; Thu, 4 Aug 2005 03:43:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74AhqN5061260; Thu, 4 Aug 2005 03:43:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74Ahpcf061228 for ; Thu, 4 Aug 2005 03:43:51 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 44597 messnum 5273081 invoked from network[213.94.211.166/mail2.newbay.com]); 4 Aug 2005 10:43:45 -0000 Received: from mail2.newbay.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 44597) with SMTP; 4 Aug 2005 10:43:45 -0000 Message-ID: <42F1F160.10707@dehora.net> Date: Thu, 04 Aug 2005 11:43:44 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > At 7:37 PM -0400 8/2/05, Robert Sayre wrote: > >> One way of saying this would be "Atom Processors MAY ignore leading >> and trailing whitespace in _____________." > > > That works for me. Another idea is "Atom Processors MAY ignore leading > and/or trailing whitespace in elements whose content does not allow > leading and/or trailing whitespace, such as IRIs and ________." I don't understand the benefits of MAY. It sounds like this to me: "whitespace is not allowed in certain elements, but you may ignore that directive by trimming the content". cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 04 08:13:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ebm-0000aS-Cu for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:13:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00726 for ; Thu, 4 Aug 2005 08:13:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C6qkI091996; Thu, 4 Aug 2005 05:06:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74C6qYk091995; Thu, 4 Aug 2005 05:06:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C6qRq091964 for ; Thu, 4 Aug 2005 05:06:52 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so116893wra for ; Thu, 04 Aug 2005 05:06:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mBofWNT1GpHyDtWnBUK157IptzfiHnajM6Az0pQ2prV4lHZHN4gx4SyLsBNmKvzJ2qpN7bC8B54u6PcKOgxDsZ7uGZ8Xa4FNydHEIijTI66j4wpBwlG5ogRLlPSIok3frifKySi7YxW0dUkdJc7GAzJSQSNxgE80sAlJN3RQcvs= Received: by 10.54.10.23 with SMTP id 23mr1445408wrj; Thu, 04 Aug 2005 05:06:46 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 4 Aug 2005 05:06:46 -0700 (PDT) Message-ID: <68fba5c505080405062ca17a7e@mail.gmail.com> Date: Thu, 4 Aug 2005 08:06:46 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: spec bug: can we fix for draft-11? Cc: Atom WG In-Reply-To: <42F1F160.10707@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <42F1F160.10707@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74C6qRq091988 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 ietf.org id IAA00726 On 8/4/05, Bill de h=D3ra wrote: > I don't understand the benefits of MAY. It sounds like this to me: > "whitespace is not allowed in certain elements, but you may ignore that > directive by trimming the content". What's the problem with that? That discourages sloppy feed generation, while acknowledging what Atom Processors actually do (yes, already. we don't actually have a choice). Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 04 08:14:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ecZ-0000dx-CP for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:14:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00767 for ; Thu, 4 Aug 2005 08:14:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C6bkq091902; Thu, 4 Aug 2005 05:06:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74C6bGv091901; Thu, 4 Aug 2005 05:06:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [86.255.19.201] (open-26-18.ietf63.ietf.org [86.255.26.18]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C6UFN091858; Thu, 4 Aug 2005 05:06:31 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42F1F160.10707@dehora.net> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <42F1F160.10707@dehora.net> Date: Thu, 4 Aug 2005 14:06:33 +0200 To: Bill de =?iso-8859-1?Q?h=D3ra?= , Atom WG From: Paul Hoffman Subject: Re: spec bug: can we fix for draft-11? Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" 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 ietf.org id IAA00767 At 11:43 AM +0100 8/4/05, Bill de h=D3ra wrote: >Paul Hoffman wrote: >> >> At 7:37 PM -0400 8/2/05, Robert Sayre wrote: >> >>> One way of saying this would be "Atom Processors MAY ignore leading >>> and trailing whitespace in _____________." >> >> >> That works for me. Another idea is "Atom Processors MAY ignore leadin= g >> and/or trailing whitespace in elements whose content does not allow >> leading and/or trailing whitespace, such as IRIs and ________." > >I don't understand the benefits of MAY. It sounds like this to me: >"whitespace is not allowed in certain elements, but you may ignore that >directive by trimming the content". Exactly: that's the MAY. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 04 08:18:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eg5-0001do-QL for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:18:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00908 for ; Thu, 4 Aug 2005 08:18:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C7SMu092205; Thu, 4 Aug 2005 05:07:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74C7SbZ092204; Thu, 4 Aug 2005 05:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74C7Rg8092191; Thu, 4 Aug 2005 05:07:27 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j74C7RvU012770; Thu, 4 Aug 2005 06:07:27 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKP000VZ5OEVW@edgemail1.Central.Sun.COM>; Thu, 04 Aug 2005 06:07:27 -0600 (MDT) Received: from [192.168.1.100] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKP0030C5OEYW@mail.sun.net>; Thu, 04 Aug 2005 06:07:26 -0600 (MDT) Date: Thu, 04 Aug 2005 05:07:43 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: To: Paul Hoffman Cc: Atom WG Message-id: <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote: > > At 7:37 PM -0400 8/2/05, Robert Sayre wrote: > >> One way of saying this would be "Atom Processors MAY ignore leading >> and trailing whitespace in _____________." >> > > That works for me. Another idea is "Atom Processors MAY ignore > leading and/or trailing whitespace in elements whose content does > not allow leading and/or trailing whitespace, such as IRIs and > ________." The more I think about this family of suggestions, the less I like them. There is no coherent argument from the published specifications of XML and IRIs that allows our 4.2.6 language "Its content MUST be an IRI" to regard http://example.com/foo as anything but an error. I suggest an alternate formulation: =========================================================== "Implementors are advised that there is a common class of error in which, when the content of an element is specified as being an IRI, software which generates Atom documents introduces spurious white space before and after the IRI, for example: urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 In this case, since [RFC3987] makes it clear that the leading and trailing white space cannot be part of the IRI, implementors MAY choose to be forgiving in regards to this error, by ignoring the leading and trailing white space." =========================================================== I'm strongly -1 on treating this as anything but an error. We may at our discretion make it forgiveable. This formulation would also allow the feed validator to complain. I suppose if we did this, we should generalize it slightly to apply to date constructs as well. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 04 08:42:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0f3V-0008BK-Fw for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:42:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02226 for ; Thu, 4 Aug 2005 08:42:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74CVGYO000981; Thu, 4 Aug 2005 05:31:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74CVGZ1000980; Thu, 4 Aug 2005 05:31:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74CVFnU000934 for ; Thu, 4 Aug 2005 05:31:15 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 61931 messnum 3320574 invoked from network[213.94.211.166/dev2.mcpps.com]); 4 Aug 2005 12:31:09 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail05.svc.cra.dublin.eircom.net (qp 61931) with SMTP; 4 Aug 2005 12:31:09 -0000 Message-ID: <42F20A8B.6010909@dehora.net> Date: Thu, 04 Aug 2005 13:31:07 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> In-Reply-To: <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > I'm strongly -1 on treating this as anything but an error. We may at > our discretion make it forgiveable. I really do not understand - it's an error or it's not not. Elsewhere in their replies, Paul and Robert seem to think this is obviously meaningful. Clearly I don't get it because I just see it as equivocation. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 04 08:52:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fCl-0002X0-MZ for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 08:52:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03597 for ; Thu, 4 Aug 2005 08:52:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74CggSR006161; Thu, 4 Aug 2005 05:42:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Cgg3J006159; Thu, 4 Aug 2005 05:42:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74CgfFr006120 for ; Thu, 4 Aug 2005 05:42:41 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 04 Aug 2005 12:42:34 -0000 Received: from dsl-084-056-251-025.arcor-ip.net (EHLO localhost) [84.56.251.25] by mail.gmx.net (mp004) with SMTP; 04 Aug 2005 14:42:34 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Date: Thu, 04 Aug 2005 14:42:31 +0200 Message-ID: <42f50929.65833015@smtp.bjoern.hoehrmann.de> References: <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> In-Reply-To: <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id IAA03597 * Tim Bray wrote: >"Implementors are advised that there is a common class of error in =20 >[...] Sorry but this is ridiculous; if we say X MUST Y even though we know that many X won't Y we are abusing RFC 2119 terminology and make it much more difficult to evangelize 100% compliance, since this allows people to argue that compliance with this particular requirement is not relevant in practise so they can worry less about compliance in general. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Thu Aug 04 09:19:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fdT-0005kW-2Z for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:19:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09009 for ; Thu, 4 Aug 2005 09:19:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74D9JFd016474; Thu, 4 Aug 2005 06:09:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74D9Jvm016473; Thu, 4 Aug 2005 06:09:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [66.9.53.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74D9IxX016459 for ; Thu, 4 Aug 2005 06:09:18 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1E0fTK-0005dh-00; Thu, 04 Aug 2005 14:09:18 +0100 Date: Thu, 4 Aug 2005 14:09:18 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050804130918.GH1961@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42f50929.65833015@smtp.bjoern.hoehrmann.de> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote: > * Tim Bray wrote: > >"Implementors are advised that there is a common class of error in > >[...] > > Sorry but this is ridiculous; if we say X MUST Y even though we know > that many X won't Y we are abusing RFC 2119 terminology and make it > much more difficult to evangelize 100% compliance, since this allows > people to argue that compliance with this particular requirement is > not relevant in practise so they can worry less about compliance in > general. +1 I don't entirely see why having the MUST in place doesn't satisfy this anyway, providing we point out explicitly that whitespace around URIs and dates is an error. This puts a clear restriction on compliant Atom document producers, but lets consumers deal with not-quite-Atom documents that break this particular MUST in any way these choose fit. Some will catch fire. The feed validator will fault them. Others may choose to strip whitespace, in a kind of Postel-like fashion. If this needs pointing out to people writing Atom consuming applications, then it's a job for implementation guidelines in a separate document. That's how I'd expect this sort of thing to be handled in any other IETF spec, certainly; otherwise, as pointed out, no matter what language we use we run the risk of non-conformant Atom documents being considered 'blessed' by our wording. We don't spell out what Atom consumers should do if they encounter a Date construct with "Last Thursday" in, either. Pointing out the common error AS AN ERROR should be sufficient IMHO. J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu Aug 04 09:46:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0g3Z-0005wm-Kt for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 09:46:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11098 for ; Thu, 4 Aug 2005 09:46:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Dd0SS027631; Thu, 4 Aug 2005 06:39:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Dd0ZO027630; Thu, 4 Aug 2005 06:39:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [86.255.19.201] (open-26-18.ietf63.ietf.org [86.255.26.18]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Dcq4w027570; Thu, 4 Aug 2005 06:38:53 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42f50929.65833015@smtp.bjoern.hoehrmann.de> References: <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> Date: Thu, 4 Aug 2005 15:38:52 +0200 To: Bjoern Hoehrmann , Tim Bray From: Paul Hoffman Subject: Re: spec bug: can we fix for draft-11? Cc: atom-syntax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:42 PM +0200 8/4/05, Bjoern Hoehrmann wrote: >* Tim Bray wrote: >>"Implementors are advised that there is a common class of error in >>[...] > >Sorry but this is ridiculous; if we say X MUST Y even though we know >that many X won't Y we are abusing RFC 2119 terminology and make it >much more difficult to evangelize 100% compliance, since this allows >people to argue that compliance with this particular requirement is >not relevant in practise so they can worry less about compliance in >general. You can't compare an IRI with a non-IRI. So, if you are handed an non-IRI (as in, an IRI-looking string that has whitespace around it), should you fail immediately or try harder? I propose trying harder, but I am open to "just fail". --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 04 10:01:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gHv-0004BS-ON for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 10:01:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12367 for ; Thu, 4 Aug 2005 10:01:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74DrExT033456; Thu, 4 Aug 2005 06:53:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DrEoX033455; Thu, 4 Aug 2005 06:53:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74DrBUa033388 for ; Thu, 4 Aug 2005 06:53:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so136376wra for ; Thu, 04 Aug 2005 06:53:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bLU7PukQKG4lOkHBYQKAdKDKWYpPVoEtVfIvS9rbfbRVQodUzYR02UP72B+CjToExY3sZtk7xOuESUQThOXrGP8/PMedD88JMTh9yho2JeX4bBEx8f7sz1UYYWhGzmspf08zhNWdIimnVXtt4T+w5PvOafUQY5NVhkPEZrBifzA= Received: by 10.54.30.27 with SMTP id d27mr1549661wrd; Thu, 04 Aug 2005 06:53:05 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 4 Aug 2005 06:53:05 -0700 (PDT) Message-ID: <68fba5c50508040653457d427e@mail.gmail.com> Date: Thu, 4 Aug 2005 09:53:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: spec bug: can we fix for draft-11? Cc: Bjoern Hoehrmann , Tim Bray , atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74DrDUa033440 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/4/05, Paul Hoffman wrote: > I propose trying harder, but I am open to "just fail". As am I. I am not OK with a long treatise on whitespace, like the one Tim suggested. If there is a MUST-breaking error in a feed, that's not an Atom document and I don't want to talk about it. I slightly prefer documenting and allowing what the world's PHP scripts have been observed to produce, but either way is fine. BTW, my proposed text was taken from HTML 4.01. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 04 10:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gPn-0006lK-HZ for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 10:09:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13262 for ; Thu, 4 Aug 2005 10:09:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74DunXn034887; Thu, 4 Aug 2005 06:56:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74DunNf034883; Thu, 4 Aug 2005 06:56:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74DulYH034829 for ; Thu, 4 Aug 2005 06:56:48 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 04 Aug 2005 13:56:42 -0000 Received: from dsl-084-056-251-025.arcor-ip.net (EHLO localhost) [84.56.251.25] by mail.gmx.net (mp030) with SMTP; 04 Aug 2005 15:56:42 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman Cc: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Date: Thu, 04 Aug 2005 15:56:38 +0200 Message-ID: <42f61d1c.70940421@smtp.bjoern.hoehrmann.de> References: <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id KAA13262 * Paul Hoffman wrote: >You can't compare an IRI with a non-IRI. So, if you are handed an=20 >non-IRI (as in, an IRI-looking string that has whitespace around it),=20 >should you fail immediately or try harder? I propose trying harder,=20 >but I am open to "just fail". Well, if we expect that many content providers will consider the content model of atom:id elements to be "IRI with optional surrounding white space" then we define the content model accordingly. Hardcoding "We know many people will ignore this, but the content model is 'IRI *without* optional sourrounding white space'" doesn't make any sense. Of course, content providers would pay more attention to the requirement if Atom implementations must not (and in practise will not) provide the content of feeds or entries with such a non-conforming atom:id to users, so that might indeed be an option too, though I'm not sure how likely it is that implementers follow such a requirement. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Thu Aug 04 11:51:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0i0L-0003Mt-19 for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 11:51:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20858 for ; Thu, 4 Aug 2005 11:51:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Fk7sk050385; Thu, 4 Aug 2005 08:46:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Fk7jc050384; Thu, 4 Aug 2005 08:46:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Fk5Ev050377 for ; Thu, 4 Aug 2005 08:46:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so216303nzi for ; Thu, 04 Aug 2005 08:46:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G6nYddoX0CiOBHKH3i5gBKiXWFfRByfrn0fq7mcJJGErLsIctoPX+EEF7fE+Xt4eG9Kg5g8MRGNvnV8Y3GFk5UlsJJe3ExXePg2alsqweBNNh7WhmUbt+XcuZnWS8biw9gDaCzg5gcl1uUIriIfIOeOL+q1E6sXqmWmkeigHCjU= Received: by 10.36.20.20 with SMTP id 20mr871871nzt; Thu, 04 Aug 2005 08:46:00 -0700 (PDT) Received: by 10.36.157.4 with HTTP; Thu, 4 Aug 2005 08:45:59 -0700 (PDT) Message-ID: <1f2ed5cd050804084568572653@mail.gmail.com> Date: Thu, 4 Aug 2005 17:45:59 +0200 From: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: spec bug: can we fix for draft-11? Cc: Graham , atom-syntax In-Reply-To: <42EF49A4.5050904@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74Fk6Ev050379 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 ietf.org id LAA20858 On 8/2/05, Bill de h=D3ra wrote: >=20 > Graham wrote: > > From atompub-format-10, 4.2.6: "Its content MUST be an IRI" > > > > That to me is demonstrates a very clear intention of the working gro= up > > that the content must be exactly equal to the IRI.=20 My reading too. > I don't want to allow whitespace. But this >=20 > > urn:foo > >=20 > is going to happen, is going to cause problems, and working around it > does not strike me as being something you can foist entirely onto the > spec's end-users.=20 Why is it particularly likely to happen? I don't really understand why this should be treated any differently than the numerous other problematic things that could happen if one doesn't take the spec literally. (I'd suggest spec prose trumps RNG grammar, as there's a lot of other stuff not expressable in the grammar). But now the issue has been raised, it does seem reasonable to add a note (assuming the process is ok for that) to the effect that stray whitespace in content is an error. I can't see how it can be desirable to allow it (though am not given to lying in the road). At the application level we're back to Postel again - publishers shouldn't pump this stuff out, but liberal clients may find it useful to trim whitespace from IRI and date fields. But surely that's outside the scope of the format spec itself. Cheers, Danny. --=20 http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Aug 04 12:30:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0icP-000768-B4 for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 12:30:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23311 for ; Thu, 4 Aug 2005 12:30:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74GH0je052962; Thu, 4 Aug 2005 09:17:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74GH0HD052961; Thu, 4 Aug 2005 09:17:00 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j74GGwxZ052952 for ; Thu, 4 Aug 2005 09:16:59 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Aug 2005 16:16:53 -0000 Received: from xdsl-81-173-171-75.netcologne.de (EHLO klangraum) [81.173.171.75] by mail.gmx.net (mp033) with SMTP; 04 Aug 2005 18:16:53 +0200 X-Authenticated: #163624 Date: Thu, 4 Aug 2005 18:22:22 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050804162222.GA3283@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <20050804130918.GH1961@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050804130918.GH1961@tartarus.org> 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 ietf.org id MAA23311 * James Aylett [2005-08-04 15:25]: > On Thu, Aug 04, 2005 at 02:42:31PM +0200, Bjoern Hoehrmann wrote: >=20 > > * Tim Bray wrote: > > >"Implementors are advised that there is a common class of > > >error in [...] > >=20 > > Sorry but this is ridiculous; if we say X MUST Y even though > > we know that many X won't Y we are abusing RFC 2119 > > terminology and make it much more difficult to evangelize > > 100% compliance, since this allows people to argue that > > compliance with this particular requirement is not relevant > > in practise so they can worry less about compliance in > > general. >=20 > +1 >=20 > [=E2=80=A6] >=20 > We don't spell out what Atom consumers should do if they > encounter a Date construct with "Last Thursday" in, either. > Pointing out the common error AS AN ERROR should be sufficient > IMHO. +1 to James and Bjoern. There Is Only MAY, SHOULD And MUST. I want to remind everyone that the spec=E2=80=99s job is to say exactly what the bits mean, rather than what people should do with them. It therefore strikes me as foolish to be coy about what constitutes an error. Telling implementors that they KINDA MUST, PROBABLY comply serves noone. An error is an error is an error. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 04 14:17:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kHs-0008Tf-Nk for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:17:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27833 for ; Thu, 4 Aug 2005 14:17:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74IBW8X062356; Thu, 4 Aug 2005 11:11:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74IBWeP062355; Thu, 4 Aug 2005 11:11:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74IBU6l062341; Thu, 4 Aug 2005 11:11:31 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j74IBUvU015545; Thu, 4 Aug 2005 12:11:30 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKP002ZZMJ5JY@edgemail1.Central.Sun.COM>; Thu, 04 Aug 2005 12:11:30 -0600 (MDT) Received: from [10.192.5.13] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKP003QHMJ5YO@mail.sun.net>; Thu, 04 Aug 2005 12:11:29 -0600 (MDT) Date: Thu, 04 Aug 2005 09:31:55 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <68fba5c50508040653457d427e@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Bjoern Hoehrmann , atom-syntax@imc.org Message-id: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote: >> I propose trying harder, but I am open to "just fail". > > As am I. I am not OK with a long treatise on whitespace, like the one > Tim suggested. If there is a MUST-breaking error in a feed, that's not > an Atom document and I don't want to talk about it. I slightly prefer > documenting and allowing what the world's PHP scripts have been > observed to produce, but either way is fine. BTW, my proposed text was > taken from HTML 4.01. I'm getting increasingly grumpy and "just fail" is looking better and better. The current normative text, "The element's content MUST be an IRI", is clear and simple and supported by other well-understood normative text, supported by lots of interoperable software, that make the meanings of "element", "content", and "IRI" not really open to intelligent dispute. I claim that text enjoyed strong, not rough, consensus support from the WG. So my preferred course of action would be to leave it the way it bloody well is. The Feed validator should throw whitespace-polluted pseudo-Atom on the floor, and if some bozos persist in producing it, and some implementors decide to work around this error, well, that's the way the Internet is. But if a couple of leading implementations decide to be strict, and the producers develop a culture of Doing The Right Thing, well then, that's the way the Internet is too, sometimes. PHP is, if nothing else, flexible and friendly to quick changes in deployed scripts, I can hear a zillion publishing-system hackers grumbling "Oh, it's that damn tight-assed Atom stuff, guess I have to use mod_finicky here". So for now, I'm -1 on an weakening or removing "The element's content MUST be an IRI" or analogous text in any other section. I'll stop shouting if I'm in a small minority here. -Tim From owner-atom-syntax@mail.imc.org Thu Aug 04 14:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kPg-0001aE-80 for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:25:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28040 for ; Thu, 4 Aug 2005 14:25:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74ILHB4063094; Thu, 4 Aug 2005 11:21:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74ILH2m063093; Thu, 4 Aug 2005 11:21:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74ILFPq063087 for ; Thu, 4 Aug 2005 11:21:16 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 2782 invoked from network); 4 Aug 2005 18:21:14 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 4 Aug 2005 18:21:14 -0000 Subject: Re: spec bug: can we fix for draft-11? From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Danny Ayers Cc: Bill de =?ISO-8859-1?Q?h=D3ra?= , Graham , atom-syntax In-Reply-To: <1f2ed5cd050804084568572653@mail.gmail.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> Content-Type: text/plain Date: Thu, 04 Aug 2005 19:21:14 +0100 Message-Id: <1123179674.3346.22.camel@marge> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-08-04 at 17:45 +0200, Danny Ayers wrote: > > I don't want to allow whitespace. But this > > > > > > urn:foo > > > > > > is going to happen, is going to cause problems, and working around it > > does not strike me as being something you can foist entirely onto the > > spec's end-users. > > Why is it particularly likely to happen? Because there is nothing to 'see' that looks wrong Danny, and relaxNG has nothing that allows both text (ws) and anyURI to mix. I think that means it needs sneaky words to state it; or tee people off by failing content that 'looks' good. regards DaveP From owner-atom-syntax@mail.imc.org Thu Aug 04 14:29:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kTD-00023A-RR for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:29:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28187 for ; Thu, 4 Aug 2005 14:29:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74IORcf063392; Thu, 4 Aug 2005 11:24:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74IORKf063391; Thu, 4 Aug 2005 11:24:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74IOQE9063380 for ; Thu, 4 Aug 2005 11:24:26 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 4382 invoked from network); 4 Aug 2005 18:24:25 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 4 Aug 2005 18:24:25 -0000 Subject: Re: spec bug: can we fix for draft-11? From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Tim Bray Cc: Robert Sayre , Paul Hoffman , Bjoern Hoehrmann , atom-syntax@imc.org In-Reply-To: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> Content-Type: text/plain Date: Thu, 04 Aug 2005 19:24:24 +0100 Message-Id: <1123179864.3346.25.camel@marge> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. > So for now, I'm -1 on an weakening or removing "The element's content > MUST be an IRI" or analogous text in any other section. I'll stop > shouting if I'm in a small minority here. It's clean, except I'd like an informative statement for people failing and wondering why. And something in the schema that lets people know why, since we can validate against the schema and *pass*? Now that could be confusing. regards DaveP From owner-atom-syntax@mail.imc.org Thu Aug 04 14:47:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kkY-0005pI-0x for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 14:47:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29044 for ; Thu, 4 Aug 2005 14:47:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74Ig26t064470; Thu, 4 Aug 2005 11:42:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74Ig2DC064469; Thu, 4 Aug 2005 11:42:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74Ig0nh064444 for ; Thu, 4 Aug 2005 11:42:01 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Aug 2005 18:41:55 -0000 Received: from p508F910B.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.145.11] by mail.gmx.net (mp027) with SMTP; 04 Aug 2005 20:41:55 +0200 X-Authenticated: #1915285 Message-ID: <42F2616C.5050407@gmx.de> Date: Thu, 04 Aug 2005 20:41:49 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: davep@dpawson.co.uk CC: Tim Bray , Robert Sayre , Paul Hoffman , Bjoern Hoehrmann , atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <1123179864.3346.25.camel@marge> In-Reply-To: <1123179864.3346.25.camel@marge> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dave Pawson wrote: > On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote: > > >>I'm getting increasingly grumpy and "just fail" is looking better and >>better. > > >>So for now, I'm -1 on an weakening or removing "The element's content >>MUST be an IRI" or analogous text in any other section. I'll stop >>shouting if I'm in a small minority here. > > > It's clean, except I'd like an informative statement for people > failing and wondering why. > > And something in the schema that lets people know why, since we > can validate against the schema and *pass*? > Now that could be confusing. > > regards DaveP +1 on both (not changing the semantics, but possibly adding a warning that whitespace *really* is significant here). regards, Julian From owner-atom-syntax@mail.imc.org Thu Aug 04 15:04:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0l0u-0001bf-SB for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 15:04:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29878 for ; Thu, 4 Aug 2005 15:04:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74ItFRW065475; Thu, 4 Aug 2005 11:55:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74ItFLY065474; Thu, 4 Aug 2005 11:55:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74ItEEu065464 for ; Thu, 4 Aug 2005 11:55:14 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so236202nzi for ; Thu, 04 Aug 2005 11:55:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SWdxZmETOcd+8CUQ89dGDhe5Y9Mf25gMAy2BM3FLFULagKYQpJVIaVodj87jO7WEOdVSzWFmYsfNNSiZ0fDudeZ8j/bGmKYcFesphzAgGYAOm2jucO38122tzL14L3mYRlAOdI8uA2jnqezdoJarbtBP+v1VGJA7k349hCtk6KQ= Received: by 10.36.71.5 with SMTP id t5mr943132nza; Thu, 04 Aug 2005 11:55:09 -0700 (PDT) Received: by 10.36.61.12 with HTTP; Thu, 4 Aug 2005 11:55:09 -0700 (PDT) Message-ID: <3f1451f50508041155132f743@mail.gmail.com> Date: Thu, 4 Aug 2005 14:55:09 -0400 From: Joe Gregorio To: Danny Ayers Subject: Re: spec bug: can we fix for draft-11? Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Graham , atom-syntax In-Reply-To: <1f2ed5cd050804084568572653@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j74ItFEu065469 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/4/05, Danny Ayers wrote: > I don't really understand why this should be treated any differently > than the numerous other problematic things that could happen if one > doesn't take the spec literally. (I'd suggest spec prose trumps RNG > grammar, as there's a lot of other stuff not expressable in the > grammar). "Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B." This is quoted directly from Section 1.3. This whitespace issue is a good illustration of why the schema isn't normative ;) I would vote for leaving the text as is and having the validator give errors on whitespace. We have the same issue with dates and believe they should be flagged likewise, i.e. errors on whitespace. -joe > > But now the issue has been raised, it does seem reasonable to add a > note (assuming the process is ok for that) to the effect that stray > whitespace in content is an error. I can't see how it can be desirable > to allow it (though am not given to lying in the road). > > At the application level we're back to Postel again - publishers > shouldn't pump this stuff out, but liberal clients may find it useful > to trim whitespace from IRI and date fields. But surely that's outside > the scope of the format spec itself. > > Cheers, > Danny. > > -- > > http://dannyayers.com > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Aug 04 15:11:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0l8H-0002jn-Ts for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 15:11:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00754 for ; Thu, 4 Aug 2005 15:11:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74J3jv3066118; Thu, 4 Aug 2005 12:03:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74J3jdV066117; Thu, 4 Aug 2005 12:03:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74J3idR066104 for ; Thu, 4 Aug 2005 12:03:44 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so182356wra for ; Thu, 04 Aug 2005 12:03:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RQ6EimBc9fQ75LbGlHxAMHjBimh+f6MifGHK4Zy3f0Nqcp3sSqLa+Xm52erjqa0SJ+5inn/GI0xrMnh2ZmkVJ+01tYd7d4Id1XizVvxMsUJrmL0C7KTNXjZHeKkAt6bvLEXybwbOhmPWXuuvDyF7yG5LcX7IkvvpEDtMurdbW1k= Received: by 10.54.147.3 with SMTP id u3mr1856551wrd; Thu, 04 Aug 2005 12:03:39 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id d16sm2584642wra.2005.08.04.12.03.34; Thu, 04 Aug 2005 12:03:39 -0700 (PDT) Message-ID: <42F26661.1020200@gmail.com> Date: Thu, 04 Aug 2005 12:02:57 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Comments Draft References: <20050731162400.GE25925@klangraum> <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> <20050801172740.GA32587@klangraum> In-Reply-To: <20050801172740.GA32587@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id PAA00754 I definitely appreciate all of the feedback on this. The conversation=20 has definitely been helpful. Personally, however, I think that the=20 elegance and simplicity of in-reply-to and replies link rel values=20 trumps defining them as elements in a separate namespace or an otherwise=20 perfectly engineered solution. As for specifying the source of the=20 resource being replied to, a namespace extension inside the link element=20 is probably the best way to go. So what we end up with is: ... ... =20 http://www.example.com/sourcefeed.xml" Implementations that are not thread aware can safely drop thread:source=20 as they won't be able to do anything useful with the in-reply-to link=20 anyway (whether it is dereferenceable or not).=20 While this approach may be a bit hackish, I believe that it's natural,=20 simple and unambiguous enough to solve the problem effectively. Using=20 the via link just seems unnatural to this purpose in that we're not=20 expressing a relationship like "The information contained here-in was=20 received through..." we're expressig "The information contained here-in=20 is a response to...". Via works great for the former and doesn't fit=20 for the latter. All of the examples that have been offered built around=20 the via mechanism just seem entirely too verbose for comfort...=20 especially given that we're trying to optimize for optional metadata=20 that hints at a relationship that can't be reliably confirmed (e.g. that=20 the entity being replied to MAY exist at the specified source). Thoughts? - James A. Pagaltzis wrote: >* Antone Roundy [2005-08-01 18:30]: > =20 > >>On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote: >> =20 >> >>>This undermines the purpose of the link. >>> =20 >>> >>I'd say that not being able to tell whether @href in >>link[@rel=3D"in-reply-to"] is dereferencable or not is what >>undermines link. >> =20 >> > >It undermines the purpose of the link insofar as IMO the entry >being replied to MUST ALWAYS be identified by its atom:id. I am >strongly -1 on letting the producer choose to identify it by its >network location in any way or shape. Such a location is valuable >as additional information to provide, but it=E2=80=99s strictly optional. > > =20 > >>If "If the resource being replied to is an atom:entry, the >>value of the href attribute MUST be the atom:id of the >>atom:entry" doesn't sound like a good rule, then I'd argue that >>using atom:link to identify the resource being replied to is a >>bad idea. >> =20 >> > >I have already agreed about the fact that atom:link is not the >right vehicle for carrying the atom:id, so there=E2=80=99s no need for >you to preach to the choir. See my "Thread/comment extension >refactoring" post about my current stance. > >As for overloading @rel=3D'in-reply-to' to carry either >dereferencable URIs or atom:ids, that would just needlessly >require conditional checks on the consumer end. And because I=E2=80=99m >strongly -1 on omitting the atom:id but also no longer consider >atom:link to be the right place for it, the idea is triply wrong. > > =20 > >>>Atom Entry Documents can move around; their IDs are eternal. >>> =20 >>> >>True, so you could just omit @type from this link if you're >>concerned that your entry document might move. Or we could go >>with something like this: >> >> >> >> >> >> =20 >> > >That makes the information in the nested atom:link elements >inaccessible to compliant clients without threading support, and >it also requires new relationships to boot. Also, note that >entry-sources vs replied-to-entries is an 1:N relationship, so it >would make sense to group replied-to-entries by entry-source, >rather than vice versa. > >So then you have > > > urn:foo:1 > urn:foo:2 > > >which properly reuses a known relationship, so that even a >non-thread-aware consumer can do something interesting with the >information, even if it does not understand it quite as precisely >as a client with proper thread awareness. > >Again, see my "Thread/comment extension refactoring" post about >my current thinking. > > =20 > >>...okay, that last sentence suggests that what I propose just >>above here is a superior way to having possibly-derefencable >>atom:links, because you could update the >>found-in-entry-document link if it got out of sync with the >>location of the document. Otherwise, we'll have to be limited >>to linking to the feed in which the entry is found. >> =20 >> > >I don=E2=80=99t see why that is an advantage specific to using the @type >attribute on atom:link in the way you proposed, rather than >a benefit that *any* approach for including a source URL would >provide. > >Again, please see my other post. The approach we started with >(relying mostly on @rel=3D'in-reply-to' which I proposed) was >hackish, which was okay as long as it was minimal, but is no >longer tenable now that we are trying to accomplish even a bit >more. My new proposition deals with all of your objections and >several other issues I ran across on my own. > >Regards, > =20 > From owner-atom-syntax@mail.imc.org Thu Aug 04 15:26:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0lMe-0005mb-TO for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 15:26:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02141 for ; Thu, 4 Aug 2005 15:26:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JK0qe067663; Thu, 4 Aug 2005 12:20:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74JK0jt067662; Thu, 4 Aug 2005 12:20:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74JJx5N067647 for ; Thu, 4 Aug 2005 12:20:00 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so185246wra for ; Thu, 04 Aug 2005 12:19:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uB/maxIUR0Xs8RphTnDq1TizUVo23iG6rXWGimdwm4howVYGBBXIVcYIUdYHEenM0F7//mNdlEJV8kp9wN5GE50B72pKeaj8aPfO5N1TAIN9gCSRgoQrSVd9iOL+hhOiN9QK6BGFYnFSXKLQjKF5qUIJ6cueishhUKXKlODIoU0= Received: by 10.54.25.11 with SMTP id 11mr1858236wry; Thu, 04 Aug 2005 12:19:54 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id d61sm1273822wra.2005.08.04.12.19.52; Thu, 04 Aug 2005 12:19:54 -0700 (PDT) Message-ID: <42F269B2.1080506@gmail.com> Date: Thu, 04 Aug 2005 12:17:06 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> <3f1451f50508041155132f743@mail.gmail.com> In-Reply-To: <3f1451f50508041155132f743@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +++1 Joe Gregorio wrote: >On 8/4/05, Danny Ayers wrote: > > >>I don't really understand why this should be treated any differently >>than the numerous other problematic things that could happen if one >>doesn't take the spec literally. (I'd suggest spec prose trumps RNG >>grammar, as there's a lot of other stuff not expressable in the >>grammar). >> >> > >"Some sections of this specification are illustrated with fragments of >a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text >of this specification provides the definition of conformance. A >complete schema appears in Appendix B." > >This is quoted directly from Section 1.3. > >This whitespace issue is a good illustration of why the schema isn't >normative ;) > >I would vote for leaving the text as is and having the validator give >errors on whitespace. > >We have the same issue with dates and believe they should be flagged >likewise, i.e. errors on whitespace. > > -joe > > > > >>But now the issue has been raised, it does seem reasonable to add a >>note (assuming the process is ok for that) to the effect that stray >>whitespace in content is an error. I can't see how it can be desirable >>to allow it (though am not given to lying in the road). >> >>At the application level we're back to Postel again - publishers >>shouldn't pump this stuff out, but liberal clients may find it useful >>to trim whitespace from IRI and date fields. But surely that's outside >>the scope of the format spec itself. >> >>Cheers, >>Danny. >> >>-- >> >>http://dannyayers.com >> >> >> >> > > > > From owner-atom-syntax@mail.imc.org Thu Aug 04 16:09:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0m1X-0000kE-Hk for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 16:09:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07568 for ; Thu, 4 Aug 2005 16:09:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74K4Ra9072186; Thu, 4 Aug 2005 13:04:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74K4R1l072185; Thu, 4 Aug 2005 13:04:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74K4QtG072173 for ; Thu, 4 Aug 2005 13:04:26 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [10.10.3.151] (ip134.198.145.214.iinet.com [198.145.214.134] (may be forged)) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j74KBr3Z015447; Thu, 4 Aug 2005 16:11:56 -0400 Message-ID: <42F274C4.3020302@intertwingly.net> Date: Thu, 04 Aug 2005 16:04:20 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> In-Reply-To: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. The current normative text, "The element's content MUST be an > IRI", is clear and simple and supported by other well-understood > normative text, supported by lots of interoperable software, that make > the meanings of "element", "content", and "IRI" not really open to > intelligent dispute. I claim that text enjoyed strong, not rough, > consensus support from the WG. I believe that the term "content" is open to intelligent dispute. Apparently the authors of RFC3470/BCP70 believe so too. I won't dispute your read on the consensus of the working group, but I would like to request that *SOME* language be present in the spec that makes this clear. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 04 16:36:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0mSP-000659-Gq for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 16:36:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08676 for ; Thu, 4 Aug 2005 16:36:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74KR0S7074114; Thu, 4 Aug 2005 13:27:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74KR0uF074113; Thu, 4 Aug 2005 13:27:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74KQwNx073928 for ; Thu, 4 Aug 2005 13:26:59 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 Aug 2005 20:26:52 -0000 Received: from xdsl-81-173-171-75.netcologne.de (EHLO klangraum) [81.173.171.75] by mail.gmx.net (mp007) with SMTP; 04 Aug 2005 22:26:52 +0200 X-Authenticated: #163624 Date: Thu, 4 Aug 2005 22:32:22 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Cc: Tim.Bray@Sun.COM Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050804203222.GA4742@klangraum> Mail-Followup-To: atom-syntax@imc.org, Tim.Bray@Sun.COM References: <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> 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 ietf.org id QAA08676 * Tim Bray [2005-08-04 20:25]: > I'm getting increasingly grumpy and "just fail" is looking > better and better. The way I read the conversation is that noone will dispute =E2=80=9Cjust fail=E2=80=9D if we do choose to adopt it. > I claim that text enjoyed strong, not rough, consensus support > from the WG. And that stance appears not to have changed. > So for now, I'm -1 on an weakening or removing "The element's > content MUST be an IRI" or analogous text in any other > section. I'll stop shouting if I'm in a small minority here. No, you=E2=80=99re in the unanimous majority. What people aren=E2=80=99t sure about is what the spec text means, as it stands. And if the WG can get into such a long discussion about it, that does not bode well for the spec=E2=80=99s interpretation by implementors. The call, therefore, is not to weaken the spec in any fashion, rather just to make it more explicit about intent. Further, having raised this issue with atom:id, it seems prudent to add the same clarification to the text for atom:updated and friends. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 04 17:38:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nPd-0001CO-VN for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 17:38:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10753 for ; Thu, 4 Aug 2005 17:37:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74LWCXB078905; Thu, 4 Aug 2005 14:32:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74LWCWa078904; Thu, 4 Aug 2005 14:32:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74LWB0L078895 for ; Thu, 4 Aug 2005 14:32:11 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 1050 messnum 11068484 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 4 Aug 2005 21:32:05 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail11.svc.cra.dublin.eircom.net (qp 1050) with SMTP; 4 Aug 2005 21:32:05 -0000 Message-ID: <42F28952.6060709@dehora.net> Date: Thu, 04 Aug 2005 22:32:02 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> <3f1451f50508041155132f743@mail.gmail.com> <42F269B2.1080506@gmail.com> In-Reply-To: <42F269B2.1080506@gmail.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit 0. The validator isn't the spec. cheers Bill James M Snell wrote: > > +++1 > > Joe Gregorio wrote: > >> On 8/4/05, Danny Ayers wrote: >> >> >>> I don't really understand why this should be treated any differently >>> than the numerous other problematic things that could happen if one >>> doesn't take the spec literally. (I'd suggest spec prose trumps RNG >>> grammar, as there's a lot of other stuff not expressable in the >>> grammar). >>> >> >> >> "Some sections of this specification are illustrated with fragments of >> a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text >> of this specification provides the definition of conformance. A >> complete schema appears in Appendix B." >> >> This is quoted directly from Section 1.3. >> >> This whitespace issue is a good illustration of why the schema isn't >> normative ;) >> >> I would vote for leaving the text as is and having the validator give >> errors on whitespace. >> >> We have the same issue with dates and believe they should be flagged >> likewise, i.e. errors on whitespace. >> >> -joe >> >> >> >> >>> But now the issue has been raised, it does seem reasonable to add a >>> note (assuming the process is ok for that) to the effect that stray >>> whitespace in content is an error. I can't see how it can be desirable >>> to allow it (though am not given to lying in the road). >>> >>> At the application level we're back to Postel again - publishers >>> shouldn't pump this stuff out, but liberal clients may find it useful >>> to trim whitespace from IRI and date fields. But surely that's outside >>> the scope of the format spec itself. >>> >>> Cheers, >>> Danny. >>> >>> -- >>> >>> http://dannyayers.com >>> >>> >>> >> >> >> >> >> > > > > From owner-atom-syntax@mail.imc.org Thu Aug 04 17:49:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0nak-00038k-8N for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 17:49:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11077 for ; Thu, 4 Aug 2005 17:49:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74LjZgG079557; Thu, 4 Aug 2005 14:45:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74LjZni079556; Thu, 4 Aug 2005 14:45:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j74LjYgv079535 for ; Thu, 4 Aug 2005 14:45:35 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 43523 messnum 6678575 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 4 Aug 2005 21:45:29 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail10.svc.cra.dublin.eircom.net (qp 43523) with SMTP; 4 Aug 2005 21:45:29 -0000 Message-ID: <42F28C76.5050908@dehora.net> Date: Thu, 04 Aug 2005 22:45:26 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> In-Reply-To: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I'm getting increasingly grumpy and "just fail" is looking better and > better. The current normative text, "The element's content MUST be an > IRI", is clear and simple and supported by other well-understood > normative text, supported by lots of interoperable software, that make > the meanings of "element", "content", and "IRI" not really open to > intelligent dispute. I claim that text enjoyed strong, not rough, > consensus support from the WG. > > So my preferred course of action would be to leave it the way it bloody > well is. [...] > > So for now, I'm -1 on an weakening or removing "The element's content > MUST be an IRI" or analogous text in any other section. I'll stop > shouting if I'm in a small minority here. -Tim Fine by me. However, "extraneous whitespace will cause compliant software to puke" needs to be said, not inferred. I don't believe the text here is as broadly obvious or as well-understood as you suggest. cheers Bill From owner-atom-syntax@mail.imc.org Thu Aug 04 20:21:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0pyJ-0002xA-97 for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 20:21:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19140 for ; Thu, 4 Aug 2005 20:21:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j750BTQb091644; Thu, 4 Aug 2005 17:11:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j750BTaS091643; Thu, 4 Aug 2005 17:11:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j750BSJI091635 for ; Thu, 4 Aug 2005 17:11:28 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [10.10.1.212] (ip134.198.145.214.iinet.com [198.145.214.134] (may be forged)) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j750Ihdg006752; Thu, 4 Aug 2005 20:18:47 -0400 Message-ID: <42F2AE9D.5050406@intertwingly.net> Date: Thu, 04 Aug 2005 20:11:09 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: atom-syntax Subject: Re: spec bug: can we fix for draft-11? References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> <3f1451f50508041155132f743@mail.gmail.com> <42F269B2.1080506@gmail.com> <42F28952.6060709@dehora.net> In-Reply-To: <42F28952.6060709@dehora.net> 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 ietf.org id UAA19140 Bill de h=D3ra wrote: > 0. The validator isn't the spec. +1 to the sentiment that the validator isn't the spec. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 04 22:35:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0s3u-0000KF-Eo for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 22:35:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25585 for ; Thu, 4 Aug 2005 22:35:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j752OU2b002196; Thu, 4 Aug 2005 19:24:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j752OUBN002195; Thu, 4 Aug 2005 19:24:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j752OSUb002172 for ; Thu, 4 Aug 2005 19:24:29 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so53903wra for ; Thu, 04 Aug 2005 19:24:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oya+WwUwoi23LULQj+7fuBkfQ7zcjR0D87GVw64ebCk+5CVf2Gub2PSTZronqxIxFKN3lHCNWOSHHOc5yiOYbC3zsY5IN+71EQRHCKONyAfksrMIn+zRvyArddlSecF3M+n/vqzuQZwlrFQD9qyrGA77Vp3oYgzEXVan9bG+LAg= Received: by 10.54.13.77 with SMTP id 77mr2072630wrm; Thu, 04 Aug 2005 19:24:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 4 Aug 2005 19:24:23 -0700 (PDT) Message-ID: <68fba5c505080419247f735ee9@mail.gmail.com> Date: Thu, 4 Aug 2005 22:24:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: spec bug: can we fix for draft-11? Cc: Tim Bray , atom-syntax@imc.org In-Reply-To: <42F274C4.3020302@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j752OTUb002188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/4/05, Sam Ruby wrote: > I believe that the term "content" is open to intelligent dispute. > Apparently the authors of RFC3470/BCP70 believe so too. Agree. > I won't dispute your read on the consensus of the working group Agree. > but I > would like to request that *SOME* language be present in the spec that > makes this clear. Agree. I'll also note that this requirement has basically zero value for a desktop aggragator. I have only written three or four Atom parsers, but I think the approach that has the best mix of performance and correctness is one where SAX events are treated as input events for a scanner-like state machine. Leading and trailing whitespace input for these fields should be discarded by a robust scanner, and doing so proposes no risk to compliant feeds, unlike guessing the "true meaning" of an ampersand in an RSS feed. So, it will be my recommendation to ignore this MUST-level requirement of the Atom spec in any consumer aggregator that I contribute to. I think it might be useful as bozo filter in an Atom protocol server, because the lazy thing for client implementors to do is find a decent serialization library. The lazy thing for publishers to do is concatenate strings in their loosely-typed language of choice. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 04 22:52:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0sJr-0003Xd-5x for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 22:52:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26105 for ; Thu, 4 Aug 2005 22:52:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j752faLM003422; Thu, 4 Aug 2005 19:41:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j752fa2J003421; Thu, 4 Aug 2005 19:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j752fXBu003405 for ; Thu, 4 Aug 2005 19:41:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 5 Aug 2005 12:42:35 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 05 Aug 2005 12:41:29 +1000 Subject: comments spec: id URIs in @href, vs 301 Moved From: Eric Scheid To: Atom Syntax Message-ID: 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: Content-Transfer-Encoding: 7bit A question... If I have a store of entries, which of course contain many s, and at some point I retrieve various of those links and find that some of them respond with 301 Moved and a new Location ... should I then be updating the s in my store? What if those particular had @rel="in-reply-to", and per that spec would be the URIs. Would updating those URIs be wrong? Of course if updating the store at all would be wrong then all bets are off. e. From owner-atom-syntax@mail.imc.org Thu Aug 04 23:35:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0szx-0003OQ-Lo for atompub-archive@megatron.ietf.org; Thu, 04 Aug 2005 23:35:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27555 for ; Thu, 4 Aug 2005 23:35:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j753PEZA007601; Thu, 4 Aug 2005 20:25:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j753PEYC007600; Thu, 4 Aug 2005 20:25:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j753PClL007593 for ; Thu, 4 Aug 2005 20:25:12 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 03:25:06 -0000 Received: from xdsl-213-196-220-19.netcologne.de (EHLO klangraum) [213.196.220.19] by mail.gmx.net (mp014) with SMTP; 05 Aug 2005 05:25:06 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 05:30:36 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: comments spec: id URIs in @href, vs 301 Moved Message-ID: <20050805033036.GA7422@klangraum> Mail-Followup-To: Atom Syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id XAA27555 * Eric Scheid [2005-08-05 04:55]: > What if those particular had @rel=3D"in-reply-to", and > per that spec would be the URIs. Would updating those URIs > be wrong? If an atom:id happened to be a dereferencable HTTP URI and dereferencing produced 301, what would you do? The same answer (ie, nothing at all) applies to =E2=80=9Cin-reply-to.=E2=80= =9D Those aren=E2=80=99t links to a web resource. They=E2=80=99re IDs, and as= such eternal. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 00:02:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tPN-0000Bf-SL for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:02:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28513 for ; Fri, 5 Aug 2005 00:02:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j753oGZj009718; Thu, 4 Aug 2005 20:50:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j753oGoE009717; Thu, 4 Aug 2005 20:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j753oFRL009709 for ; Thu, 4 Aug 2005 20:50:16 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 5 Aug 2005 13:51:21 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 05 Aug 2005 13:50:14 +1000 Subject: Re: comments spec: id URIs in @href, vs 301 Moved From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050805033036.GA7422@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j753oGRL009712 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 ietf.org id AAA28513 On 5/8/05 1:30 PM, "A. Pagaltzis" wrote: > * Eric Scheid [2005-08-05 04:55]: >> What if those particular had @rel=3D"in-reply-to", and >> per that spec would be the URIs. Would updating those URIs >> be wrong? >=20 > If an atom:id happened to be a dereferencable HTTP URI and > dereferencing produced 301, what would you do? >=20 > The same answer (ie, nothing at all) applies to =B3in-reply-to.=B2 > Those aren=B9t links to a web resource. They=B9re IDs, and as such > eternal. ah, but how do you know those URIs are id's? or more specifically, is the following URI an id or a location? e. From owner-atom-syntax@mail.imc.org Fri Aug 05 00:11:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0tY9-00026f-RB for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:11:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28822 for ; Fri, 5 Aug 2005 00:11:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7541Lhg010430; Thu, 4 Aug 2005 21:01:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7541LYA010429; Thu, 4 Aug 2005 21:01:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7541JEN010420 for ; Thu, 4 Aug 2005 21:01:20 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 04:01:13 -0000 Received: from xdsl-213-196-220-19.netcologne.de (EHLO klangraum) [213.196.220.19] by mail.gmx.net (mp010) with SMTP; 05 Aug 2005 06:01:13 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 06:06:44 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: comments spec: id URIs in @href, vs 301 Moved Message-ID: <20050805040644.GA8015@klangraum> Mail-Followup-To: Atom Syntax References: <20050805033036.GA7422@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id AAA28822 * Eric Scheid [2005-08-05 06:00]: > ah, but how do you know those URIs are id's? >=20 > or more specifically, is the following URI an id or a location? >=20 > You don=E2=80=99t know. Just goes to show once again that Antone was right all along to rail against abusing atom:link for that purpose. Of course you could say that consumers should disregard links with relationships they don=E2=80=99t understand =E2=80=93 which, inciden= tally, is equivalent to disambiguating whether atom:link/@href is just any URI or supposed to be dereferencable. Other than those of us discussing the threading extension, noone has opined about that matter. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 00:50:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uA2-0000wa-5z for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:50:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00232 for ; Fri, 5 Aug 2005 00:50:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j754fHYk012915; Thu, 4 Aug 2005 21:41:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j754fHGb012914; Thu, 4 Aug 2005 21:41:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j754fFVX012897 for ; Thu, 4 Aug 2005 21:41:16 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 04:41:10 -0000 Received: from xdsl-213-196-220-19.netcologne.de (EHLO klangraum) [213.196.220.19] by mail.gmx.net (mp030) with SMTP; 05 Aug 2005 06:41:10 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 06:46:39 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Comments Draft Message-ID: <20050805044639.GB8015@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050731162400.GE25925@klangraum> <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> <20050801172740.GA32587@klangraum> <42F26661.1020200@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42F26661.1020200@gmail.com> 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 ietf.org id AAA00232 * James M Snell [2005-08-04 21:15]: > Personally, however, I think that the elegance and simplicity > of in-reply-to and replies link rel values trumps defining them > as elements in a separate namespace or an otherwise perfectly > engineered solution. As for specifying the source of the > resource being replied to, a namespace extension inside the > link element is probably the best way to go. I consider it stupid blunder to have proposed using atom:link for this, not elegant and simple. You need a link and an extension element either way. So choose to squirrel away information that even clients without threading support could use inside a namespaced element, and instead put information they have no use for in a place they can access. What a mess. Why not do it the other way around? > Using the via link just seems unnatural to this purpose in that > we're not expressing a relationship like "The information > contained here-in was received through..." we're expressig "The > information contained here-in is a response to...". Via works > great for the former and doesn't fit for the latter. So just drop back to =E2=80=9Crelated.=E2=80=9D Either way the exposed information is sensibly usable even by clients without threading support; they don=E2=80=99t know *why* it=E2=80=99s related, but it certa= inly is useful to let them partake of that information. > All of the examples that have been offered built around the via > mechanism just seem entirely too verbose for comfort...=20 Verbose, sure. Too verbose, how? > especially given that we're trying to optimize for optional > metadata that hints at a relationship that can't be reliably > confirmed (e.g. that the entity being replied to MAY exist at > the specified source). You are going to need a namespace any way you turn it. If you really don=E2=80=99t care about exposing as much information as they can use to as many clients as possible, and brevity is such a concern, then maybe it should be urn:foo:1 which makes this a Structured instead of a Simple Extension Element, but then maybe that was unavoidable anyway. Of course, conscientous producers will drop in a for good measure, so it=E2=80=99s verbose anyway. Hmm. Huh. Interesting. I like this even better than my previous proposition. D=E2=80=99oh. Screw sticking to Simple Extension Elements, this is better. This is *natural* =E2=80=93 no funny business with markup inside atom:link elements. Each piece of information is available to as broad an audience as possible: threading-aware clients can correlate the =E2=80=9Crelated=E2=80=9D links to the source attributes, a= nd non-aware clients can at least tell there is something related at the indicated resource. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 00:50:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uA3-0000wk-Vj for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:50:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00233 for ; Fri, 5 Aug 2005 00:50:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j754coDJ012790; Thu, 4 Aug 2005 21:38:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j754coG9012789; Thu, 4 Aug 2005 21:38:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j754coFp012781 for ; Thu, 4 Aug 2005 21:38:50 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so294841wra for ; Thu, 04 Aug 2005 21:38:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fCRCXej7zQIys120bJu86SrZadPnznE91jBN9IxODcGEdZ94hOG63Gr26EHitHaLE5K7yGqgIsH2FBDlv/D0k2y2uSC5lisVkSlsFCmaAtfMkmesia6/Vd7Zh1Pk3aR4hiDhQ9qD5wquTQqkYloe0PzuSPxrGvloMqlyz65AOGg= Received: by 10.54.51.51 with SMTP id y51mr2167766wry; Thu, 04 Aug 2005 21:38:44 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 38sm2458918wrl.2005.08.04.21.38.43; Thu, 04 Aug 2005 21:38:44 -0700 (PDT) Message-ID: <42F2ED4D.6010607@gmail.com> Date: Thu, 04 Aug 2005 21:38:37 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: comments spec: id URIs in @href, vs 301 Moved References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ietf.org id AAA00233 Eric Scheid wrote: >On 5/8/05 1:30 PM, "A. Pagaltzis" wrote: > > =20 > >>* Eric Scheid [2005-08-05 04:55]: >> =20 >> >>>What if those particular had @rel=3D"in-reply-to", and >>>per that spec would be the URIs. Would updating those URIs >>>be wrong? >>> =20 >>> >>If an atom:id happened to be a dereferencable HTTP URI and >>dereferencing produced 301, what would you do? >> >>The same answer (ie, nothing at all) applies to =B3in-reply-to.=B2 >>Those aren=B9t links to a web resource. They=B9re IDs, and as such >>eternal. >> =20 >> > >ah, but how do you know those URIs are id's? > >or more specifically, is the following URI an id or a location? > > > >e. > =20 > It's entirely dependent on the type of link. If a link relation is used=20 that you're not familiar with, you cannot make any assumptions about=20 whether or not the href is dereferenceable or not. You must treat is as=20 an opaque identifier. - James From owner-atom-syntax@mail.imc.org Fri Aug 05 00:50:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uAL-0000wz-7F for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 00:50:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00238 for ; Fri, 5 Aug 2005 00:50:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j754fvtG012961; Thu, 4 Aug 2005 21:41:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j754fvI9012960; Thu, 4 Aug 2005 21:41:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j754fvNC012951 for ; Thu, 4 Aug 2005 21:41:57 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so64405wra for ; Thu, 04 Aug 2005 21:41:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=l9MnbL84zIGmAVviyQofdVl1CQ2Z71UpU+pZpSnf2u8k+H/kSCMjWIYEJsqzG5o2nMddb+5/drD8fSsE88ah04ppQKzTmsZmNm9PHOG1L0FgoiY5M6F3pHNI9OykDEe0lvlZrdnUfTgkiCcFvbeDeXqrBqpTzPhV8muvotIsYjs= Received: by 10.54.46.30 with SMTP id t30mr2212812wrt; Thu, 04 Aug 2005 21:41:51 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id d61sm294822wra.2005.08.04.21.41.51; Thu, 04 Aug 2005 21:41:51 -0700 (PDT) Message-ID: <42F2EE07.5040307@gmail.com> Date: Thu, 04 Aug 2005 21:41:43 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: comments spec: id URIs in @href, vs 301 Moved References: <20050805033036.GA7422@klangraum> <20050805040644.GA8015@klangraum> In-Reply-To: <20050805040644.GA8015@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id AAA00238 A. Pagaltzis wrote: >* Eric Scheid [2005-08-05 06:00]: > =20 > >>ah, but how do you know those URIs are id's? >> >>or more specifically, is the following URI an id or a location? >> >> >> =20 >> > >You don=E2=80=99t know. Just goes to show once again that Antone was >right all along to rail against abusing atom:link for that >purpose. > >Of course you could say that consumers should disregard links >with relationships they don=E2=80=99t understand =E2=80=93 which, incide= ntally, >is equivalent to disambiguating whether atom:link/@href is just >any URI or supposed to be dereferencable. Other than those of us >discussing the threading extension, noone has opined about that >matter. > > =20 > I'm all for taking the approach of having consumers disregard link=20 relations they're not familiar with only I would word it differently. =20 If a consumer comes across a link relation it is not familiar with, the=20 consumer should treat the href URI as an opaque identifier and not=20 assume that it is dereferenceable. Otherwise, the definition of the=20 link relation should unambiguously indicate whether or not the href URI=20 is or is not dereferenceable. - James From owner-atom-syntax@mail.imc.org Fri Aug 05 01:19:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0uby-0006Lr-Ft for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 01:19:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01395 for ; Fri, 5 Aug 2005 01:19:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7557Hvh016823; Thu, 4 Aug 2005 22:07:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7557Hwt016822; Thu, 4 Aug 2005 22:07:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7557Ghn016808 for ; Thu, 4 Aug 2005 22:07:16 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so487226rnf for ; Thu, 04 Aug 2005 22:07:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WUczWKo8x6U/JuTxOcvryYyescuJvr0aeu2ZAaKbinxDc3zTS/jzV+ibd0wd0sSm6cHX7DRuNvPsYp9jnWFD4hhh4b1lB0rTbzPx0wmSPSxZjMXjgmZg5kk4HWZIVhMDd/eWPTHZ3dbbKw78WOSkxxEndeZn+mQPocCTVWI8rmo= Received: by 10.38.101.48 with SMTP id y48mr1178231rnb; Thu, 04 Aug 2005 22:07:15 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id k4sm1989387rnd.2005.08.04.22.07.15; Thu, 04 Aug 2005 22:07:15 -0700 (PDT) Message-ID: <42F2F3FE.2040008@gmail.com> Date: Thu, 04 Aug 2005 22:07:10 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: Comments Draft References: <20050731162400.GE25925@klangraum> <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> <20050801172740.GA32587@klangraum> <42F26661.1020200@gmail.com> <20050805044639.GB8015@klangraum> In-Reply-To: <20050805044639.GB8015@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id BAA01395 A. Pagaltzis wrote: >* James M Snell [2005-08-04 21:15]: > =20 > >>Personally, however, I think that the elegance and simplicity >>of in-reply-to and replies link rel values trumps defining them >>as elements in a separate namespace or an otherwise perfectly >>engineered solution. As for specifying the source of the >>resource being replied to, a namespace extension inside the >>link element is probably the best way to go. >> =20 >> > >I consider it stupid blunder to have proposed using atom:link for >this, not elegant and simple. > > =20 > ;-) Let's hear what you really think ;-) > > urn:foo:1 > >which makes this a Structured instead of a Simple Extension >Element, but then maybe that was unavoidable anyway. > >Of course, conscientous producers will drop in a > > > >for good measure, so it=E2=80=99s verbose anyway. > > =20 > ok.. ok.. I can take a hint ;-) ... according to my wife it only takes=20 about a couple dozen beatings to get me to think straight and listen so=20 I think we're making progress here ... How does this work for you? With a definition of: inReplyToNonDereferenceable =3D element thr:in-reply-to { attribute id { atomUri }, attribute type { atomMediaType }?, attribute src { atomUri }? } inReplyToDereferenceable =3D element thr:in-reply-to { attribute href { atomUri }, attribute type { atomMediaType }?, } This seems to tie in everything we've been discussing to this point. In=20 the NonDereferenceableForm, @id is used to express an opaque=20 identifier. @src MAY be used to specify a dereferenceable location=20 where the resource identified by @id might be found. In the=20 Dereferenceable form, @href is used to specify a location. Used in context, it would look like: ... ... Does this work or do I need to be taken out and flogged again? - James From owner-atom-syntax@mail.imc.org Fri Aug 05 02:16:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vVZ-000130-Ul for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:16:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16379 for ; Fri, 5 Aug 2005 02:16:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7560R0Z041282; Thu, 4 Aug 2005 23:00:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7560RcG041281; Thu, 4 Aug 2005 23:00:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7560PMd041030 for ; Thu, 4 Aug 2005 23:00:26 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 5 Aug 2005 16:00:57 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 05 Aug 2005 15:59:51 +1000 Subject: Re: Comments Draft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42F2F3FE.2040008@gmail.com> 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: Content-Transfer-Encoding: 7bit On 5/8/05 3:07 PM, "James M Snell" wrote: > src="http://www.example.com/atom" /> how about this instead this way processors that have a basic understanding of what a is can still do something useful. e. From owner-atom-syntax@mail.imc.org Fri Aug 05 02:30:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0vjB-0004fd-Kn for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:30:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17799 for ; Fri, 5 Aug 2005 02:30:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j756LitD049891; Thu, 4 Aug 2005 23:21:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j756LiMZ049890; Thu, 4 Aug 2005 23:21:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j756Lhc3049841 for ; Thu, 4 Aug 2005 23:21:43 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050805062137.WGKH21883.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com> for ; Fri, 5 Aug 2005 07:21:37 +0100 Received: from cpc3-stok1-5-0-cust143.bagu.cable.ntl.com ([82.11.128.143]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20050805062137.KIRB12116.aamta10-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust143.bagu.cable.ntl.com> for ; Fri, 5 Aug 2005 07:21:37 +0100 Date: Fri, 5 Aug 2005 07:21:37 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1939577739.20050805072137@djpowell.net> To: atom-syntax@imc.org Subject: Simple Extensions and xml:base 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: Content-Transfer-Encoding: 7bit The intention of Simple Extension Elements is to provide a simple class of extension that is part of the Atom model, and can therefore be preserved end-to-end by implementions via publishing clients, servers, databases, and aggregators. We say that Simple Extension Elements are not language sensitive, but we don't say that Simple Extension constructs aren't affected by xml:base. I think that the implication is that they are not, but it is not very explicit: > [...] Simple Extension elements are not Language-Sensitive. The > element can be interpreted as a simple property (or name/value pair) > of the parent element that encloses it. [...] The character data > content of the element can be interpreted as the value of the > property. If the element is empty, then the property value can be > interpreted as an empty string. It doesn't make sense for Simple Extension Elements to be affected by xml:base, because that requires extensions specific processing to know whether the extension is intended to be a URIRef or not; avoiding extension specific processing is the reason for Simple Extension Elements existence. Can we add some clarification? -- Dave From owner-atom-syntax@mail.imc.org Fri Aug 05 03:57:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0x5L-0000aQ-In for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 03:57:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23405 for ; Fri, 5 Aug 2005 03:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j757jDi9084465; Fri, 5 Aug 2005 00:45:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j757jD5X084464; Fri, 5 Aug 2005 00:45:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j757jBeS084403 for ; Fri, 5 Aug 2005 00:45:12 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 07:45:06 -0000 Received: from xdsl-213-196-220-19.netcologne.de (EHLO klangraum) [213.196.220.19] by mail.gmx.net (mp019) with SMTP; 05 Aug 2005 09:45:06 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 09:50:36 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Comments Draft Message-ID: <20050805075036.GA8481@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050731162400.GE25925@klangraum> <1F05FC15-02A8-11DA-8129-003065EA6144@geckotribe.com> <20050801172740.GA32587@klangraum> <42F26661.1020200@gmail.com> <20050805044639.GB8015@klangraum> <42F2F3FE.2040008@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42F2F3FE.2040008@gmail.com> 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 ietf.org id DAA23405 * James M Snell [2005-08-05 07:15]: > Does this work or do I need to be taken out and flogged again? Absolutely that does work for me. (Sorry for the curt reply =E2=80=93 I am off to catch a plane in a few minutes and won=E2=80=99t have =E2=80=99net for a week. Tried to get this= out before I am gone. And sorry for the harsh tone. :-) ) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 05:53:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ytT-00088R-64 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 05:53:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29771 for ; Fri, 5 Aug 2005 05:53:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j759gsTW026097; Fri, 5 Aug 2005 02:42:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j759gsba026096; Fri, 5 Aug 2005 02:42:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j759gqYS026053 for ; Fri, 5 Aug 2005 02:42:53 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 09:42:47 -0000 Received: from xdsl-213-196-220-19.netcologne.de (EHLO klangraum) [213.196.220.19] by mail.gmx.net (mp030) with SMTP; 05 Aug 2005 11:42:47 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 11:48:17 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Comments Draft Message-ID: <20050805094817.GA8753@klangraum> Mail-Followup-To: Atom Syntax References: <42F2F3FE.2040008@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id FAA29771 * Eric Scheid [2005-08-05 08:10]: > how about this instead >=20 > href=3D"http://www.example.com/atom" > type=3D"application/atom+xml" > thread:idref=3D"urn:foo:1" /> >=20 > this way processors that have a basic understanding of what a > is can still do something useful. No, that requires entries to be located in a feed available at a dereferencable URI because @href is not optional. So it would preclude replying to feeds delivered via SMTP, XMPP or other protocols that don=E2=80=99t work like that. You can try messy workarounds, but please, let=E2=80=99s not go there yet again. Please read my =E2=80=9Crefactoring=E2=80=9D post for a long trail of thoughts w= hich addresses pretty well everything which has been brought up since. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 06:41:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0zdj-0001oI-Ei for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 06:41:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01670 for ; Fri, 5 Aug 2005 06:41:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75AVd8J044001; Fri, 5 Aug 2005 03:31:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75AVdvX044000; Fri, 5 Aug 2005 03:31:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j75AVcE2043963 for ; Fri, 5 Aug 2005 03:31:39 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 78921 messnum 6679871 invoked from network[213.94.211.166/vienna.propylon.com]); 5 Aug 2005 10:31:32 -0000 Received: from vienna.propylon.com (HELO ?127.0.0.1?) (213.94.211.166) by mail10.svc.cra.dublin.eircom.net (qp 78921) with SMTP; 5 Aug 2005 10:31:32 -0000 Message-ID: <42F34000.8000107@dehora.net> Date: Fri, 05 Aug 2005 11:31:28 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> In-Reply-To: <68fba5c505080419247f735ee9@mail.gmail.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > I'll also note that this requirement has basically zero value for a > desktop aggragator. I have only written three or four Atom parsers, > but I think the approach that has the best mix of performance and > correctness is one where SAX events are treated as input events for a > scanner-like state machine. Leading and trailing whitespace input for > these fields should be discarded by a robust scanner, and doing so > proposes no risk to compliant feeds, unlike guessing the "true > meaning" of an ampersand in an RSS feed. So, it will be my > recommendation to ignore this MUST-level requirement of the Atom spec > in any consumer aggregator that I contribute to. I think it might be > useful as bozo filter in an Atom protocol server, because the lazy > thing for client implementors to do is find a decent serialization > library. The lazy thing for publishers to do is concatenate strings in > their loosely-typed language of choice. If you're going to recommend ignoring it in practice, why not recommend throwing it out? Why equivocate? cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 05 08:01:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10sx-0003vB-Pb for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 08:01:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05603 for ; Fri, 5 Aug 2005 08:01:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75BoaBF072596; Fri, 5 Aug 2005 04:50:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75Boaca072595; Fri, 5 Aug 2005 04:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75BoYYe072581 for ; Fri, 5 Aug 2005 04:50:35 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j75BoYvU023110 for ; Fri, 5 Aug 2005 05:50:34 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKQ009VNZK97R@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:50:34 -0600 (MDT) Received: from [10.12.0.239] ([65.89.25.202]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKQ00KTNZK92V@mail.sun.net> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:50:33 -0600 (MDT) Date: Fri, 05 Aug 2005 04:50:52 -0700 From: Tim Bray Subject: Re: Simple Extensions and xml:base In-reply-to: <1939577739.20050805072137@djpowell.net> To: David Powell Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <1939577739.20050805072137@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 11:21 PM, David Powell wrote: > We say that Simple Extension Elements are not language sensitive, but > we don't say that Simple Extension constructs aren't affected by > xml:base. I think that the implication is that they are not, but it > is not very explicit: They *are* affected by xml:base. xml:base establishes the base URI for wherever it's in-scope, with a specific callout to RFC3986 for the semantics. Anytime you see something that you know is a relative URI reference, you have to absolutize it using the base URI, and the base URI is what xml:base says it is. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 05 08:04:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10vi-0004Hn-8e for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 08:04:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05783 for ; Fri, 5 Aug 2005 08:04:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75BrjWH073598; Fri, 5 Aug 2005 04:53:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75Brj6F073597; Fri, 5 Aug 2005 04:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Bri2q073586 for ; Fri, 5 Aug 2005 04:53:44 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j75Brir3009583 for ; Fri, 5 Aug 2005 05:53:44 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKQ00FJPZPJQP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:53:44 -0600 (MDT) Received: from [10.12.0.239] ([65.89.25.202]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKQ003SGZPGYW@mail.sun.net> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:53:41 -0600 (MDT) Date: Fri, 05 Aug 2005 04:53:59 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <68fba5c505080419247f735ee9@mail.gmail.com> To: Robert Sayre Cc: Sam Ruby , atom-syntax@imc.org Message-id: <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <42EF5DFD.8070308@internetalchemy.org> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote: > Leading and trailing whitespace input for > these fields should be discarded by a robust scanner, and doing so > proposes no risk to compliant feeds, unlike guessing the "true > meaning" of an ampersand in an RSS feed. So, it will be my > recommendation to ignore this MUST-level requirement of the Atom spec > in any consumer aggregator that I contribute to. I think it might be > useful as bozo filter in an Atom protocol server, because the lazy > thing for client implementors to do is find a decent serialization > library. The lazy thing for publishers to do is concatenate strings in > their loosely-typed language of choice. Uh, anyone who's lazily concatenating strings is pretty soon going to end up with a free ampersand or something worse in their Atom feed. Right? -Tim From owner-atom-syntax@mail.imc.org Fri Aug 05 08:04:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E10w6-0004K5-Mt for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 08:04:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05820 for ; Fri, 5 Aug 2005 08:04:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75BtnCC074266; Fri, 5 Aug 2005 04:55:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75Btn1i074265; Fri, 5 Aug 2005 04:55:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75BtfAL074214 for ; Fri, 5 Aug 2005 04:55:42 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j75Btfr3010951 for ; Fri, 5 Aug 2005 05:55:41 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKQ00FS6ZSSQP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:55:41 -0600 (MDT) Received: from [10.12.0.239] ([65.89.25.202]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKQ00KUYZSR2V@mail.sun.net> for atom-syntax@imc.org; Fri, 05 Aug 2005 05:55:40 -0600 (MDT) Date: Fri, 05 Aug 2005 04:55:58 -0700 From: Tim Bray Subject: Re: Comments Draft In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote: > href="http://www.example.com/atom" > type="application/atom+xml" > thread:idref="urn:foo:1" /> > > this way processors that have a basic understanding of what a > is can > still do something useful. Uh, consider What useful thing is there that software could sanely do, knowing only that something is a link? -Tim From owner-atom-syntax@mail.imc.org Fri Aug 05 08:27:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11IK-0001LR-TV for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 08:27:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07036 for ; Fri, 5 Aug 2005 08:27:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75CGMP9081401; Fri, 5 Aug 2005 05:16:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75CGMLT081399; Fri, 5 Aug 2005 05:16:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75CGLjO081367 for ; Fri, 5 Aug 2005 05:16:22 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 5 Aug 2005 22:17:23 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 05 Aug 2005 22:16:15 +1000 Subject: Re: Comments Draft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: 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: Content-Transfer-Encoding: 7bit On 5/8/05 9:55 PM, "Tim Bray" wrote: > Uh, consider > > href="http://example.org/evil" /> > > What useful thing is there that software could sanely do, knowing > only that something is a link? -Tim > not knowing what that particular @rel actually means, it could still treat it as @rel="related" because the referenced resource is, uh, related. so, what could software sanely do with a link[@rel="related"], other than catch on fire? e. From owner-atom-syntax@mail.imc.org Fri Aug 05 09:11:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11zR-0004QM-A4 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 09:11:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09149 for ; Fri, 5 Aug 2005 09:11:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75D01nV097336; Fri, 5 Aug 2005 06:00:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75D01ie097335; Fri, 5 Aug 2005 06:00:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75CxxPV097312 for ; Fri, 5 Aug 2005 06:00:00 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 94503 invoked from network); 5 Aug 2005 12:59:48 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 5 Aug 2005 12:59:48 -0000 Received: from host217-36-49-205.in-addr.btopenworld.com (host217-36-49-205.in-addr.btopenworld.com [217.36.49.205]) by webmail.djpowell.net (IMP) with HTTP for ; Fri, 5 Aug 2005 13:59:48 +0100 Message-ID: <1123246788.42f362c48a9ff@webmail.djpowell.net> Date: Fri, 5 Aug 2005 13:59:48 +0100 From: David Powell To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: Simple Extensions and xml:base References: <1939577739.20050805072137@djpowell.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.36.49.205 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Tim Bray : > On Aug 4, 2005, at 11:21 PM, David Powell wrote: > > > We say that Simple Extension Elements are not language sensitive, but > > we don't say that Simple Extension constructs aren't affected by > > xml:base. I think that the implication is that they are not, but it > > is not very explicit: > > They *are* affected by xml:base. xml:base establishes the base URI > for wherever it's in-scope, with a specific callout to RFC3986 for > the semantics. Anytime you see something that you know is a relative > URI reference, you have to absolutize it using the base URI, and the > base URI is what xml:base says it is. -Tim Yes, I understand, but I disagree. xml:base only affects things that are designated to be URI references. I wouldn't expect /index.html to get resolved as a URI, because atom:title isn't defined to be a URIRef. Neither are Simple Extension Elements. There is a layering. Implementors of draft-ietf-atompub-format-10 can never know that an arbitrary Simple Extension Element's value is a URI reference, so it can never be treated as one; the value is clearly stated to be a language-insensitive string, not a URIRef, therefore xml:base has no effect. Specifications for extensions may declare that the string value should be interpretted by applications as being a URI (or a date, or an integer, or whatever), but we are at a different layer now, the xml:base of the element that the property was declared is as irrelevent as its namespace-prefix. -- Dave From owner-atom-syntax@mail.imc.org Fri Aug 05 09:17:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1255-0005Ro-OX for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 09:17:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09374 for ; Fri, 5 Aug 2005 09:17:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75D8evp000579; Fri, 5 Aug 2005 06:08:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75D8eLE000578; Fri, 5 Aug 2005 06:08:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j75D8dAx000535 for ; Fri, 5 Aug 2005 06:08:39 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 41881 messnum 5250239 invoked from network[213.94.211.166/mail2.newbay.com]); 5 Aug 2005 13:08:32 -0000 Received: from mail2.newbay.com (HELO ?127.0.0.1?) (213.94.211.166) by mail02.svc.cra.dublin.eircom.net (qp 41881) with SMTP; 5 Aug 2005 13:08:32 -0000 Message-ID: <42F364CA.9050305@dehora.net> Date: Fri, 05 Aug 2005 14:08:26 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Simple Extensions and xml:base References: <1939577739.20050805072137@djpowell.net> In-Reply-To: X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 4, 2005, at 11:21 PM, David Powell wrote: > >> We say that Simple Extension Elements are not language sensitive, but >> we don't say that Simple Extension constructs aren't affected by >> xml:base. I think that the implication is that they are not, but it >> is not very explicit: > > > They *are* affected by xml:base. xml:base establishes the base URI for > wherever it's in-scope, with a specific callout to RFC3986 for the > semantics. Anytime you see something that you know is a relative URI > reference, you have to absolutize it using the base URI, and the base > URI is what xml:base says it is. -Tim What Tim said. The xml:base is generic XML tech, so implementations won't/can't care about extension specifics of Atom. Asking people's XML tool chains to handle Atom base processing in a special way... pain, lots of pain ;) cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 05 09:22:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12A1-0006xS-KZ for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 09:22:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09905 for ; Fri, 5 Aug 2005 09:22:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75DCpNU001983; Fri, 5 Aug 2005 06:12:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75DCpTf001982; Fri, 5 Aug 2005 06:12:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j75DCokZ001941 for ; Fri, 5 Aug 2005 06:12:50 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 69989 messnum 3315836 invoked from network[213.94.211.166/vienna.propylon.com]); 5 Aug 2005 13:12:43 -0000 Received: from vienna.propylon.com (HELO ?127.0.0.1?) (213.94.211.166) by mail05.svc.cra.dublin.eircom.net (qp 69989) with SMTP; 5 Aug 2005 13:12:43 -0000 Message-ID: <42F365C3.8010905@dehora.net> Date: Fri, 05 Aug 2005 14:12:35 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> In-Reply-To: <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote: > >> Leading and trailing whitespace input for >> these fields should be discarded by a robust scanner, and doing so >> proposes no risk to compliant feeds, unlike guessing the "true >> meaning" of an ampersand in an RSS feed. So, it will be my >> recommendation to ignore this MUST-level requirement of the Atom spec >> in any consumer aggregator that I contribute to. I think it might be >> useful as bozo filter in an Atom protocol server, because the lazy >> thing for client implementors to do is find a decent serialization >> library. The lazy thing for publishers to do is concatenate strings in >> their loosely-typed language of choice. > > > Uh, anyone who's lazily concatenating strings is pretty soon going to > end up with a free ampersand or something worse in their Atom feed. > Right? -Tim Right. Doesn't mean everyone (statistically speaking) isn't doing it. Using templating languages to generate feeds comes to mind. cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 05 10:08:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E12sR-0000Yh-11 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 10:08:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12111 for ; Fri, 5 Aug 2005 10:08:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75DxJDY020286; Fri, 5 Aug 2005 06:59:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75DxJRv020285; Fri, 5 Aug 2005 06:59:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75DxIeb020243 for ; Fri, 5 Aug 2005 06:59:18 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so142311wra for ; Fri, 05 Aug 2005 06:59:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ikjuvCPSW5oCFFwC/NfHst56/pHWkr1o3u3VtM+EQUv35fPKtIcfZ64zD2jeJ/sovW98nJ9NKfxnnXk+VEc/DHrCgE1wY3ibDjv381RBagvMrb0bX/5c4DS+n7I4IM0b0bqt7WI5nv1Zh5FtNnm6euRStzOuq2zPjIOUchkI8BY= Received: by 10.54.36.43 with SMTP id j43mr2481483wrj; Fri, 05 Aug 2005 06:59:12 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 5 Aug 2005 06:59:10 -0700 (PDT) Message-ID: <68fba5c50508050659507bc569@mail.gmail.com> Date: Fri, 5 Aug 2005 09:59:10 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: spec bug: can we fix for draft-11? Cc: atom-syntax@imc.org In-Reply-To: <42F34000.8000107@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <42F34000.8000107@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j75DxIeb020278 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 ietf.org id KAA12111 On 8/5/05, Bill de h=D3ra wrote: > If you're going to recommend ignoring it in practice, why not recommend > throwing it out? Why equivocate? You keep saying "equivocate", as if there were some hard-to-swallow truth I'm avoiding. I'm suggesting saying something vague because the situation is vague, it doesn't matter very much, and I don't consider detailed information oh whitespace in XML feeds to be the Purpose Of Atom. I'm going to recommend ignoring it to people writing Atom processors with the intent of consuming a wide variety of feeds for consumer usage. My favorite use case is Grandmother Trying To View Pictures Of Her Grandchildren. Am I going to prevent that from happening in order enforce a whitespace rule? Since there are no compliant feeds I'm hurting, it's an easy decision to make. That said, I know from experience that it's very easy to write an Atom Processor that would choke on such whitespace. I would like for those processors to be supported by the spec as compliant, because writing one should not have to be an exercise in Keep-Going-No-Matter-What consumer software in all cases. I don't really care how they are supported (MAY, SHOULD, MUST...), because it doesn't matter. We do need to write something that lets the feed validator warn people about it, but actually trying to enforce a MUST-level requirement here seems like pissing into the wind. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 05 11:09:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E13ot-0006ct-B3 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 11:09:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15778 for ; Fri, 5 Aug 2005 11:09:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75EtKbi035236; Fri, 5 Aug 2005 07:55:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75EtKcD035235; Fri, 5 Aug 2005 07:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75EtJ1b035229 for ; Fri, 5 Aug 2005 07:55:19 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j75EtJvU027659 for ; Fri, 5 Aug 2005 08:55:19 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKR009QD8467R@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 05 Aug 2005 08:55:19 -0600 (MDT) Received: from [10.192.5.13] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKR00K4T8462V@mail.sun.net> for atom-syntax@imc.org; Fri, 05 Aug 2005 08:55:18 -0600 (MDT) Date: Fri, 05 Aug 2005 07:55:38 -0700 From: Tim Bray Subject: Re: Simple Extensions and xml:base In-reply-to: <1123246788.42f362c48a9ff@webmail.djpowell.net> To: David Powell Cc: atom-syntax@imc.org Message-id: <5A4243E0-3851-4188-A727-BC04D77866C5@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <1939577739.20050805072137@djpowell.net> <1123246788.42f362c48a9ff@webmail.djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 5, 2005, at 5:59 AM, David Powell wrote: >>> We say that Simple Extension Elements are not language sensitive, >>> but >> They *are* affected by xml:base. xml:base establishes the base URI >> for wherever it's in-scope, with a specific callout to RFC3986 for >> the semantics. Anytime you see something that you know is a relative >> URI reference, you have to absolutize it using the base URI, and the >> base URI is what xml:base says it is. -Tim > > Yes, I understand, but I disagree. xml:base only affects things > that are > designated to be URI references. I wouldn't expect > /index.html to get resolved as a URI, because > atom:title isn't defined to be a URIRef. Neither are Simple Extension > Elements. Right, but anyone who reads a simple extension out of an Atom feed and finds something they consider to be a relative URI reference, and wants to absolutize the reference, either uses the base URI as established by xml:base, or they are wrong. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 05 12:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E14l4-0002rd-65 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 12:09:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18088 for ; Fri, 5 Aug 2005 12:09:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75G37GQ041680; Fri, 5 Aug 2005 09:03:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75G37sc041679; Fri, 5 Aug 2005 09:03:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j75G2w1T041657 for ; Fri, 5 Aug 2005 09:03:06 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 Aug 2005 16:02:51 -0000 Received: from xdsl-213-196-221-229.netcologne.de (EHLO klangraum) [213.196.221.229] by mail.gmx.net (mp012) with SMTP; 05 Aug 2005 18:02:51 +0200 X-Authenticated: #163624 Date: Fri, 5 Aug 2005 18:08:22 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Message-ID: <20050805160822.GB23602@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> 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 ietf.org id MAA18088 * Tim Bray [2005-08-05 14:05]: > Uh, anyone who's lazily concatenating strings is pretty soon > going to end up with a free ampersand or something worse in > their Atom feed. Right? I think that=E2=80=99s a bit grand of a generalization. It=E2=80=99s not hard to build XML by concatening strings, after all, a DOM serializer doesn=E2=80=99t do anything else. The strategy is to establish which concatenations expect XML fragments and which expect content, and to be diligent about turning the latter into the former when such is expected, by way of escaping. It=E2=80=99s the strategy. I=E2=80=99ve written that sort of code more times than I care to count and I=E2=80=99ve never had an escaping bug in it. It=E2=80=99s trivial. S= o just because someone=E2=80=99s concatenating strings in a template doesn=E2=80= =99t mean they=E2=80=99re lazy or dumb, but they can still fall for this trap. I suggest simply the following: in 4.2.6 (The "atom:id" Element), change Its content MUST be an IRI, as defined by [RFC3987]. to read: Its content MUST be an IRI, as defined by [RFC3987], and MUST NOT contain any whitespace. It doesn=E2=80=99t change anything, it just says the same thing more explicitly. In addition, the same minimal change should be applied to * 3.2.2 (The "atom:uri" Element) * 3.2.3 (The "atom:email" Element) * 3.3 (Date Constructs) * 4.2.5 (The "atom:icon" Element) * 4.2.8 (The "atom:logo" Element) which all contain either a URI, an ISO date, or an email address. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 05 12:10:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E14lv-00032j-1J for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 12:10:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18131 for ; Fri, 5 Aug 2005 12:10:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75G1QrC041289; Fri, 5 Aug 2005 09:01:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75G1QgI041288; Fri, 5 Aug 2005 09:01:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j75G1Psw041276 for ; Fri, 5 Aug 2005 09:01:25 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 45454 messnum 5271707 invoked from network[213.94.211.166/mail2.newbay.com]); 5 Aug 2005 16:01:19 -0000 Received: from mail2.newbay.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 45454) with SMTP; 5 Aug 2005 16:01:19 -0000 Message-ID: <42F38D4B.3070902@dehora.net> Date: Fri, 05 Aug 2005 17:01:15 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <42F34000.8000107@dehora.net> <68fba5c50508050659507bc569@mail.gmail.com> In-Reply-To: <68fba5c50508050659507bc569@mail.gmail.com> X-Enigmail-Version: 0.92.0.0 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 ietf.org id MAA18131 Robert Sayre wrote: > On 8/5/05, Bill de h=D3ra wrote: >=20 >>If you're going to recommend ignoring it in practice, why not recommend >>throwing it out? Why equivocate? >=20 >=20 > You keep saying "equivocate", as if there were some hard-to-swallow > truth I'm avoiding.=20 I've said it twice; don't take it personally it's not an attack. > I'm suggesting saying something vague because the > situation is vague, it doesn't matter very much, and I don't consider > detailed information oh whitespace in XML feeds to be the Purpose Of > Atom. The siutation didn't just happen to be vague, we made it vague, I don't agree it doesn't matter, and if the Atom spec can't get it's story straight on whitespace to the extent one of the editors is going to advise people to ignore a MUST directive that one of the chairs and others believes has strong consensus support from the WG, then I firmly believe that puts detailed information on whitespace on the table. Finally, if there is a Purpose Of Atom I suspect it has something to do with clarity and unambiguity in specification - and this is not it. > I'm going to recommend ignoring it to people writing Atom processors > with the intent of consuming a wide variety of feeds for consumer > usage. My favorite use case is Grandmother Trying To View Pictures Of > Her Grandchildren. Am I going to prevent that from happening in order > enforce a whitespace rule? Since there are no compliant feeds I'm > hurting, it's an easy decision to make. >=20 > That said, I know from experience that it's very easy to write an Atom > Processor that would choke on such whitespace. I would like for those > processors to be supported by the spec as compliant, because writing > one should not have to be an exercise in Keep-Going-No-Matter-What > consumer software in all cases. I don't really care how they are > supported (MAY, SHOULD, MUST...), because it doesn't matter. We do > need to write something that lets the feed validator warn people about > it, but actually trying to enforce a MUST-level requirement here seems > like pissing into the wind. I read that as saying we have a broken spec. If there's another way to read it, help me out. This entire thread is like being in a Joseph Heller novel, except its called Catch-32. cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 05 12:25:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E150T-0008NS-58 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 12:25:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18850 for ; Fri, 5 Aug 2005 12:25:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75GKJIS043048; Fri, 5 Aug 2005 09:20:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75GKJup043047; Fri, 5 Aug 2005 09:20:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75GKIbO043032 for ; Fri, 5 Aug 2005 09:20:19 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i6so352840wra for ; Fri, 05 Aug 2005 09:20:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jgw/P3Y2upp0bFGV5bT7OYal3PyCbnoercjSpYfLYl0mNJM7y9KiM18GDDo3Im8XRciPHvRg4KfJSIcNV0NFljgH2v1FeERHmU1Fr7pmqbQlsYoHnmbXcs8Q/lS15pGaF4ypzMYzjXk+WbatGpDRKAiS335/WKfhPZ930NF7Wjo= Received: by 10.54.4.8 with SMTP id 8mr2686162wrd; Fri, 05 Aug 2005 09:20:13 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id g12sm1042258wra.2005.08.05.09.20.12; Fri, 05 Aug 2005 09:20:13 -0700 (PDT) Message-ID: <42F391B9.5000103@gmail.com> Date: Fri, 05 Aug 2005 09:20:09 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <14FFF7DA-AFA9-4E8E-BF49-91DF2AE9C7A2@Sun.COM> <20050805160822.GB23602@klangraum> In-Reply-To: <20050805160822.GB23602@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id MAA18850 A. Pagaltzis wrote: > I suggest simply the following: in 4.2.6 (The "atom:id" Element), > >change > > Its content MUST be an IRI, as defined by [RFC3987]. > >to read: > > Its content MUST be an IRI, as defined by [RFC3987], and MUST > NOT contain any whitespace. > >It doesn=E2=80=99t change anything, it just says the same thing more >explicitly. > > =20 > I'm not convinced that we need "MUST NOT contain any whitespace". How=20 about something along the lines of: "Its content MUST be an ..., and SHOULD NOT contain any whitespace.=20 Software written to conform to this version of the specification MUST=20 remove all leading and trailing whitespace that happens to appear in the=20 value." Ok, so the wording can be cleaned up a bit, but you get the point. With=20 this language, the validator can flag a warning if whitespace does=20 appear but conformant parsers can be written to handle cases when=20 whitespace does appear. This also shifts the burden of ensuring correct=20 handling of whitespace to the feed reader rather than the feed producer=20 which is significantly better IMHO. >In addition, the same minimal change should be applied to > >* 3.2.2 (The "atom:uri" Element) >* 3.2.3 (The "atom:email" Element) >* 3.3 (Date Constructs) >* 4.2.5 (The "atom:icon" Element) >* 4.2.8 (The "atom:logo" Element) > >which all contain either a URI, an ISO date, or an email address. > > =20 > +1 >Regards, > =20 > - James From owner-atom-syntax@mail.imc.org Fri Aug 05 12:32:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1577-0001Nt-RQ for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 12:32:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19084 for ; Fri, 5 Aug 2005 12:32:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75GPF5I043502; Fri, 5 Aug 2005 09:25:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75GPFwf043501; Fri, 5 Aug 2005 09:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75GPE12043465 for ; Fri, 5 Aug 2005 09:25:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so172918wra for ; Fri, 05 Aug 2005 09:25:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s88KMEii1b1Btk9r4F5PIpDMh0CdU6ia/IJU8oNqvgeYfHg7ky0i+XF6BOOzNkZnjyOiRpPqNIm6G7I7UVTJgPBHEMIO0n/2bMIbarcIpfMRunGSTePgWApuSGMUO+p5PR0d+pAHO4rzcsA/u9L5+ZUR9vqdn7LUiD55hH2N+S0= Received: by 10.54.144.7 with SMTP id r7mr2617970wrd; Fri, 05 Aug 2005 09:25:08 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 5 Aug 2005 09:25:08 -0700 (PDT) Message-ID: <68fba5c50508050925360e7f2e@mail.gmail.com> Date: Fri, 5 Aug 2005 12:25:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: spec bug: can we fix for draft-11? Cc: atom-syntax@imc.org In-Reply-To: <42F38D4B.3070902@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EF5DFD.8070308@internetalchemy.org> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <68fba5c505080419247f735ee9@mail.gmail.com> <42F34000.8000107@dehora.net> <68fba5c50508050659507bc569@mail.gmail.com> <42F38D4B.3070902@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j75GPE12043496 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 ietf.org id MAA19084 On 8/5/05, Bill de h=D3ra wrote: > The siutation didn't just happen to be vague, we made it vague, I don't > agree it doesn't matter, and if the Atom spec can't get it's story > straight on whitespace to the extent one of the editors is going to > advise people to ignore a MUST directive=20 To be clear, I would not go shouting this opinion from the rooftops.=20 > that one of the chairs and > others believes has strong consensus support from the WG, then I firmly > believe that puts detailed information on whitespace on the table. Paul, Tim, and I have all proposed text. All of them communicate the reality, and they would all do the job. Graham +1ed Sam's idea, but there was no spec text there. Mnot has pointed out we should write something, because of the BCP, so let's just write something, like now. Robert Sayre Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 05 13:27:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15yg-0006sc-9u for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 13:27:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21769 for ; Fri, 5 Aug 2005 13:27:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75HKqHa048240; Fri, 5 Aug 2005 10:20:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75HKqDa048239; Fri, 5 Aug 2005 10:20:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75HKoSD048228 for ; Fri, 5 Aug 2005 10:20:51 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 6 Aug 2005 03:21:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 06 Aug 2005 03:20:45 +1000 Subject: Re: Comments Draft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050805094817.GA8753@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j75HKqSD048232 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 ietf.org id NAA21769 On 5/8/05 7:48 PM, "A. Pagaltzis" wrote: >> > href=3D"http://www.example.com/atom" >> type=3D"application/atom+xml" >> thread:idref=3D"urn:foo:1" /> >>=20 >> this way processors that have a basic understanding of what a >> is can still do something useful. >=20 > No, that requires entries to be located in a feed available at a > dereferencable URI because @href is not optional. So it would > preclude replying to feeds delivered via SMTP, XMPP or other > protocols that don=B9t work like that. Ah dammit, you're right. There was blood spilled to allow entries to not = be required to have an alternate too, so we can't even point at that. e. From owner-atom-syntax@mail.imc.org Fri Aug 05 14:10:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16eF-0008Ik-KP for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 14:10:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24041 for ; Fri, 5 Aug 2005 14:10:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75I49qL059419; Fri, 5 Aug 2005 11:04:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75I49F3059418; Fri, 5 Aug 2005 11:04:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75I48uG059387 for ; Fri, 5 Aug 2005 11:04:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so662460wra for ; Fri, 05 Aug 2005 11:04:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VkxegS3KZwPeCoIb8vs4PF48pcYzAgCO0kH4GphmdcvzZRRrIKU/KYHC2hPrQPwU15BIkv81Ia0TDkYGVot5ETYb7+3anXq6P4McML6BkmuSObWA61CeVCDwZ02wulTDWbcsFgg17EtweaC5mRYBdGbyX3nDgjP7q914Rh2Wh00= Received: by 10.54.68.16 with SMTP id q16mr2705781wra; Fri, 05 Aug 2005 11:04:03 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 5 Aug 2005 11:04:03 -0700 (PDT) Message-ID: <68fba5c50508051104b4b4a00@mail.gmail.com> Date: Fri, 5 Aug 2005 14:04:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Two Proposed Resolutions for whitespace handling. Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j75I49uG059413 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In Section 2, paragraph 5, Both kinds of Atom Documents are specified in terms of the XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and identified with the "application/atom+xml" media type. Atom Documents MUST be well-formed XML. This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML). append one of the following: 1.) Atom processors MAY consider leading and trailing whitespace in element and attribute values to be significant. 2.) In attribute values and elements containing text, leading and trailing whitespace is considered significant. I give a big +1 to either option. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 05 14:25:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E16sT-0002uN-Np for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 14:25:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24558 for ; Fri, 5 Aug 2005 14:25:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75IICT1060771; Fri, 5 Aug 2005 11:18:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75IICmm060770; Fri, 5 Aug 2005 11:18:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75IIBFC060753 for ; Fri, 5 Aug 2005 11:18:11 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so179275wra for ; Fri, 05 Aug 2005 11:18:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WLRRTj3LMEo2AhJbGZzHuwf+Gg7Odw5Zv8j9Db9eqxszyyKVSDZ/dOxefyvJMiai8QXfH+iSA+XUSNMVLHPb2CoSlkeb5yL/xUHb/C97825VYfr+othe8VhQN8B+2ivLdE6iwXSJMUTmFDf8y9VrANALymcAKBO+n6OHqjWL15I= Received: by 10.54.56.69 with SMTP id e69mr2796658wra; Fri, 05 Aug 2005 11:18:05 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 13sm1925381wrl.2005.08.05.11.18.05; Fri, 05 Aug 2005 11:18:05 -0700 (PDT) Message-ID: <42F3AD59.8060101@gmail.com> Date: Fri, 05 Aug 2005 11:18:01 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Two Proposed Resolutions for whitespace handling. References: <68fba5c50508051104b4b4a00@mail.gmail.com> In-Reply-To: <68fba5c50508051104b4b4a00@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >In Section 2, paragraph 5, > > Both kinds of Atom Documents are specified in terms of the XML > Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and > identified with the "application/atom+xml" media type. Atom > Documents MUST be well-formed XML. This specification does not > define a DTD for Atom Documents, and hence does not require them to > be valid (in the sense used by XML). > >append one of the following: > >1.) Atom processors MAY consider leading and trailing whitespace in >element and attribute values to be significant. > >2.) In attribute values and elements containing text, leading and >trailing whitespace is considered significant. > >I give a big +1 to either option. > >Robert Sayre > > > > +1 to #1 From owner-atom-syntax@mail.imc.org Fri Aug 05 17:46:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1A1n-000557-36 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 17:46:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05438 for ; Fri, 5 Aug 2005 17:46:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Lboaw085928; Fri, 5 Aug 2005 14:37:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75LbokK085927; Fri, 5 Aug 2005 14:37:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75LbnlO085916 for ; Fri, 5 Aug 2005 14:37:49 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 354A869 for ; Fri, 5 Aug 2005 14:37:44 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j75LbVkv025934 for ; Fri, 5 Aug 2005 14:37:43 -0700 (PDT) Date: Fri, 05 Aug 2005 14:37:02 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? Message-ID: <3F58950E734914DBC970ED25@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 4, 2005 9:31:55 AM -0700 Tim Bray wrote: > > So for now, I'm -1 on an weakening or removing "The element's content MUST be > an IRI" or analogous text in any other section. I'll stop shouting if I'm in > a small minority here. -Tim Wow, this string has made my "away on vacation" mailbox fatter. I strongly favor making white space around IRIs illegal in Atom, whether they are an ID or somewhere else. Same for dates. This follows the robustness principle, where we are conservative in what we generate. Atom processors are free to be liberal in what they accept, so they can strip whitespace. Or not, I don't care. Note that a feed with whitespace around an IRI can never be aggregated into another feed, because a) the ID IRI cannot be changed, and b) the new feed cannot cannot contain whitespace. Making every single processor strip whitespace smells too much like the HTML tag soup processors that we all have to maintain. Yuk. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 05 17:59:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1AE4-0007zU-B9 for atompub-archive@megatron.ietf.org; Fri, 05 Aug 2005 17:59:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05839 for ; Fri, 5 Aug 2005 17:59:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75LrgiH087354; Fri, 5 Aug 2005 14:53:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j75LrgjC087353; Fri, 5 Aug 2005 14:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [66.9.53.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75Lrfrf087346 for ; Fri, 5 Aug 2005 14:53:42 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1E1A8G-0008Ru-00; Fri, 05 Aug 2005 22:53:36 +0100 Date: Fri, 5 Aug 2005 22:53:36 +0100 From: James Aylett To: Atom Syntax Subject: Re: Two Proposed Resolutions for whitespace handling. Message-ID: <20050805215336.GA31265@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <68fba5c50508051104b4b4a00@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c50508051104b4b4a00@mail.gmail.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Aug 05, 2005 at 02:04:03PM -0400, Robert Sayre wrote: > 1.) Atom processors MAY consider leading and trailing whitespace in > element and attribute values to be significant. > > 2.) In attribute values and elements containing text, leading and > trailing whitespace is considered significant. I'm in favour of the approach. I'd prefer #2, because I think it's better to spell out that publishers have to be careful about whitespace. This is true with #1 (since some Atom processors will consider whitespace significant), after all. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sat Aug 06 04:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1KIF-0000JL-LV for atompub-archive@megatron.ietf.org; Sat, 06 Aug 2005 04:44:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12526 for ; Sat, 6 Aug 2005 04:44:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j768YmoB006191; Sat, 6 Aug 2005 01:34:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j768YmrY006190; Sat, 6 Aug 2005 01:34:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j768YlJR006174 for ; Sat, 6 Aug 2005 01:34:47 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 68674 invoked from network); 6 Aug 2005 08:34:46 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 6 Aug 2005 08:34:46 -0000 Received: from 212.183.128.185 ([212.183.128.185]) by webmail.djpowell.net (IMP) with HTTP for ; Sat, 6 Aug 2005 09:34:45 +0100 Message-ID: <1123317285.42f47625d7cda@webmail.djpowell.net> Date: Sat, 6 Aug 2005 09:34:45 +0100 From: David Powell To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: Simple Extensions and xml:base References: <1939577739.20050805072137@djpowell.net> <1123246788.42f362c48a9ff@webmail.djpowell.net> <5A4243E0-3851-4188-A727-BC04D77866C5@Sun.COM> In-Reply-To: <5A4243E0-3851-4188-A727-BC04D77866C5@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 212.183.128.185 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Tim Bray : >Right, but anyone who reads a simple extension out of an Atom feed >and finds something they consider to be a relative URI reference, and >wants to absolutize the reference, either uses the base URI as >established by xml:base, or they are wrong. -Tim > I wasn't suggesting that we needed special xml:base rules. My point was that it is not legal for an extension to define its content to be a (relative) URIRef. (although it is ok for an extension to contain an absolute URI.) Simple Extensions are designed to be a simple class of extension that generic support can be implemented for fairly easily in publishing clients and servers. They are intended to be name/value pairs that can be stored outside of an Atom Infoset. Generic processing is the reason that the distinction between Simple and Structured extensions exists. Generic processing, for implementations with database or RDF backends, can't be implemented if you need to know whether each extension contains a URIRef or text before putting the extension in your database. You can't put URIRefs in Simple Extension Elements because some implementations will not preserve their base URI (which is legal behavior, because the spec defines them to contain plain strings, not URIRefs.) I think that this is already implied by the spec, but it obviously isn't very clear. -- Dave From owner-atom-syntax@mail.imc.org Sun Aug 07 20:32:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1vZ2-0002tg-UY for atompub-archive@megatron.ietf.org; Sun, 07 Aug 2005 20:32:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07161 for ; Sun, 7 Aug 2005 20:32:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j780N7D4019490; Sun, 7 Aug 2005 17:23:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j780N75Q019489; Sun, 7 Aug 2005 17:23:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j780N6PG019483 for ; Sun, 7 Aug 2005 17:23:06 -0700 (PDT) (envelope-from lindsley@labs.mot.com) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j780WlOP007592; Sun, 7 Aug 2005 17:32:51 -0700 (MST) Received: from labs.mot.com (udomsvc1.labs.mot.com [173.23.250.1]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j780TpCg011087; Sun, 7 Aug 2005 19:29:52 -0500 (CDT) Received: from ims1.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j780Mve1023434; Sun, 7 Aug 2005 19:22:57 -0500 (CDT) Received: from [10.19.251.252] by udomsvc5.labs.mot.com (mshttpd); Sun, 07 Aug 2005 19:22:57 -0500 From: Brett Lindsley To: Walter Underwood Cc: atom-syntax@imc.org Message-ID: <56ca3512.351256ca@ims1.labs.mot.com> Date: Sun, 07 Aug 2005 19:22:57 -0500 X-Mailer: iPlanet Messenger Express 5.2 (built Feb 21 2002) MIME-Version: 1.0 Content-Language: en Subject: Re: spec bug: can we fix for draft-11? X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was just observing most of this discussion, but I am wondering how much of an issue the whitespace issue will cause when generating signatures. Obviously, different signatures will result when signing an element that has white space and one that does not. Does the canonicalization fix this? Brett. ----- Original Message ----- From: Walter Underwood Date: Friday, August 5, 2005 4:37 pm Subject: Re: spec bug: can we fix for draft-11? > > --On August 4, 2005 9:31:55 AM -0700 Tim Bray > wrote:> > > So for now, I'm -1 on an weakening or removing "The element's > content MUST be > > an IRI" or analogous text in any other section. I'll stop > shouting if I'm in > > a small minority here. -Tim > > Wow, this string has made my "away on vacation" mailbox fatter. > > I strongly favor making white space around IRIs illegal in Atom, > whetherthey are an ID or somewhere else. Same for dates. > > This follows the robustness principle, where we are conservative > in what > we generate. Atom processors are free to be liberal in what they > accept,so they can strip whitespace. Or not, I don't care. > > Note that a feed with whitespace around an IRI can never be aggregated > into another feed, because a) the ID IRI cannot be changed, and b) > the new > feed cannot cannot contain whitespace. > > Making every single processor strip whitespace smells too much like > the HTML tag soup processors that we all have to maintain. Yuk. > > wunder > -- > Walter Underwood > Principal Architect, Verity > > From owner-atom-syntax@mail.imc.org Sun Aug 07 20:47:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1vne-0005E4-PP for atompub-archive@megatron.ietf.org; Sun, 07 Aug 2005 20:47:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07759 for ; Sun, 7 Aug 2005 20:47:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j780fFcm020731; Sun, 7 Aug 2005 17:41:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j780fFbK020730; Sun, 7 Aug 2005 17:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j780fEDp020706 for ; Sun, 7 Aug 2005 17:41:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 81991 messnum 270577 invoked from network[83.70.29.246/83-70-29-246.b-ras1.prp.dublin.eircom.net]); 8 Aug 2005 00:41:07 -0000 Received: from 83-70-29-246.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.29.246) by mail03.svc.cra.dublin.eircom.net (qp 81991) with SMTP; 8 Aug 2005 00:41:07 -0000 Message-ID: <42F6AA22.8010905@dehora.net> Date: Mon, 08 Aug 2005 01:41:06 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <56ca3512.351256ca@ims1.labs.mot.com> In-Reply-To: <56ca3512.351256ca@ims1.labs.mot.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Brett Lindsley wrote: > I was just observing most of this discussion, but I am wondering how > much of an issue the whitespace issue will cause when generating > signatures. Obviously, different signatures will result when signing > an element that has white space and one that does not. Does the > canonicalization fix this? Brett. Exclusive canonicalization (which is the one we care about here) like canonicalization keeps whitespace inside element content significant. Those bytes are counted. I take that as meaning in the dsig case, trimming is broken. cheers Bill From owner-atom-syntax@mail.imc.org Mon Aug 08 02:04:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E20kD-00050b-AJ for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 02:04:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22679 for ; Mon, 8 Aug 2005 02:04:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j785w06H063652; Sun, 7 Aug 2005 22:58:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j785w0Vc063651; Sun, 7 Aug 2005 22:58:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j785vsAY063575 for ; Sun, 7 Aug 2005 22:57:55 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j785vsx7000698 for ; Sun, 7 Aug 2005 23:57:54 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKW004CF38HKN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 07 Aug 2005 23:57:54 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKW00KRY38H2V@mail.sun.net> for atom-syntax@imc.org; Sun, 07 Aug 2005 23:57:53 -0600 (MDT) Date: Sun, 07 Aug 2005 22:58:15 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <42F274C4.3020302@intertwingly.net> To: Sam Ruby Cc: atom-syntax@imc.org Message-id: <15A88244-DDC4-49FF-90B6-7FC324AFEC11@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: > Tim Bray wrote: > >> >> I'm getting increasingly grumpy and "just fail" is looking better and >> better. The current normative text, "The element's content MUST >> be an >> IRI", is clear and simple and supported by other well-understood >> normative text, supported by lots of interoperable software, that >> make >> the meanings of "element", "content", and "IRI" not really open to >> intelligent dispute. I claim that text enjoyed strong, not rough, >> consensus support from the WG. >> > > I believe that the term "content" is open to intelligent dispute. > Apparently the authors of RFC3470/BCP70 believe so too. Could you reference that? It seems to me that the guidance we should take from 3470 is from section 4.16, which seems to me to make it clear that *we* should make it clear that http://example.com/foo is an error and nothing but an error. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 08 02:05:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E20lW-0005DB-Ts for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 02:05:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24186 for ; Mon, 8 Aug 2005 02:05:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7860vUd065768; Sun, 7 Aug 2005 23:00:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7860van065765; Sun, 7 Aug 2005 23:00:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7860uaB065747 for ; Sun, 7 Aug 2005 23:00:56 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7860tvU012159 for ; Mon, 8 Aug 2005 00:00:55 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKW004FC3DJI3@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 08 Aug 2005 00:00:55 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKW003TT3CFYW@mail.sun.net> for atom-syntax@imc.org; Mon, 08 Aug 2005 00:00:55 -0600 (MDT) Date: Sun, 07 Aug 2005 23:01:15 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <42F6AA22.8010905@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: atom-syntax@imc.org Message-id: <51B63093-4AEF-4FE0-B756-6D67C6E5C7D5@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed References: <56ca3512.351256ca@ims1.labs.mot.com> <42F6AA22.8010905@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7860uaB065756 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 ietf.org id CAA24186 On Aug 7, 2005, at 5:41 PM, Bill de h=D3ra wrote: > Exclusive canonicalization (which is the one we care about here) like > canonicalization keeps whitespace inside element content significant. > Those bytes are counted. I take that as meaning in the dsig case, > trimming is broken. The c14n/dsig implementations I know of would agree with you. The =20 XML and RFC3470 are both crystal-clear on this. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 08 02:08:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E20nw-0005UI-AI for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 02:08:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26572 for ; Mon, 8 Aug 2005 02:08:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7860Iko065271; Sun, 7 Aug 2005 23:00:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7860IrL065270; Sun, 7 Aug 2005 23:00:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7860H7N065255 for ; Sun, 7 Aug 2005 23:00:17 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7860GvU011662 for ; Mon, 8 Aug 2005 00:00:17 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKW004F03CGI3@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 08 Aug 2005 00:00:16 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKW003TT3CFYW@mail.sun.net> for atom-syntax@imc.org; Mon, 08 Aug 2005 00:00:16 -0600 (MDT) Date: Sun, 07 Aug 2005 23:00:37 -0700 From: Tim Bray Subject: Re: spec bug: can we fix for draft-11? In-reply-to: <42F0C0C6.8090802@intertwingly.net> To: Sam Ruby Cc: Robert Sayre , Graham , atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF5DFD.8070308@internetalchemy.org> <2378A8E5-0FB6-43F9-A870-5A927511AF63@mac.com> <42EF7B7F.6090906@intertwingly.net> <20050802143036.GB4929@klangraum> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <42F0C0C6.8090802@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote: > To an Infoset person, this following is a completely different stream > from the example above (please ignore any line breaks that your email > client may insert): > > http://exam > ;ple.com/foo atom:id> I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ #omitted, item 6 > > Infoset views the below two examples as different: > > > http://example.com/foo I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ #omitted, item 19 Or am I missing something obvious? -Tim From owner-atom-syntax@mail.imc.org Mon Aug 08 07:35:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E25v2-0000m3-Om for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 07:35:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14705 for ; Mon, 8 Aug 2005 07:35:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78BSNDA001404; Mon, 8 Aug 2005 04:28:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78BSN7m001403; Mon, 8 Aug 2005 04:28:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78BSMAL001393 for ; Mon, 8 Aug 2005 04:28:22 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.104] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j78BaEWm001932; Mon, 8 Aug 2005 07:36:14 -0400 Message-ID: <42F741D5.2070104@intertwingly.net> Date: Mon, 08 Aug 2005 07:28:21 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax@imc.org Subject: Re: spec bug: can we fix for draft-11? References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> <15A88244-DDC4-49FF-90B6-7FC324AFEC11@Sun.COM> In-Reply-To: <15A88244-DDC4-49FF-90B6-7FC324AFEC11@Sun.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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: > >> Tim Bray wrote: >> >>> I'm getting increasingly grumpy and "just fail" is looking better and >>> better. The current normative text, "The element's content MUST be an >>> IRI", is clear and simple and supported by other well-understood >>> normative text, supported by lots of interoperable software, that make >>> the meanings of "element", "content", and "IRI" not really open to >>> intelligent dispute. I claim that text enjoyed strong, not rough, >>> consensus support from the WG. >> >> I believe that the term "content" is open to intelligent dispute. >> Apparently the authors of RFC3470/BCP70 believe so too. > > Could you reference that? It seems to me that the guidance we should > take from 3470 is from section 4.16, which seems to me to make it clear > that *we* should make it clear that > > > http://example.com/foo > > > is an error and nothing but an error. -Tim My point was simply that *we* should make it clear. Either of the texts that Rob proposed [1] is sufficient for my purposes. You appear to have a strong preference for #2, and a strong aversion to #1. I haven't heard anybody opposed to #2. This seems to me to be to be a sufficient basis for the chairs to declare (re-affirm?) consensus on this matter. If either is adopted, I will simply add a slew of tests to [2], ensure that they pass, and commit the change. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg16616.html [2] http://feedvalidator.org/testcases/atom/2/ From owner-atom-syntax@mail.imc.org Mon Aug 08 07:42:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E261r-00024g-SL for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 07:42:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15065 for ; Mon, 8 Aug 2005 07:42:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78Bbn6P004649; Mon, 8 Aug 2005 04:37:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78BbnUa004648; Mon, 8 Aug 2005 04:37:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78Bbmdq004629 for ; Mon, 8 Aug 2005 04:37:48 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 08 Aug 2005 07:37:47 -0400 id 005646C0.42F7440B.00007A6D From: "Scott Hollenbeck" To: "'Tim Bray'" Cc: atom-syntax@imc.org Subject: RE: spec bug: can we fix for draft-11? Date: Mon, 8 Aug 2005 07:38:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWb3lyvu6/kPOiqSf+C083/8UX85QALp7CA In-reply-to: <15A88244-DDC4-49FF-90B6-7FC324AFEC11@Sun.COM> Message-ID: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Tim Bray [mailto:Tim.Bray@Sun.COM] > Sent: Monday, August 08, 2005 1:58 AM > To: Sam Ruby > Cc: atom-syntax@imc.org > Subject: Re: spec bug: can we fix for draft-11? > > > > On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote: > > > Tim Bray wrote: > > > >> > >> I'm getting increasingly grumpy and "just fail" is looking > better and > >> better. The current normative text, "The element's content MUST > >> be an > >> IRI", is clear and simple and supported by other well-understood > >> normative text, supported by lots of interoperable > software, that > >> make > >> the meanings of "element", "content", and "IRI" not really open to > >> intelligent dispute. I claim that text enjoyed strong, not rough, > >> consensus support from the WG. > >> > > > > I believe that the term "content" is open to intelligent dispute. > > Apparently the authors of RFC3470/BCP70 believe so too. > > Could you reference that? It seems to me that the guidance > we should > take from 3470 is from section 4.16, which seems to me to make it > clear that *we* should make it clear that > > > http://example.com/foo > > > is an error and nothing but an error. -Tim That's my interpretation of what we (the authors of 3470) wrote, too. Knowing that white space is significant, you guys need to explain what to do with it. -Scott- From owner-atom-syntax@mail.imc.org Mon Aug 08 14:18:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CCK-00006y-NX for atompub-archive@megatron.ietf.org; Mon, 08 Aug 2005 14:18:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07394 for ; Mon, 8 Aug 2005 14:18:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j78IBdfH079330; Mon, 8 Aug 2005 11:11:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j78IBdYY079329; Mon, 8 Aug 2005 11:11:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailhost.netweaver.net (mailhost.netweaver.net [213.160.118.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id j78IBbY1079321 for ; Mon, 8 Aug 2005 11:11:38 -0700 (PDT) (envelope-from davep@dpawson.co.uk) Received: (qmail 3526 invoked from network); 8 Aug 2005 18:11:36 -0000 Received: from dpawson.gotadsl.co.uk (HELO ?192.168.2.7?) (davep@dpawson.co.uk@81.6.251.105) by 0 with SMTP; 8 Aug 2005 18:11:36 -0000 Subject: Re: spec bug: can we fix for draft-11? From: Dave Pawson Reply-To: davep@dpawson.co.uk To: Sam Ruby Cc: Tim Bray , atom-syntax@imc.org In-Reply-To: <42F274C4.3020302@intertwingly.net> References: <42EF5DFD.8070308@internetalchemy.org> <42EFA37F.70401@intertwingly.net> <98EFC2B4-B748-453E-A0AB-E5133B975454@mac.com> <68fba5c505080213075dea847@mail.gmail.com> <166DA79E-76DA-49BF-808E-DB97F62D0DE0@mac.com> <68fba5c505080216371c20f5b3@mail.gmail.com> <6E85BA00-5AAF-4CFD-8D24-98228287FA1A@sun.com> <42f50929.65833015@smtp.bjoern.hoehrmann.de> <68fba5c50508040653457d427e@mail.gmail.com> <4A2D8BD2-483D-4CBD-8281-AD608AB0212F@Sun.COM> <42F274C4.3020302@intertwingly.net> Content-Type: text/plain Date: Mon, 08 Aug 2005 19:11:35 +0100 Message-Id: <1123524695.3417.35.camel@marge> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Using Sun's 'relames' [1] it is *nearly* possible to validate an instance as is intended by the text! Where (datetime for instance) an element content must not have whitespace, relames picks it up nicely. There must be no white space before or after a date time value Unfortunately, as of this release, relames doesn't support Schematron assert statements for attribute values, which is required for uri's. C'est la vie [1]https://msv.dev.java.net/ regards DaveP From owner-atom-syntax@mail.imc.org Tue Aug 09 01:21:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2MXv-0000sR-BS for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 01:21:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29592 for ; Tue, 9 Aug 2005 01:21:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j795BAML038433; Mon, 8 Aug 2005 22:11:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j795BA5D038432; Mon, 8 Aug 2005 22:11:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j795B9fc038389 for ; Mon, 8 Aug 2005 22:11:09 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so654464nzb for ; Mon, 08 Aug 2005 22:11:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=aNO3S3Qj/cs5lL+O+gzGNuLzaDIKP0gy98cZQbPJprsyJ8nDXqLvVW5yqpVnpRdrD5L3N5Sb5a1IG7TDkwTtj6x6NwaBiwOMNOPmr6s3zgWRJN8QrOt1OLMezA4eKkZYsMASYRE6icYJXzWDYrePNfv5Rpm+5yVNpjWdXk7LATU= Received: by 10.36.224.6 with SMTP id w6mr3370463nzg; Mon, 08 Aug 2005 22:11:03 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id m2sm3776294nzf.2005.08.08.22.11.02; Mon, 08 Aug 2005 22:11:02 -0700 (PDT) Message-ID: <42F83AE0.8010107@gmail.com> Date: Mon, 08 Aug 2005 22:10:56 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Updated Comments Draft (getting closer) 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: Content-Transfer-Encoding: 7bit I've updated the draft of the comments extension. I think this is just about ready to submit as an I-D. http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt The major change is a refactoring of the in-reply-to and replies-source following the extensive discussion here on the list. ... tag:example.com,2005:1 ... ... tag:example.com,2005:2 tag:example.com,2005:3 The second feed illustrates the two forms of the in-reply-to element. The dereferenceable form uses the href attribute to locate the entity being responded to. The nondereferenceable form uses a combination of a required id attribute and an optional src attribute. I'll likely go ahead and submit this as an I-D in the morning. As always, comments welcome. - James From owner-atom-syntax@mail.imc.org Tue Aug 09 02:07:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2NGh-0007lz-MF for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 02:07:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07340 for ; Tue, 9 Aug 2005 02:07:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7961SUL061406; Mon, 8 Aug 2005 23:01:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7961SOj061405; Mon, 8 Aug 2005 23:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7961RlK061384 for ; Mon, 8 Aug 2005 23:01:27 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:57192 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1229136AbVHIGB0 (ORCPT ); Tue, 9 Aug 2005 09:01:26 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <3f1451f50508041155132f743@mail.gmail.com> References: <20050802044123.14149.qmail@web42204.mail.yahoo.com> <42EF37CD.4030405@dehora.net> <8959E900-6ABE-495D-AE13-846B38BB175F@mac.com> <42EF49A4.5050904@dehora.net> <1f2ed5cd050804084568572653@mail.gmail.com> <3f1451f50508041155132f743@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <938d78d6d2c9d230774e31b57c3ffbe5@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: spec bug: can we fix for draft-11? Date: Tue, 9 Aug 2005 09:01:04 +0300 To: atom-syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Aug 4, 2005, at 21:55, Joe Gregorio wrote: > "Some sections of this specification are illustrated with fragments of > a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text > of this specification provides the definition of conformance. A > complete schema appears in Appendix B." > > This is quoted directly from Section 1.3. > > This whitespace issue is a good illustration of why the schema isn't > normative ;) This thread makes me wonder if taking the schema seriously enough to actually encourage validation against the schema causes more harm than good. Perhaps I should remove the Atom schema from the presets of http://hsivonen.iki.fi/validator/ . > I would vote for leaving the text as is and having the validator give > errors on whitespace. ITYM, the Feed Validator and not a RELAX NG validator. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue Aug 09 06:24:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2RHw-0002Fz-JL for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 06:24:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26610 for ; Tue, 9 Aug 2005 06:24:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79AI3Qa060794; Tue, 9 Aug 2005 03:18:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79AI3OP060793; Tue, 9 Aug 2005 03:18:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79AI2eb060751 for ; Tue, 9 Aug 2005 03:18:03 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so165640nzp for ; Tue, 09 Aug 2005 03:17:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cUNi+A995UaEQPVAkE/72zoiSd/pXu/9twkDKMi+cirH6RxqzcC+Ac9yH/2cHdKDDGFhEndPPwa0kp96rfSww/v4oODYto1ClK7SA5GkJUqIRt/2UJNBnzlr/ftrEcmxjt0BY70ipzk6HBWIhT4eDDL/KBhg/WCrcBgUBkVc5F0= Received: by 10.36.158.12 with SMTP id g12mr871807nze; Tue, 09 Aug 2005 03:17:57 -0700 (PDT) Received: by 10.36.153.6 with HTTP; Tue, 9 Aug 2005 03:17:57 -0700 (PDT) Message-ID: <1f2ed5cd050809031755d62e2c@mail.gmail.com> Date: Tue, 9 Aug 2005 12:17:57 +0200 From: Danny Ayers To: atom-syntax@imc.org Subject: Project descriptions with Atom In-Reply-To: <1123101980.28603.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1123101980.28603.39.camel@localhost.localdomain> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j79AI3eb060787 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit DOAP is Description of a Project, done in RDF. CodeZoo are using Atom as a format to receive project updates, using DOAP RDF/XML as a payload. Details - ---------- Forwarded message ---------- From: Edd Dumbill Date: Aug 3, 2005 10:46 PM Subject: [doap-interest] CodeZoo launches DOAP support To: doap-interest@lists.gnomehack.com http://usefulinc.com/doap/news/contents/2005/08-03-codezoo/read O'Reilly's [1]CodeZoo has just launched a major deployment of DOAP. CodeZoo is a software registry for code libraries, covering Java, Ruby and Python. Each entry in the registry has a DOAP export available. Additionally, developers can provide CodeZoo with an Atom feed containing embedded DOAP. This means the repository can be kept up to date with releases. More information: * [2]DOAP in CodeZoo * [3]DOAP over Atom * [4]Keep CodeZoo up to date with DOAP References 1. http://www.codezoo.com/ 2. http://ruby.codezoo.com/about/doap.csp 3. http://www.codezoo.com/about/doap_over_atom.csp 4. http://www.codezoo.com/cs/user/create/doap_feedback _______________________________________________ doap-interest mailing list doap-interest@lists.gnomehack.com http://lists.gnomehack.com/mailman/listinfo/doap-interest -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Aug 09 06:59:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Rpd-0007F0-Kc for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 06:59:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28224 for ; Tue, 9 Aug 2005 06:59:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79AsfVP073342; Tue, 9 Aug 2005 03:54:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Asf3F073341; Tue, 9 Aug 2005 03:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79AseMn073330 for ; Tue, 9 Aug 2005 03:54:40 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 31226 invoked by uid 17064); 9 Aug 2005 10:54:39 -0000 Received: from unknown (HELO [192.168.1.40]) ([83.78.7.248]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 10:54:39 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AE406B5-F74F-408D-903C-4A37309E31E2@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: nested feeds (was: Feed History -02) Date: Tue, 9 Aug 2005 12:54:38 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry for taking so long to reply. I have been off on a 700km cycle trip http://blogs.sun.com/roller/page/bblfish/20050807 I don't really want to spend to much time on the top-X discussion, as I am a lot more interested in the feed history itself, but here are some thoughts anyway... On 29 Jul 2005, at 17:01, Eric Scheid wrote: > On 29/7/05 11:39 PM, "Henry Story" wrote: >> Below I think I have worked out how one can in fact have a top20 >> feed, and I >> show how this can be combined without trouble with the >> >> link... >> >> On 29 Jul 2005, at 13:12, Eric Scheid wrote: >>> On 29/7/05 7:57 PM, "Henry Story" wrote: >>> >>>> 1- The top 20 list: here one wants to move to the previous top >>>> 20 list and >>>> think of them as one thing. The link to the next feed is not >>>> meant to be >>>> additive. Each feed is to be seen as a whole. I have a little >>>> trouble still >>>> thinking of these as feeds, but ... >>> >>> What happens if the publisher realises they have a typo and need >>> to emit an >>> update to an entry? Would the set of 20 entries (with one entry >>> updated) be >>> seen as a complete replacement set? >>> >> Well if it is a typo and this is considered to be an >> insignificant change >> then they can change the typo in the feed document and not need to >> change any >> updated time stamps. >> > > Misspelling the name of the artist for the top 20 songs list is not > insignificant. Even worse fubars are possible too -- such as > attributing the > wrong artist/author to the #1 song/book (and even worse: leaving off a > co-author). Yes, I see this now. This is a problem for my suggestion. The atom:updated field cannot be used to indicate the date at which an entry has a certain position in a chart for the reason you mention. We could then no longer update that entry for spelling mistakes or other more serious issues. One would have to add a about date or something, and then the things gets a little more complicated than I care to think about right now. >>> The way I see it, maybe a better way would be to have a sliding >>> window feed >>> where each entry points to another Atom Feed Document with it's >>> own URI, and >>> it is that second Feed Document which contains the individual >>> items (the top >>> 20 list). >>> >> This is certainly closer to my intuitions too. A top 20 something >> is *not* a >> feed. Feed entries are not ordered, and are not meant to be >> thought of as a >> closed collection. At least this is my initial intuition. BUT.... >> > > Not all Atom Feed Documents are feeds, some are static collections of > entries. We keep tripping over this :-( > >> I can think of a solution like the following: Let us imagine a top >> 20 feed >> where the resources being described by the entries are the >> position in the >> top list. So we have entries with ids such as >> >> http://TopOfThePops.co.uk/top20/Number1 >> http://TopOfThePops.co.uk/top20/Number2 >> http://TopOfThePops.co.uk/top20/Number3 ... > >> will contain a new entry such as >> >> >> Top of the pops entry number 1 >> >> http://TopOfThePops.co.uk/top20/Number1 >> 2005-07-05T18:30:00Z >> Top of the pops winner for the week starting 5 July >> 2005 >> >> > > The problem here is that this doesn't describe the referent, it only > describes the reference. I want to see top 20 feeds where each > entry links > to the referent in question. For example, the Amazon Top 10 Selling > Books > feed would link to the book specific page at Amazon, not to some > page saying > "the #3 selling book is at the other end of this link". Oh, I don't really want to defend this position too much but there would be a way around this criticism by simply having the link point to the album like this: Top of the pops entry number 1 http://TopOfThePops.co.uk/top20/Number1 2005-07-05T18:30:00Z Top of the pops winner for the week starting 5 July 2005 So here the id would be the same for each position from week to week, but the link it points to would change. We would still need to solve the issue of the date at which it had that position, though... And so yes, a feed where the entry is a feed seems easier to work with in this case. The feed would be something like this I suppose: top 20 French songs ... week of August 1 2005 ...?... 2005-08-01T18:30:00Z week of August 1 2005 ...?... 2005-08-02T18:30:00Z week of August 8 2005 ...?... 2005-08-08T18:30:00Z But while you are at it then why not just create a special top-X ontology and express your information in RDF? top 20 French songs ... week of August 1 2005 ...?... 2005-08-01T18:30:00Z week of August 1 2005 ...?... 2005-08-02T18:30:00Z week of August 8 2005 ...?... 2005-08-08T18:30:00Z Or if you want to make your life more difficult invent a special purpose xml format for your top-X. In either case you could really add all the bells and whistles for the particular domain of discourse of interest, such as popularity, number of sales, etc, etc. One can of course shoe-horn a top X into a feed document, but it feels a little cramped... Henry From owner-atom-syntax@mail.imc.org Tue Aug 09 07:12:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2S2R-0003Qt-MW for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 07:12:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28784 for ; Tue, 9 Aug 2005 07:12:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79B7UKm077976; Tue, 9 Aug 2005 04:07:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79B7U6a077975; Tue, 9 Aug 2005 04:07:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79B7UL3077964 for ; Tue, 9 Aug 2005 04:07:30 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 35801 invoked by uid 17064); 9 Aug 2005 11:07:30 -0000 Received: from unknown (HELO [192.168.1.40]) ([83.78.7.248]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 11:07:30 -0000 In-Reply-To: <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> Cc: Eric Scheid , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -02 Date: Tue, 9 Aug 2005 13:07:29 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Aug 2005, at 06:27, Mark Nottingham wrote: > So, if I read you correctly, it sounds like you have a method > whereby a 'top20' feed wouldn't need history:prev to give the kind > of history that you're thinking of, right? > > If that's the case, I'm tempted to just tweak the draft so that > history:stateful is optional if history:prev is present. I was > considering dropping stateful altogether, but I think something is > necessary to explicitly say "don't try to keep a history of my > feed." My latest use case for this is the RSS feed that Netflix > provides to let you keep an eye on your queue (sort of like top20, > but more specialised). > > Sound good? Sounds good to me. But I would really like some way to specify that the next feed document is an archive (ie. won't change). This would make it easy for clients to know when to stop following the links, ie, when they have cought up with the changes since they last looked at the feed. Perhaps something like this: http://liftoff.msfc.nasa.gov/2003/04/ feed.rss Henry Story From owner-atom-syntax@mail.imc.org Tue Aug 09 12:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Wri-0000AR-8G for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 12:22:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20414 for ; Tue, 9 Aug 2005 12:22:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GFgnQ057774; Tue, 9 Aug 2005 09:15:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79GFgXk057772; Tue, 9 Aug 2005 09:15:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GFfJS057755 for ; Tue, 9 Aug 2005 09:15:41 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 824C66C for ; Tue, 9 Aug 2005 09:15:32 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j79GFQkv020494 for ; Tue, 9 Aug 2005 09:15:32 -0700 (PDT) Date: Tue, 09 Aug 2005 09:15:03 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Feed History -02 Message-ID: In-Reply-To: <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 9, 2005 1:07:29 PM +0200 Henry Story wrote: > > But I would really like some way to specify that the next feed document is an > archive (ie. won't change). This would make it easy for clients to know when > to stop following the links, ie, when they have cought up with the changes > since they last looked at the feed. I made some proposals for cache control info (expires and max-age). That might work for this. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 09 12:35:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X4H-0005m1-Pt for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 12:35:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21663 for ; Tue, 9 Aug 2005 12:35:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GT6kQ058882; Tue, 9 Aug 2005 09:29:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79GT6BH058881; Tue, 9 Aug 2005 09:29:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GT4jO058870 for ; Tue, 9 Aug 2005 09:29:05 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so846990wra for ; Tue, 09 Aug 2005 09:28:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=goHxmhHi6Aexo7AonPi+V0WDi2MiaGH/aRIveyzEzxOr3JiY23tV5Vf6A2h64lh6MfhAkWnh/rbuvqekR83QpGRYkmM1qmaxwP2RE1gLYyiCUemEFm4rf1mRM9sW/nqrUda5T9GNO1lacXeDrj3JO/XNi1djrxMCqUs7osA8G1U= Received: by 10.54.5.42 with SMTP id 42mr928170wre; Tue, 09 Aug 2005 09:28:59 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 24sm10095742wrl.2005.08.09.09.28.58; Tue, 09 Aug 2005 09:28:59 -0700 (PDT) Message-ID: <42F8D9C4.9030100@gmail.com> Date: Tue, 09 Aug 2005 09:28:52 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Feed History -02 References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> In-Reply-To: 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: Content-Transfer-Encoding: 7bit Walter Underwood wrote: >--On August 9, 2005 1:07:29 PM +0200 Henry Story wrote: > > >>But I would really like some way to specify that the next feed document is an >>archive (ie. won't change). This would make it easy for clients to know when >>to stop following the links, ie, when they have cought up with the changes >>since they last looked at the feed. >> >> > >I made some proposals for cache control info (expires and max-age). >That might work for this. > > > I missed these proposals. I've been giving some thought to an and extension myself and was getting ready to write up a draft. Expires is a simple date construct specifying the exact moment (inclusive) that the entry/feed expires. Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the moment specified by atom:updated when then entry/feed expires. The two cannot appear together within a single entry/feed and follows the same basic rules as atom:author elements. - James From owner-atom-syntax@mail.imc.org Tue Aug 09 12:38:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X7R-0006XU-VM for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 12:38:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22163 for ; Tue, 9 Aug 2005 12:38:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GXUGN059159; Tue, 9 Aug 2005 09:33:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79GXUiv059158; Tue, 9 Aug 2005 09:33:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GXUwE059151 for ; Tue, 9 Aug 2005 09:33:30 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id E8F3C22 for ; Tue, 9 Aug 2005 09:33:24 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j79GXNkv020721 for ; Tue, 9 Aug 2005 09:33:24 -0700 (PDT) Date: Tue, 09 Aug 2005 09:32:59 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Feed History -02 Message-ID: <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <42F8D9C4.9030100@gmail.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 9, 2005 9:28:52 AM -0700 James M Snell wrote: >> I made some proposals for cache control info (expires and max-age). >> That might work for this. >> > I missed these proposals. I've been giving some thought to an and extension myself and was getting ready to write up a draft. Expires is a simple date construct specifying the exact moment (inclusive) that the entry/feed expires. Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the moment specified by atom:updated when then entry/feed expires. The two cannot appear together within a single entry/feed and follows the same basic rules as atom:author elements. Here it is: Adding max-age also means defining IntegerConstruct and disallowing white space around it. Formerly, it was OK as a text construct, but the white space issues change that. Also, we should decide whether cache information is part of the signature. I can see arguments either way. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 09 12:51:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2XKR-00056N-8g for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 12:51:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23925 for ; Tue, 9 Aug 2005 12:51:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GkAuJ060100; Tue, 9 Aug 2005 09:46:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79GkAk7060099; Tue, 9 Aug 2005 09:46:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79GkA8B060091 for ; Tue, 9 Aug 2005 09:46:10 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 94013 invoked by uid 17064); 9 Aug 2005 16:46:10 -0000 Received: from unknown (HELO [192.168.1.40]) ([83.78.7.248]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 16:46:10 -0000 In-Reply-To: <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95730E3A-95A0-48D0-A2A2-E1EE9BD14B7A@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -02 Date: Tue, 9 Aug 2005 18:46:10 +0200 To: Walter Underwood X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9 Aug 2005, at 18:32, Walter Underwood wrote: > --On August 9, 2005 9:28:52 AM -0700 James M Snell > wrote: >>> I made some proposals for cache control info (expires and max-age). >>> That might work for this. >>> >>> >> I missed these proposals. I've been giving some thought to an >> and extension myself and was getting ready >> to write up a draft. Expires is a simple date construct specifying >> the exact moment (inclusive) that the entry/feed expires. Max-age >> is a non negative integer specifying the number of miliseconds >> (inclusive) from the moment specified by atom:updated when then >> entry/feed expires. The two cannot appear together within a >> single entry/feed and follows the same basic >> > rules as atom:author elements. > > Here it is: Interesting... but why have a limit of one year? For archives, I would like a limit of forever. But otherwise I suppose this would do. Instead of putting the information in the link of the linking feed, you would put it in the archive feed. Which sounds good. I suppose we end up with some duplication of information here with the http headers again. > Adding max-age also means defining IntegerConstruct and disallowing > white space around it. Formerly, it was OK as a text construct, but > the white space issues change that. > > Also, we should decide whether cache information is part of the > signature. > I can see arguments either way. > > wunder > -- > Walter Underwood > Principal Architect, Verity > From owner-atom-syntax@mail.imc.org Tue Aug 09 13:14:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Xgb-0005Zr-Nx for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 13:14:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24744 for ; Tue, 9 Aug 2005 13:14:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79HA0Kh062307; Tue, 9 Aug 2005 10:10:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79HA0Lp062306; Tue, 9 Aug 2005 10:10:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79H9xDs062299 for ; Tue, 9 Aug 2005 10:09:59 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so1162000rng for ; Tue, 09 Aug 2005 10:09:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VcbEctI8gPm6elRkk89eIBzWoveE4Fo3dy+3oVo4KvdoNiRNBXLGE9zYsvjRHdSqNVLzs7fEAd9gUycke3z05yU66dIwGGq7UFUEQdh+PZ8+Tg19HZnsprdmWK8SC6WJSD9OvmwRcUOATi2EbESDUleCRxHbdwYTkZ6/KY72Vd4= Received: by 10.38.76.73 with SMTP id y73mr3051463rna; Tue, 09 Aug 2005 10:09:59 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 71sm2550653rnc.2005.08.09.10.09.58; Tue, 09 Aug 2005 10:09:59 -0700 (PDT) Message-ID: <42F8E361.60603@gmail.com> Date: Tue, 09 Aug 2005 10:09:53 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Feed History -02 References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: >--On August 9, 2005 9:28:52 AM -0700 James M Snell wrote: > > > >>>I made some proposals for cache control info (expires and max-age). >>>That might work for this. >>> >>> >>> >>I missed these proposals. I've been giving some thought to an and extension myself and was getting ready to write up a draft. Expires is a simple date construct specifying the exact moment (inclusive) that the entry/feed expires. Max-age is a non negative integer specifying the number of miliseconds (inclusive) from the moment specified by atom:updated when then entry/feed expires. The two cannot appear together within a single entry/feed and follows the same basic >> >> >rules as atom:author elements. > >Here it is: > > > The expires and max-age elements look fine. I hesitate at bringing in a caching discussion. I'm much more comfortable leaving the definition of caching rules to the protocol level (HTTP) rather than the format extension level. Namely, I don't want to have to go into defining rules for how HTTP headers that affect caching interact with the expires and max-age elements... IMHO, there is simply no value in that. The expires and max-age extension elements affect the feed / entry on the application level not the document level. HTTP caching works on the document level. >Adding max-age also means defining IntegerConstruct and disallowing >white space around it. Formerly, it was OK as a text construct, but >the white space issues change that. > > > This is easy enough. >Also, we should decide whether cache information is part of the signature. >I can see arguments either way. > > > -1. let's let caching be handled by the transport layer. - James From owner-atom-syntax@mail.imc.org Tue Aug 09 13:33:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Xz3-0004Tn-QU for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 13:33:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25428 for ; Tue, 9 Aug 2005 13:33:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79HSxgp064574; Tue, 9 Aug 2005 10:28:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79HSxSu064573; Tue, 9 Aug 2005 10:28:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79HSw2p064566 for ; Tue, 9 Aug 2005 10:28:58 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so722563nzb for ; Tue, 09 Aug 2005 10:28:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=QWXNXvvCcdWajF2aPwHbyACxFT9ZUTAbF7SwNtB4262tnirzPkFUsBxfnj965m5ppo5CCJ21bCqsZszljR6aNolt0Eyoby/yg2z8OqC9RStZtlJuvM7JU9/Vxf0gyCmWG/n7T2oshAbW7BJ0rQU7dYEUq5bHMDIgH2nXxSeUnvg= Received: by 10.37.22.51 with SMTP id z51mr3830248nzi; Tue, 09 Aug 2005 10:28:52 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id r15sm4341293nza.2005.08.09.10.28.52; Tue, 09 Aug 2005 10:28:52 -0700 (PDT) Message-ID: <42F8E7CE.30809@gmail.com> Date: Tue, 09 Aug 2005 10:28:46 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: FYI: License and Comments I-D's Submitted 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: Content-Transfer-Encoding: 7bit I've submitted the Comments thread and License extensions as Internet Drafts. They should post in the coming few days. In the meantime, the latest versions can be found at the locations below. http://www.snellspace.com/public/draft-snell-atompub-feed-license-00.txt http://www.snellspace.com/public/draft-snell-atompub-feed-thread-00.txt As a reminder, the license extension provides a link relation for associating a copyright license with a feed or entry. The most common use case will be to associate creative commons licenses with feeds. - James From owner-atom-syntax@mail.imc.org Tue Aug 09 14:51:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZBw-0001WT-9z for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 14:51:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29191 for ; Tue, 9 Aug 2005 14:51:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79IkEaP070934; Tue, 9 Aug 2005 11:46:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79IkEVn070933; Tue, 9 Aug 2005 11:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79IkEee070927 for ; Tue, 9 Aug 2005 11:46:14 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 39708 invoked by uid 17064); 9 Aug 2005 18:46:13 -0000 Received: from unknown (HELO [192.168.1.43]) ([83.78.7.248]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 Aug 2005 18:46:13 -0000 In-Reply-To: <42F8E361.60603@gmail.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Walter Underwood , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -02 Date: Tue, 9 Aug 2005 20:46:13 +0200 To: James M Snell X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To answer my own question [[ Interesting... but why have a limit of one year? For archives, I would like a limit of forever. ]] I found the following in the HTTP spec [[ To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. ]] (though that still does not explain why.) Now I am wondering if the http mechanism is perhaps all that is needed for what I want with the unchanging archives. If it is then perhaps this could be explained in the Feed History RFC. Or are there other reasons to add and "expires" tag to the document itself? Henry Story On 9 Aug 2005, at 19:09, James M Snell wrote: >>> >>> >> rules as atom:author elements. >> >> Here it is: >> >> >> > The expires and max-age elements look fine. I hesitate at bringing > in a caching discussion. I'm much more comfortable leaving the > definition of caching rules to the protocol level (HTTP) rather > than the format extension level. Namely, I don't want to have to > go into defining rules for how HTTP headers that affect caching > interact with the expires and max-age elements... IMHO, there is > simply no value in that. > The expires and max-age extension elements affect the feed / entry > on the application level not the document level. HTTP caching > works on the document level. > > >> Adding max-age also means defining IntegerConstruct and disallowing >> white space around it. Formerly, it was OK as a text construct, but >> the white space issues change that. >> >> >> > This is easy enough. > > >> Also, we should decide whether cache information is part of the >> signature. >> I can see arguments either way. >> >> >> > -1. let's let caching be handled by the transport layer. > From owner-atom-syntax@mail.imc.org Tue Aug 09 15:01:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZMG-0005M7-SI for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 15:01:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29745 for ; Tue, 9 Aug 2005 15:01:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79IrpmM071524; Tue, 9 Aug 2005 11:53:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Irp3Q071523; Tue, 9 Aug 2005 11:53:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79Iroti071514 for ; Tue, 9 Aug 2005 11:53:50 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so734227nzb for ; Tue, 09 Aug 2005 11:53:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fdFTc1UbU1yumiuPOUU1sWhOenXSWcvVHqL9eOGQ1AJWbKN0kRQBLjSb2n5zLnvWKmfTkT7HfnWuc3SUw+tYjU5Ea+K6XwQlwoQFiu/ipytrEAdtSQvc0+2IYbLp+piQoJxMFFJf4y99vYHAtBuE9Re+Mvr5NcEE3WDPXP+vzaQ= Received: by 10.36.252.56 with SMTP id z56mr4068017nzh; Tue, 09 Aug 2005 11:53:44 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 6sm2758976nzn.2005.08.09.11.53.44; Tue, 09 Aug 2005 11:53:44 -0700 (PDT) Message-ID: <42F8FBB1.5060603@gmail.com> Date: Tue, 09 Aug 2005 11:53:37 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Walter Underwood , Atom Syntax Subject: Re: Feed History -02 References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> In-Reply-To: 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: Content-Transfer-Encoding: 7bit Henry Story wrote: > > Now I am wondering if the http mechanism is perhaps all that is needed > for what I want with the unchanging archives. If it is then perhaps this > could be explained in the Feed History RFC. Or are there other > reasons to > add and "expires" tag to the document itself? On the application level, a feed or entry may expire or age indepedently of whatever caching mechanisms may be applied at the transport level. For example, imagine a source that publishes special offers in the form of Atom entries that expire at a given point in time. Now suppose that those entries are being distributed via XMPP and HTTP. It is helpful to have a transport independent expiration/max-age mechanism whose semantics operate on the application layer rather than the transport layer. - James From owner-atom-syntax@mail.imc.org Tue Aug 09 16:46:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2azk-0001rT-7V for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:46:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13551 for ; Tue, 9 Aug 2005 16:46:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79Kf0kY079890; Tue, 9 Aug 2005 13:41:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Kf0Im079889; Tue, 9 Aug 2005 13:41:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79KexNA079861 for ; Tue, 9 Aug 2005 13:40:59 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id E206843F759 for ; Tue, 9 Aug 2005 14:41:02 -0600 (MDT) Message-ID: <42F914DE.2030706@jabber.org> Date: Tue, 09 Aug 2005 14:41:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-03.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060603060301060007040603" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms060603060301060007040603 Content-Type: multipart/mixed; boundary="------------000802020804090308080906" This is a multi-part message in MIME format. --------------000802020804090308080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI... ****** -------- Original Message -------- Subject: I-D ACTION:draft-saintandre-atompub-notify-03.txt Date: Tue, 09 Aug 2005 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-atompub-notify-03.txt Pages : 14 Date : 2005-8-9 This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-saintandre-atompub-notify-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-saintandre-atompub-notify-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ****** -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------000802020804090308080906 Content-Type: message/external-body; x-mac-type="0"; x-mac-creator="0"; name="draft-saintandre-atompub-notify-03.txt" Content-Disposition: inline; filename="draft-saintandre-atompub-notify-03.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-8-9115146.I-D@ietf.org> --------------000802020804090308080906 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="file:///tmp/nsmail.asc" Content-Disposition: inline; filename="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------000802020804090308080906-- --------------ms060603060301060007040603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC BPUwggLdoAMCAQICAwEjfTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA1 MTcxNzQ2MDBaFw0wNjA1MTcxNzQ2MDBaMEIxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6QaezyuQyuya0zB98ew+fDDeO6dbkFE1Td2OrePzTOuSMNHH1 kvpAxpC7m9WtSeeQ874XC9qmPxBurEILQYZrA/IJNUR+kWvJzAJLJK/62xOCOuDuNjLXKv5F BJEeg/uDpiq6K7yfsLcwg5wkxmIGsajYR+maGDlqV7aJeMuTcRTeNHNIBliwToPlIRvQfJbP B3D4tCInHxWeg5BmyqXZgpEPdJ1hyoHB+YvA/0YKAb1Fq9Fq2n6ZC0O70ndkx++OXw65kkYi m6N/dHQ9xjtpOOk6cQu+SKoL2BfU8kBp9bSmIUymn+KqUdwTcge4vFieJ1lWmtMsKUTbLbgh 0P9ZAgMBAAGjgbwwgbkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlv dXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNl cnQub3JnMB0GA1UdEQQWMBSBEnN0cGV0ZXJAamFiYmVyLm9yZzANBgkqhkiG9w0BAQQFAAOC AgEAk+5v9P2B9Zher5QMtmGRSqg+Dkmd2xMoBjPItsR2FFS6waXf3Hv82n4W//9HzM+zAuKv a0kzHY9IHCqcpRVBAqKpN6a6VHb6ZmtwKtj38wmLwMUIqnfvEx4AvP8QJHERLRVn8JL801QT 8Nt1y/6LaOKkFiQUZGvP5m6plXHx2DqL2gfAtZ/VSivSTzkJp3XyDnL04TdKFMY6vPvoT1Ub d48KW+ZA1NE1+h6gxr4jQVUExKeKB25RoxZMXyMqbawnzJZYl2fEkYgQVWVpPZO6NC9u45u4 kyOXNaLjiQwLpCvZj6x87YOQKn1YyiIWXSUFU4ArsaR/BvtVb53IKYE2LE8dPqq/fn1iMCb4 qLesxc+SQWAQB/xiDlVA00eJq+Ulyq4KTFnbARWHgXOqLUo9Uu+GsiK8L6WLf4vr2F8dhDwa tfw7oGjGmGJd0ZO/Yt3Wp7ytutsM+4I3ewlQyRWsXx6zcSHN43FUFZpCJxrfD1k1t9z/MJy/ d2zx7mjjbjcfTykIi8taC2UwdMBAbpNmH4gh+VnrEPgYHOONwBTqL/dfW0Px5pa0Fv/WU/VQ gYep9RLmdDYcwR2bn9XLdVDngMHHTr3Z9LNl1VfQnZg2wi2wvfIrrE0gOtJD7dMPl64Un2Tv L0bvyJrhkiKKdFACad+aOcw1pyWIiDixoYZPJi8wggT1MIIC3aADAgECAgMBI30wDQYJKoZI hvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDUwNTE3MTc0NjAwWhcNMDYwNTE3MTc0NjAw WjBCMR0wGwYDVQQDExRKLiBQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3Rw ZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAukGns8rk MrsmtMwffHsPnww3junW5BRNU3djq3j80zrkjDRx9ZL6QMaQu5vVrUnnkPO+Fwvapj8QbqxC C0GGawPyCTVEfpFrycwCSySv+tsTgjrg7jYy1yr+RQSRHoP7g6Yquiu8n7C3MIOcJMZiBrGo 2Efpmhg5ale2iXjLk3EU3jRzSAZYsE6D5SEb0HyWzwdw+LQiJx8VnoOQZsql2YKRD3SdYcqB wfmLwP9GCgG9RavRatp+mQtDu9J3ZMfvjl8OuZJGIpujf3R0PcY7aTjpOnELvkiqC9gX1PJA afW0piFMpp/iqlHcE3IHuLxYnidZVprTLClE2y24IdD/WQIDAQABo4G8MIG5MAwGA1UdEwEB /wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3Ig RlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYw JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAdBgNVHREEFjAUgRJzdHBl dGVyQGphYmJlci5vcmcwDQYJKoZIhvcNAQEEBQADggIBAJPub/T9gfWYXq+UDLZhkUqoPg5J ndsTKAYzyLbEdhRUusGl39x7/Np+Fv//R8zPswLir2tJMx2PSBwqnKUVQQKiqTemulR2+mZr cCrY9/MJi8DFCKp37xMeALz/ECRxES0VZ/CS/NNUE/Dbdcv+i2jipBYkFGRrz+ZuqZVx8dg6 i9oHwLWf1Uor0k85Cad18g5y9OE3ShTGOrz76E9VG3ePClvmQNTRNfoeoMa+I0FVBMSnigdu UaMWTF8jKm2sJ8yWWJdnxJGIEFVlaT2TujQvbuObuJMjlzWi44kMC6Qr2Y+sfO2DkCp9WMoi Fl0lBVOAK7Gkfwb7VW+dyCmBNixPHT6qv359YjAm+Ki3rMXPkkFgEAf8Yg5VQNNHiavlJcqu CkxZ2wEVh4Fzqi1KPVLvhrIivC+li3+L69hfHYQ8GrX8O6BoxphiXdGTv2Ld1qe8rbrbDPuC N3sJUMkVrF8es3EhzeNxVBWaQica3w9ZNbfc/zCcv3ds8e5o4243H08pCIvLWgtlMHTAQG6T Zh+IIflZ6xD4GBzjjcAU6i/3X1tD8eaWtBb/1lP1UIGHqfUS5nQ2HMEdm5/Vy3VQ54DBx069 2fSzZdVX0J2YNsItsL3yK6xNIDrSQ+3TD5euFJ9k7y9G78ia4ZIiinRQAmnfmjnMNacliIg4 saGGTyYvMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwEjfTAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MDkyMDQx MDJaMCMGCSqGSIb3DQEJBDEWBBSXKlc2YM9axFbs4krUOMcnlvb9qzBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB I30wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBI30wDQYJKoZIhvcN AQEBBQAEggEADX82LpRXXkvH6OcpSYLB139TepzFTvXoDN3747cHepGUWfvid4swff5gKsag H71c4kqWJaf1qorlmvM6rSDOMz/BXgsR2Zg6EfastapBVpY5bTr/ka/2WNc+vMgtubFiVhVL 4534sWD2hzDvIKHk3OqFbm5mfu16WeI/Uj4TUqM+qjupDbawb7LBQC8Ck+qOtrMO5tCXiTcx 9//MkNqc4/Dht+cWQaNXvLtqzlmd9tB+r33OT2GVTJPyNO9pEOmjDqTlD49rUUF2fvGCTEJH 5vWeXpeLsBdMdGW4chGQzYOYQ3P8aFO4XU9XZD2HXZYsLZPDDH4ZNESmfBWu0FBI2gAAAAAA AA== --------------ms060603060301060007040603-- From owner-atom-syntax@mail.imc.org Tue Aug 09 16:55:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2b8B-0005mv-S8 for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:55:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13928 for ; Tue, 9 Aug 2005 16:55:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79Kp86f080720; Tue, 9 Aug 2005 13:51:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79Kp8Ot080719; Tue, 9 Aug 2005 13:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79Kp7Kj080705 for ; Tue, 9 Aug 2005 13:51:07 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050809205101.TXIK21883.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com> for ; Tue, 9 Aug 2005 21:51:01 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20050809205101.NNTH12116.aamta10-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com> for ; Tue, 9 Aug 2005 21:51:01 +0100 Date: Tue, 9 Aug 2005 21:50:57 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <6110504678.20050809215057@djpowell.net> To: atom-syntax@imc.org Subject: More about Extensions 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: Content-Transfer-Encoding: 7bit I still believe that relative URIs shouldn't exist in Simple Extension constructs [1]. I think that the lack of rationale for their being 2-3 classes of extension construct is proving to be harmful. Prior to the introduction of Section 6, Atom pretty much said you can include any foreign markup anywhere. I thought that this conflicted with the claim made by the charter that: > Atom consists of: > * A conceptual model of a resource > * A concrete syntax for this model I thought that the model should be separable from the syntax, so that people can use databases and RDF stores as their back-ends rather than just XML files. And I thought that it was important that extensions should be part of that model, rather than only be representable in the syntax, else extensions would be poor-cousins of the core elements. Restricting Atom extensions to only being simple string name/value parameters would ensure that they were represented in the model, but it would have been too limiting. So the two classes of Extension construct, Simple and Structured, are a compromise between constraints and flexibility. The pros and cons of each class are: Simple Extension constructs: ---------------------------- + simple string name/value properties of the feed/entry/person. Easy to implement generically end-to-end in servers/clients so that extensions can be deployed generically without requiring "boil the ocean" acceptance. + property semantics as described by section 6.4.1. + publishing clients could provide an extension editor, where metadata fields could be added to the clients form, given a namespace URI and element name. + extensions don't need to be defined specifically for Atom. RDF Vocabularies, RSS extensions, DC, and PRISM already define properties that are compatible with Atom Simple Extensions. + simple, useful mapping to RDF - can't represent language sensitive text. This decision was made because very few RSS extensions contain language sensitive text, (they tend to contain dates, numbers, tokens, URIs etc - when language-sensitive text is required Structured Extensions should be used). Also, the barrier for implementations such as custom property tables, CRMs, and WebDAV implementations would be high. - can't represent relative URI references, because they are defined to be strings only, and generic implementations can't know what is or isn't a URI reference. Structured Extension constructs: -------------------------------- + Can support (almost) arbitrary XML. - no pre-defined semantics. + no pre-defined semantics. - clumsy generic mapping to RDF (by preserving the XML blob), though with extension specific knowledge a better mapping could be used. + Publishing servers can generically support them by preserving the blob of XML. - Publishing clients can't easily generically support them, as the UI to edit a chunk of arbitrary XML wouldn't be very user-friendly. - require at least a mandatory attribute or child in order to exist. Namespaced attributes & atom:link children ------------------------------------------ - Not part of the Atom model - only representable by the syntax. - Not really practical to support generically; require "boil the ocean" adoption. - Really not something I'm keen on as evidenced by this biased assessment... Are they really allowed for things other than future versions of Atom? + ...OK, they let you add annotations to elements in a way that would be difficult to address without an RDF style graph-based format. Does that sound about right? So, can we agree that relative URIRefs aren't allowed in Simple Extension constructs and add a clarification, else their implementation won't satisfy the rationale for their design. If I'm wrong, and the rationale behind Simple Extensions isn't important, then can someone explain why there are two classes of extension? [1] http://www.imc.org/atom-syntax/mail-archive/msg16598.html -- Dave From owner-atom-syntax@mail.imc.org Tue Aug 09 17:49:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2byZ-0004fH-QX for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 17:49:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16691 for ; Tue, 9 Aug 2005 17:49:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79LiRwJ085123; Tue, 9 Aug 2005 14:44:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79LiRSr085122; Tue, 9 Aug 2005 14:44:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79LiN4P085116 for ; Tue, 9 Aug 2005 14:44:23 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.173.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 108C1A32BB; Tue, 9 Aug 2005 17:44:21 -0400 (EDT) In-Reply-To: <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D5381F9-247C-4C70-93D4-5D1768EAF6D1@mnot.net> Cc: Eric Scheid , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -02 Date: Tue, 9 Aug 2005 14:44:18 -0700 To: Henry Story X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 09/08/2005, at 4:07 AM, Henry Story wrote: > > But I would really like some way to specify that the next feed > document is an archive (ie. won't change). This would make it easy > for clients to know when to stop following the links, ie, when they > have cought up with the changes since they last looked at the feed. > > Perhaps something like this: > > http://liftoff.msfc.nasa.gov/2003/04/ > feed.rss I'd think that would be more appropriate as an extension to the archive itself, wouldn't it? That way, the metadata (the fact that it's an archive) is part of the data (the archive feed). E.g., ... By (current) definition, anything that history:prev points to is an archive. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 09 18:27:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2cZF-0003aa-Je for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 18:27:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19545 for ; Tue, 9 Aug 2005 18:27:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79MML5Z088577; Tue, 9 Aug 2005 15:22:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j79MMLMH088576; Tue, 9 Aug 2005 15:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j79MMK50088563 for ; Tue, 9 Aug 2005 15:22:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so9612wra for ; Tue, 09 Aug 2005 15:22:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oFh6VtVSD5bd0PM2l4D/3v7mRJ8mTULZGtxUB1yCYo8YArJhChi8lvsiQku50FecxDDmU8U39MHOMxSxOSdQcFdl6LOz5Fmtafh90upby/2W3L+6UnH1eXWBFGsAxlS+7QLG7RwIEKQhOITiLYfOlUAQMeU1Z/GAEfhHYq794S0= Received: by 10.54.16.26 with SMTP id 26mr59706wrp; Tue, 09 Aug 2005 15:22:14 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 9 Aug 2005 15:22:14 -0700 (PDT) Message-ID: <68fba5c505080915223633505@mail.gmail.com> Date: Tue, 9 Aug 2005 18:22:14 -0400 From: Robert Sayre To: David Powell Subject: Re: More about Extensions Cc: atom-syntax@imc.org In-Reply-To: <6110504678.20050809215057@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6110504678.20050809215057@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j79MMK50088571 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/9/05, David Powell wrote: > If I'm wrong, and the rationale behind Simple Extensions isn't > important... Sorry, I don't buy this. You're wrong, but the rationale is important. :) What are we going to do, outlaw strings that happen to look like relative references? If you want a generic processor to handle your extension, you've got atom:link, which will work fine. Maybe you want the relative reference to point at something relative, no matter where it ends up. I can't think of why anyone would want to do that, but maybe they will. Relative references are fragile, and people understand why they break. None of the other pros for this capability are affected. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 09 20:16:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2eHC-0003Rg-Ma for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:16:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25213 for ; Tue, 9 Aug 2005 20:16:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0Bohp096670; Tue, 9 Aug 2005 17:11:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A0BoeN096669; Tue, 9 Aug 2005 17:11:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0BmJm096662 for ; Tue, 9 Aug 2005 17:11:49 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050810001143.XYYO21883.mta07-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>; Wed, 10 Aug 2005 01:11:43 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20050810001143.OFHQ1947.aamta09-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com>; Wed, 10 Aug 2005 01:11:43 +0100 Date: Wed, 10 Aug 2005 01:11:38 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1651873542.20050810011138@djpowell.net> To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <68fba5c505080915223633505@mail.gmail.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit Tuesday, August 9, 2005, 11:22:14 PM, Robert Sayre wrote: > What are we going to do, outlaw strings that happen to look like > relative references? No, we just need to warn publishers (and extension authors) that the base URI of Simple Extension elements is not significant, and that they must not expect it to be preserved. We do the same regarding xml:lang already by saying that the element is not Language Sensitive, which means that the language context is not significant and that publishers must not expect it to be preserved. from Section 2: > The language context is only significant for elements and attributes > declared to be "Language-Sensitive" by this specification. I'd suggest adding something similar to Section 6.4.1, eg: "The base URI is not significant for Simple Extension elements." > Relative references are fragile, and people understand why they > break. Publishers should expect that relative refs used in atom:link will work, but publishers should expect that relative refs used in Simple Extensions will break. -- Dave From owner-atom-syntax@mail.imc.org Tue Aug 09 20:39:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ed6-0003sn-GV for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:39:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26579 for ; Tue, 9 Aug 2005 20:39:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0V0f4098383; Tue, 9 Aug 2005 17:31:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A0V0Pk098382; Tue, 9 Aug 2005 17:31:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0UxLw098367 for ; Tue, 9 Aug 2005 17:30:59 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so24848wra for ; Tue, 09 Aug 2005 17:30:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JzgVZgAVrD245E74/qxZt+iZdDbZHwsFAzKXFia1fGVPnabVv7Bc9GzIBychiB+tpSwOgj7snNvCmCejUc4zKEMvWANaoVWlF8ucxUoTq7ZodZtENT8EEnBSXdvZlBHcEh1nkYPDNFwhGnGkT1ICqBVEo79DvmJFcwCtMmty6E8= Received: by 10.54.50.65 with SMTP id x65mr114842wrx; Tue, 09 Aug 2005 17:30:54 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 9 Aug 2005 17:30:54 -0700 (PDT) Message-ID: <68fba5c5050809173076087214@mail.gmail.com> Date: Tue, 9 Aug 2005 20:30:54 -0400 From: Robert Sayre To: David Powell Subject: Re: More about Extensions Cc: atom-syntax@imc.org In-Reply-To: <1651873542.20050810011138@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7A0UxLw098373 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/9/05, David Powell wrote: > > Publishers should expect that relative refs used in atom:link will > work, but publishers should expect that relative refs used in Simple > Extensions will break. Disagree. We have no idea what people will do with this, or where they will be deployed. You're suggesting adding implementation advice, since the content of a simple extension element is not defined as a URI reference. By your logic, we have to explicitly clarify that atom:updated is not subject to xml:base processing. Sorry, I strongly disagree. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 09 20:39:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ed6-0003sm-GU for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:39:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26578 for ; Tue, 9 Aug 2005 20:39:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0YO7f098642; Tue, 9 Aug 2005 17:34:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A0YO1G098641; Tue, 9 Aug 2005 17:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0YNsK098635 for ; Tue, 9 Aug 2005 17:34:23 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7A0YMvU017737 for ; Tue, 9 Aug 2005 18:34:22 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IKZ00FDSDL9XV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 09 Aug 2005 18:34:22 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IKZ00G5LDL9FG@mail.sun.net> for atom-syntax@imc.org; Tue, 09 Aug 2005 18:34:21 -0600 (MDT) Date: Tue, 09 Aug 2005 17:34:44 -0700 From: Tim Bray Subject: Re: More about Extensions In-reply-to: <1651873542.20050810011138@djpowell.net> To: David Powell Cc: Robert Sayre , atom-syntax@imc.org Message-id: <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 9, 2005, at 5:11 PM, David Powell wrote: > No, we just need to warn publishers (and extension authors) that the > base URI of Simple Extension elements is not significant, and that > they must not expect it to be preserved. Either the software understands the foreign markup, in which case it might recognize a relative URI, in which case it should apply the correct base URI, or it doesn't, in which case everything in the foreign markup is just a semantics-free string. The problem could hypothetically arise when someone extracts properties from the foreign markup, stuffs them in a tuple store, and then when the software that knows what to do with comes along and retrieves it and recognizes the relative URI and can't do much because the base URI is lost. So... IF you know how to handle some particular extension, AND IF you expect to handle it when the extension data has been ripped out of the feed and stored somewhere without any context, THEN you shouldn't use a relative reference. Alternatively, IF you want to empower extensions to process they data they understand, AND IF you want to rip that data out of the feed and store it somewhere, THEN it would be smart to provide software an interface to retrieve context, such as feed-level metadata and the base URI. Sounds like implementor's-guide material to me. And, to whoever said relative references are "fragile": Wrong. When you have to move bales of web content around from one place to another, and just supposing hypothetically that you have internal links, relative references are robust, absolute URIs are fragile. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 09 20:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2eqW-0000vA-FB for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 20:53:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27002 for ; Tue, 9 Aug 2005 20:53:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0keAU000354; Tue, 9 Aug 2005 17:46:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A0keBX000353; Tue, 9 Aug 2005 17:46:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0kcT4000343 for ; Tue, 9 Aug 2005 17:46:39 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so26492wra for ; Tue, 09 Aug 2005 17:46:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aS++zvWCIuyLrmKPqanbk0U8oJas8H90aZj0DibWkLD0kK3+oswfRroiatRQCkMfBzZ+luu4zPrS0kmM2PwS/jnNt1VJBkxslDi7dP1uf4DbDPoQxdc/Z0q8TGw0Dyx+p2Cp95MPUk3NCCjohebnH62ww5picqt03hdvszHz304= Received: by 10.54.141.18 with SMTP id o18mr117204wrd; Tue, 09 Aug 2005 17:46:33 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 9 Aug 2005 17:46:33 -0700 (PDT) Message-ID: <68fba5c5050809174663701bb6@mail.gmail.com> Date: Tue, 9 Aug 2005 20:46:33 -0400 From: Robert Sayre To: Tim Bray Subject: Re: More about Extensions Cc: David Powell , atom-syntax@imc.org In-Reply-To: <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7A0kdT4000348 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/9/05, Tim Bray wrote: > And, to whoever said relative references are "fragile": Wrong. When > you have to move bales of web content around from one place to > another, and just supposing hypothetically that you have internal > links, relative references are robust, absolute URIs are fragile. And when you have bales of web content that have to be displayed on a super-wide variety of display technologies, many of which have limited supported for changing and mixing base URIs (like HTML), relative references are fragile. This is the kind of situation you run into with syndication formats, and it should go in the implementation guide. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 09 21:01:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2eyP-00045S-Po for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 21:01:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27297 for ; Tue, 9 Aug 2005 21:01:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0uEfa000941; Tue, 9 Aug 2005 17:56:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A0uEIW000940; Tue, 9 Aug 2005 17:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A0uDYg000932 for ; Tue, 9 Aug 2005 17:56:14 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so14791nzi for ; Tue, 09 Aug 2005 17:56:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FHr5oziZuOgjtR4Jo0+rzPLOvItaxKypNRmDk86yKX/5Oyh8CDs9qY7zAG4vNsYKZD9OYZXoel6ShsqX6n3Bu7k0lBMoTXuKBB+yPcgVGn9xm1ZpaS1yWvY3f31XLzYCNAnwfEjfhZc4FVjNAzjdW/SUG10y/0AQ5vqMhhB3WPw= Received: by 10.36.146.20 with SMTP id t20mr156264nzd; Tue, 09 Aug 2005 17:56:08 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 38sm74715nzf.2005.08.09.17.56.07; Tue, 09 Aug 2005 17:56:08 -0700 (PDT) Message-ID: <42F950A1.1060407@gmail.com> Date: Tue, 09 Aug 2005 17:56:01 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: David Powell , Robert Sayre , atom-syntax@imc.org Subject: Re: More about Extensions References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> In-Reply-To: <8A735428-A0CC-4C66-8364-D24794B76A81@sun.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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > Sounds like implementor's-guide material to me. > ++++1 - James From owner-atom-syntax@mail.imc.org Tue Aug 09 22:52:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ghv-0003wy-DD for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 22:52:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01052 for ; Tue, 9 Aug 2005 22:52:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A2kIlI010824; Tue, 9 Aug 2005 19:46:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A2kIvX010823; Tue, 9 Aug 2005 19:46:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A2kHru010814 for ; Tue, 9 Aug 2005 19:46:17 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so23407nzi for ; Tue, 09 Aug 2005 19:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EELqTXhKi1UME+jbi6G0eMvcB3/FsKxqeYFfxCCWILB5Y5GOs9J4kfD60rfsQB6Tc4XeEoqgokJglgMeYJxTHiJHIWBMHN9YjpGGTSYKxpRPDvq/+/C4BUA4OqC0KTKk01ypwYcxRncjgQF0DLLCdykCafd0h09iy0Udjx8uIIk= Received: by 10.36.9.8 with SMTP id 8mr244868nzi; Tue, 09 Aug 2005 19:46:10 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 38sm3075933nzk.2005.08.09.19.46.09; Tue, 09 Aug 2005 19:46:10 -0700 (PDT) Message-ID: <42F96A6B.9050109@gmail.com> Date: Tue, 09 Aug 2005 19:46:03 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Walter Underwood , Atom Syntax Subject: Expires extension draft (was Re: Feed History -02) References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> In-Reply-To: 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: Content-Transfer-Encoding: 7bit This is fairly quick and off-the-cuff, but here's an initial draft to get the ball rolling.. http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt - James Henry Story wrote: > To answer my own question > > [[ > Interesting... but why have a limit of one year? For archives, I > would like a limit of > forever. > ]] > > I found the following in the HTTP spec > > [[ > To mark a response as "never expires," an origin server sends an > Expires date approximately one year from the time the response is > sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one > year in the future. > ]] > > (though that still does not explain why.) > > Now I am wondering if the http mechanism is perhaps all that is needed > for what I want with the unchanging archives. If it is then perhaps this > could be explained in the Feed History RFC. Or are there other > reasons to > add and "expires" tag to the document itself? > > Henry Story > > On 9 Aug 2005, at 19:09, James M Snell wrote: > >>>> >>>> >>> rules as atom:author elements. >>> >>> Here it is: >>> >>> >>> >> The expires and max-age elements look fine. I hesitate at bringing >> in a caching discussion. I'm much more comfortable leaving the >> definition of caching rules to the protocol level (HTTP) rather than >> the format extension level. Namely, I don't want to have to go into >> defining rules for how HTTP headers that affect caching interact >> with the expires and max-age elements... IMHO, there is simply no >> value in that. >> The expires and max-age extension elements affect the feed / entry >> on the application level not the document level. HTTP caching works >> on the document level. >> >> >>> Adding max-age also means defining IntegerConstruct and disallowing >>> white space around it. Formerly, it was OK as a text construct, but >>> the white space issues change that. >>> >>> >>> >> This is easy enough. >> >> >>> Also, we should decide whether cache information is part of the >>> signature. >>> I can see arguments either way. >>> >>> >>> >> -1. let's let caching be handled by the transport layer. >> > > From owner-atom-syntax@mail.imc.org Tue Aug 09 23:35:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hNU-0002h9-Mg for atompub-archive@megatron.ietf.org; Tue, 09 Aug 2005 23:35:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02485 for ; Tue, 9 Aug 2005 23:35:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A3V9ib017164; Tue, 9 Aug 2005 20:31:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A3V9pp017163; Tue, 9 Aug 2005 20:31:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A3V8Mo017157 for ; Tue, 9 Aug 2005 20:31:08 -0700 (PDT) (envelope-from mark.nottingham@bea.com) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 1E494A32BD; Tue, 9 Aug 2005 23:31:07 -0400 (EDT) In-Reply-To: <42F8FBB1.5060603@gmail.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> <42F8FBB1.5060603@gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Henry Story , Walter Underwood , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -02 Date: Tue, 9 Aug 2005 20:31:04 -0700 To: James M Snell X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit HTTP isn't a transport protocol, it's a transfer protocol; i.e., the caching information (and other entity metadata) are *part of* the entity, not something that's conceptually separate. The problem with having an "abstract" or "transport-neutral" concept of caching is that it leaves you with an awkward choice; you can either a) exactly replicate the HTTP caching model, which is difficult to do in other protocols, b) "dumb down" HTTP caching to a subset that's "neutral", or c) introduce a contradictory caching model and suffer the clashes between HTTP caching and it. This is the same road that Web services sometimes tries to go down, and it's a painful one; coming up with the grand, protocol-neutral abstraction that enables all of the protocol-specific features is hard, and IMO not necessary. Ask yourself: are there any situations where you *have* to be able to seamlessly switch between protocols, or is it just a "convenience?" I think we can declare victory here by simply a) using whatever caching mechanism is available, and b) designating a "won't change" flag. On 09/08/2005, at 11:53 AM, James M Snell wrote: > Henry Story wrote: >> Now I am wondering if the http mechanism is perhaps all that is >> needed >> for what I want with the unchanging archives. If it is then >> perhaps this >> could be explained in the Feed History RFC. Or are there other >> reasons to >> add and "expires" tag to the document itself? > > On the application level, a feed or entry may expire or age > indepedently of whatever caching mechanisms may be applied at the > transport level. For example, imagine a source that publishes > special offers in the form of Atom entries that expire at a given > point in time. Now suppose that those entries are being > distributed via XMPP and HTTP. It is helpful to have a transport > independent expiration/max-age mechanism whose semantics operate on > the application layer rather than the transport layer. > > - James > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Wed Aug 10 00:03:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hoT-0005GI-Q5 for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 00:03:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03831 for ; Wed, 10 Aug 2005 00:03:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A3u9eF019018; Tue, 9 Aug 2005 20:56:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A3u92e019017; Tue, 9 Aug 2005 20:56:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A3u7Mn019010 for ; Tue, 9 Aug 2005 20:56:08 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 10 Aug 2005 13:57:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 10 Aug 2005 13:56:05 +1000 Subject: Re: Expires extension draft (was Re: Feed History -02) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42F96A6B.9050109@gmail.com> 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: Content-Transfer-Encoding: 7bit On 10/8/05 12:46 PM, "James M Snell" wrote: > This is fairly quick and off-the-cuff, but here's an initial draft to > get the ball rolling.. > > http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt > Looks good, I think it does need a little bit of prose explaining that this has nothing to do with caching, and should not be used in scheduling when to revisit/refresh/expire local copies of the resource. Similarly, if I understand correctly, when you write "The 'max-age' extension element is used to indicate the maximum age of a feed or entry." you are referring to the max-age until the informational content of the respective feed or entry expires. And similarly with age:expires. Yes? Aside: a perfect example of what sense of 'expires' is in the I-D itself... Network Working Group Internet-Draft Expires: January 2, 2006 :-) e. From owner-atom-syntax@mail.imc.org Wed Aug 10 00:13:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hyK-0001bO-Qe for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 00:13:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04212 for ; Wed, 10 Aug 2005 00:13:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A485L8019876; Tue, 9 Aug 2005 21:08:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A485A5019875; Tue, 9 Aug 2005 21:08:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A484JJ019866 for ; Tue, 9 Aug 2005 21:08:04 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so51594wra for ; Tue, 09 Aug 2005 21:07:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OmZHGnhvMxKLXcvZiAFoV7FnRtn2yInyVDV2uBKFafJj9QhVWsLTUJXxPEQkafPO+CYURqzMnHKk6Wj5WIth5RNRBex65ZI0i6t4sfv41wv3UXuhIAbSiX8VcCH2+Eh3grzqxm1c7pjNzYJ9IOy5jHHJ5naZiW9cK6RSIfsyh6o= Received: by 10.54.83.5 with SMTP id g5mr211703wrb; Tue, 09 Aug 2005 21:07:58 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id g12sm11065203wra.2005.08.09.21.07.57; Tue, 09 Aug 2005 21:07:58 -0700 (PDT) Message-ID: <42F97D97.3000007@gmail.com> Date: Tue, 09 Aug 2005 21:07:51 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Henry Story , Walter Underwood , Atom Syntax Subject: Re: Feed History -02 References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> <42F8FBB1.5060603@gmail.com> In-Reply-To: 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: Content-Transfer-Encoding: 7bit First off, let me stress that I am NOT talking about caching scenarios here... (my use of the terms "application layer" and "transport layer" were an unfortunate mistake on my part that only served to confuse my point) Let's get away from the multiprotocol question for a bit (it never leads anywhere constructive anyway)... Let's consider an aggregator scenario. Take an entry from a feed that is supposed to expire after 10 days. The feed document is served up to the aggregator with the proper HTTP headers for expiration. The entry is extracted from the original feed and dumped into an aggregated feed. Suppose each of the entries in the aggregated feed are supposed to have their own distinct expirations. How should the aggregator communicate the appropriate expirations to the subscriber? Specifying expirations on the HTTP level does not allow me to specify expirations for individual entries within a feed. Use case: an online retailer wishes to produce a "special offers" feed. Each offer in the feed is a distinct entity with it's own terms and own expiration: e.g. some offers are valid for a week, other offers are valid for two weeks, etc. The expiration of the offer (a business level construct) is independent of whether or not the feed is being cached or not (a protocol level construct); publishing a new version of the feed (e.g. by adding a new offer to the feed) should have no impact on the expiration of prior offers published to the feed. Again, I am NOT attempting to reinvent an abstract or transport-neutral caching mechanism in the same sense that the atom:updated element is not attempting to reinvent Last-Modified or that the via link relation is not attempting to reinvent the Via header, etc. They serve completely different purposes. The expires and max-age extensions I am proposing should NOT be used for cache control of the Atom documents in which they appear. >I think we can declare victory here by simply a) using whatever caching mechanism is available, and b) designating a "won't change" flag. Speaking *strictly* about cache control of Atom documents, +1. No document level mechanisms for cache control are necessary. - James Mark Nottingham wrote: > HTTP isn't a transport protocol, it's a transfer protocol; i.e., the > caching information (and other entity metadata) are *part of* the > entity, not something that's conceptually separate. > > The problem with having an "abstract" or "transport-neutral" concept > of caching is that it leaves you with an awkward choice; you can > either a) exactly replicate the HTTP caching model, which is > difficult to do in other protocols, b) "dumb down" HTTP caching to a > subset that's "neutral", or c) introduce a contradictory caching > model and suffer the clashes between HTTP caching and it. > > This is the same road that Web services sometimes tries to go down, > and it's a painful one; coming up with the grand, protocol-neutral > abstraction that enables all of the protocol-specific features is > hard, and IMO not necessary. Ask yourself: are there any situations > where you *have* to be able to seamlessly switch between protocols, > or is it just a "convenience?" > > I think we can declare victory here by simply a) using whatever > caching mechanism is available, and b) designating a "won't change" > flag. > > > > > > > On 09/08/2005, at 11:53 AM, James M Snell wrote: > >> Henry Story wrote: >> >>> Now I am wondering if the http mechanism is perhaps all that is needed >>> for what I want with the unchanging archives. If it is then perhaps >>> this >>> could be explained in the Feed History RFC. Or are there other >>> reasons to >>> add and "expires" tag to the document itself? >> >> >> On the application level, a feed or entry may expire or age >> indepedently of whatever caching mechanisms may be applied at the >> transport level. For example, imagine a source that publishes >> special offers in the form of Atom entries that expire at a given >> point in time. Now suppose that those entries are being distributed >> via XMPP and HTTP. It is helpful to have a transport independent >> expiration/max-age mechanism whose semantics operate on the >> application layer rather than the transport layer. >> >> - James >> >> >> > > > -- > Mark Nottingham Principal Technologist > Office of the CTO BEA Systems > > From owner-atom-syntax@mail.imc.org Wed Aug 10 00:20:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2i4j-0003sT-Mb for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 00:20:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04596 for ; Wed, 10 Aug 2005 00:20:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A4Ertx020573; Tue, 9 Aug 2005 21:14:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A4ErXX020572; Tue, 9 Aug 2005 21:14:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A4EqDK020544 for ; Tue, 9 Aug 2005 21:14:52 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so34557nzb for ; Tue, 09 Aug 2005 21:14:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NnGU7EXymVMA/o10QDRaVOEdM0onm1gpOleNJ7WaYcraMUdcDhajhC2oHCpSxUKC+gRNdofZLHCKLZC/4L079y5E/1d7Dq3filnn0tgpVQfO5ajgXHQ4bLqudFej7N1Yv1fQhSmIIgb9vj0P7RsNrXPQdR8yuH3OxgJskrV98nA= Received: by 10.36.221.9 with SMTP id t9mr16217nzg; Tue, 09 Aug 2005 21:14:46 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 20sm5335547nzp.2005.08.09.21.14.46; Tue, 09 Aug 2005 21:14:46 -0700 (PDT) Message-ID: <42F97F2F.10005@gmail.com> Date: Tue, 09 Aug 2005 21:14:39 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Expires extension draft (was Re: Feed History -02) References: In-Reply-To: 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: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 10/8/05 12:46 PM, "James M Snell" wrote: > > > >>This is fairly quick and off-the-cuff, but here's an initial draft to >>get the ball rolling.. >> >>http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt >> >> >> > >Looks good, I think it does need a little bit of prose explaining that this >has nothing to do with caching, and should not be used in scheduling when to >revisit/refresh/expire local copies of the resource. > > > Absolutely. I put this together rather quickly fully knowing that I would need to revisit the text to fully explain the use of the extension. I'll be taking a few whacks at that over the coming days as time allows. >Similarly, if I understand correctly, when you write > "The 'max-age' extension element is used to indicate > the maximum age of a feed or entry." >you are referring to the max-age until the informational content of the >respective feed or entry expires. And similarly with age:expires. Yes? > > > Yes. I will be clarifying this in the draft. The extensions are really only reflective of the informational content in individual entries. As we do with the atom:author element, expires and max-age can be specified at the feed or source level, but apply to the content of individual entries. e.g. ... is equivalent to ... ... >Aside: a perfect example of what sense of 'expires' is in the I-D itself... > > Network Working Group > Internet-Draft > Expires: January 2, 2006 > > > Excellent point :-) - James From owner-atom-syntax@mail.imc.org Wed Aug 10 02:40:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kGi-0006kt-QZ for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:40:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07773 for ; Wed, 10 Aug 2005 02:40:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A6Ui3C064438; Tue, 9 Aug 2005 23:30:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A6Uixc064437; Tue, 9 Aug 2005 23:30:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A6UhnM064426 for ; Tue, 9 Aug 2005 23:30:43 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 73095 invoked by uid 17064); 10 Aug 2005 06:30:42 -0000 Received: from unknown (HELO [192.168.1.43]) ([83.79.2.11]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 Aug 2005 06:30:42 -0000 In-Reply-To: <42F96A6B.9050109@gmail.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> <42F96A6B.9050109@gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16A44F36-76F7-4B1D-808A-8F89DB39C057@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Expires extension draft (was Re: Feed History -02) Date: Wed, 10 Aug 2005 08:30:42 +0200 To: James M Snell X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There is an interesting problem of how this interacts with the history tag. If you set an a feed ... then what are you setting it on? Well not the document, clearly, as you have pointed out since HTTP headers deal with that. So it must be on the feed. And of course a feed is identified by its id. Now we have to make sure we avoid contradictions where different feed documents describing the same feed state that the feed has different expiry dates. Eg: ----the main feed---------- August 25 2006 tag:example.com,2000/feed1 http://example.com/archive1 --------------------------- The above is a partial description of the feed tag:example.com,2000/ feed1 The history:previous link points to another document that gives us more information about that feed. ---the archive feed-------- August 15 2006 tag:example.com,2000/feed1 http://example.com/archive2 --------------------------- Now of course we have a feed id with two expiry dates. Which one is correct? In graph terms we end up with something like this: tag:example.com,2000 |----expires------>August 25 2006 |----expires------>August 15 2006 |----entry-------->... |----entry-------->... |----entry-------->... |----entry-------->... One has the feeling that the expires relation should be functional, ie have only one value. This makes me think again that for what I was looking for (that the document in history:previous not change, so that one can work out when to stop fetching documents) can in fact be entirely be taken care of by the http expiry dates and cache control mechanism. Of course if this is so, I think it should be noted clearly in the history spec. ((btw. Is it easy to set expiry dates for documents served by apache?)) Henry Story On 10 Aug 2005, at 04:46, James M Snell wrote: > > This is fairly quick and off-the-cuff, but here's an initial draft > to get the ball rolling.. > > http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt > > - James > > Henry Story wrote: > > >> To answer my own question >> >> [[ >> Interesting... but why have a limit of one year? For archives, I >> would like a limit of >> forever. >> ]] >> >> I found the following in the HTTP spec >> >> [[ >> To mark a response as "never expires," an origin server sends an >> Expires date approximately one year from the time the response is >> sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one >> year in the future. >> ]] >> >> (though that still does not explain why.) >> >> Now I am wondering if the http mechanism is perhaps all that is >> needed >> for what I want with the unchanging archives. If it is then >> perhaps this >> could be explained in the Feed History RFC. Or are there other >> reasons to >> add and "expires" tag to the document itself? >> >> Henry Story >> >> On 9 Aug 2005, at 19:09, James M Snell wrote: >> >> >>>>> >>>>> >>>>> >>>> rules as atom:author elements. >>>> >>>> Here it is: >>>> >>>> >>>> >>>> >>> The expires and max-age elements look fine. I hesitate at >>> bringing in a caching discussion. I'm much more comfortable >>> leaving the definition of caching rules to the protocol level >>> (HTTP) rather than the format extension level. Namely, I don't >>> want to have to go into defining rules for how HTTP headers that >>> affect caching interact with the expires and max-age elements... >>> IMHO, there is simply no value in that. >>> The expires and max-age extension elements affect the feed / >>> entry on the application level not the document level. HTTP >>> caching works on the document level. >>> >>> >>> >>>> Adding max-age also means defining IntegerConstruct and disallowing >>>> white space around it. Formerly, it was OK as a text construct, but >>>> the white space issues change that. >>>> >>>> >>>> >>>> >>> This is easy enough. >>> >>> >>> >>>> Also, we should decide whether cache information is part of the >>>> signature. >>>> I can see arguments either way. >>>> >>>> >>>> >>>> >>> -1. let's let caching be handled by the transport layer. >>> >>> >> >> > From owner-atom-syntax@mail.imc.org Wed Aug 10 02:48:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kNs-0008No-La for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 02:48:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08134 for ; Wed, 10 Aug 2005 02:48:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A6hTl7069683; Tue, 9 Aug 2005 23:43:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A6hTRn069682; Tue, 9 Aug 2005 23:43:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A6hTXQ069675 for ; Tue, 9 Aug 2005 23:43:29 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 78398 invoked by uid 17064); 10 Aug 2005 06:43:29 -0000 Received: from unknown (HELO [192.168.1.43]) ([83.79.2.11]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 Aug 2005 06:43:29 -0000 In-Reply-To: <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45CC9881-686F-42B7-AB77-DE84357813E4@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: More about Extensions Date: Wed, 10 Aug 2005 08:43:29 +0200 To: Tim Bray X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry to note the obvious, but does this not sound so much like a good reason we should have engineered atom to *be* RDF? Is this not exactly one of the many problems that RDF sets out to solve? Henry Story On 10 Aug 2005, at 02:34, Tim Bray wrote: > > On Aug 9, 2005, at 5:11 PM, David Powell wrote: > > >> No, we just need to warn publishers (and extension authors) that the >> base URI of Simple Extension elements is not significant, and that >> they must not expect it to be preserved. >> > > Either the software understands the foreign markup, in which case > it might recognize a relative URI, in which case it should apply > the correct base URI, or it doesn't, in which case everything in > the foreign markup is just a semantics-free string. > > The problem could hypothetically arise when someone extracts > properties from the foreign markup, stuffs them in a tuple store, > and then when the software that knows what to do with comes along > and retrieves it and recognizes the relative URI and can't do much > because the base URI is lost. > > So... IF you know how to handle some particular extension, AND IF > you expect to handle it when the extension data has been ripped out > of the feed and stored somewhere without any context, THEN you > shouldn't use a relative reference. Alternatively, IF you want to > empower extensions to process they data they understand, AND IF you > want to rip that data out of the feed and store it somewhere, THEN > it would be smart to provide software an interface to retrieve > context, such as feed-level metadata and the base URI. > > Sounds like implementor's-guide material to me. > > And, to whoever said relative references are "fragile": Wrong. > When you have to move bales of web content around from one place to > another, and just supposing hypothetically that you have internal > links, relative references are robust, absolute URIs are fragile. - > Tim > From owner-atom-syntax@mail.imc.org Wed Aug 10 04:42:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mA7-0002eE-K3 for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 04:42:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12638 for ; Wed, 10 Aug 2005 04:42:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A8YkrL013352; Wed, 10 Aug 2005 01:34:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A8Yk36013351; Wed, 10 Aug 2005 01:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A8YjDV013315 for ; Wed, 10 Aug 2005 01:34:46 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050810083439.CURL21883.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Wed, 10 Aug 2005 09:34:39 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20050810083439.RFSC12116.aamta10-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com>; Wed, 10 Aug 2005 09:34:39 +0100 Date: Wed, 10 Aug 2005 09:34:35 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1661002168.20050810093435@djpowell.net> To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <68fba5c5050809173076087214@mail.gmail.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit Wednesday, August 10, 2005, 1:30:54 AM, Robert Sayre wrote: > On 8/9/05, David Powell wrote: >> >> Publishers should expect that relative refs used in atom:link will >> work, but publishers should expect that relative refs used in Simple >> Extensions will break. > Disagree. We have no idea what people will do with this, or where they > will be deployed. You're suggesting adding implementation advice, > since the content of a simple extension element is not defined as a > URI reference. I want to know whether an implementation is corrupting data if it discards the base-uri of simple extensions. I think that it is the job of the spec to tell me this, not the the job of "implementation advice" to decide this. > By your logic, we have to explicitly clarify that > atom:updated is not subject to xml:base processing. Sorry, I strongly > disagree. Are you saying that we don't need clarification because it is obvious that simple extensions only contain strings that aren't subject to base processing? I think that it is pretty clear, but as Tim disagrees, I think that this is a good indication that we need clarification. -- Dave From owner-atom-syntax@mail.imc.org Wed Aug 10 04:42:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2mAT-0002j7-4f for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 04:42:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12682 for ; Wed, 10 Aug 2005 04:42:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A8Ymot013364; Wed, 10 Aug 2005 01:34:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A8YmTv013363; Wed, 10 Aug 2005 01:34:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A8YlFX013325 for ; Wed, 10 Aug 2005 01:34:47 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20050810083441.TUKZ9239.mta09-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>; Wed, 10 Aug 2005 09:34:41 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20050810083441.PPUB17166.aamta12-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com>; Wed, 10 Aug 2005 09:34:41 +0100 Date: Wed, 10 Aug 2005 09:34:37 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <301469631.20050810093437@djpowell.net> To: Tim Bray CC: Robert Sayre , atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <8A735428-A0CC-4C66-8364-D24794B76A81@sun.com> 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: Content-Transfer-Encoding: 7bit Wednesday, August 10, 2005, 1:34:44 AM, Tim Bray wrote: > The problem could hypothetically arise when someone extracts > properties from the foreign markup, stuffs them in a tuple store, and > then when the software that knows what to do with comes along and > retrieves it and recognizes the relative URI and can't do much > because the base URI is lost. I expect that many Atom Protocol server implementations will work this way. > So... IF you know how to handle some particular extension, AND IF you > expect to handle it when the extension data has been ripped out of > the feed and stored somewhere without any context, THEN you shouldn't > use a relative reference. The 1st/2nd "you"s are likely to be a different person from the 3rd "you". You seem to be saying: "if the consumer knows how to handle some particular extension [...] then the producer shouldn't use a relative reference". How does the producer know what the consumer will do? (Well of course that is the job of the specification, which is my point here). > Alternatively, IF you want to empower extensions to process they > data they understand, AND IF you want to rip that data out of the > feed and store it somewhere, THEN it would be smart to provide > software an interface to retrieve context, such as feed-level > metadata and the base URI. It sounds like you disagree with the rationale for Simple vs Structured extensions in [1]. So can I ask you why you think Atom defines Simple and Structured Extensions, when according to your understanding they need to be processed in exactly the seem way (though simple aren't language sensitive - which seems a bit odd if you believe that). I think that the second paragraph of 6.2.1 is pretty clear about what Simple Extensions mean (the value range of the property is character data, not character data plus base URI and language context), and that base URIs would be irrelevant to their processing, but I thought that it might need some clarification as once people start using them for URIs there is a risk that people could start using them for relative refs, given the lack of explanation or rationale for their purpose. > Sounds like implementor's-guide material to me. Alternative 1 is not implementable, and alternative 2 suggests processing that is not compatible with the intended purpose of Simple Extension elements. I wasn't entirely convinced that we needed to add this clarification, but now I am sure that we do. If there is a belief that implementations SHOULD preserve the base uri of Simple Extensions then we need to indicate that this is not true, else Simple Extensions will be broken from the start. [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html -- Dave From owner-atom-syntax@mail.imc.org Wed Aug 10 05:38:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2n2R-0000zY-Uo for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 05:38:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16096 for ; Wed, 10 Aug 2005 05:38:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A9WE8E033182; Wed, 10 Aug 2005 02:32:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7A9WEgs033179; Wed, 10 Aug 2005 02:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7A9WDj1033134 for ; Wed, 10 Aug 2005 02:32:14 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i16so105532wra for ; Wed, 10 Aug 2005 02:32:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LAwCYvSFD28NQDJqxf55x7llqrJ48E7Xbehi457c+c4eVY2A3YyUWh8gSodSQ0YRWGKui0rQ5NNJj+1VIdpipqFngpjy4e5HfWHj81AgL+hbLZ3ooCMdz9QS7LSLklz7QiVmZNxDo9wfU/7O9B7ZdnKNv2zloR3xOShYBkyZapc= Received: by 10.54.53.39 with SMTP id b39mr338386wra; Wed, 10 Aug 2005 02:32:08 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 7sm5077485wrl.2005.08.10.02.32.07; Wed, 10 Aug 2005 02:32:08 -0700 (PDT) Message-ID: <42F9C990.5040301@gmail.com> Date: Wed, 10 Aug 2005 02:32:00 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax Subject: Re: Expires extension draft (was Re: Feed History -02) References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> <42F96A6B.9050109@gmail.com> <16A44F36-76F7-4B1D-808A-8F89DB39C057@bblfish.net> In-Reply-To: <16A44F36-76F7-4B1D-808A-8F89DB39C057@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is precisely why the expires/max-age needs to operate strictly on the entry level. The expires/max-age elements may appear on the feed level but it actually only applies to the entries within that feed. Going back and reading my draft, I see that I screwed up and didn't indicate that properly. So in your example, the entries contained in the main feed expire on August 25th, the entries contained in the archive feed expire August 15th. There is no conflict. Henry Story wrote: > There is an interesting problem of how this interacts with the > history tag. > > If you set an a feed > > > ... > > > > > then what are you setting it on? Well not the document, clearly, as > you have > pointed out since HTTP headers deal with that. So it must be on the > feed. And > of course a feed is identified by its id. > > Now we have to make sure we avoid contradictions where different feed > documents > describing the same feed state that the feed has different expiry dates. > > Eg: > > ----the main feed---------- > > August 25 2006 > tag:example.com,2000/feed1 > > > http://example.com/archive1 > > --------------------------- > > The above is a partial description of the feed tag:example.com,2000/ > feed1 > The history:previous link points to another document that gives > us more information about that feed. > > ---the archive feed-------- > > August 15 2006 > tag:example.com,2000/feed1 > > > http://example.com/archive2 > > --------------------------- > > Now of course we have a feed id with two expiry dates. Which one is > correct? > In graph terms we end up with something like this: > > tag:example.com,2000 > |----expires------>August 25 2006 > |----expires------>August 15 2006 > |----entry-------->... > |----entry-------->... > |----entry-------->... > |----entry-------->... > > One has the feeling that the expires relation should be functional, > ie have > only one value. > > This makes me think again that for what I was looking for (that the > document > in history:previous not change, so that one can work out when to stop > fetching > documents) can in fact be entirely be taken care of by the http > expiry dates and > cache control mechanism. Of course if this is so, I think it should > be noted > clearly in the history spec. ((btw. Is it easy to set expiry dates > for documents served > by apache?)) > > > Henry Story > > > On 10 Aug 2005, at 04:46, James M Snell wrote: > >> >> This is fairly quick and off-the-cuff, but here's an initial draft >> to get the ball rolling.. >> >> http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt >> >> - James >> >> Henry Story wrote: >> >> >>> To answer my own question >>> >>> [[ >>> Interesting... but why have a limit of one year? For archives, I >>> would like a limit of >>> forever. >>> ]] >>> >>> I found the following in the HTTP spec >>> >>> [[ >>> To mark a response as "never expires," an origin server sends an >>> Expires date approximately one year from the time the response is >>> sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one >>> year in the future. >>> ]] >>> >>> (though that still does not explain why.) >>> >>> Now I am wondering if the http mechanism is perhaps all that is needed >>> for what I want with the unchanging archives. If it is then perhaps >>> this >>> could be explained in the Feed History RFC. Or are there other >>> reasons to >>> add and "expires" tag to the document itself? >>> >>> Henry Story >>> >>> On 9 Aug 2005, at 19:09, James M Snell wrote: >>> >>> >>>>>> >>>>>> >>>>>> >>>>> rules as atom:author elements. >>>>> >>>>> Here it is: >>>>> >>>>> >>>>> >>>>> >>>> The expires and max-age elements look fine. I hesitate at >>>> bringing in a caching discussion. I'm much more comfortable >>>> leaving the definition of caching rules to the protocol level >>>> (HTTP) rather than the format extension level. Namely, I don't >>>> want to have to go into defining rules for how HTTP headers that >>>> affect caching interact with the expires and max-age elements... >>>> IMHO, there is simply no value in that. >>>> The expires and max-age extension elements affect the feed / >>>> entry on the application level not the document level. HTTP >>>> caching works on the document level. >>>> >>>> >>>> >>>>> Adding max-age also means defining IntegerConstruct and disallowing >>>>> white space around it. Formerly, it was OK as a text construct, but >>>>> the white space issues change that. >>>>> >>>>> >>>>> >>>>> >>>> This is easy enough. >>>> >>>> >>>> >>>>> Also, we should decide whether cache information is part of the >>>>> signature. >>>>> I can see arguments either way. >>>>> >>>>> >>>>> >>>>> >>>> -1. let's let caching be handled by the transport layer. >>>> >>>> >>> >>> >> > > From owner-atom-syntax@mail.imc.org Wed Aug 10 11:26:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sTi-0001kU-O3 for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 11:26:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06079 for ; Wed, 10 Aug 2005 11:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AFKdQA043235; Wed, 10 Aug 2005 08:20:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AFKdo7043234; Wed, 10 Aug 2005 08:20:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AFKcJI043219 for ; Wed, 10 Aug 2005 08:20:38 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 1C0F74F; Wed, 10 Aug 2005 08:20:33 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7AFKVkv008987; Wed, 10 Aug 2005 08:20:32 -0700 (PDT) Date: Wed, 10 Aug 2005 08:20:09 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Expires extension draft (was Re: Feed History -02) Message-ID: <76C23EB178C35424B7CBC5A7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 10, 2005 1:56:05 PM +1000 Eric Scheid wrote: > Aside: a perfect example of what sense of 'expires' is in the I-D itself... > > Network Working Group > Internet-Draft > Expires: January 2, 2006 Especially perfect because the HTTP header does not reflect the expiration. Honestly, another reason to put expiration inside the feed is that HTTP caching is just not used. Well, except to force reloads and show you new ads. But it is extremely rare to see it per-document cache information. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Wed Aug 10 13:26:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uLD-0003VE-Ca for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:26:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12416 for ; Wed, 10 Aug 2005 13:26:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AHLCaQ053582; Wed, 10 Aug 2005 10:21:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AHLCQd053581; Wed, 10 Aug 2005 10:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AHLBMJ053574 for ; Wed, 10 Aug 2005 10:21:11 -0700 (PDT) (envelope-from mark.nottingham@bea.com) Received: from [172.16.1.2] (unknown [63.96.164.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 580B8A3508; Wed, 10 Aug 2005 13:21:09 -0400 (EDT) In-Reply-To: <42F97D97.3000007@gmail.com> References: <11F83246-2C4B-48EC-ADD7-3AED2296B476@bblfish.net> <69B3062C-71B8-4CA7-B38F-B0CB2913B08C@bea.com> <47988278-9794-43FF-9DF1-48B6D8F0949F@bblfish.net> <81B9C7E2EB36D6D49A93FFE8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <42F8E361.60603@gmail.com> <42F8FBB1.5060603@gmail.com> <42F97D97.3000007@gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Henry Story , Walter Underwood , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -02 Date: Wed, 10 Aug 2005 10:21:06 -0700 To: James M Snell X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit So, you're really looking for entry-level, time-based invalidation, no? I guess the simplest way to do this would be to dereference the link and see if you get a 404/410; if you do, you know it's no longer good. That's not terribly efficient, but OTOH managing metadata in multiple places is tricky, and predicting the future doubly so :) Most people get expiration times really wrong. And clock sync becomes an issue as well. I'd think that if you have reasonable control over the polling of the feed, and a solid enough state model (which might include an explicit deletion mechanism), you could have a similar effect by just removing the items from the feed when they expire, with the expectation that when they disappear from the feed, they disappear from the client. Would that work for your use case? On 09/08/2005, at 9:07 PM, James M Snell wrote: > > First off, let me stress that I am NOT talking about caching > scenarios here... (my use of the terms "application layer" and > "transport layer" were an unfortunate mistake on my part that only > served to confuse my point) > > Let's get away from the multiprotocol question for a bit (it never > leads anywhere constructive anyway)... Let's consider an aggregator > scenario. Take an entry from a feed that is supposed to expire > after 10 days. The feed document is served up to the aggregator > with the proper HTTP headers for expiration. The entry is > extracted from the original feed and dumped into an aggregated > feed. Suppose each of the entries in the aggregated feed are > supposed to have their own distinct expirations. How should the > aggregator communicate the appropriate expirations to the > subscriber? Specifying expirations on the HTTP level does not > allow me to specify expirations for individual entries within a > feed. Use case: an online retailer wishes to produce a "special > offers" feed. Each offer in the feed is a distinct entity with > it's own terms and own expiration: e.g. some offers are valid for > a week, other offers are valid for two weeks, etc. The expiration > of the offer (a business level construct) is independent of whether > or not the feed is being cached or not (a protocol level > construct); publishing a new version of the feed (e.g. by adding a > new offer to the feed) should have no impact on the expiration of > prior offers published to the feed. > > Again, I am NOT attempting to reinvent an abstract or transport- > neutral caching mechanism in the same sense that the atom:updated > element is not attempting to reinvent Last-Modified or that the via > link relation is not attempting to reinvent the Via header, etc. > They serve completely different purposes. The expires and max-age > extensions I am proposing should NOT be used for cache control of > the Atom documents in which they appear. > > >I think we can declare victory here by simply a) using whatever > caching mechanism is available, and b) designating a "won't > change" flag. > Speaking *strictly* about cache control of Atom documents, +1. No > document level mechanisms for cache control are necessary. > > - James > > > Mark Nottingham wrote: > > >> HTTP isn't a transport protocol, it's a transfer protocol; i.e., >> the caching information (and other entity metadata) are *part of* >> the entity, not something that's conceptually separate. >> >> The problem with having an "abstract" or "transport-neutral" >> concept of caching is that it leaves you with an awkward choice; >> you can either a) exactly replicate the HTTP caching model, which >> is difficult to do in other protocols, b) "dumb down" HTTP >> caching to a subset that's "neutral", or c) introduce a >> contradictory caching model and suffer the clashes between HTTP >> caching and it. >> >> This is the same road that Web services sometimes tries to go >> down, and it's a painful one; coming up with the grand, protocol- >> neutral abstraction that enables all of the protocol-specific >> features is hard, and IMO not necessary. Ask yourself: are there >> any situations where you *have* to be able to seamlessly switch >> between protocols, or is it just a "convenience?" >> >> I think we can declare victory here by simply a) using whatever >> caching mechanism is available, and b) designating a "won't >> change" flag. >> >> >> >> >> >> >> On 09/08/2005, at 11:53 AM, James M Snell wrote: >> >> >>> Henry Story wrote: >>> >>> >>>> Now I am wondering if the http mechanism is perhaps all that is >>>> needed >>>> for what I want with the unchanging archives. If it is then >>>> perhaps this >>>> could be explained in the Feed History RFC. Or are there other >>>> reasons to >>>> add and "expires" tag to the document itself? >>>> >>> >>> >>> On the application level, a feed or entry may expire or age >>> indepedently of whatever caching mechanisms may be applied at >>> the transport level. For example, imagine a source that >>> publishes special offers in the form of Atom entries that expire >>> at a given point in time. Now suppose that those entries are >>> being distributed via XMPP and HTTP. It is helpful to have a >>> transport independent expiration/max-age mechanism whose >>> semantics operate on the application layer rather than the >>> transport layer. >>> >>> - James >>> >>> >>> >>> >> >> >> -- >> Mark Nottingham Principal Technologist >> Office of the CTO BEA Systems >> >> >> > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Wed Aug 10 18:18:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2yuJ-0004sQ-Mo for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 18:18:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07771 for ; Wed, 10 Aug 2005 18:18:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AMCf23077757; Wed, 10 Aug 2005 15:12:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AMCfVh077756; Wed, 10 Aug 2005 15:12:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AMCe8O077746 for ; Wed, 10 Aug 2005 15:12:40 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so248709wra for ; Wed, 10 Aug 2005 15:12:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c14xVeiPcc8DMMXDs2nNkH3YdVupXMWxKWnK0iumJVuEzBDPGLoycYntfZ5bP7Uva02b9q28Fvo0gA9faQs8q6yjJnSKFlG1jdF65OhSLfhNMWHd/p9gmjkb0THFshHk3hElkRkk9RpWtwGG4JYyFi9vv9VI3XM0rv1nSLWlgvU= Received: by 10.54.46.72 with SMTP id t72mr779773wrt; Wed, 10 Aug 2005 15:12:30 -0700 (PDT) Received: by 10.54.104.20 with HTTP; Wed, 10 Aug 2005 15:12:30 -0700 (PDT) Message-ID: <540e373205081015121d6738a5@mail.gmail.com> Date: Wed, 10 Aug 2005 17:12:30 -0500 From: "Roger B." To: atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <1661002168.20050810093435@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> <1661002168.20050810093435@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7AMCe8O077750 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dave: I think I see what you're getting at... correct me if I'm wrong. So I decide that my aggregator is going to look for unknown Simple Extensions in Atom feeds and display them as a table of name/value pairs at the bottom of every entry. And during the display process, I'm going to run a regex over the values and linkify any URLs I find. When someone's relative references just sit there as plain text and I get a complaint, who's to blame? (1) Me, for trying to provide generic support for unknown extensions? (2) The publisher, for failing to consider non-specific or limited support of the extension? (3) The complaining user, for expecting too much? If it's (3), then I agree with Tim... the spec says what it says, and that's fine. Otherwise, there may be a legitimate problem here. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed Aug 10 18:39:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2zEK-0000pZ-7Q for atompub-archive@megatron.ietf.org; Wed, 10 Aug 2005 18:39:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08939 for ; Wed, 10 Aug 2005 18:39:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AMXqQW078983; Wed, 10 Aug 2005 15:33:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7AMXq7I078982; Wed, 10 Aug 2005 15:33:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7AMXpU2078965 for ; Wed, 10 Aug 2005 15:33:52 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so248704wra for ; Wed, 10 Aug 2005 15:33:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NAuJX1Ylwvl/EDAzXTk+yo3+fhgy2cJZ5KMyUzHtn5B7Twe55MHjj5BT+6aXwr5wkTCK7DiDoGDxy4K8WUJU65bqbIWl4pP9bUwLiyP1rj8W5e8/IcTxiSWmv5yQRq1O+yfgN/KhjsONp0O8Vtw+gYRuFVWnOM1CV9WGy9LBYr8= Received: by 10.54.13.33 with SMTP id 33mr258439wrm; Wed, 10 Aug 2005 15:33:46 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 10 Aug 2005 15:33:46 -0700 (PDT) Message-ID: <68fba5c505081015331962c1d1@mail.gmail.com> Date: Wed, 10 Aug 2005 18:33:46 -0400 From: Robert Sayre To: David Powell Subject: Re: More about Extensions Cc: atom-syntax@imc.org In-Reply-To: <1661002168.20050810093435@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> <1661002168.20050810093435@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7AMXqU2078977 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/10/05, David Powell wrote: > I think that it is pretty clear, but as Tim disagrees, I think that > this is a good indication that we need clarification. I think it's good indication that you've argued with everyone, no matter what they say. I'm strongly opposed to adding anything like you're suggesting. Tim and I agree that the current text is sufficient. There's a word for that. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 11 01:06:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35Go-0004XG-LV for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:06:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24441 for ; Thu, 11 Aug 2005 01:06:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B50OeS017048; Wed, 10 Aug 2005 22:00:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B50OrV017047; Wed, 10 Aug 2005 22:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7B50Nk3017006 for ; Wed, 10 Aug 2005 22:00:23 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 05:00:16 -0000 Received: from xdsl-213-196-249-6.netcologne.de (EHLO klangraum) [213.196.249.6] by mail.gmx.net (mp013) with SMTP; 11 Aug 2005 07:00:16 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 07:05:54 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) Message-ID: <20050811050554.GA19363@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42F83AE0.8010107@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42F83AE0.8010107@gmail.com> 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 ietf.org id BAA24441 * James M Snell [2005-08-09 07:25]: > The second feed illustrates the two forms of the in-reply-to > element. The dereferenceable form uses the href attribute to > locate the entity being responded to. I am still strongly -1 on making the ID optional. Why do you want to do that? What scenario exists wherein it would be *more* desirable to provide *only* a dereferencable location but *not* an ID? When would it be *wiser* to *rely* on a pointer to a resource which is always in danger of voiding, irrecoverably breaking the connection from a reply to its parent? The ID is REQUIRED in Atom entries. Given this, is there any *cost* to requiring its inclusion when specifying in-reply-to? I can=E2=80=99t see any. To me, making the option available seems like requiring content producers to make a choice about something their consumers will never benefit from but may sometimes be harmed by =E2=80=93 while burdening consumer implementors with an extra conditional to implement support for a useless option, and possibly requiring them to sometimes fetch representations over the network to even decide how to thread things. If you can give me just one example of a scenario where omitting the ID is beneficial, I=E2=80=99ll concede the point. Otherwise, I maintain that this is a mistake. Options have a cost. They should not be provided just for the sake of having them. And sorry that I keep bludgeoning you. :-) I hope you can see that my arguments are sound =E2=80=93 or show me that they=E2=80=99re not= . (After all, I was just as wrong during half the previous discussion=E2=80=A6) > The nondereferenceable form uses a combination of a required id > attribute and an optional src attribute. I=E2=80=99d really like this to include an atom:link[@rel=3D'related'] pointing to the source to encourage its provision. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 01:07:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35IF-0004k5-Pi for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:07:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24479 for ; Thu, 11 Aug 2005 01:07:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B51s2l017777; Wed, 10 Aug 2005 22:01:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B51swT017776; Wed, 10 Aug 2005 22:01:54 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7B51qdm017741 for ; Wed, 10 Aug 2005 22:01:53 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 05:01:46 -0000 Received: from xdsl-213-196-249-6.netcologne.de (EHLO klangraum) [213.196.249.6] by mail.gmx.net (mp025) with SMTP; 11 Aug 2005 07:01:46 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 07:07:24 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Comments Draft Message-ID: <20050811050724.GB19363@klangraum> Mail-Followup-To: Atom Syntax References: <20050805094817.GA8753@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id BAA24479 * Eric Scheid [2005-08-05 19:35]: > ... and it's too late to write a pace with atom:idref, and > wording saying an atom:link must have at least either an > atom:href attribute or an atom:idref attribute. That is, one or > both but not neither. I dunno if it=E2=80=99d be such a great idea anyway =E2=80=93 it just so = happens that it would work for the threading extension, but I=E2=80=99m not sure it would be very universally useful. But yeah, it *would* work for this case=E2=80=A6 Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 01:15:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35PM-0006JW-SL for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:15:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24771 for ; Thu, 11 Aug 2005 01:15:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B57nuZ020127; Wed, 10 Aug 2005 22:07:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B57nx3020126; Wed, 10 Aug 2005 22:07:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B57lHa020073 for ; Wed, 10 Aug 2005 22:07:48 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so184745nzf for ; Wed, 10 Aug 2005 22:07:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=n2LAAWoLLXSBceK6tJZZ5uVmdMQfVFxZFypvScvypXoZ1LByI3Pwx9lUO4JVZ5O2DN4lSXeu+OFgX4l8WQwrqSX4cDDuTtRaUl92deAPAG34lViUchYRGLSEL9Gx7U5NiCtb5uqh5IzzefiN+IpvUlXJSlQcSbRiznkUn9Bhi7c= Received: by 10.36.48.6 with SMTP id v6mr1397009nzv; Wed, 10 Aug 2005 22:07:41 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 6sm5063361nzn.2005.08.10.22.07.41; Wed, 10 Aug 2005 22:07:41 -0700 (PDT) Message-ID: <42FADD1A.4000100@gmail.com> Date: Wed, 10 Aug 2005 22:07:38 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: Atom Syntax Subject: Re: Comments Draft References: <20050805094817.GA8753@klangraum> <20050811050724.GB19363@klangraum> In-Reply-To: <20050811050724.GB19363@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id BAA24771 A. Pagaltzis wrote: >* Eric Scheid [2005-08-05 19:35]: > =20 > >>... and it's too late to write a pace with atom:idref, and >>wording saying an atom:link must have at least either an >>atom:href attribute or an atom:idref attribute. That is, one or >>both but not neither. >> =20 >> > >I dunno if it=E2=80=99d be such a great idea anyway =E2=80=93 it just so= happens >that it would work for the threading extension, but I=E2=80=99m not sure >it would be very universally useful. But yeah, it *would* work >for this case=E2=80=A6 > >Regards, > =20 > Yes it does work in the comments draft ;-) If you haven't done so=20 already, take a look at the version I submitted as an I-D [1]. It uses=20 @idref for the ID reference. - James [1]=20 http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-00.tx= t From owner-atom-syntax@mail.imc.org Thu Aug 11 01:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35UN-0007Hn-GV for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:20:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24968 for ; Thu, 11 Aug 2005 01:20:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5GgVu023707; Wed, 10 Aug 2005 22:16:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B5GgYD023706; Wed, 10 Aug 2005 22:16:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7B5GfoE023645 for ; Wed, 10 Aug 2005 22:16:41 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 05:16:35 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp033) with SMTP; 11 Aug 2005 07:16:35 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 07:22:12 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Comments Draft Message-ID: <20050811052212.GD19363@klangraum> Mail-Followup-To: Atom Syntax References: <20050805094817.GA8753@klangraum> <20050811050724.GB19363@klangraum> <42FADD1A.4000100@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42FADD1A.4000100@gmail.com> 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 ietf.org id BAA24968 * James M Snell [2005-08-11 07:20]: > Yes it does work in the comments draft ;-) If you haven't done > so already, take a look at the version I submitted as an I-D > [1]. It uses @idref for the ID reference. Yeah, but that=E2=80=99s @thr:idref, not @atom:idref. ;-) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 01:20:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35UP-0007I0-PA for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:20:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24973 for ; Thu, 11 Aug 2005 01:20:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5FjQq023248; Wed, 10 Aug 2005 22:15:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B5FjjK023247; Wed, 10 Aug 2005 22:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5FfjH023183 for ; Wed, 10 Aug 2005 22:15:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 11 Aug 2005 15:16:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 11 Aug 2005 15:15:11 +1000 Subject: Re: Updated Comments Draft (getting closer) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050811050554.GA19363@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7B5FjjH023240 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 ietf.org id BAA24973 On 11/8/05 3:05 PM, "A. Pagaltzis" wrote: > What scenario exists wherein it would be *more* desirable to > provide *only* a dereferencable location but *not* an ID? When > would it be *wiser* to *rely* on a pointer to a resource which is > always in danger of voiding, irrecoverably breaking the > connection from a reply to its parent? scenario: I'm reading some feed I've subscribed to, and hit an entry whic= h is a reply to someone else's posting elsewhere. I'm not subscribed to tha= t other feed. I want to read it. There doesn't exist any atom:id resolvers (yet). The author neglected to include a direct link. How do I get there? > The ID is REQUIRED in Atom entries. Given this, is there any > *cost* to requiring its inclusion when specifying in-reply-to? I > can=B9t see any. Are authors only going to reply to Atom feed publishers? Are they going t= o avoid replying to RSS feeds, or to statements on some generic HTML page (= or even PDF document)? Requiring an ID when an ID may not be available will mean not being able to create in-reply-to links to non-Atom resources. e. From owner-atom-syntax@mail.imc.org Thu Aug 11 01:32:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E35gG-00011z-F5 for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:32:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25242 for ; Thu, 11 Aug 2005 01:32:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5RBkD027845; Wed, 10 Aug 2005 22:27:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B5RBpq027844; Wed, 10 Aug 2005 22:27:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5RAWA027831 for ; Wed, 10 Aug 2005 22:27:10 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 11 Aug 2005 15:28:18 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 11 Aug 2005 15:27:08 +1000 Subject: Re: Comments Draft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050811052011.GC19363@klangraum> 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: Content-Transfer-Encoding: 7bit On 11/8/05 3:20 PM, "A. Pagaltzis" wrote: > As long as producers throw in atom:link[@rel='related'] pointers > to the source as well, that base is covered anyway. I'd prefer to see atom:link[@rel="in-reply-to"]. Of course it's "related". All links in an entry point to related resources, that's the very definition of a link. We also know what the nature of the relationship is (it's in reply to that resource), so it doesn't hurt to specify that. James -- any chance of defining that in the comments draft, alongside the 'replies' link relation. You could then simplify the thr:in-reply-to element to just needing to handle the thr:idref case. e. From owner-atom-syntax@mail.imc.org Thu Aug 11 01:56:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E362t-00055v-VH for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 01:56:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26051 for ; Thu, 11 Aug 2005 01:56:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5nehF038907; Wed, 10 Aug 2005 22:49:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B5neRn038906; Wed, 10 Aug 2005 22:49:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B5ndY0038863 for ; Wed, 10 Aug 2005 22:49:40 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so180601nzi for ; Wed, 10 Aug 2005 22:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=noT6qYjJs7LFPfpEdsKQpTXtCC8xpEQrMIEu1rW3H5cmQl/3XW9mDPGcpip++3dGHK1zLiq/AP6NM9EJY/nE5gPV9PUfQpRmR+gJyBDJwE1I9AlccfTbDXLOCaHNU9lRb0+3Go9mPwwmZZ9wBTOYNuzkpWtW7TCHyFAthGBvoM8= Received: by 10.36.5.3 with SMTP id 3mr1226240nze; Wed, 10 Aug 2005 22:49:33 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 36sm2945635nza.2005.08.10.22.49.33; Wed, 10 Aug 2005 22:49:33 -0700 (PDT) Message-ID: <42FAE6EA.1020106@gmail.com> Date: Wed, 10 Aug 2005 22:49:30 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> In-Reply-To: <20050811050554.GA19363@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id BAA26051 The simple answer is that not everything I may want to reply too will=20 have an ID I can reference. Suppose that what I'm responding to is an=20 item in an RSS feed that does not contain a guid element? All I have to=20 go off of is the URL of the RSS feed or the RSS item's link element...=20 neither of which are actual ID's.=20 A. Pagaltzis wrote: >* James M Snell [2005-08-09 07:25]: > =20 > >>The second feed illustrates the two forms of the in-reply-to >>element. The dereferenceable form uses the href attribute to >>locate the entity being responded to. >> =20 >> > >I am still strongly -1 on making the ID optional. Why do you want >to do that? > >What scenario exists wherein it would be *more* desirable to >provide *only* a dereferencable location but *not* an ID? When >would it be *wiser* to *rely* on a pointer to a resource which is >always in danger of voiding, irrecoverably breaking the >connection from a reply to its parent? > >The ID is REQUIRED in Atom entries. Given this, is there any >*cost* to requiring its inclusion when specifying in-reply-to? I >can=E2=80=99t see any. > >To me, making the option available seems like requiring content >producers to make a choice about something their consumers will >never benefit from but may sometimes be harmed by =E2=80=93 while >burdening consumer implementors with an extra conditional to >implement support for a useless option, and possibly requiring >them to sometimes fetch representations over the network to even >decide how to thread things. > >If you can give me just one example of a scenario where omitting >the ID is beneficial, I=E2=80=99ll concede the point. Otherwise, I >maintain that this is a mistake. Options have a cost. They should >not be provided just for the sake of having them. > >And sorry that I keep bludgeoning you. :-) I hope you can see >that my arguments are sound =E2=80=93 or show me that they=E2=80=99re no= t. (After >all, I was just as wrong during half the previous discussion=E2=80=A6) > > =20 > >>The nondereferenceable form uses a combination of a required id >>attribute and an optional src attribute. >> =20 >> > >I=E2=80=99d really like this to include an atom:link[@rel=3D'related'] >pointing to the source to encourage its provision. > >Regards, > =20 > From owner-atom-syntax@mail.imc.org Thu Aug 11 02:09:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E36G0-00088z-4Q for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 02:09:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05690 for ; Thu, 11 Aug 2005 02:09:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B62slN051048; Wed, 10 Aug 2005 23:02:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B62s4x051047; Wed, 10 Aug 2005 23:02:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B62reR051024 for ; Wed, 10 Aug 2005 23:02:53 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so229581rnf for ; Wed, 10 Aug 2005 23:02:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=T9EZLBLWUBuwEPTv57nEw520uG8A6VekuNpzLevHaJvxU4bdYrVFNq7FZkiZNXw8BTjTCwQpkaI+ZPf3GDxlNxxwCKyISqlc2mjiXpCMWLy6EQgUUZpxqYDb9h4Q7iw9HHCPU//WpCZ4RqrB9c3+ESZUcBUzi8SzuX+yshguhAY= Received: by 10.38.101.2 with SMTP id y2mr526412rnb; Wed, 10 Aug 2005 23:02:52 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id z1sm4846005rne.2005.08.10.23.02.52; Wed, 10 Aug 2005 23:02:52 -0700 (PDT) Message-ID: <42FAEA09.6000608@gmail.com> Date: Wed, 10 Aug 2005 23:02:49 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Comments Draft References: In-Reply-To: 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: Content-Transfer-Encoding: 7bit I *really* don't want to get into a protracted debate that gets us going back and forth between atom:link[@rel="in-reply-to"] and thr:in-reply-to when either approach would work just as well as the other. The thr:in-reply-to tends to make the most sense to me at this point because of the need to a) do ID refs and b) identify the source of a link as a part of the link itself ... both of which *could* be done with atom:link but only with a bit of massaging and a namespace extension (to introduce idref). Since either solution requires namespace extensions to be added, thr:in-reply-to is likely the better option (IMHO). What I will say is that it is rather unfortunate that Link wasn't conceptualized the way the Author, Date and Text constructs were. If there had been a Link construct in the spec that defined a common base for Link oriented elements, it would have made it very simple for me to do something akin to the following: atomLink { atomCommonAttributes, attribute href {URI}?, attribute idref {URI}?, attribute title {text}?, attribute hreflang {text}?, } inReplyTo = element thr:in-reply-to { atomLink } Ah well... - James Eric Scheid wrote: >On 11/8/05 3:20 PM, "A. Pagaltzis" wrote: > > > >>As long as producers throw in atom:link[@rel='related'] pointers >>to the source as well, that base is covered anyway. >> >> > >I'd prefer to see atom:link[@rel="in-reply-to"]. > >Of course it's "related". All links in an entry point to related resources, >that's the very definition of a link. We also know what the nature of the >relationship is (it's in reply to that resource), so it doesn't hurt to >specify that. > >James -- any chance of defining that in the comments draft, alongside the >'replies' link relation. You could then simplify the thr:in-reply-to element >to just needing to handle the thr:idref case. > >e. > > > > From owner-atom-syntax@mail.imc.org Thu Aug 11 02:59:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E372b-0000VX-2N for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 02:59:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12296 for ; Thu, 11 Aug 2005 02:59:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B6sw6G000931; Wed, 10 Aug 2005 23:54:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B6swTD000930; Wed, 10 Aug 2005 23:54:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7B6su8V000837 for ; Wed, 10 Aug 2005 23:54:57 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 06:54:50 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp003) with SMTP; 11 Aug 2005 08:54:50 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 09:00:27 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) Message-ID: <20050811070027.GF19363@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> <42FAE6EA.1020106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <42FAE6EA.1020106@gmail.com> 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 ietf.org id CAA12296 * James M Snell [2005-08-11 08:00]: > Suppose that what I'm responding to is an item in an RSS feed > that does not contain a guid element? All I have to go off of > is the URL of the RSS feed or the RSS item's link element... > neither of which are actual ID's.=20 Ugh. Sigh. Yeah, okay. I can see that. Can we still include language that if it=E2=80=99s an Atom entry being replied to, the atom:id of the original entry is REQUIRED? Also, that if it=E2=80=99s an RSS feed, then using the GUID value if provided is strongly encouraged? (I=E2=80=99d like to make that RECOMMENDED, but that=E2=80=99s too strong a requirement for reliance on an OPTIONAL feature=E2=80=A6 sigh.) Sigh=E2=80=A6 bleh. I hope one day we can forget about RSS=E2=80=A6 :-( Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 03:11:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37Ds-0003CF-NK for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 03:11:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12819 for ; Thu, 11 Aug 2005 03:11:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B76mOl010026; Thu, 11 Aug 2005 00:06:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B76mku010025; Thu, 11 Aug 2005 00:06:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7B76kLE009939 for ; Thu, 11 Aug 2005 00:06:47 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 07:06:40 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp033) with SMTP; 11 Aug 2005 09:06:40 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 09:12:18 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Updated Comments Draft (getting closer) Message-ID: <20050811071218.GG19363@klangraum> Mail-Followup-To: Atom Syntax References: <20050811050554.GA19363@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id DAA12819 * Eric Scheid [2005-08-11 07:25]: >=20 > On 11/8/05 3:05 PM, "A. Pagaltzis" wrote: >=20 > > What scenario exists wherein it would be *more* desirable to > > provide *only* a dereferencable location but *not* an ID? > > When would it be *wiser* to *rely* on a pointer to a resource > > which is always in danger of voiding, irrecoverably breaking > > the connection from a reply to its parent? >=20 > scenario: I'm reading some feed I've subscribed to, and hit an > entry which is a reply to someone else's posting elsewhere. I'm > not subscribed to that other feed. I want to read it. There > doesn't exist any atom:id resolvers (yet). The author neglected > to include a direct link. How do I get there? How is that an argument for omitting the ID? It=E2=80=99s an argument in favour of including a source link, but both forms provide for a way to store this information. > Are authors only going to reply to Atom feed publishers? Are > they going to avoid replying to RSS feeds, or to statements on > some generic HTML page (or even PDF document)? Requiring an ID > when an ID may not be available will mean not being able to > create in-reply-to links to non-Atom resources. Yeah; point conceded, as I already wrote to James. And as I said there, I=E2=80=99d still like the ID to be REQUIRED when replying to Atom entries. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 03:23:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37Pw-0005Xo-Ab for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 03:23:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13387 for ; Thu, 11 Aug 2005 03:23:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B7HpKq018678; Thu, 11 Aug 2005 00:17:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B7Hpo2018676; Thu, 11 Aug 2005 00:17:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7B7Hokq018584 for ; Thu, 11 Aug 2005 00:17:50 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 07:17:44 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp027) with SMTP; 11 Aug 2005 09:17:44 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 09:23:22 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Comments Draft Message-ID: <20050811072322.GH19363@klangraum> Mail-Followup-To: Atom Syntax References: <20050811052011.GC19363@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id DAA13387 * Eric Scheid [2005-08-11 07:40]: > Of course it's "related". All links in an entry point to > related resources, that's the very definition of a link. We > also know what the nature of the relationship is (it's in reply > to that resource), so it doesn't hurt to specify that. I=E2=80=99m neutral on this one =E2=80=93 can=E2=80=99t hurt, though I do= n=E2=80=99t think it=E2=80=99s really required either. The point of using "related" is simply to expose the URL in a commonly understood location for consumers which do not know to look for it in an extension element=E2=80=99s attribute. > James -- any chance of defining that in the comments draft, > alongside the 'replies' link relation. You could then simplify > the thr:in-reply-to element to just needing to handle the > thr:idref case. +0.5. If @rel=3D'in-reply-to' is specified, there=E2=80=99s little point = to also having thr:in-reply-to/@href. I have no strong opinion on this one either, though. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 03:24:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E37Q6-0005Z9-Gi for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 03:24:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13390 for ; Thu, 11 Aug 2005 03:24:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B7ISh2019184; Thu, 11 Aug 2005 00:18:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B7ISZw019183; Thu, 11 Aug 2005 00:18:28 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7B7IQZr019090 for ; Thu, 11 Aug 2005 00:18:27 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 07:18:21 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp020) with SMTP; 11 Aug 2005 09:18:21 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 09:23:58 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Comments Draft Message-ID: <20050811072358.GI19363@klangraum> Mail-Followup-To: Atom Syntax References: <20050805223215.GA24553@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id DAA13390 * Eric Scheid [2005-08-06 05:40]: > either that or a flag that says "this is dereferenceable", but > that is ugly and doesn't let the publisher have a link with > both. >=20 > would it be useful? google does interesting things by crawling > links, so do many other link crawling tools. As long as producers throw in atom:link[@rel=3D'related'] pointers to the source as well, that base is covered anyway. Putting the non-dereferencable bit in an @idref wouldn=E2=80=99t be all that interesting anyway, I think, unless the crawler knows how to interpret it. But if it has specific knowledge about @idref values in particular relationships, it may as well have specific knowledge about particular extension elements. So that base is covered as well in either case. So in conclusion, there=E2=80=99s no advantage to using atom:link as the principal vehicle for IDs here either. Seems like a trend=E2=80=A6 it=E2=80= =99s getting very clear to me that an extension element really is The Right Choice for this thing. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 11 04:12:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38BP-0005oz-A1 for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 04:12:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15217 for ; Thu, 11 Aug 2005 04:12:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B855iD045402; Thu, 11 Aug 2005 01:05:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B855O4045401; Thu, 11 Aug 2005 01:05:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta07-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B854Ta045342 for ; Thu, 11 Aug 2005 01:05:04 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta11-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20050811080458.IATC21883.mta07-winn.ispmail.ntl.com@aamta11-winn.ispmail.ntl.com>; Thu, 11 Aug 2005 09:04:58 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta11-winn.ispmail.ntl.com with ESMTP id <20050811080458.JZE820.aamta11-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com>; Thu, 11 Aug 2005 09:04:58 +0100 Date: Thu, 11 Aug 2005 09:04:54 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <198965794.20050811090454@djpowell.net> To: "Roger B." CC: atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <540e373205081015121d6738a5@mail.gmail.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> <1661002168.20050810093435@djpowell.net> <540e373205081015121d6738a5@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit Wednesday, August 10, 2005, 11:12:30 PM, you wrote: > Dave: I think I see what you're getting at... correct me if I'm wrong. > So I decide that my aggregator is going to look for unknown Simple > Extensions in Atom feeds and display them as a table of name/value > pairs at the bottom of every entry. And during the display process, > I'm going to run a regex over the values and linkify any URLs I find. > When someone's relative references just sit there as plain text and I > get a complaint, who's to blame? Another example is: An AtomPP client publishes entries to an AtomPP server. The server stores the entries in a CMS. The CMS publishes the entries as an Atom feed. The CMS shouldn't have to preserve the value and base URI for each extension attribute. Simple Extensions were designed with this sort of scenario in mind. > (1) Me, for trying to provide generic support for unknown extensions? > (2) The publisher, for failing to consider non-specific or limited > support of the extension? > (3) The complaining user, for expecting too much? > If it's (3), then I agree with Tim... the spec says what it says, and > that's fine. Otherwise, there may be a legitimate problem here. Well I think that it can't be (1). We wouldn't have wrote section 6.4.1 and 6.4.2, if we didn't want to support this. It shouldn't be (3) either. If the publisher puts something into an Atom document, it shouldn't be ambiguous whether it is a URIRef or not, even for extensions. This is what I mean by extensions being part of the Atom model. We wouldn't have banned Simple Extensions from containing language sensitive text, if we were requiring implementations to preserve each of their base URIs. This paragraph explains that, but obviously not well enough: > The element can be interpreted as a simple property (or name/value > pair) of the parent element that encloses it. The pair consisting of > the namespace-URI of the element and the local name of the element > can be interpreted as the name of the property. The character data > content of the element can be interpreted as the value of the > property. If the element is empty, then the property value can be > interpreted as an empty string. I'm requesting that some clarification be added specific to relative refs. -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 11 04:12:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E38Ae-0005j0-Ef for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 04:12:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15194 for ; Thu, 11 Aug 2005 04:12:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B80CTM043763; Thu, 11 Aug 2005 01:00:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B80Cje043762; Thu, 11 Aug 2005 01:00:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B80At2043714 for ; Thu, 11 Aug 2005 01:00:11 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20050811080004.LOEA23002.mta08-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>; Thu, 11 Aug 2005 09:00:04 +0100 Received: from cpc3-stok1-5-0-cust147.bagu.cable.ntl.com ([82.11.128.147]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20050811080004.LYH17166.aamta12-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust147.bagu.cable.ntl.com>; Thu, 11 Aug 2005 09:00:04 +0100 Date: Thu, 11 Aug 2005 09:00:00 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <457686082.20050811090000@djpowell.net> To: sayrer@gmail.com CC: atom-syntax@imc.org Subject: Re: More about Extensions In-Reply-To: <68fba5c505081015331962c1d1@mail.gmail.com> References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> <1661002168.20050810093435@djpowell.net> <68fba5c505081015331962c1d1@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit Wednesday, August 10, 2005, 11:33:46 PM, Robert Sayre wrote: > On 8/10/05, David Powell wrote: >> I think that it is pretty clear, but as Tim disagrees, I think that >> this is a good indication that we need clarification. > I think it's good indication that you've argued with everyone, no > matter what they say. I'm strongly opposed to adding anything like > you're suggesting. Tim and I agree that the current text is > sufficient. There's a word for that. I might have misinterpreted your comment, but I'm arguing with Tim for saying that SEE's CAN contain relative refs and no clarifification is needed, and with you for saying that SEE's CANNOT contain relative refs and no clarification is needed. There's a word for that :) -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 11 05:13:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E397o-0002Px-TN for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 05:13:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18085 for ; Thu, 11 Aug 2005 05:13:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B95lG8066860; Thu, 11 Aug 2005 02:05:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7B95l7H066859; Thu, 11 Aug 2005 02:05:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7B95kJU066844 for ; Thu, 11 Aug 2005 02:05:46 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 2462 invoked from network); 11 Aug 2005 09:05:34 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 11 Aug 2005 09:05:34 -0000 Received: from host217-36-49-205.in-addr.btopenworld.com (host217-36-49-205.in-addr.btopenworld.com [217.36.49.205]) by webmail.djpowell.net (IMP) with HTTP for ; Thu, 11 Aug 2005 10:05:34 +0100 Message-ID: <1123751134.42fb14ded152d@webmail.djpowell.net> Date: Thu, 11 Aug 2005 10:05:34 +0100 From: David Powell To: David Powell Cc: sayrer@gmail.com, atom-syntax@imc.org Subject: Re: More about Extensions References: <6110504678.20050809215057@djpowell.net> <68fba5c505080915223633505@mail.gmail.com> <1651873542.20050810011138@djpowell.net> <68fba5c5050809173076087214@mail.gmail.com> <1661002168.20050810093435@djpowell.net> <68fba5c505081015331962c1d1@mail.gmail.com> <457686082.20050811090000@djpowell.net> In-Reply-To: <457686082.20050811090000@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.36.49.205 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I said: > I might have misinterpreted your comment, but I'm arguing with Tim for > saying that SEE's CAN contain relative refs and no clarifification is > needed, and with you for saying that SEE's CANNOT contain relative > refs and no clarification is needed. There's a word for that :) I oversimplified that. What I really meant is not that rel refs are banned, but that publishers should not expect rel refs to be processed differently than strings. The value of a Simple Extension is a string. It is the job of an unextended Atom implementation to transfer those strings. Extensions can encode what they like in those strings, and if the extension is supported by the receiver, then it can be decoded. A publisher can put numbers, dates, URIs, or escaped XML in one of these string; they can even put relative refs in there, but they must only expect the string to be preserved, not the context of the surrounding XML. SEE's exist so that simple properties can be transfered without requiring that the CMS store an Infoset equivalent. -- Dave From owner-atom-syntax@mail.imc.org Thu Aug 11 11:01:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EZ2-0006Ad-1n for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:01:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07682 for ; Thu, 11 Aug 2005 11:01:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BEoCe2079425; Thu, 11 Aug 2005 07:50:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BEoCI6079424; Thu, 11 Aug 2005 07:50:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BEoBRI079418 for ; Thu, 11 Aug 2005 07:50:11 -0700 (PDT) (envelope-from gerph@gerph.org) Received: from dynamic-62-56-59-183.park-s46b.dslaccess.co.uk ([62.56.59.183] helo=buttercup.gerph.org) by anchor-post-35.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1E3EJ5-000ALS-GJ; Thu, 11 Aug 2005 14:45:20 +0000 Received: by buttercup.gerph.org (Postfix, from userid 1001) id CA941F52D2; Thu, 11 Aug 2005 15:49:46 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 82936EC39D; Thu, 11 Aug 2005 15:49:46 +0100 (BST) Date: Thu, 11 Aug 2005 15:49:46 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: "A. Pagaltzis" Cc: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) In-Reply-To: <20050811050554.GA19363@klangraum> Message-ID: References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 11 Aug 2005, A. Pagaltzis wrote: > > * James M Snell [2005-08-09 07:25]: > > The second feed illustrates the two forms of the in-reply-to > > element. The dereferenceable form uses the href attribute to > > locate the entity being responded to. > > I am still strongly -1 on making the ID optional. Why do you want > to do that? > > What scenario exists wherein it would be *more* desirable to > provide *only* a dereferencable location but *not* an ID? When > would it be *wiser* to *rely* on a pointer to a resource which is > always in danger of voiding, irrecoverably breaking the > connection from a reply to its parent? Any scenario where the document being referenced is not Atom. If the comments specification were to restrict itself to just discussion about the Atom community then that's both very insular and hardly likely to encourage anyone to contribute to it. Consider you have a news website that gives you a page with text in it. You want to reply to it. They don't have an Atom feed. Do you give up on ever commenting on their text because you can never reference it ? Do you comment on it but omit any linking details ? Do you complain to the website author to add an Atom feed because otherwise you can't refer to it on your weblog ? There are many document forms which have identifiers to locate them uniquely in the world (Atom id, RSS guid, RFC2822 mid, MIME cid, book isbn, etc), but there are also many document forms which have no unique identifier (HTML documents, PDF documents, physical memos, conversations in the pub (!), newspaper articles, etc). To preclude refering to non-id'd documents would be restricting the specification to only allowing Atom people to talk about Atom people. By all means require any reference to a Atom document to supply an identifier, but requiring it on all references would make it impossible to fulfill on some documents. -- Gerph ... Want to cry for you. Would it do any good ? From owner-atom-syntax@mail.imc.org Thu Aug 11 11:27:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3EyB-0004J3-Bc for atompub-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:27:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09355 for ; Thu, 11 Aug 2005 11:27:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7BFMO93083437; Thu, 11 Aug 2005 08:22:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7BFMOdL083436; Thu, 11 Aug 2005 08:22:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7BFMMGT083415 for ; Thu, 11 Aug 2005 08:22:23 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 Aug 2005 15:22:16 -0000 Received: from xdsl-213-196-255-54.netcologne.de (EHLO klangraum) [213.196.255.54] by mail.gmx.net (mp031) with SMTP; 11 Aug 2005 17:22:16 +0200 X-Authenticated: #163624 Date: Thu, 11 Aug 2005 17:27:53 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) Message-ID: <20050811152753.GA20908@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id LAA09355 * Justin Fletcher [2005-08-11 17:10]: > By all means require any reference to a Atom document to supply > an identifier, but requiring it on all references would make it > impossible to fulfill on some documents. Yeah; again, I=E2=80=99ve conceded the point. I still don=E2=80=99t parti= cularly like this reality we=E2=80=99re dealing with, but unfortunately, there=E2= =80=99s only one of those=E2=80=A6 Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 12 00:12:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Qu3-0001eM-OP for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 00:12:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17044 for ; Fri, 12 Aug 2005 00:12:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C444nL084807; Thu, 11 Aug 2005 21:04:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C4441X084806; Thu, 11 Aug 2005 21:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C443Vl084800 for ; Thu, 11 Aug 2005 21:04:03 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 11 Aug 2005 21:04:21 -0700 To: Atom WG From: Paul Hoffman Subject: Finishing up on whitespace in IRIs and dates Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. I think we have rough consensus on "emitting with whitespace around IRIs and dates is an error" and "we should warn folks that people might emit errors here because this is somewhat subtle". If that is true, I propose that, just before section 3.1 (at the end of the introductory text to "Common Atom Constructs") we add: Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Aug 12 00:28:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3R9T-0004AB-OV for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 00:28:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17682 for ; Fri, 12 Aug 2005 00:28:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C4Nq1n086076; Thu, 11 Aug 2005 21:23:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C4NqG2086075; Thu, 11 Aug 2005 21:23:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7C4NpEo086064 for ; Thu, 11 Aug 2005 21:23:51 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 12 Aug 2005 04:23:45 -0000 Received: from xdsl-213-196-240-119.netcologne.de (EHLO klangraum) [213.196.240.119] by mail.gmx.net (mp004) with SMTP; 12 Aug 2005 06:23:45 +0200 X-Authenticated: #163624 Date: Fri, 12 Aug 2005 06:29:23 +0200 From: "A. Pagaltzis" To: Atom WG Subject: Re: Finishing up on whitespace in IRIs and dates Message-ID: <20050812042923.GA25312@klangraum> Mail-Followup-To: Atom WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id AAA17682 * Paul Hoffman [2005-08-12 06:15]: > Note that there MUST be no whitespace in a Date construct or in > any IRI. Some XML-emitting implementations erroneously insert > whitespace around values by default, and such implementations > will emit invalid Atom. +1 Minor niggle: I=E2=80=99d prefer =E2=80=9Cthere MUST NOT be any whitespac= e=E2=80=9D over the proposed wording. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 12 00:43:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ROc-0007MT-QY for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 00:43:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18126 for ; Fri, 12 Aug 2005 00:43:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C4cIbS087977; Thu, 11 Aug 2005 21:38:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C4cIKI087976; Thu, 11 Aug 2005 21:38:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C4cItm087966 for ; Thu, 11 Aug 2005 21:38:18 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 1D9135C; Thu, 11 Aug 2005 21:38:13 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7C4c4kv013241; Thu, 11 Aug 2005 21:38:10 -0700 (PDT) Date: Thu, 11 Aug 2005 21:37:43 -0700 From: Walter Underwood To: Atom WG Subject: Re: Finishing up on whitespace in IRIs and dates Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 11, 2005 9:04:21 PM -0700 Paul Hoffman wrote: > Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. Nice clear wording. +1 with "MUST be no" changed to "MUST NOT be", as suggested by Aristotle. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 12 01:13:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Rrg-0004rO-AF for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 01:13:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19215 for ; Fri, 12 Aug 2005 01:13:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C58dbN092521; Thu, 11 Aug 2005 22:08:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C58dB2092519; Thu, 11 Aug 2005 22:08:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C58cgC092507 for ; Thu, 11 Aug 2005 22:08:38 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c51so431579rne for ; Thu, 11 Aug 2005 22:08:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hbSatpDHZ+3WOlGRkV0e/iDcfHk12kXd2wbAIOQeXbIMT1tgsIuMD0cQMWEacV68igp7RNjldGXRPCtLF6V9RBOE26gvogbN/SzRq3NT4qL63l7fvk6Fv+LYC57fAFuDoIUM1gYoh9CRiUm3mKapQe6sgngXmuEzxM9jwnC0u4w= Received: by 10.38.75.6 with SMTP id x6mr918530rna; Thu, 11 Aug 2005 22:08:38 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id z1sm6168588rne.2005.08.11.22.08.37; Thu, 11 Aug 2005 22:08:38 -0700 (PDT) Message-ID: <42FC2ED2.4030403@gmail.com> Date: Thu, 11 Aug 2005 22:08:34 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom WG Subject: Re: Finishing up on whitespace in IRIs and dates References: In-Reply-To: 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: Content-Transfer-Encoding: 7bit +1 on this with the "MUST NOT be" suggestion Walter Underwood wrote: >--On August 11, 2005 9:04:21 PM -0700 Paul Hoffman wrote: > > > >>Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. >> >> > >Nice clear wording. > >+1 with "MUST be no" changed to "MUST NOT be", as suggested by Aristotle. > >wunder >-- >Walter Underwood >Principal Software Architect, Verity > > > > From owner-atom-syntax@mail.imc.org Fri Aug 12 01:36:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3SDb-00010t-0o for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 01:36:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20048 for ; Fri, 12 Aug 2005 01:36:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C5VXKN003281; Thu, 11 Aug 2005 22:31:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C5VXqK003280; Thu, 11 Aug 2005 22:31:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C5VUi9003197 for ; Thu, 11 Aug 2005 22:31:32 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 12 Aug 2005 15:32:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 12 Aug 2005 14:40:01 +1000 Subject: Re: Finishing up on whitespace in IRIs and dates From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050812042923.GA25312@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7C5VWi9003273 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 ietf.org id BAA20048 On 12/8/05 2:29 PM, "A. Pagaltzis" wrote: >> Note that there MUST be no whitespace in a Date construct or in >> any IRI. Some XML-emitting implementations erroneously insert >> whitespace around values by default, and such implementations >> will emit invalid Atom. >=20 > +1 >=20 > Minor niggle: I=B9d prefer =B3there MUST NOT be any whitespace=B2 over > the proposed wording. +1. Also,=20 =20 s/emit invalid Atom./emit invalid Atom documents./ e. From owner-atom-syntax@mail.imc.org Fri Aug 12 04:25:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3UrL-0001Co-AK for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 04:25:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10437 for ; Fri, 12 Aug 2005 04:25:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C8Gs8N073176; Fri, 12 Aug 2005 01:16:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C8GsAh073175; Fri, 12 Aug 2005 01:16:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C8GrqQ073126 for ; Fri, 12 Aug 2005 01:16:53 -0700 (PDT) (envelope-from carey.evans@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so336477nzb for ; Fri, 12 Aug 2005 01:16:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mpNRYIftDBLUmAc77cFpRZKZ7cNWeaDsZAzNgwA0/2BjnflF2Y3vWxXKi0Ns/UtTpy5lucqcc4D4h93uUO4TI9O6TQCDXek6PU9+SgpYkdaXvN763gHG1CVdJm5G9/ea1kH9wjSXIUmUo8vRLB7GY9LxHTlfqDzsKYMT2y5BfhM= Received: by 10.36.224.45 with SMTP id w45mr2512369nzg; Fri, 12 Aug 2005 01:16:48 -0700 (PDT) Received: by 10.36.132.5 with HTTP; Fri, 12 Aug 2005 01:16:48 -0700 (PDT) Message-ID: <492010e005081201166dc33727@mail.gmail.com> Date: Fri, 12 Aug 2005 20:16:48 +1200 From: Carey Evans To: Atom WG Subject: Spec explanations for Pebble? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7C8GsqQ073169 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Simon Brown has upgraded the Atom feed generated by his Pebble weblog software (http://pebble.sf.net/) to draft-10. I've reported a few problems with it, based on my understanding of the spec, but there are a couple of points that don't seem to be directly addressed. See: http://www.simongbrown.com/jira/secure/ViewIssue.jspa?key=PEB-266 First, where does the spec actually say that the atom:id shouldn't change if the blog moves to a different domain? I think that if the URL of the blog changes, it means that the Atom Feed Document has been relocated so the ID should stay the same, but Simon doesn't see this in the spec. Second, what sort of values should be used for the scheme attribute on the category? Looking at http://www.tbray.org/ongoing/ongoing.atom as an authoritative example, it seems that the scheme should be the same for all categories, but Pebble uses the URL of the individual category page. The spec doesn't say, so does it matter? Can the list offer some advice? Thanks. (Reposted because the original didn't get through; my apologies for any duplicates. Look out for the Gmail Reply-To.) -- http://carey.geek.nz/ From owner-atom-syntax@mail.imc.org Fri Aug 12 05:01:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3VQB-0000fh-Ty for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 05:01:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11741 for ; Fri, 12 Aug 2005 05:01:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C8tQ5t081285; Fri, 12 Aug 2005 01:55:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7C8tQGt081284; Fri, 12 Aug 2005 01:55:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7C8tQQC081278 for ; Fri, 12 Aug 2005 01:55:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout12/MantshX 4.0) with ESMTP id j7C8tPK3020117; Fri, 12 Aug 2005 01:55:25 -0700 (PDT) Received: from [192.168.2.9] (fujita.plus.com [84.92.128.107]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j7C8tM5r009694 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 12 Aug 2005 01:55:24 -0700 (PDT) In-Reply-To: <492010e005081201166dc33727@mail.gmail.com> References: <492010e005081201166dc33727@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Parks Subject: Re: Spec explanations for Pebble? Date: Fri, 12 Aug 2005 09:55:19 +0100 To: Carey Evans X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 Aug 2005, at 9:16 am, Carey Evans wrote: > First, where does the spec actually say that the atom:id shouldn't > change if the blog moves to a different domain? I think that if the > URL of the blog changes, it means that the Atom Feed Document has been > relocated so the ID should stay the same, but Simon doesn't see this > in the spec. Section 4.2.6, paragraph 3: "an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource." If an Atom document is a feed of the same blog, then even if the blog has moved, the id should stay the same. What makes you think otherwise? > Second, what sort of values should be used for the scheme attribute on > the category? Looking at http://www.tbray.org/ongoing/ongoing.atom as > an authoritative example, it seems that the scheme should be the same > for all categories, but Pebble uses the URL of the individual category > page. The spec doesn't say, so does it matter? Section 4.2.2.2: "The "scheme" attribute is an IRI that identifies a categorization scheme." "categorization scheme" means the system used to categorize entries. Presumably each blog has its own system for doing so, so the scheme attribute should be the same for all posts from the same blog, and unique to the blog. Graham From owner-atom-syntax@mail.imc.org Fri Aug 12 06:31:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3WpM-00042R-Ux for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 06:31:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15077 for ; Fri, 12 Aug 2005 06:31:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CAQqxL090078; Fri, 12 Aug 2005 03:26:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CAQqNM090077; Fri, 12 Aug 2005 03:26:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7CAQpJO090067 for ; Fri, 12 Aug 2005 03:26:51 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 2241 messnum 5757803 invoked from network[213.94.211.166/dev2.mcpps.com]); 12 Aug 2005 10:26:45 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail12.svc.cra.dublin.eircom.net (qp 2241) with SMTP; 12 Aug 2005 10:26:45 -0000 Message-ID: <42FC7963.3010606@dehora.net> Date: Fri, 12 Aug 2005 11:26:43 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom WG Subject: Re: Finishing up on whitespace in IRIs and dates References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > Greetings again. I think we have rough consensus on "emitting with > whitespace around IRIs and dates is an error" and "we should warn folks > that people might emit errors here because this is somewhat subtle". > > If that is true, I propose that, just before section 3.1 (at the end of > the introductory text to "Common Atom Constructs") we add: > > Note that there MUST be no whitespace in a Date construct or in any IRI. > Some XML-emitting implementations erroneously insert whitespace around > values by default, and such implementations will emit invalid Atom. +1 cheers Bill From owner-atom-syntax@mail.imc.org Fri Aug 12 09:41:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Zmv-0003Jw-R8 for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 09:41:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22449 for ; Fri, 12 Aug 2005 09:41:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CDYZbi010198; Fri, 12 Aug 2005 06:34:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CDYZC4010197; Fri, 12 Aug 2005 06:34:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CDYYFM010177 for ; Fri, 12 Aug 2005 06:34:35 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so363500nzi for ; Fri, 12 Aug 2005 06:34:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SPoV/sILA1wavbHTCaiP45AYBlQpXmo8FCmkvuolOrlOpxn3Zwd4CJz/RXLbeE0E3YfQzhBXh+kkqzFHYLftmWgozrs2vCocHoGGiUzG8UWhxG1YrSM4gyZXf1gi2r0ssUOYH2h9+CWHGp1PhyXiPNi/fmgOMjgzCpMEUK5SCvU= Received: by 10.36.5.3 with SMTP id 3mr2399815nze; Fri, 12 Aug 2005 06:34:29 -0700 (PDT) Received: by 10.36.61.14 with HTTP; Fri, 12 Aug 2005 06:34:29 -0700 (PDT) Message-ID: <3f1451f505081206342bb70084@mail.gmail.com> Date: Fri, 12 Aug 2005 09:34:29 -0400 From: Joe Gregorio Subject: Re: Finishing up on whitespace in IRIs and dates Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7CDYZFM010184 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/12/05, Walter Underwood wrote: > > --On August 11, 2005 9:04:21 PM -0700 Paul Hoffman wrote: > > > Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. > > Nice clear wording. > > +1 with "MUST be no" changed to "MUST NOT be", as suggested by Aristotle. +1 with the MUST NOT change incorporated. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Aug 12 09:56:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3a1l-0007AR-0o for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 09:56:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23255 for ; Fri, 12 Aug 2005 09:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CDq6p7011805; Fri, 12 Aug 2005 06:52:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CDq62u011804; Fri, 12 Aug 2005 06:52:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CDq56N011797 for ; Fri, 12 Aug 2005 06:52:05 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7CDq5x7016382 for ; Fri, 12 Aug 2005 07:52:05 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IL40090E3US3K@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 12 Aug 2005 07:52:04 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IL400GBN3URFG@mail.sun.net> for atom-syntax@imc.org; Fri, 12 Aug 2005 07:52:04 -0600 (MDT) Date: Fri, 12 Aug 2005 06:52:28 -0700 From: Tim Bray Subject: Re: Spec explanations for Pebble? In-reply-to: To: Graham Parks Cc: Carey Evans , Atom Syntax Message-id: <27A3BD65-78FC-4BB1-A212-0A9C0574B012@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <492010e005081201166dc33727@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 12, 2005, at 1:55 AM, Graham Parks wrote: > "categorization scheme" means the system used to categorize > entries. Presumably each blog has its own system for doing so, so > the scheme attribute should be the same for all posts from the same > blog, and unique to the blog. Mostly agree. Except for, a bunch of blogs might agree to share a categorization scheme, so probably not "unique to each blog". But I suspect that the notion of "categorization scheme" is underdefined enough that if someone wanted to use different URIs for each page like the example Carey cited, that's really dumb but not actually illegal. -Tim From owner-atom-syntax@mail.imc.org Fri Aug 12 10:59:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3b0N-0008B5-Vg for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 10:59:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29573 for ; Fri, 12 Aug 2005 10:59:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CEp4PR017157; Fri, 12 Aug 2005 07:51:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CEp4Dn017156; Fri, 12 Aug 2005 07:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CEp4ah017150 for ; Fri, 12 Aug 2005 07:51:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id j7CEp3Ix005766; Fri, 12 Aug 2005 07:51:03 -0700 (PDT) Received: from [192.168.2.9] (fujita.plus.com [84.92.128.107]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j7CEox4G014352 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 12 Aug 2005 07:51:03 -0700 (PDT) In-Reply-To: <27A3BD65-78FC-4BB1-A212-0A9C0574B012@sun.com> References: <492010e005081201166dc33727@mail.gmail.com> <27A3BD65-78FC-4BB1-A212-0A9C0574B012@sun.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7689DE6A-AA95-436B-AE0B-68351A6CE173@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Spec explanations for Pebble? Date: Fri, 12 Aug 2005 15:50:58 +0100 To: Tim Bray X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 Aug 2005, at 2:52 pm, Tim Bray wrote: > On Aug 12, 2005, at 1:55 AM, Graham Parks wrote: > >> "categorization scheme" means the system used to categorize >> entries. Presumably each blog has its own system for doing so, so >> the scheme attribute should be the same for all posts from the >> same blog, and unique to the blog. > > Except for, a bunch of blogs might agree to share a categorization > scheme, so probably not "unique to each blog". Fair point. btw, Doesn't scheme and term require atom:id style discussion of equivalence to be useful? Graham From owner-atom-syntax@mail.imc.org Fri Aug 12 11:16:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bGy-0004cn-6j for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 11:16:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00424 for ; Fri, 12 Aug 2005 11:16:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CFCROj018668; Fri, 12 Aug 2005 08:12:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CFCRVc018667; Fri, 12 Aug 2005 08:12:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CFCQQi018648; Fri, 12 Aug 2005 08:12:26 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7CFCKd19297; Sat, 13 Aug 2005 00:12:20 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 07498c58_0b43_11da_8300_0030482532aa_19368; Sat, 13 Aug 2005 00:09:07 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO002600; 13 Aug 05 00:12:44 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 13 Aug 05 00:12:19 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.8) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0025FD; 13 Aug 05 00:12:09 +0900 Message-Id: <6.0.0.20.2.20050812235942.08549250@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 13 Aug 2005 00:02:40 +0900 To: Paul Hoffman , Atom WG From: Martin Duerst Subject: Re: Finishing up on whitespace in IRIs and dates In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, including the 'MUST NOT' suggestion. (Note that the XML Schema anyURI datatype, which may be used in the RelaxNG schema for IRIs, allows spaces, because it was based on an early draft of the IRI spec. If precision is desired, spaces (and the other US-ASCII characters that the XML Schema anyURI datatype allows) can easily be excluded using a pattern facet.) Regards, Martin. At 13:04 05/08/12, Paul Hoffman wrote: > >Greetings again. I think we have rough consensus on "emitting with whitespace around IRIs and dates is an error" and "we should warn folks that people might emit errors here because this is somewhat subtle". > >If that is true, I propose that, just before section 3.1 (at the end of the introductory text to "Common Atom Constructs") we add: > >Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. > >--Paul Hoffman, Director >--Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Fri Aug 12 11:52:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bpV-0008El-4r for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 11:52:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02276 for ; Fri, 12 Aug 2005 11:52:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CFkWT1021437; Fri, 12 Aug 2005 08:46:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CFkWJh021436; Fri, 12 Aug 2005 08:46:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CFkVfZ021418 for ; Fri, 12 Aug 2005 08:46:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so640955wra for ; Fri, 12 Aug 2005 08:46:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y11iwYd8MUQ1jvcDJ1DTn+JC0t4qTclPgGiIh1LYMZPoLO6UGufRAO2npnyG8V+ZEB/31Ngu3BbA799X0qGLr+UnI0ONfk/Bn+Kz+dztc+erQHO9pvLDFWsJJRDXLPRhU7h9ZyAwnkjDid3V9h5hg8She9xO86MPUP1J1MckGgA= Received: by 10.54.30.54 with SMTP id d54mr1952632wrd; Fri, 12 Aug 2005 08:46:25 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 12 Aug 2005 08:46:25 -0700 (PDT) Message-ID: <68fba5c505081208463f0cc752@mail.gmail.com> Date: Fri, 12 Aug 2005 11:46:25 -0400 From: Robert Sayre To: Martin Duerst Subject: Re: Finishing up on whitespace in IRIs and dates Cc: Paul Hoffman , Atom WG In-Reply-To: <6.0.0.20.2.20050812235942.08549250@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6.0.0.20.2.20050812235942.08549250@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7CFkVfZ021423 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/12/05, Martin Duerst wrote: > > +1, including the 'MUST NOT' suggestion. +1. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Aug 12 12:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3c4d-0003ZA-5M for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 12:08:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03417 for ; Fri, 12 Aug 2005 12:07:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CG3Ul7022582; Fri, 12 Aug 2005 09:03:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CG3UJl022581; Fri, 12 Aug 2005 09:03:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CG3UOg022573 for ; Fri, 12 Aug 2005 09:03:30 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 0AF5E5B for ; Fri, 12 Aug 2005 09:03:25 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7CG3Nkv023150 for ; Fri, 12 Aug 2005 09:03:24 -0700 (PDT) Date: Fri, 12 Aug 2005 09:03:02 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Spec explanations for Pebble? Message-ID: <7E15ACBE631FA4F1E2A47BF8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <27A3BD65-78FC-4BB1-A212-0A9C0574B012@sun.com> References: <492010e005081201166dc33727@mail.gmail.com> <27A3BD65-78FC-4BB1-A212-0A9C0574B012@sun.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 12, 2005 6:52:28 AM -0700 Tim Bray wrote: > > Except for, a bunch of blogs might agree to share a categorization > scheme, so probably not "unique to each blog". For example, as libraries start delivering literature monitoring with feeds, we'll see LCSH or some other standard category system in those. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 12 13:34:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dQD-0003uA-LE for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 13:34:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07380 for ; Fri, 12 Aug 2005 13:34:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CHMlrb028709; Fri, 12 Aug 2005 10:22:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CHMljK028708; Fri, 12 Aug 2005 10:22:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CHMhV8028684; Fri, 12 Aug 2005 10:22:43 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c505081208463f0cc752@mail.gmail.com> References: <6.0.0.20.2.20050812235942.08549250@itmail.it.aoyama.ac.jp> <68fba5c505081208463f0cc752@mail.gmail.com> Date: Fri, 12 Aug 2005 10:23:03 -0700 To: Robert Sayre From: Paul Hoffman Subject: Re: Finishing up on whitespace in IRIs and dates Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seems like we have consensus. Rob: please make this change and turn in the -11. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Aug 12 17:50:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hQQ-0007bd-97 for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 17:50:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04940 for ; Fri, 12 Aug 2005 17:50:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CLfYQL068836; Fri, 12 Aug 2005 14:41:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7CLfYN3068835; Fri, 12 Aug 2005 14:41:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7CLfXoF068802 for ; Fri, 12 Aug 2005 14:41:33 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.65.68]) by smtp.cegetel.net (Postfix) with ESMTP id C6EE41A4240; Fri, 12 Aug 2005 23:41:27 +0200 (CEST) Message-ID: <42FD1788.4070505@cegetel.net> Date: Fri, 12 Aug 2005 23:41:28 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050712) MIME-Version: 1.0 To: James M Snell Cc: "A. Pagaltzis" , atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> <42FAE6EA.1020106@gmail.com> In-Reply-To: <42FAE6EA.1020106@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > > The simple answer is that not everything I may want to reply too will > have an ID I can reference. Suppose that what I'm responding to is an > item in an RSS feed that does not contain a guid element? All I have > to go off of is the URL of the RSS feed or the RSS item's link > element... neither of which are actual ID's. From your draft's abstract: This memo presents a mechanism that allows feeds publishers to express threading relationships between entries and feeds. And from your draft's introduction section: This document specifies a mechanism that allows the expression of threaded discussions within the Atom Syndication Format ([I-D.ietf- atompub-format]). As I read it, your proposal is about enabling threading in Atom to allow aggregators to present entries in a tree form. If you want to comment on a non-Atom resource, create a new link/@rel value or use a link[@rel="related"] or link[@rel="via"] or something like that. So a strong +1 to making the id REQUIRED. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Aug 12 20:53:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3kHK-0002fl-1N for atompub-archive@megatron.ietf.org; Fri, 12 Aug 2005 20:53:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13233 for ; Fri, 12 Aug 2005 20:53:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D0mSJg039786; Fri, 12 Aug 2005 17:48:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7D0mSDC039785; Fri, 12 Aug 2005 17:48:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7D0mREV039746 for ; Fri, 12 Aug 2005 17:48:27 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 13 Aug 2005 00:48:20 -0000 Received: from xdsl-81-173-174-60.netcologne.de (EHLO klangraum) [81.173.174.60] by mail.gmx.net (mp025) with SMTP; 13 Aug 2005 02:48:20 +0200 X-Authenticated: #163624 Date: Sat, 13 Aug 2005 02:54:00 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Updated Comments Draft (getting closer) Message-ID: <20050813005400.GA30968@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42F83AE0.8010107@gmail.com> <20050811050554.GA19363@klangraum> <42FAE6EA.1020106@gmail.com> <42FD1788.4070505@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42FD1788.4070505@cegetel.net> 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: * Thomas Broyer [2005-08-12 23:55]: > As I read it, your proposal is about enabling threading in Atom > to allow aggregators to present entries in a tree form. > > If you want to comment on a non-Atom resource, create a new > link/@rel value or use a link[@rel="related"] or > link[@rel="via"] or something like that. > > So a strong +1 to making the id REQUIRED. You have a point. Hmm. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat Aug 13 04:52:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3rkx-0002zt-Pk for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 04:52:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11410 for ; Sat, 13 Aug 2005 04:52:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D8jB13066569; Sat, 13 Aug 2005 01:45:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7D8jBSU066567; Sat, 13 Aug 2005 01:45:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j7D8j96G066532 for ; Sat, 13 Aug 2005 01:45:10 -0700 (PDT) (envelope-from ga-atom-syntax@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E3rYI-0003DC-LW for atom-syntax@imc.org; Sat, 13 Aug 2005 10:39:48 +0200 Received: from 81-178-197-52.dsl.pipex.com ([81.178.197.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 10:39:38 +0200 Received: from simon_g_brown by 81-178-197-52.dsl.pipex.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Aug 2005 10:39:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: atom-syntax@imc.org From: Simon Brown Subject: Re: Spec explanations for Pebble? Date: Sat, 13 Aug 2005 08:34:49 +0000 (UTC) Lines: 71 Message-ID: References: <492010e005081201166dc33727@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.178.197.52 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks writes: > On 12 Aug 2005, at 9:16 am, Carey Evans wrote: > > > First, where does the spec actually say that the atom:id shouldn't > > change if the blog moves to a different domain? I think that if the > > URL of the blog changes, it means that the Atom Feed Document has been > > relocated so the ID should stay the same, but Simon doesn't see this > > in the spec. > > Section 4.2.6, paragraph 3: > > "an atom:id element pertains to all instantiations of a particular > Atom entry or feed; revisions retain the same content in their > atom:id elements. It is suggested that the atom:id element be > stored along with the associated resource." > > If an Atom document is a feed of the same blog, then even if the blog > has moved, the id should stay the same. What makes you think otherwise? That same paragraph starts, "When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change.". For me, this paragraph talks about the *Atom Document* moving, rather than the content that it represents (i.e. a blog). Mark Pilgrim has a great article about Atom IDs and towards the end of it goes on to talk about the same entry in multiple feeds (http://diveintomark.org/archives/2004/05/28/howto-atom-id#multiple), although that's not what I'm talking about here. Just to quote an example, Tim is currently using URL based Atom IDs, such as : http://www.tbray.org/ongoing/ http://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0 If Tim *moves* his blog to www.timbray.com/ongoing, would you expect his Atom IDs to remain the same? Spec aside, this has some implications for storing Atom IDs next to content they identify, which I imagine doesn't happen in most CMS tools at the moment. > > Second, what sort of values should be used for the scheme attribute on > > the category? Looking at http://www.tbray.org/ongoing/ongoing.atom as > > an authoritative example, it seems that the scheme should be the same > > for all categories, but Pebble uses the URL of the individual category > > page. The spec doesn't say, so does it matter? > > Section 4.2.2.2: > > "The "scheme" attribute is an IRI that identifies a > categorization scheme." > > "categorization scheme" means the system used to categorize entries. > Presumably each blog has its own system for doing so, so the scheme > attribute should be the same for all posts from the same blog, and > unique to the blog. The categorization scheme is a little confusing, although looking at Tim's feed and a few others has cleared up in my mind what I should be using. Basically, I was using this rather than this (notice the shorter scheme) Are there any recommendations as to that the scheme attribute should be and what it might be used for? Simon From owner-atom-syntax@mail.imc.org Sat Aug 13 05:09:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3s0k-0005Q0-Kz for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 05:09:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11826 for ; Sat, 13 Aug 2005 05:09:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D947VC072637; Sat, 13 Aug 2005 02:04:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7D9470X072636; Sat, 13 Aug 2005 02:04:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7D947Wa072628 for ; Sat, 13 Aug 2005 02:04:07 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id j7D946mT013050 for ; Sat, 13 Aug 2005 02:04:06 -0700 (PDT) Received: from [192.168.2.9] (fujita.plus.com [84.92.128.107]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j7D942XF005848 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sat, 13 Aug 2005 02:04:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Atom Syntax From: Graham Subject: atom:id spec bug Date: Sat, 13 Aug 2005 10:03:41 +0100 X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Simon brown raises a valid point on the "Spec explanations for Pebble?" thread: That same paragraph starts, "When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change.". For me, this paragraph talks about the *Atom Document* moving, rather than the content that it represents (i.e. a blog)." Perhaps we could add "or its associated resource" after "Atom Document"? Graham From owner-atom-syntax@mail.imc.org Sat Aug 13 10:50:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xL6-0005Xr-MC for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 10:50:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25484 for ; Sat, 13 Aug 2005 10:50:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DEbZR0082144; Sat, 13 Aug 2005 07:37:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7DEbZ2f082143; Sat, 13 Aug 2005 07:37:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DEbYx0082135 for ; Sat, 13 Aug 2005 07:37:34 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7DEbXx7007173 for ; Sat, 13 Aug 2005 08:37:33 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IL6007YR0MKFC@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 13 Aug 2005 08:37:33 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IL600H6I0MKPR@mail.sun.net> for atom-syntax@imc.org; Sat, 13 Aug 2005 08:37:32 -0600 (MDT) Date: Sat, 13 Aug 2005 07:37:58 -0700 From: Tim Bray Subject: Re: Spec explanations for Pebble? In-reply-to: To: Simon Brown Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <492010e005081201166dc33727@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 13, 2005, at 1:34 AM, Simon Brown wrote: > Just to quote an example, Tim is currently using URL based Atom > IDs, such as : > > http://www.tbray.org/ongoing/ > http://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0 > > If Tim *moves* his blog to www.timbray.com/ongoing, would you > expect his Atom > IDs to remain the same? Absolutely, otherwise everyone who subscribes to me is going to see all the same old articles again, exactly what atom:id exists to prevent. The fact that I use HTTP URIs for identifiers reflects my belief that good Web citizenship requires that once something is published and its URI widely disseminated, it should never ever be moved; so in my case this scenario is unlikely to arise. -Tim > > From owner-atom-syntax@mail.imc.org Sat Aug 13 13:44:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4038-0007p8-My for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 13:44:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01545 for ; Sat, 13 Aug 2005 13:44:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DHcjfQ012629; Sat, 13 Aug 2005 10:38:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7DHcjCl012628; Sat, 13 Aug 2005 10:38:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7DHcilY012605 for ; Sat, 13 Aug 2005 10:38:44 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 8EBB36B for ; Sat, 13 Aug 2005 10:38:39 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7DHcckv018829 for ; Sat, 13 Aug 2005 10:38:38 -0700 (PDT) Date: Sat, 13 Aug 2005 10:38:17 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Spec explanations for Pebble? Message-ID: In-Reply-To: References: <492010e005081201166dc33727@mail.gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 13, 2005 8:34:49 AM +0000 Simon Brown wrote: > If Tim *moves* his blog to www.timbray.com/ongoing, would you expect his Atom > IDs to remain the same? Spec aside, this has some implications for storing Atom > IDs next to content they identify, which I imagine doesn't happen in most CMS > tools at the moment. Of course they stay the same. At the risk of being rude, "duh". It is an ID, not an href. ID, ID, ID. If we need to clarify the spec further, though, let's do it now. I don't mind specifically saying that the ID stays the same when content is relocated. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Sat Aug 13 21:41:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E47VB-0006gV-Kz for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 21:41:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21172 for ; Sat, 13 Aug 2005 21:41:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E1YoEA072398; Sat, 13 Aug 2005 18:34:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E1YouJ072397; Sat, 13 Aug 2005 18:34:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7E1Ynkp072391 for ; Sat, 13 Aug 2005 18:34:49 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 14 Aug 2005 01:34:43 -0000 Received: from xdsl-213-196-244-119.netcologne.de (EHLO klangraum) [213.196.244.119] by mail.gmx.net (mp032) with SMTP; 14 Aug 2005 03:34:43 +0200 X-Authenticated: #163624 Date: Sun, 14 Aug 2005 03:40:33 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Spec explanations for Pebble? Message-ID: <20050814014033.GA11647@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <492010e005081201166dc33727@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id VAA21172 * Tim Bray [2005-08-13 16:50]: > The fact that I use HTTP URIs for identifiers reflects my > belief that good Web citizenship requires that once something > is published and its URI widely disseminated, it should never > ever be moved; so in my case this scenario is unlikely to > arise. I don=E2=80=99t know if you can reflect any belief by your choice of scheme for your atom:id values, though. As far as the consumer is concerned, the string is opaque and meaningless anyway, so whatever you put in there matters naught as long as it=E2=80=99s a URI. Therefore, *I* believe that authors of database-based CMS software of any form should be advised to use UUIDs, because a) it is instantly obvious that UUIDs have to be stored with their respective entry, so there=E2=80=99s no temptation to derive the ID dynamically from any other part of the data, and b) UUIDs are fixed-size and the binary form is very compact, which makes them extra easy to deal with in a database. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat Aug 13 21:43:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E47XJ-0006yP-H8 for atompub-archive@megatron.ietf.org; Sat, 13 Aug 2005 21:43:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21232 for ; Sat, 13 Aug 2005 21:43:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E1dW9P072606; Sat, 13 Aug 2005 18:39:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E1dW8O072605; Sat, 13 Aug 2005 18:39:32 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7E1dUrF072598 for ; Sat, 13 Aug 2005 18:39:31 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 14 Aug 2005 01:39:24 -0000 Received: from xdsl-213-196-244-119.netcologne.de (EHLO klangraum) [213.196.244.119] by mail.gmx.net (mp026) with SMTP; 14 Aug 2005 03:39:24 +0200 X-Authenticated: #163624 Date: Sun, 14 Aug 2005 03:45:15 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Spec explanations for Pebble? Message-ID: <20050814014515.GB11647@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <492010e005081201166dc33727@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id VAA21232 * Simon Brown [2005-08-13 11:00]: > If Tim *moves* his blog to www.timbray.com/ongoing, would you > expect his Atom IDs to remain the same? Yes. That=E2=80=99s what the spec says and that=E2=80=99s what IDs are fo= r: they *NEVER change*. Period. Regardless of what else you do with your content, the ID of the same entry is *ALWAYS* the *SAME* it has had since the moment it was created. > Spec aside, this has some implications for storing Atom IDs > next to content they identify, which I imagine doesn't happen > in most CMS tools at the moment. That=E2=80=99s a different matter, and one we need to educate producers about. IDs should always be generated once, at the time of entry creation, and then stored alongside the entry, for eternity =E2=80=93 unchanging. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 14 05:11:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4EX2-0001Ac-PO for atompub-archive@megatron.ietf.org; Sun, 14 Aug 2005 05:11:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17559 for ; Sun, 14 Aug 2005 05:11:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E93fb5087078; Sun, 14 Aug 2005 02:03:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7E93fWR087077; Sun, 14 Aug 2005 02:03:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7E93eUC087067 for ; Sun, 14 Aug 2005 02:03:40 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7E9C7nU021051; Sun, 14 Aug 2005 05:12:10 -0400 Message-ID: <42FF08ED.5020109@intertwingly.net> Date: Sun, 14 Aug 2005 05:03:41 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: Re: atom:id spec bug 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: Content-Transfer-Encoding: 7bit Graham wrote: > > Simon brown raises a valid point on the "Spec explanations for Pebble?" > thread: > > That same paragraph starts, "When an Atom Document is relocated, > migrated, > syndicated, republished, exported or imported, the content of its > atom:id > element MUST NOT change.". For me, this paragraph talks about the *Atom > Document* moving, rather than the content that it represents (i.e. a > blog)." > > Perhaps we could add "or its associated resource" after "Atom Document"? +1 - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 09:27:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4f0P-00084O-He for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 09:27:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02618 for ; Mon, 15 Aug 2005 09:27:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FDKfa9052188; Mon, 15 Aug 2005 06:20:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FDKfY4052187; Mon, 15 Aug 2005 06:20:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FDKdmH052171 for ; Mon, 15 Aug 2005 06:20:40 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr9.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FDKX1a052433 for ; Mon, 15 Aug 2005 15:20:38 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4300969C.1060905@w3future.com> Date: Mon, 15 Aug 2005 15:20:28 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: xml:base abuse Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, A while ago we had a discussion about how xml:base should be used. We didn't reach a conclusion, but I think we need to act. The way Tim Bray's feed and the examples from James Snell on developerWorks use xml:base is what Roy T. Fielding calls an abuse. Now I think that no matter what we decide, we should not do something that the writer of the URI spec thinks is an abuse. More here: http://w3future.com/weblog/2005/08/#howToUseBaseUris -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 09:58:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fU4-0003p0-QC for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 09:58:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03726 for ; Mon, 15 Aug 2005 09:58:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FDqjGD064142; Mon, 15 Aug 2005 06:52:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FDqjhE064141; Mon, 15 Aug 2005 06:52:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FDqiJe064126 for ; Mon, 15 Aug 2005 06:52:44 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7FE1IlE010353; Mon, 15 Aug 2005 10:01:21 -0400 Message-ID: <43009E2E.3000902@intertwingly.net> Date: Mon, 15 Aug 2005 09:52:46 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> In-Reply-To: <4300969C.1060905@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Hi, > > A while ago we had a discussion about how xml:base should be used. > We didn't reach a conclusion, but I think we need to act. > > The way Tim Bray's feed and the examples from James Snell on > developerWorks use xml:base is what Roy T. Fielding calls an abuse. > > Now I think that no matter what we decide, we should not do something > that the writer of the URI spec thinks is an abuse. > > More here: > http://w3future.com/weblog/2005/08/#howToUseBaseUris I would prefer to deal with what the spec actually says. As you point out, it is "really odd" that nothing was added to the new RFC 3986 to support your position. The authors of DOM3 looked at both the xml:base and InfoSet specifications. I've taken a look at how two respected XML parsers have implemented DOM3: http://www.intertwingly.net/blog/2005/08/12/xml-base-support - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 10:19:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4foM-0006sc-MA for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 10:19:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05488 for ; Mon, 15 Aug 2005 10:19:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FEDA6B072025; Mon, 15 Aug 2005 07:13:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FEDAKd072024; Mon, 15 Aug 2005 07:13:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FED8Di072009 for ; Mon, 15 Aug 2005 07:13:09 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FED05c051771; Mon, 15 Aug 2005 16:13:01 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4300A2E7.5010002@w3future.com> Date: Mon, 15 Aug 2005 16:12:55 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> In-Reply-To: <43009E2E.3000902@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > I would prefer to deal with what the spec actually says. As you point > out, it is "really odd" that nothing was added to the new RFC 3986 to > support your position. > > The authors of DOM3 looked at both the xml:base and InfoSet > specifications. I've taken a look at how two respected XML parsers have > implemented DOM3: > > http://www.intertwingly.net/blog/2005/08/12/xml-base-support > > - Sam Ruby > Yes, that code is perfectly fine, and not the actual problem. Let me show you some pseudo-code that implements how to dereference an atom link according to rfc3986: dereference(linkElement) = baseURI = linkElement.baseURI linkURI = makeAbsolute(linkElement.href, baseURI) if stripFragmentID(linkURI) == stripFragmentID(baseURI) then return linkElement.ownerDocument else return loadDocument(linkURI) You'll see the problem when you pass the link element of Tim Brays feed. Also, Roy T. Fielding says "[...] a person is deliberately abusing the base URI by assigning it an unrelated URI for the purpose of creating an artificial shorthand notation for external references." There is nothing in rfc3986 that contradicts this, it only indirectly hints to it. The real purpose of a base URI isn't explained in rfc3986. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 10:32:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4g0w-0000Rk-DL for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 10:32:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06312 for ; Mon, 15 Aug 2005 10:32:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FESG94074676; Mon, 15 Aug 2005 07:28:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FESGOo074675; Mon, 15 Aug 2005 07:28:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FESG51074667 for ; Mon, 15 Aug 2005 07:28:16 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7FESFF2019090 for ; Mon, 15 Aug 2005 08:28:15 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IL900JLDPJ13G@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 15 Aug 2005 08:28:14 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IL900JNPPJ1PY@mail.sun.net> for atom-syntax@imc.org; Mon, 15 Aug 2005 08:28:13 -0600 (MDT) Date: Mon, 15 Aug 2005 07:28:42 -0700 From: Tim Bray Subject: Re: xml:base abuse In-reply-to: <4300969C.1060905@w3future.com> To: Sjoerd Visscher Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <4300969C.1060905@w3future.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 15, 2005, at 6:20 AM, Sjoerd Visscher wrote: > > Hi, > > A while ago we had a discussion about how xml:base should be used. > We didn't reach a conclusion, but I think we need to act. > > The way Tim Bray's feed and the examples from James Snell on > developerWorks use xml:base is what Roy T. Fielding calls an abuse. I do plan to revise my feed, will try to do so in the next day or two. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 15 10:33:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4g1d-0000V8-FB for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 10:33:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06367 for ; Mon, 15 Aug 2005 10:33:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FESrvp074727; Mon, 15 Aug 2005 07:28:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FESrrR074726; Mon, 15 Aug 2005 07:28:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7FESp3R074713 for ; Mon, 15 Aug 2005 07:28:52 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 15 Aug 2005 14:28:45 -0000 Received: from dsl-084-056-247-063.arcor-ip.net (EHLO hive) [84.56.247.63] by mail.gmx.net (mp009) with SMTP; 15 Aug 2005 16:28:45 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Sjoerd Visscher Cc: atom-syntax@imc.org Subject: Re: xml:base abuse Date: Mon, 15 Aug 2005 16:29:04 +0200 Message-ID: References: <4300969C.1060905@w3future.com> In-Reply-To: <4300969C.1060905@w3future.com> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id KAA06367 * Sjoerd Visscher wrote: >A while ago we had a discussion about how xml:base should be used. >We didn't reach a conclusion, but I think we need to act. How to use xml:base is a matter of the xml:base specification and (less so) the resource identifier specifications. If you think xml:base is unclear in this regard, please let the W3C XML Core Working Group know. >Now I think that no matter what we decide, we should not do >something that the writer of the URI spec thinks is an abuse. "We" as in there is specific text in one of the atompub drafts that make misleading suggestions that are inconsistent with the xml:base Recommendation or RFC 3986/7 other than some con- fusion about how to handle IRIs in non-Unicode encoded Atom documents that are not in NFC? --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Mon Aug 15 10:47:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gEu-00029N-HH for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 10:47:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07093 for ; Mon, 15 Aug 2005 10:46:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FEgDEr075923; Mon, 15 Aug 2005 07:42:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FEgDVm075922; Mon, 15 Aug 2005 07:42:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FEgBMT075916 for ; Mon, 15 Aug 2005 07:42:12 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FEg43L079050; Mon, 15 Aug 2005 16:42:05 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4300A9B7.30003@w3future.com> Date: Mon, 15 Aug 2005 16:41:59 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bjoern Hoehrmann wrote: > * Sjoerd Visscher wrote: >>Now I think that no matter what we decide, we should not do >>something that the writer of the URI spec thinks is an abuse. > > > "We" as in there is specific text in one of the atompub drafts > that make misleading suggestions that are inconsistent with > the xml:base Recommendation or RFC 3986/7 other than some con- > fusion about how to handle IRIs in non-Unicode encoded Atom > documents that are not in NFC? I have no problem with the spec, only with some high profile Atom feed examples. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 11:30:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4guz-0006b1-Um for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 11:30:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08739 for ; Mon, 15 Aug 2005 11:30:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFPaiv079275; Mon, 15 Aug 2005 08:25:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FFPaR9079274; Mon, 15 Aug 2005 08:25:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFPZH8079268 for ; Mon, 15 Aug 2005 08:25:35 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7FFYAhf019614; Mon, 15 Aug 2005 11:34:13 -0400 Message-ID: <4300B3F0.8020108@intertwingly.net> Date: Mon, 15 Aug 2005 11:25:36 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> In-Reply-To: <4300A2E7.5010002@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Let me show you some pseudo-code that implements how to dereference an > atom link according to rfc3986: > > dereference(linkElement) = > baseURI = linkElement.baseURI > linkURI = makeAbsolute(linkElement.href, baseURI) > if stripFragmentID(linkURI) == stripFragmentID(baseURI) > then return linkElement.ownerDocument > else return loadDocument(linkURI) > > You'll see the problem when you pass the link element of Tim Brays feed. Focusing on the in Tim's existing feed, it seems to me that Tim intended to express . How you interpret the spec is that this will actually resolve to . Am I correct so far? If so, what would happen if he replaced this with ? linkURI would still resolve to the same value as baseURI. Do you interpret the spec is that this will also resolve to ? How about ? I guess that would depend on what the meaning of "==" is. - - - I am quite willing to add feed validator warnings for edge cases where reasonable professionals might have differing opinions of how to read the specification, particularly if there is no compelling use case for use of the feature. Can we agree that empty //atom:link/@href values, or //atom:link/@href values that consist entirely of a fragment are problematic? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 11:52:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hFu-00014M-Rt for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 11:52:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09833 for ; Mon, 15 Aug 2005 11:52:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFkJkS080643; Mon, 15 Aug 2005 08:46:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FFkJK1080642; Mon, 15 Aug 2005 08:46:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFkJaK080632 for ; Mon, 15 Aug 2005 08:46:19 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 8A6B6724122; Mon, 15 Aug 2005 11:46:13 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , Subject: RE: Introduction to The Atom Syndication Format Date: Mon, 15 Aug 2005 11:46:09 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <42EEDCBF.6010405@intertwingly.net> thread-index: AcWXDeFJ0XPqvujbSC6tHubuMZuBsQKof4gQ Message-Id: <20050815154613.8A6B6724122@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The "Introduction to The Atom Syndication Format" indicates that atom:source is an "optional" element of atom:entry. While this is indicated by the "MAY" in the first sentence of the specification's description of atom:source, the second sentence, by using "SHOULD", would seem to indicate that in some circumstances, atom:source is a recommended element. The text I refer to is: 4.2.11: "Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:rights, or atom:category and those child elements are not present in the source atom:entry." I suggest that the Introduction cover atom:source in the "recommended" section and highlight the case in which it is recommended. bob wyman -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Sam Ruby Sent: Monday, August 01, 2005 10:39 PM To: atom-syntax@imc.org Subject: Introduction to The Atom Syndication Format http://www.atomenabled.org/developers/syndication/ Feedback welcome. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 11:53:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hGu-0001PE-43 for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 11:53:08 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09928 for ; Mon, 15 Aug 2005 11:53:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFkXUk080661; Mon, 15 Aug 2005 08:46:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FFkWNL080660; Mon, 15 Aug 2005 08:46:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FFkVAk080653 for ; Mon, 15 Aug 2005 08:46:32 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FFkN8e085945; Mon, 15 Aug 2005 17:46:24 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4300B8CA.3000806@w3future.com> Date: Mon, 15 Aug 2005 17:46:18 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> In-Reply-To: <4300B3F0.8020108@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Sjoerd Visscher wrote: > >>Let me show you some pseudo-code that implements how to dereference an >>atom link according to rfc3986: >> >>dereference(linkElement) = >> baseURI = linkElement.baseURI >> linkURI = makeAbsolute(linkElement.href, baseURI) >> if stripFragmentID(linkURI) == stripFragmentID(baseURI) >> then return linkElement.ownerDocument >> else return loadDocument(linkURI) >> >>You'll see the problem when you pass the link element of Tim Brays feed. > > > Focusing on the in Tim's existing feed, it seems to me > that Tim intended to express . How you > interpret the spec is that this will actually resolve to > . > > Am I correct so far? Not quite, it is a nitpick, but I think the source of our disagreement. Resolution is the procedure of making absolute paths from relative paths. So the link resolves to . But this is equal (string-equal) to the base URI, so this is a same-document reference. > If so, what would happen if he replaced this with ? > linkURI would still resolve to the same value as baseURI. Do you > interpret the spec is that this will also resolve to > / resolves to , not the same value as the base URI, and not a same-document reference. > How about ? I guess that would depend on what the > meaning of "==" is. "==" is string equality in my pseudo-code. I think <./> resolves to , so that would be a same-document reference as well. > I am quite willing to add feed validator warnings for edge cases where > reasonable professionals might have differing opinions of how to read > the specification, particularly if there is no compelling use case for > use of the feature. > > Can we agree that empty //atom:link/@href values, or //atom:link/@href > values that consist entirely of a fragment are problematic? The problematic values are the ones that when resolved are the same as the base URI (ignoring the fragment). In this case even would be problematic. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 12:38:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hyc-0000Hu-Ef for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 12:38:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12357 for ; Mon, 15 Aug 2005 12:38:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGX3jR084463; Mon, 15 Aug 2005 09:33:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGX3d2084462; Mon, 15 Aug 2005 09:33:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGX28A084456 for ; Mon, 15 Aug 2005 09:33:02 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7FGfd0f026493; Mon, 15 Aug 2005 12:41:39 -0400 Message-ID: <4300C3BE.3010209@intertwingly.net> Date: Mon, 15 Aug 2005 12:33:02 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> In-Reply-To: <4300B8CA.3000806@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Not quite, it is a nitpick, but I think the source of our disagreement. > Resolution is the procedure of making absolute paths from relative > paths. So the link resolves to . > But this is equal (string-equal) to the base URI, so this is a > same-document reference. In the sentence above, you refer to "the base URI". I would interpret that as "the base URI of the document", not "the base URI of the element". Note that the base URI of the document is not necessarily the same as the base URI of the first element of the document (often referred to as the documentElement). > The problematic values are the ones that when resolved are the same as > the base URI (ignoring the fragment). In this case even href="http://www.tbray.org/ongoing/"/> would be problematic. My reading of this statement is that your feed also contains a problematic link. Issuing warnings on what is unambiguously a fully qualified URI and on your usage are things I would rather avoid. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 12:44:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4i4u-0001W3-Ia for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 12:44:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13138 for ; Mon, 15 Aug 2005 12:44:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGeG3k084908; Mon, 15 Aug 2005 09:40:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGeGRn084907; Mon, 15 Aug 2005 09:40:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGeExl084896 for ; Mon, 15 Aug 2005 09:40:15 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FGe6Ao091013; Mon, 15 Aug 2005 18:40:06 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4300C560.30709@w3future.com> Date: Mon, 15 Aug 2005 18:40:00 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> In-Reply-To: <4300C3BE.3010209@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Sjoerd Visscher wrote: > >>Not quite, it is a nitpick, but I think the source of our disagreement. >>Resolution is the procedure of making absolute paths from relative >>paths. So the link resolves to . >>But this is equal (string-equal) to the base URI, so this is a >>same-document reference. > > > In the sentence above, you refer to "the base URI". I would interpret > that as "the base URI of the document", not "the base URI of the element". It has to the base URI of the element, otherwise links can change meaning when you XInclude them in another document. >>The problematic values are the ones that when resolved are the same as >>the base URI (ignoring the fragment). In this case even >href="http://www.tbray.org/ongoing/"/> would be problematic. > > > My reading of this statement is that your feed also contains a > problematic link. Issuing warnings on what is unambiguously a fully > qualified URI and on your usage are things I would rather avoid. Why? -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 12:45:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4i5z-0001kS-2z for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 12:45:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13224 for ; Mon, 15 Aug 2005 12:45:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGgQEH085087; Mon, 15 Aug 2005 09:42:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGgQmd085086; Mon, 15 Aug 2005 09:42:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGgP1l085076 for ; Mon, 15 Aug 2005 09:42:26 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1083568wra for ; Mon, 15 Aug 2005 09:42:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fIulxaqsBPVeR9sNO0xL1MEZK6sonHTQMbFUxmK19pmcTH3p0xtHipXdkogCPRzlkqkTla/DfaGlnKfrExtFl+ij6C2XNO2gXvuZh4qgIZ/8bQh3nik7oizox0NTyCVQKKlQMlY7lMQFeCwF7grWK0CW+vJ3l8zNOZ1xygtrF4M= Received: by 10.54.144.9 with SMTP id r9mr3674906wrd; Mon, 15 Aug 2005 09:42:16 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 15 Aug 2005 09:42:16 -0700 (PDT) Message-ID: <68fba5c505081509427ac66504@mail.gmail.com> Date: Mon, 15 Aug 2005 12:42:16 -0400 From: Robert Sayre To: bobwyman@pubsub.com Subject: Re: Introduction to The Atom Syndication Format Cc: Sam Ruby , atom-syntax@imc.org In-Reply-To: <20050815154613.8A6B6724122@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42EEDCBF.6010405@intertwingly.net> <20050815154613.8A6B6724122@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7FGgQ1l085081 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, Bob Wyman wrote: > > I suggest that the Introduction cover atom:source in the "recommended" > section and highlight the case in which it is recommended. Disagree. The introduction is for newbies. Folks implementing synthetic feed services (the case in which it is recommended) have to read the real spec. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 15 13:00:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iJq-00056F-EJ for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:00:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14180 for ; Mon, 15 Aug 2005 13:00:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGrHkD085964; Mon, 15 Aug 2005 09:53:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FGrH4e085963; Mon, 15 Aug 2005 09:53:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FGrGJ5085926 for ; Mon, 15 Aug 2005 09:53:17 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1087527wra for ; Mon, 15 Aug 2005 09:53:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mQPnNN3iKktpcC+fKQbxtAr64Cd81MXNQh3gan7as5ciB/NYAO89vPwTG0PbC3yTmjc9xWGjOO4K5En4ecED9MV0hKBETYT/lHzcbUbg0xJjbsih8o2iXM/5a5LosQAzdihkSZia7+PVfvjGKKaMad7KyERxpvHSO2d3gekXGfc= Received: by 10.54.50.65 with SMTP id x65mr3708590wrx; Mon, 15 Aug 2005 09:53:11 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 15 Aug 2005 09:53:11 -0700 (PDT) Message-ID: <68fba5c50508150953208b1d5@mail.gmail.com> Date: Mon, 15 Aug 2005 12:53:11 -0400 From: Robert Sayre To: Sjoerd Visscher Subject: Re: xml:base abuse Cc: Sam Ruby , atom-syntax@imc.org In-Reply-To: <4300C560.30709@w3future.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7FGrHJ5085958 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, Sjoerd Visscher wrote: > > In the sentence above, you refer to "the base URI". I would interpret > > that as "the base URI of the document", not "the base URI of the element". > > It has to the base URI of the element, otherwise links can change > meaning when you XInclude them in another document. The implementors of Internet Explorer and Mozilla agree with Sam. http://www.franklinmint.fm/2005/08/15/base.html Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 15 13:38:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iv8-0002dw-7e for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:38:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16228 for ; Mon, 15 Aug 2005 13:38:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FHYB6F090505; Mon, 15 Aug 2005 10:34:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FHYBP1090504; Mon, 15 Aug 2005 10:34:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7FHYAn7090484 for ; Mon, 15 Aug 2005 10:34:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Aug 2005 17:34:04 -0000 Received: from xdsl-81-173-226-182.netcologne.de (EHLO klangraum) [81.173.226.182] by mail.gmx.net (mp006) with SMTP; 15 Aug 2005 19:34:04 +0200 X-Authenticated: #163624 Date: Mon, 15 Aug 2005 19:39:57 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base abuse Message-ID: <20050815173957.GA18058@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c50508150953208b1d5@mail.gmail.com> 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: * Robert Sayre [2005-08-15 19:05]: > The implementors of Internet Explorer and Mozilla agree with > Sam. > > http://www.franklinmint.fm/2005/08/15/base.html That uses html:base, which sets the base URI for the entire document, not @xml:base, which sets the base URI for the element and its children. Your example is irrelevant. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 15 13:57:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jD7-0005Cf-0N for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:57:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16862 for ; Mon, 15 Aug 2005 13:57:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FHrDG5091960; Mon, 15 Aug 2005 10:53:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FHrDtP091959; Mon, 15 Aug 2005 10:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FHrCQd091946 for ; Mon, 15 Aug 2005 10:53:13 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so1065287wra for ; Mon, 15 Aug 2005 10:53:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mh7gTRUaiF3+NUpxjOC2LGMwFWBjd3VkyTF72C2h6gGXbmRjgLzjk8B0a3v+xNMokX7nsRxAwwAE+ke1AtZQJTDwGDSkK8l4QEHJLDy3dDvc/PXweSH6WVtJHhK1FMqCO8gyDPY3FrpH+9LQx3IqHdXTK5Kfs2EX1mF75sh/0Es= Received: by 10.54.34.61 with SMTP id h61mr3750622wrh; Mon, 15 Aug 2005 10:53:07 -0700 (PDT) Received: by 10.54.104.17 with HTTP; Mon, 15 Aug 2005 10:53:07 -0700 (PDT) Message-ID: <540e3732050815105339e1be78@mail.gmail.com> Date: Mon, 15 Aug 2005 12:53:07 -0500 From: "Roger B." To: Sjoerd Visscher Subject: Re: xml:base abuse Cc: atom-syntax@imc.org In-Reply-To: <4300969C.1060905@w3future.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4300969C.1060905@w3future.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7FHrDQd091954 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sjoerd: While reading your linked post, I noticed this: "Finally I'd like to share a trick to set the base URI for escaped HTML in RSS and Atom: add a BASE element to the beginning of the HTML content." Maybe I shouldn't be, but I'd be surprised if that worked in too many aggregators. After all the warnings (and platypus attacks) over the years, I know that I strip pretty much any non-essential markup/attributes from incoming RSS/Atom items, including html:base. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Mon Aug 15 14:08:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jOM-0006mN-7d for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 14:08:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17328 for ; Mon, 15 Aug 2005 14:08:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FI1lQG092613; Mon, 15 Aug 2005 11:01:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FI1l3T092611; Mon, 15 Aug 2005 11:01:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FI1k2x092600; Mon, 15 Aug 2005 11:01:46 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7FIAO44002533; Mon, 15 Aug 2005 14:10:24 -0400 Message-ID: <4300D88F.5030400@intertwingly.net> Date: Mon, 15 Aug 2005 14:01:51 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , Atom-Protocol Subject: AtomPubIssuesList for 2005/08/15 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <421B5057.2020603@intertwingly.net> <427A00AC.5020007@intertwingly.net> <42B9958E.4060504@intertwingly.net> <42BAD7E1.6010307@intertwingly.net> In-Reply-To: <42BAD7E1.6010307@intertwingly.net> 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: Content-Transfer-Encoding: 7bit The biggest issue yet to be solved is categorizing draft documents. Accordingly, I'm scheduling the following, each of which either addresses the specific issue, or the more general one: PaceCollectionControl PaceCollectionProcess PaceSimpleDraft Discussion of these paces should occur on the atom protocol list, with a subject line identifying which pace you are expressing an opinion on. I'm also marking for closure: PaceCategorize PaceRenameUriElement The former seems to have been withdrawn, and the latter is neither a showstopper or a clarification/bug fix to the format document. In either case speak now if you feel otherwise. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 15 14:12:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jRb-0007F3-Py for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 14:12:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17430 for ; Mon, 15 Aug 2005 14:12:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FI8UIq093068; Mon, 15 Aug 2005 11:08:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FI8UOS093067; Mon, 15 Aug 2005 11:08:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FI8Thj093040 for ; Mon, 15 Aug 2005 11:08:29 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1106918wra for ; Mon, 15 Aug 2005 11:08:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a1hqFk4bM8Y6wd1Sp9WVVcOqX5rEssCkbscHBY9cOAcUKh7+xJQTerZ7QfLa6zS3qtE4wv4oiTArNl3+8/zip17euWESROHJfLUmeTaZfUqWaiU8lrAKToY7ArEwGyuwo/memtSIN1tMNnVwMuByXqUQK5z9tj+HM8UIlwLR79c= Received: by 10.54.18.59 with SMTP id 59mr3726930wrr; Mon, 15 Aug 2005 11:08:24 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 15 Aug 2005 11:08:24 -0700 (PDT) Message-ID: <68fba5c5050815110844247571@mail.gmail.com> Date: Mon, 15 Aug 2005 14:08:24 -0400 From: Robert Sayre To: atom-syntax@imc.org Subject: Re: xml:base abuse In-Reply-To: <20050815173957.GA18058@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7FI8Uhj093054 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, A. Pagaltzis wrote: > > * Robert Sayre [2005-08-15 19:05]: > > The implementors of Internet Explorer and Mozilla agree with > > Sam. > > > > http://www.franklinmint.fm/2005/08/15/base.html > > That uses html:base, which sets the base URI for the entire > document, not @xml:base, which sets the base URI for the element > and its children. Your example is irrelevant. Oh no, not irrelevance! :) Both seem to do the job described in section 5.1.1 of RFC 3986, "Base URI embedded in content". Just for fun, I made a version that uses xml:base instead. You can try it with Firefox, which happens to support xml:base: Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 15 15:31:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kgR-0008BJ-U3 for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 15:31:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22189 for ; Mon, 15 Aug 2005 15:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FJPF6p098311; Mon, 15 Aug 2005 12:25:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FJPFGR098310; Mon, 15 Aug 2005 12:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FJPE3Y098304 for ; Mon, 15 Aug 2005 12:25:14 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7FJPEBL000771 for ; Mon, 15 Aug 2005 13:25:14 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILA00D293A108@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 15 Aug 2005 13:25:14 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILA00GOS3A0FG@mail.sun.net> for atom-syntax@imc.org; Mon, 15 Aug 2005 13:25:13 -0600 (MDT) Date: Mon, 15 Aug 2005 12:25:11 -0700 From: Tim Bray Subject: Re: xml:base abuse In-reply-to: To: Tim Bray Cc: Sjoerd Visscher , atom-syntax@imc.org Message-id: <702C3648-6422-48D6-B79B-A7297743CFF8@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <4300969C.1060905@w3future.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 15, 2005, at 7:28 AM, Tim Bray wrote: >> The way Tim Bray's feed and the examples from James Snell on >> developerWorks use xml:base is what Roy T. Fielding calls an abuse. I disagree with Roy, but agree that the way my links were set up was a little surprising to the eye, so I tweaked. Check out http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% 2Fongoing%2Fongoing.atom -Tim From owner-atom-syntax@mail.imc.org Mon Aug 15 16:39:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ljh-0005Qh-Hj for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 16:39:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03619 for ; Mon, 15 Aug 2005 16:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FKVuUC003282; Mon, 15 Aug 2005 13:31:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FKVuGh003281; Mon, 15 Aug 2005 13:31:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FKVtLf003273 for ; Mon, 15 Aug 2005 13:31:55 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 5CCB1A34E0 for ; Mon, 15 Aug 2005 16:31:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Feed History -03 Date: Mon, 15 Aug 2005 13:31:52 -0700 To: Atom Syntax X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Draft -03 of feed history is now available, at: http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- history-03.txt Significant changes in this revision include: - add fh:archive element, to indicate that an entry is an archive - allow subscription feed to omit fh:stateful if fh:prev is present - clarified that fh doesn't add ordering semantics, just allows you to reconstruct state - cleaned up text, fixed examples, general standards hygiene There's going to be at least one more draft, as I neglected to acknowledge people who have made suggestions and otherwise helped so far. Sorry! -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 15 17:08:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mC0-0001aY-Ut for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 17:08:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04798 for ; Mon, 15 Aug 2005 17:08:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FL1uB1005999; Mon, 15 Aug 2005 14:01:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FL1u8m005998; Mon, 15 Aug 2005 14:01:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FL1tCm005991 for ; Mon, 15 Aug 2005 14:01:55 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FL1lDg033257; Mon, 15 Aug 2005 23:01:47 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <430102B4.3060000@w3future.com> Date: Mon, 15 Aug 2005 23:01:40 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> In-Reply-To: <68fba5c5050815110844247571@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 8/15/05, A. Pagaltzis wrote: > >>* Robert Sayre [2005-08-15 19:05]: >> >>>The implementors of Internet Explorer and Mozilla agree with >>>Sam. >>> >>>http://www.franklinmint.fm/2005/08/15/base.html >> >>That uses html:base, which sets the base URI for the entire >>document, not @xml:base, which sets the base URI for the element >>and its children. Your example is irrelevant. > > > Oh no, not irrelevance! :) > > Both seem to do the job described in section 5.1.1 of RFC 3986, "Base > URI embedded in content". > > Just for fun, I made a version that uses xml:base instead. You can try > it with Firefox, which happens to support xml:base: > Yes, it's a known bug. https://bugzilla.mozilla.org/show_bug.cgi?id=275689 As a result of that bug, same-document references in documents with xml:base or html:base (like documents from the Google cache) don't work. Also content-location support is removed in Firefox because it broke same-document references (which hadn't be the case if same-document references would have been correctly implemented in the first place.) -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 18:15:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nEU-0003zi-CU for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 18:15:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08263 for ; Mon, 15 Aug 2005 18:14:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FM9iqc012100; Mon, 15 Aug 2005 15:09:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FM9iwH012099; Mon, 15 Aug 2005 15:09:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FM9hUf012093 for ; Mon, 15 Aug 2005 15:09:44 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FM9gkI012005; Tue, 16 Aug 2005 00:09:42 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4301129F.4090008@w3future.com> Date: Tue, 16 Aug 2005 00:09:35 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <702C3648-6422-48D6-B79B-A7297743CFF8@sun.com> In-Reply-To: <702C3648-6422-48D6-B79B-A7297743CFF8@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 15, 2005, at 7:28 AM, Tim Bray wrote: > >>> The way Tim Bray's feed and the examples from James Snell on >>> developerWorks use xml:base is what Roy T. Fielding calls an abuse. > > > I disagree with Roy, Shouldn't he be the one who knows? He actually he made it into an abuse by changing the definition of same-document references in the new rfc, so some documents that used the base URI in a way it was (apparently) never intended break. Read his whole argument if you want: http://lists.w3.org/Archives/Public/uri/2004Jan/0009 It would be nice to know how bad he actually thinks the abuse is. > but agree that the way my links were set up was a > little surprising to the eye, so I tweaked. Check out > > http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% > 2Fongoing%2Fongoing.atom It would be really cool if you would move the xml:base of the entry to the div, but as you have 2 divs per entry I can imagine you don't want to do that. Or you could change the base URI to f.e. When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't dereference to anything) -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 18:33:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nVw-0006yi-QA for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 18:33:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09551 for ; Mon, 15 Aug 2005 18:33:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FMR6U7013532; Mon, 15 Aug 2005 15:27:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FMR6ed013531; Mon, 15 Aug 2005 15:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7FMR5o0013515 for ; Mon, 15 Aug 2005 15:27:05 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 15 Aug 2005 22:26:59 -0000 Received: from dsl-084-056-224-006.arcor-ip.net (EHLO hive) [84.56.224.6] by mail.gmx.net (mp012) with SMTP; 16 Aug 2005 00:26:59 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Sjoerd Visscher Cc: atom-syntax@imc.org Subject: Re: xml:base abuse Date: Tue, 16 Aug 2005 00:27:19 +0200 Message-ID: <2k52g1lq97tcrp5qtad2rv2qg6e8ooh96f@hive.bjoern.hoehrmann.de> References: <4300969C.1060905@w3future.com> <702C3648-6422-48D6-B79B-A7297743CFF8@sun.com> <4301129F.4090008@w3future.com> In-Reply-To: <4301129F.4090008@w3future.com> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id SAA09551 * Sjoerd Visscher wrote: >It would be really cool if you would move the xml:base of the entry to=20 >the div, but as you have 2 divs per entry I can imagine you don't want=20 >to do that. Or you could change the base URI to f.e.=20 >When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't=20 >dereference to anything) xml:base is not allowed on xhtml1:div elements. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Mon Aug 15 18:49:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nmA-0001BU-7s for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 18:49:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10317 for ; Mon, 15 Aug 2005 18:49:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FMjDNE015111; Mon, 15 Aug 2005 15:45:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FMjDKq015110; Mon, 15 Aug 2005 15:45:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FMjC4Q015103 for ; Mon, 15 Aug 2005 15:45:12 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7FMjBki024149; Tue, 16 Aug 2005 00:45:11 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <43011AF0.4090701@w3future.com> Date: Tue, 16 Aug 2005 00:45:04 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Hoehrmann CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <702C3648-6422-48D6-B79B-A7297743CFF8@sun.com> <4301129F.4090008@w3future.com> <2k52g1lq97tcrp5qtad2rv2qg6e8ooh96f@hive.bjoern.hoehrmann.de> In-Reply-To: <2k52g1lq97tcrp5qtad2rv2qg6e8ooh96f@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bjoern Hoehrmann wrote: > * Sjoerd Visscher wrote: > >>It would be really cool if you would move the xml:base of the entry to >>the div, but as you have 2 divs per entry I can imagine you don't want >>to do that. Or you could change the base URI to f.e. >>When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't >>dereference to anything) > > > xml:base is not allowed on xhtml1:div elements. Doh. The imperfections of the real world make it sometimes overwhelmingly disappointing. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Mon Aug 15 19:33:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oSY-0000Zw-E1 for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 19:33:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13384 for ; Mon, 15 Aug 2005 19:33:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNTrJ5019494; Mon, 15 Aug 2005 16:29:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FNTruE019493; Mon, 15 Aug 2005 16:29:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNTqwV019478 for ; Mon, 15 Aug 2005 16:29:53 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so702512nzb for ; Mon, 15 Aug 2005 16:29:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=YEwBwz9aLSpKZgIswC7TeDDbf4ZVg5wdbPXDk3GNWROJ3mdhKTlqVbYzbQH9zJkTxAcPkNytxiovXHcwnU2E0QDFs6Q7Q8jTtXlXsHb6BKITBvZBi8AvPMFdqcETtsysh3nYdJV9lRo6S9MhXTjoHSgYKyVdu9xEKYTsHyu6+Cs= Received: by 10.37.21.79 with SMTP id y79mr2329673nzi; Mon, 15 Aug 2005 16:29:47 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 39sm228295nzk.2005.08.15.16.29.47; Mon, 15 Aug 2005 16:29:47 -0700 (PDT) Message-ID: <43012566.9010902@gmail.com> Date: Mon, 15 Aug 2005 16:29:42 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Extension spec updates 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: Content-Transfer-Encoding: 7bit I have just submitted updates to the Index, Threads and License extension I-D's. They should appear on the IETF site in the coming days. Significant updates: A. Index - Disallow whitespace in the element. B. Thread - Added title and reflang attributes to the in-reply-to element - 'SHOULD' use link related with in-reply-to if the resource being responded to exists outside the current document C. License - Allow multiple license links to support dual-licensed content - Clarify that the license covers the information content of an entry There will be at least one more version of each. - James From owner-atom-syntax@mail.imc.org Mon Aug 15 19:34:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4oTO-0000qf-5p for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 19:34:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13444 for ; Mon, 15 Aug 2005 19:34:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNT2IY019291; Mon, 15 Aug 2005 16:29:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FNT2CL019290; Mon, 15 Aug 2005 16:29:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNT1I8019270 for ; Mon, 15 Aug 2005 16:29:01 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1154991wra for ; Mon, 15 Aug 2005 16:28:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WNDerAQBMg3qsto1G/MDBs3ipwCNqp4lcVYLoEFoKaj5udUe8mOfsion6M6GbFsWCuK5Jjz3C0QDlcgtIgb8twm48lt4Mp+GcMq6n92lR1VHzvk1HLum2TafHg/DlhC5BXAhJdZR5T26SsWCBlzgwaJQetGpBVwhSyU68kiVDSc= Received: by 10.54.18.28 with SMTP id 28mr438405wrr; Mon, 15 Aug 2005 16:28:56 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 15 Aug 2005 16:28:56 -0700 (PDT) Message-ID: <68fba5c505081516285925ce41@mail.gmail.com> Date: Mon, 15 Aug 2005 19:28:56 -0400 From: Robert Sayre To: Mark Nottingham Subject: Re: Feed History -03 Cc: Atom Syntax In-Reply-To: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7FNT1I8019285 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, Mark Nottingham wrote: > > Draft -03 of feed history is now available, at: > http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- > history-03.txt From :: "I registered this PURL namespace for the benefit of format-neutral syndication extensions; i.e., those that will work equally well in all versions of RSS as well as Atom." Why is it desirable to promote mulitple syndication formats? Practically any RSS2 extension would be ok in Atom, and any Atom element would be legal in RSS2. If feed-history used atom:link, it would get xml:base processing and link descriptions "for free." I'm guessing extensions "that will work equally well in all versions of RSS" must be valid RDF. This feels like crypto-RDF-advocacy to me, which seems a little pointless. Five years of syndication software seem to show that RDF isn't very useful in this space. Most aggregators don't parse RSS1 with an RDF processor, and the most popular one that does (Thunderbird) would get a lot fewer bug reports if it ditched the RDF processor (which it probably will when Mozilla switches to SQLLite for storage). Mark, James, and anyone else are obviously free to spec any extension they want. That said, it feels fishy to call RDF modules Atompub drafts given that the WG rejected RDF with prejudice (I wouldn't count myself in that camp, though I do despise RDF-promises and RDF-lessons offered instead of RDF-benefits and RDF-running-code). Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 15 19:54:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4omX-0003jl-7o for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 19:54:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14252 for ; Mon, 15 Aug 2005 19:54:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNnJ9n020852; Mon, 15 Aug 2005 16:49:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7FNnJlq020851; Mon, 15 Aug 2005 16:49:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7FNnIBF020845 for ; Mon, 15 Aug 2005 16:49:18 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.173.219]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 887B0A3210; Mon, 15 Aug 2005 19:49:17 -0400 (EDT) In-Reply-To: <68fba5c505081516285925ce41@mail.gmail.com> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <68fba5c505081516285925ce41@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Mon, 15 Aug 2005 16:49:14 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/08/2005, at 4:28 PM, Robert Sayre wrote: > Why is it desirable to promote mulitple syndication formats? > Practically any RSS2 extension would be ok in Atom, and any Atom > element would be legal in RSS2. If feed-history used atom:link, it > would get xml:base processing and link descriptions "for free." Because it's not free; publishers have to declare the Atom namespace, and that's confusing; atom:link is defined in the context of Atom, not in the context of RSS. I'm interested in getting things working, not playing the syndication format advocacy game. There's a difference between promoting multiple syndication formats and accommodating the reality that there are many. > I'm guessing extensions "that will work equally well in all versions > of RSS" must be valid RDF. This feels like crypto-RDF-advocacy to me, > which seems a little pointless. Er, no. > Mark, James, and anyone else are obviously free to spec any extension > they want. That said, it feels fishy to call RDF modules Atompub > drafts given that the WG rejected RDF with prejudice (I wouldn't count > myself in that camp, though I do despise RDF-promises and RDF-lessons > offered instead of RDF-benefits and RDF-running-code). This isn't an atompub draft, it's a draft to the attention of the atompub WG (hence draft-nottingham-atompub). -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 15 20:14:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4p67-0006iQ-OE for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 20:14:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15232 for ; Mon, 15 Aug 2005 20:14:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G09s9O022179; Mon, 15 Aug 2005 17:09:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G09s2v022178; Mon, 15 Aug 2005 17:09:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G09raw022166 for ; Mon, 15 Aug 2005 17:09:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so1199920wra for ; Mon, 15 Aug 2005 17:09:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NTBGT9gEU3CKnph8JSgmhSdE5ZdZJJ1VFKajZXDX9Fd0vQa9tqUj9KruasN0tnTz6UNo3x2J+RTAOAGEkkpw/HJnQUfbq7x5cCjQ9UBDowZZvSesPhBz3dqYRAKANwzG1jbJMk1DCAXNhEtiQQueudmGJPAbkdwRE6WmVjFwPFs= Received: by 10.54.10.61 with SMTP id 61mr3915755wrj; Mon, 15 Aug 2005 17:09:47 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 15 Aug 2005 17:09:47 -0700 (PDT) Message-ID: <68fba5c5050815170975a6b327@mail.gmail.com> Date: Mon, 15 Aug 2005 20:09:47 -0400 From: Robert Sayre To: Mark Nottingham Subject: Re: Feed History -03 Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <68fba5c505081516285925ce41@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7G09saw022173 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, Mark Nottingham wrote: > On 15/08/2005, at 4:28 PM, Robert Sayre wrote: > > Why is it desirable to promote mulitple syndication formats? > > Practically any RSS2 extension would be ok in Atom, and any Atom > > element would be legal in RSS2. If feed-history used atom:link, it > > would get xml:base processing and link descriptions "for free." > > Because it's not free; publishers have to declare the Atom namespace, > and that's confusing; Less confusing than the purl namespace? Most people just think those are magic strings they have to include at the top. You could be right, though. > atom:link is defined in the context of Atom, > not in the context of RSS. What problems or ambiguities arise from putting Atom links in RSS? I can't think of any. > I'm interested in getting things working, > not playing the syndication format advocacy game. Not sure how feed-history will work without a unique id. > There's a difference between promoting multiple syndication formats > and accommodating the reality that there are many. Well, since any extension element (that I know of) is valid RSS2 or Atom, I'm confused as to why "extensions that can be used in any format" is necessary. > > > I'm guessing extensions "that will work equally well in all versions > > of RSS" must be valid RDF. This feels like crypto-RDF-advocacy to me, > > which seems a little pointless. > > Er, no. So, they must be valid RDF, or no? Pardon my crypto comment, that was a little over the top. > This isn't an atompub draft, it's a draft to the attention of the > atompub WG (hence draft-nottingham-atompub). Well, you could still bring it to the attention of the WG by emailing us, but the drafts don't purport to solve any of the problems in the charter. I feel it's (unintentionally) intellectually dishonest, since most folks will assume it's an Atompub draft. But, that's just my humble opinion. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 15 20:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pFG-0008JE-U6 for atompub-archive@megatron.ietf.org; Mon, 15 Aug 2005 20:23:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15580 for ; Mon, 15 Aug 2005 20:23:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G0JN5g022731; Mon, 15 Aug 2005 17:19:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G0JNFg022730; Mon, 15 Aug 2005 17:19:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G0JNrU022723 for ; Mon, 15 Aug 2005 17:19:23 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.173.219]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 77FD1A3210; Mon, 15 Aug 2005 20:19:22 -0400 (EDT) In-Reply-To: <68fba5c5050815170975a6b327@mail.gmail.com> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <68fba5c505081516285925ce41@mail.gmail.com> <68fba5c5050815170975a6b327@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DC8FA3A-B7DE-427D-9DC3-B5238DF17DFA@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Mon, 15 Aug 2005 17:19:19 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15/08/2005, at 5:09 PM, Robert Sayre wrote: >> I'm interested in getting things working, >> not playing the syndication format advocacy game. > > Not sure how feed-history will work without a unique id. ? Sorry, you lost me there. >> There's a difference between promoting multiple syndication formats >> and accommodating the reality that there are many. > > Well, since any extension element (that I know of) is valid RSS2 or > Atom, I'm confused as to why "extensions that can be used in any > format" is necessary. I wanted a neutral place/namespace for them, where the extension can be separated from the back-and-forth of what format to use. Put it this way; how would it go over here if I came along and suggested using an existing RSS element for some functionality in Atom? It's all just syntactic sugar, of course, but a clear separation avoids the politics and makes the status of the extension clearer to users. >>> I'm guessing extensions "that will work equally well in all versions >>> of RSS" must be valid RDF. This feels like crypto-RDF-advocacy to >>> me, >>> which seems a little pointless. >> >> Er, no. > > So, they must be valid RDF, or no? Pardon my crypto comment, that was > a little over the top. I'm not going to be incredibly strict about it; some RSS 1.0 people might not like non-RDF syntax getting into RDF 1.0, but I think it's a fact of life. I like the RDF model; hate the XML syntax. So, you can accuse me of being anything *but* an RDF/XML syntax advocate :) >> This isn't an atompub draft, it's a draft to the attention of the >> atompub WG (hence draft-nottingham-atompub). >> > > Well, you could still bring it to the attention of the WG by emailing > us, but the drafts don't purport to solve any of the problems in the > charter. I feel it's (unintentionally) intellectually dishonest, since > most folks will assume it's an Atompub draft. But, that's just my > humble opinion. Sorry, it's an IETF convention; I assumed that it was well-known (but then again, many/most IETF conventions aren't, so I should have known better!) -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 16 00:21:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4swu-0004Zt-1y for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 00:21:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04702 for ; Tue, 16 Aug 2005 00:21:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G4FE7F045588; Mon, 15 Aug 2005 21:15:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G4FE6x045587; Mon, 15 Aug 2005 21:15:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G4FDQx045579 for ; Mon, 15 Aug 2005 21:15:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so717676nzi for ; Mon, 15 Aug 2005 21:15:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hC/Eei4zfACgKRQ6alBY3dRTOFUzWmMem0iZ1TsADQMxRduyr3F/YL0TxLOknjqp/epTerCd2a4Ir7DQ5lW31LnrOV6nXzllj6juDFTQbAOFxZgRGWS0SnHabwxPwNKD2SOU5a5xvmiG5FDfC27uP/KUzRz+VouX1fcCxL5ZnXA= Received: by 10.36.24.5 with SMTP id 5mr2863046nzx; Mon, 15 Aug 2005 21:15:08 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Mon, 15 Aug 2005 21:15:08 -0700 (PDT) Message-ID: <68fba5c505081521156afd6314@mail.gmail.com> Date: Tue, 16 Aug 2005 00:15:08 -0400 From: Robert Sayre To: Sjoerd Visscher Subject: Re: xml:base abuse Cc: atom-syntax@imc.org In-Reply-To: <430102B4.3060000@w3future.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7G4FEQx045581 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/15/05, Sjoerd Visscher wrote: > Yes, it's a known bug. > https://bugzilla.mozilla.org/show_bug.cgi?id=275689 > Well, it's not clear from that bug that any Mozilla committers feel it's wise to "fix." Even so, they seem to be leaning towards patching html:a as a special case, in the event that they do anything. I'll agree that this should be a warning, and perhaps write something that willcome back to haunt me--Atom makes a point of leaning many established specifications. It's unwise to lean on those specs in the corner cases where they diverge from existing implementations, and a warning in the feedvalidator is justified in such cases. > As a result of that bug, same-document references in documents with > xml:base or html:base... As long as we're picking on Tim's URI space... what happens in this hypothetical situation: Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 16 04:33:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4wtP-0004kM-Rh for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 04:33:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27697 for ; Tue, 16 Aug 2005 04:33:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G8ROva037954; Tue, 16 Aug 2005 01:27:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G8ROEk037953; Tue, 16 Aug 2005 01:27:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from krusty.greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G8RMIl037935 for ; Tue, 16 Aug 2005 01:27:23 -0700 (PDT) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by krusty.greenbytes.de (Postfix) with ESMTP id 67B5654D2D37 for ; Tue, 16 Aug 2005 10:27:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <420a6592ab563430ac6a6b412def3285@greenbytes.de> Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 10:27:20 +0200 To: Atom WG X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Am 15.08.2005 um 22:31 schrieb Mark Nottingham: > > Draft -03 of feed history is now available, at: > > http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- > history-03.txt Ch 4. Typo: remove period of first sentence Ch 4: Different use of MAY and SHOULD when compared to Ch. 3.: "fh:stateful ...MAY occur" vs. "fh:archive...SHOULD occur..." On third read i think i know how you mean it. But it is a circular definition nevertheless. Proposal: "The fh:archive element MAY occur in a document's head section and declares that the document is an archive document." Ch. 5 similar: "MUST occur unless". If the document is an archive there are only 2 possiblities: either fh:prev is there or not. If not it will always "terminate" the archive list, won't it? You seem to have a (server-side) model in mind which drives the document structure. From a client perspective, there are only the documents and it derives its own model from that. Maybe its a matter of taste. //Stefan From owner-atom-syntax@mail.imc.org Tue Aug 16 04:37:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4wwu-0005Mj-T9 for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 04:37:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27804 for ; Tue, 16 Aug 2005 04:37:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G8XRpb040232; Tue, 16 Aug 2005 01:33:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G8XQ4Z040228; Tue, 16 Aug 2005 01:33:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7G8XOgK040151 for ; Tue, 16 Aug 2005 01:33:24 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 Aug 2005 08:33:18 -0000 Received: from xdsl-213-196-221-52.netcologne.de (EHLO klangraum) [213.196.221.52] by mail.gmx.net (mp026) with SMTP; 16 Aug 2005 10:33:18 +0200 X-Authenticated: #163624 Date: Tue, 16 Aug 2005 10:33:18 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base abuse Message-ID: <20050816083318.GA11343@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c505081521156afd6314@mail.gmail.com> 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 ietf.org id EAA27804 * Robert Sayre [2005-08-16 09:40]: > As long as we're picking on Tim's URI space... what happens in > this hypothetical situation: >=20 > That=E2=80=99s the same as ie the document author made a mistake. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 16 04:40:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4wzd-0005dy-9n for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 04:40:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27888 for ; Tue, 16 Aug 2005 04:40:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G8ZXXF041079; Tue, 16 Aug 2005 01:35:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G8ZXZs041078; Tue, 16 Aug 2005 01:35:33 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7G8ZWlX041024 for ; Tue, 16 Aug 2005 01:35:32 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 Aug 2005 08:35:26 -0000 Received: from xdsl-213-196-221-52.netcologne.de (EHLO klangraum) [213.196.221.52] by mail.gmx.net (mp005) with SMTP; 16 Aug 2005 10:35:26 +0200 X-Authenticated: #163624 Date: Tue, 16 Aug 2005 10:35:26 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base abuse Message-ID: <20050816083526.GB11343@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4300969C.1060905@w3future.com> <43009E2E.3000902@intertwingly.net> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c5050815110844247571@mail.gmail.com> 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: * Robert Sayre [2005-08-15 20:15]: > > That uses html:base, which sets the base URI for the entire > > document, not @xml:base, which sets the base URI for the > > element and its children. Your example is irrelevant. > > Oh no, not irrelevance! :) > > Both seem to do the job described in section 5.1.1 of RFC 3986, > "Base URI embedded in content". > Sorry, I misunderstood what you were trying to demonstrate because I mixed it up with the discussion about @xml:base providing a base URI for a subtree of a document only. In other matters, what Sjoerd said. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 16 05:09:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4xRu-0001MZ-3l for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 05:09:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28885 for ; Tue, 16 Aug 2005 05:09:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G94r1g051502; Tue, 16 Aug 2005 02:04:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7G94r1d051501; Tue, 16 Aug 2005 02:04:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7G94rME051492 for ; Tue, 16 Aug 2005 02:04:53 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 73084 invoked by uid 17064); 16 Aug 2005 09:04:52 -0000 Received: from unknown (HELO [192.168.1.43]) ([83.79.5.214]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2005 09:04:52 -0000 In-Reply-To: <8DC8FA3A-B7DE-427D-9DC3-B5238DF17DFA@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <68fba5c505081516285925ce41@mail.gmail.com> <68fba5c5050815170975a6b327@mail.gmail.com> <8DC8FA3A-B7DE-427D-9DC3-B5238DF17DFA@mnot.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F38A6E4-4923-4770-BA42-8F1AEBF31A04@bblfish.net> Cc: Robert Sayre , Mark Nottingham Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 11:04:50 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Aug 2005, at 02:19, Mark Nottingham wrote: > On 15/08/2005, at 5:09 PM, Robert Sayre wrote: > >>> I'm interested in getting things working, >>> not playing the syndication format advocacy game. >>> >> >> Not sure how feed-history will work without a unique id. >> > > ? Sorry, you lost me there. Yes. If you were to take a subscription feed "feed.atom" and map it to a graph you might get something like this: _feed |----id------> |---entry----> _ | |----id-----> | |---title---> "first entry" |--fh:next---> The graph of the history1.atom archive may be: _feed2 |----id------> |---entry----> _ |----id-----> |---title---> "another entry" The role of id is to help us merge the two graphs. IE the point of the history tag is to help us think of the history.atom document as a continuation of the same document, or rather that they are both descriptions of the feed with id . Merging the above two as simple graphs at most gives this |--1/id---> _feed | |---entry----> _ | | |----id-----> | | |---title---> "first entry" | |--fh:next---> |--1/id--->_feed2 |---entry----> _ | |----id-----> | |---title---> "another entry" |--fh:next---> But what we really want is something like this: |---entry----> _ | |----id-----> | |---title---> "first entry" |---entry----> _ |----id-----> |---title---> "another entry" I think we require some form of inferencing beyond what is available in OWL to achieve this result. This could probably be achieved through some simple N3 rules. Henry Story From owner-atom-syntax@mail.imc.org Tue Aug 16 10:24:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52N3-000856-Cq for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 10:24:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14661 for ; Tue, 16 Aug 2005 10:24:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GEFB9Z059716; Tue, 16 Aug 2005 07:15:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GEFB6x059715; Tue, 16 Aug 2005 07:15:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GEFAhM059706 for ; Tue, 16 Aug 2005 07:15:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7GENl9U009261; Tue, 16 Aug 2005 10:23:48 -0400 Message-ID: <4301F4E7.7070908@intertwingly.net> Date: Tue, 16 Aug 2005 10:15:03 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Sjoerd Visscher , atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> In-Reply-To: <68fba5c505081521156afd6314@mail.gmail.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: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 8/15/05, Sjoerd Visscher wrote: > >>Yes, it's a known bug. >>https://bugzilla.mozilla.org/show_bug.cgi?id=275689 > > Well, it's not clear from that bug that any Mozilla committers feel > it's wise to "fix." Even so, they seem to be leaning towards patching > html:a as a special case, in the event that they do anything. > > I'll agree that this should be a warning, and perhaps write something > that willcome back to haunt me--Atom makes a point of leaning many > established specifications. It's unwise to lean on those specs in the > corner cases where they diverge from existing implementations, and a > warning in the feedvalidator is justified in such cases. What I see occurring here is implementations dealing with the attendent confusions that their users face as the result of an unclear specification of a corner case in a spec. After all this discussion, I am *still* unclear as to where this corner case is. Let me try again. Apparently, consuming tools are welcome to aggressively substitute references to the enclosing parent document of any element for any references that, when resolved according to xml:base, differ from that xml:base only in ways that deal with normalization and fragment identifiers. This can only cause confusion if the xml:base in effect differs from original xml:base of the document (i.e., the URI used to retrieve the document in the first place) in ways other than the fragment identifier. Sjoerd: is this your understanding? Note that I'm sidestepping all questions about who is right or wrong. Different implementations may chose different strategies on how aggressive they wish to be. If my understanding is correct, then I will agree that it is unwise for feeds to express URIs that some consumers will interpret in one way, and others will interpret in an other way; therefore a warning is warranted. If my understanding is correct, I can produce test cases (and would welcome any contributions in this area), and fix the feed validator. The recommendations produced by the feed validator will focus on the areas where the user is most likely to stumble into this problem. It seems to me that the largest problem area is at the feed level, and the recommendation will be to either make xml:base at the feed level match the URI from which the feed was loaded, or (paradoxically enough) to reference a resource that you are unlikely to directly reference later in the document. Referencing a parent directory of any given document is OK, what's important is that it isn't the document itself. And to include an example that matches what Sjoerd's feed (and now Tim's feed) now do. Fair enough? - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 16 11:48:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53fn-0006b3-EY for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:48:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19197 for ; Tue, 16 Aug 2005 11:48:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GFgvZJ067711; Tue, 16 Aug 2005 08:42:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GFgvZv067710; Tue, 16 Aug 2005 08:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GFguhj067704 for ; Tue, 16 Aug 2005 08:42:56 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.174.185]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E42A1A32CA; Tue, 16 Aug 2005 11:42:54 -0400 (EDT) In-Reply-To: <420a6592ab563430ac6a6b412def3285@greenbytes.de> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <420a6592ab563430ac6a6b412def3285@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom WG Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 08:42:50 -0700 To: Stefan Eissing X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16/08/2005, at 1:27 AM, Stefan Eissing wrote: > Ch 4: Different use of MAY and SHOULD when compared to Ch. 3.: > "fh:stateful ...MAY occur" vs. "fh:archive...SHOULD occur..." On > third read i think i know how you mean it. But it is a circular > definition nevertheless. I agree that there's a misalignment here, but would actually resolve it the other way. I wanted to encourage fh:archive's presence, because it will allow processors to avoid mistakes like subscribing to an archive feed. Hence, the SHOULD. However, fh:stateful would probably be improved by saying it SHOULD (instead of MAY) occur in a subscription document's head section, and processors MUST (instead of MAY) behave as if it is present and true if fh:prev is there. > Ch. 5 similar: "MUST occur unless". If the document is an archive > there are only 2 possiblities: either fh:prev is there or not. If > not it will always "terminate" the archive list, won't it? You seem > to have a (server-side) model in mind which drives the document > structure. From a client perspective, there are only the documents > and it derives its own model from that. Not sure what you mean here; are you saying that fh:archive is superfluous? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 16 12:26:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54Gl-0006mG-6r for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:26:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22101 for ; Tue, 16 Aug 2005 12:26:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GGHrka071748; Tue, 16 Aug 2005 09:17:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GGHrv6071747; Tue, 16 Aug 2005 09:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from krusty.greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GGHqmS071737 for ; Tue, 16 Aug 2005 09:17:52 -0700 (PDT) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by krusty.greenbytes.de (Postfix) with ESMTP id 2EDBE5518638; Tue, 16 Aug 2005 18:17:49 +0200 (CEST) In-Reply-To: References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <420a6592ab563430ac6a6b412def3285@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG From: Stefan Eissing Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 18:17:49 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Am 16.08.2005 um 17:42 schrieb Mark Nottingham: > On 16/08/2005, at 1:27 AM, Stefan Eissing wrote: [...] > >> Ch. 5 similar: "MUST occur unless". If the document is an archive >> there are only 2 possiblities: either fh:prev is there or not. If not >> it will always "terminate" the archive list, won't it? You seem to >> have a (server-side) model in mind which drives the document >> structure. From a client perspective, there are only the documents >> and it derives its own model from that. > > Not sure what you mean here; are you saying that fh:archive is > superfluous? Currently: The document first defines "archive documents" and *afterwards* requires that fh:archive MUST be present in archive documents. My proposal: Introduce fh:archive with the semantics that the server garantuees that the set of entries in this document will not change over time if fh:archive is present. A document with fh:archive in it (and its implied semantics) is then called an "archive document". To tackle it from another view: The spec should say "servers MUST NOT break the promises of fh:archive" instead of saying "archive documents MUST announce that they do not change". There is possible harm in breaking the first, but only suboptimal performance in neglecting the latter case. //Stefan From owner-atom-syntax@mail.imc.org Tue Aug 16 13:17:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E553f-0006pK-7k for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 13:17:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23999 for ; Tue, 16 Aug 2005 13:16:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GHC6DA077307; Tue, 16 Aug 2005 10:12:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GHC6Aw077306; Tue, 16 Aug 2005 10:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GHC497077297 for ; Tue, 16 Aug 2005 10:12:05 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7GHBvC4047841; Tue, 16 Aug 2005 19:11:58 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <43021E53.1060308@w3future.com> Date: Tue, 16 Aug 2005 19:11:47 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> In-Reply-To: <4301F4E7.7070908@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Apparently, consuming tools are welcome to aggressively substitute > references to the enclosing parent document of any element for any > references that, when resolved according to xml:base, differ from that > xml:base only in ways that deal with normalization and fragment > identifiers. This can only cause confusion if the xml:base in effect > differs from original xml:base of the document (i.e., the URI used to > retrieve the document in the first place) in ways other than the > fragment identifier. You've nailed it. > Note that I'm sidestepping all questions about who is right or wrong. I totally agree, there is no right or wrong here. The established usage of a base URI is so different from what Roy is saying that he shouldn't have changed the RFC in such a way. (The RFC is even an Internet Standard, defined as "a specification that is stable and well-understood.") > The recommendations produced by the feed validator will focus on the > areas where the user is most likely to stumble into this problem. It > seems to me that the largest problem area is at the feed level, and the > recommendation will be to either make xml:base at the feed level match > the URI from which the feed was loaded, or (paradoxically enough) to > reference a resource that you are unlikely to directly reference later > in the document. Referencing a parent directory of any given document > is OK, what's important is that it isn't the document itself. Yes, although I wonder how you would test for "unlikely to directly reference later". > Fair enough? Totally, thanks! -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Tue Aug 16 14:44:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56QK-0005dt-1K for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 14:44:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28082 for ; Tue, 16 Aug 2005 14:44:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GIZOWS083801; Tue, 16 Aug 2005 11:35:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GIZOJK083800; Tue, 16 Aug 2005 11:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GIZOmV083793 for ; Tue, 16 Aug 2005 11:35:24 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 91473 invoked by uid 17064); 16 Aug 2005 18:35:22 -0000 Received: from unknown (HELO [192.168.1.35]) ([83.76.37.213]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2005 18:35:22 -0000 In-Reply-To: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> Cc: David Powell , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 20:35:19 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that in section 5. you should specify that the URI reference MUST NOT be relative or MUST BE absolute (if that is the proper W3C Architecture term). I agree with the point made by David Powell in the thread entitled "More about extensions" [1]. Given that we have this problem I was wondering whether it would not be better to use the link element as I think it permits relative references. Relative references really are *extreemly useful*. I tried to work without them in my BlogEd editor because the Sesame database folk mistakenly thought it was not part of RDF, and it caused me no end of trouble: all those problems vanished as soon as they allowed relative references. So if relative references are allowed in links perhaps the following would be better: Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html On 15 Aug 2005, at 22:31, Mark Nottingham wrote: > > Draft -03 of feed history is now available, at: > http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- > history-03.txt > > Significant changes in this revision include: > - add fh:archive element, to indicate that an entry is an archive > - allow subscription feed to omit fh:stateful if fh:prev is present > - clarified that fh doesn't add ordering semantics, just allows > you to reconstruct state > - cleaned up text, fixed examples, general standards hygiene > > There's going to be at least one more draft, as I neglected to > acknowledge people who have made suggestions and otherwise helped > so far. Sorry! > > -- > Mark Nottingham http://www.mnot.net/ > From owner-atom-syntax@mail.imc.org Tue Aug 16 15:07:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56mX-0000ub-E7 for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:07:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29300 for ; Tue, 16 Aug 2005 15:07:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GIrt6a085055; Tue, 16 Aug 2005 11:53:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GIrtbG085054; Tue, 16 Aug 2005 11:53:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GIrtfL085048 for ; Tue, 16 Aug 2005 11:53:55 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7GJ2dwe006456; Tue, 16 Aug 2005 15:02:40 -0400 Message-ID: <43023641.6050206@intertwingly.net> Date: Tue, 16 Aug 2005 14:53:53 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> In-Reply-To: <43021E53.1060308@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Sam Ruby wrote: > >> Apparently, consuming tools are welcome to aggressively substitute >> references to the enclosing parent document of any element for any >> references that, when resolved according to xml:base, differ from that >> xml:base only in ways that deal with normalization and fragment >> identifiers. This can only cause confusion if the xml:base in effect >> differs from original xml:base of the document (i.e., the URI used to >> retrieve the document in the first place) in ways other than the >> fragment identifier. > > You've nailed it. Cool. Took me long enough. >> Note that I'm sidestepping all questions about who is right or wrong. > > I totally agree, there is no right or wrong here. The established usage > of a base URI is so different from what Roy is saying that he shouldn't > have changed the RFC in such a way. (The RFC is even an Internet > Standard, defined as "a specification that is stable and well-understood.") I'm sure that we can find established usages where the consuming tool has various degrees of "agressiveness". Pure speculation on my part, but now that I have been able to see how limited in scope this issue is, I can see where spec authors might have had trouble outlawing one behavior or another, and decided that publishing a spec within a reasonable timeframe was of greater value than resolving this issue. >> The recommendations produced by the feed validator will focus on the >> areas where the user is most likely to stumble into this problem. It >> seems to me that the largest problem area is at the feed level, and the >> recommendation will be to either make xml:base at the feed level match >> the URI from which the feed was loaded, or (paradoxically enough) to >> reference a resource that you are unlikely to directly reference later >> in the document. Referencing a parent directory of any given document >> is OK, what's important is that it isn't the document itself. > > Yes, although I wonder how you would test for "unlikely to directly > reference later". I will only test for actual references that meet the criteria described at the top of this note. When I encounter such a condition, I will emit a warning containing a one line message accompanied by a link. That link will take the user to a web page that repeats the one line message, provides an explation of that message (probably close to what I said at the top of the page), provide a recommendation (probably close to what I said in the second paragraph above this one), and a link to the feedvalidator mailing list. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Aug 16 15:12:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56rG-00022k-5u for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:12:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29771 for ; Tue, 16 Aug 2005 15:12:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJ10ra085454; Tue, 16 Aug 2005 12:01:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GJ10LO085453; Tue, 16 Aug 2005 12:01:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJ0xo2085435 for ; Tue, 16 Aug 2005 12:00:59 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.174.185]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CFB23A350A; Tue, 16 Aug 2005 15:00:57 -0400 (EDT) In-Reply-To: <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> Cc: David Powell , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 12:00:55 -0700 To: Henry Story X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I very much disagree; relative references should be allowable in simple extensions, and in fact the rationale that Tim gives is the reasoning I assumed regarding Atom extensions; if I had known that the division between simple and complex extensions would be used to justify a constraint on the use of context in simple extensions, I would have objected to it. If you're using something like RDF to model feeds, you already have a number of context-related issues to work through, this isn't an extra burden. I should explicitly allow relative URIs in fh:prev, though. Cheers, On 16/08/2005, at 11:35 AM, Henry Story wrote: > I think that in section 5. you should specify that the URI > reference MUST NOT be relative or > MUST BE absolute (if that is the proper W3C Architecture term). I > agree with the point made by > David Powell in the thread entitled "More about extensions" [1]. > > Given that we have this problem I was wondering whether it would > not be better > to use the link element as I think it permits relative references. > Relative references > really are *extreemly useful*. I tried to work without them in my > BlogEd editor > because the Sesame database folk mistakenly thought it was not part > of RDF, and it caused > me no end of trouble: all those problems vanished as soon as they > allowed relative references. > > So if relative references are allowed in links perhaps the > following would be better: > > > > > Henry Story > > [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html > > > On 15 Aug 2005, at 22:31, Mark Nottingham wrote: > >> >> Draft -03 of feed history is now available, at: >> http://www.ietf.org/internet-drafts/draft-nottingham-atompub- >> feed-history-03.txt >> >> Significant changes in this revision include: >> - add fh:archive element, to indicate that an entry is an archive >> - allow subscription feed to omit fh:stateful if fh:prev is present >> - clarified that fh doesn't add ordering semantics, just allows >> you to reconstruct state >> - cleaned up text, fixed examples, general standards hygiene >> >> There's going to be at least one more draft, as I neglected to >> acknowledge people who have made suggestions and otherwise helped >> so far. Sorry! >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 16 15:21:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5702-0003Oi-Me for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:21:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00549 for ; Tue, 16 Aug 2005 15:21:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJBZ85086497; Tue, 16 Aug 2005 12:11:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GJBZxK086496; Tue, 16 Aug 2005 12:11:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJBYJC086488 for ; Tue, 16 Aug 2005 12:11:35 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.174.185]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2BCC1A3206; Tue, 16 Aug 2005 15:11:34 -0400 (EDT) In-Reply-To: References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <420a6592ab563430ac6a6b412def3285@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom WG Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 12:11:30 -0700 To: Stefan Eissing X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16/08/2005, at 9:17 AM, Stefan Eissing wrote: >>> Ch. 5 similar: "MUST occur unless". If the document is an >>> archive there are only 2 possiblities: either fh:prev is there or >>> not. If not it will always "terminate" the archive list, won't >>> it? You seem to have a (server-side) model in mind which drives >>> the document structure. From a client perspective, there are only >>> the documents and it derives its own model from that. >> >> Not sure what you mean here; are you saying that fh:archive is >> superfluous? > > Currently: > The document first defines "archive documents" and *afterwards* > requires that fh:archive MUST be present in archive documents. > > My proposal: > Introduce fh:archive with the semantics that the server garantuees > that the set of entries in this document will not change over time > if fh:archive is present. A document with fh:archive in it (and its > implied semantics) is then called an "archive document". > > To tackle it from another view: The spec should say "servers MUST > NOT break the promises of fh:archive" instead of saying "archive > documents MUST announce that they do not change". There is possible > harm in breaking the first, but only suboptimal performance in > neglecting the latter case. I made it loose purposefully; I think there are several types of archives out there, and it's likely that further specs are going to come along that talk about the guarantees surrounding persistence, entry deletion, etc. Again, I want to avoid, as much as possible, defining what a feed is in this document, as there are many potential models for feeds. For example, an archive in my blog feed can change for spelling mistakes and updates, but an archive of telephone records used for SOX compliance can't. Mandating a particular definition of what an archive is would necessitate ruling some types of archives out, and that wasn't my main use case for this; rather, it was to make sure that archive feeds (as defined for the purposes of this spec) wouldn't be accidentally subscribed to. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 16 15:41:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57JH-0006O8-KK for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:41:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01394 for ; Tue, 16 Aug 2005 15:41:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJTYX2088541; Tue, 16 Aug 2005 12:29:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GJTYKm088540; Tue, 16 Aug 2005 12:29:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJTYmE088532 for ; Tue, 16 Aug 2005 12:29:34 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 12054 invoked by uid 17064); 16 Aug 2005 19:29:33 -0000 Received: from unknown (HELO [192.168.1.35]) ([83.76.37.213]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2005 19:29:33 -0000 In-Reply-To: <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 21:29:31 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Aug 2005, at 21:00, Mark Nottingham wrote: > > I very much disagree; relative references should be allowable in > simple extensions, and in fact the rationale that Tim gives is the > reasoning I assumed regarding Atom extensions; if I had known that > the division between simple and complex extensions would be used to > justify a constraint on the use of context in simple extensions, I > would have objected to it. The problem is that readers of your xml that wish to store your data in some form other than xml (relational database, triple store, object oriented database, prolog database,...), and that may not at the time of consumption know about your extension will save the content in text, which is all the spec says they should do. Since they don't at the time know the meaning of fh:prev and in particular that it should contain a URI they can't save the absolute URI it represents. All they will be able to save is relative uri which will be meaningless if the context of the original document is lost. > If you're using something like RDF to model feeds, you already have > a number of context-related issues to work through, this isn't an > extra burden. The point of making extensions is that they should be interpretable or at least in part useable by parties that don't understand the extension. RDF has nothing to do with this. (Other than it having some very solid theoretical backing and so being very helpful in thinking about these issues, and also of it having solved quite a few years ago the problems that you are just discovering) > I should explicitly allow relative URIs in fh:prev, though. -1 This is a question of the Atom spec saying that the content of a simple extension element is character data. Yet you are now wishing to put in relative references that have complex semantics not completely understandable without having the original context of the document they appear in. I know it may seem to the writer of an extension as if the meaning of his extension were clear as day, but this will not be the case to all consumers of your extension, and even if your extension becomes world famous, it certainly won't be true for all the other extensions that people will come up with. So I think we should be setting a good example in these first extensions we write. Henry Story > Cheers, > > > On 16/08/2005, at 11:35 AM, Henry Story wrote: > > >> I think that in section 5. you should specify that the URI >> reference MUST NOT be relative or >> MUST BE absolute (if that is the proper W3C Architecture term). I >> agree with the point made by >> David Powell in the thread entitled "More about extensions" [1]. >> >> Given that we have this problem I was wondering whether it would >> not be better >> to use the link element as I think it permits relative references. >> Relative references >> really are *extreemly useful*. I tried to work without them in my >> BlogEd editor >> because the Sesame database folk mistakenly thought it was not >> part of RDF, and it caused >> me no end of trouble: all those problems vanished as soon as they >> allowed relative references. >> >> So if relative references are allowed in links perhaps the >> following would be better: >> >> >> >> >> Henry Story >> >> [1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html >> >> >> On 15 Aug 2005, at 22:31, Mark Nottingham wrote: >> >> >>> >>> Draft -03 of feed history is now available, at: >>> http://www.ietf.org/internet-drafts/draft-nottingham-atompub- >>> feed-history-03.txt >>> >>> Significant changes in this revision include: >>> - add fh:archive element, to indicate that an entry is an archive >>> - allow subscription feed to omit fh:stateful if fh:prev is >>> present >>> - clarified that fh doesn't add ordering semantics, just allows >>> you to reconstruct state >>> - cleaned up text, fixed examples, general standards hygiene >>> >>> There's going to be at least one more draft, as I neglected to >>> acknowledge people who have made suggestions and otherwise helped >>> so far. Sorry! >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >> >> >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > From owner-atom-syntax@mail.imc.org Tue Aug 16 16:00:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57bY-0001Pv-Ie for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:00:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03063 for ; Tue, 16 Aug 2005 16:00:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJo38n090580; Tue, 16 Aug 2005 12:50:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GJo3T4090579; Tue, 16 Aug 2005 12:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJo2iS090563 for ; Tue, 16 Aug 2005 12:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E57Ri-0007Hw-3s; Tue, 16 Aug 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-11.txt Message-Id: Date: Tue, 16 Aug 2005 15:50:02 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : R. Sayre, M. Nottingham Filename : draft-ietf-atompub-format-11.txt Pages : 56 Date : 2005-8-16 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-16132128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-16132128.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Tue Aug 16 16:04:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57fo-0003IU-6j for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:04:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04443 for ; Tue, 16 Aug 2005 16:04:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJoY9V090674; Tue, 16 Aug 2005 12:50:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GJoYvZ090673; Tue, 16 Aug 2005 12:50:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GJoXCE090656 for ; Tue, 16 Aug 2005 12:50:33 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so11386nzi for ; Tue, 16 Aug 2005 12:50:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uEaHHvLLTf6ITD+cAA3I9bn4U4ny79PytqPSK0bnLu80It+AO3vPQAh1feAp3e11UkIHpbE4HMp+q9HaSnuzm12WKwgvKArpzucB8jDLgnYD38orzW8axEalLBjLlVSCpt3FQYuMjVTD1Dig1wWz1D4/WhC2SdSUUt82hTouXPI= Received: by 10.36.2.9 with SMTP id 9mr5571733nzb; Tue, 16 Aug 2005 12:50:27 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Tue, 16 Aug 2005 12:50:27 -0700 (PDT) Message-ID: <68fba5c505081612505f0c4a5f@mail.gmail.com> Date: Tue, 16 Aug 2005 15:50:27 -0400 From: Robert Sayre To: Henry Story Subject: Re: Feed History -03 Cc: Mark Nottingham , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7GJoXCE090668 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/16/05, Henry Story wrote: > > > On 16 Aug 2005, at 21:00, Mark Nottingham wrote: > > > > I very much disagree; relative references should be allowable in > > simple extensions, and in fact the rationale that Tim gives is the > > reasoning I assumed regarding Atom extensions; if I had known that > > the division between simple and complex extensions would be used to > > justify a constraint on the use of context in simple extensions, I > > would have objected to it. > > The problem is that readers of your xml that wish to store your data > in some form other than xml (relational database, triple store, > object oriented database, prolog database,...), and that may > not at the time of consumption know about your extension will save > the content in text, which is all the spec says they should do. Since > they don't at the time know the meaning of fh:prev and > in particular that it should contain a URI they can't save the > absolute URI it represents. > All they will be able to save is relative uri which will be > meaningless if the context of the > original document is lost. The app should store the relative URI, and it shouldn't lose the context. > > > If you're using something like RDF to model feeds, you already have > > a number of context-related issues to work through, this isn't an > > extra burden. > > The point of making extensions is that they should be interpretable > or at least in part useable > by parties that don't understand the extension. It still is. > This is a question of the Atom spec saying that the content of a > simple extension element is character data. Yet you are now wishing > to put in relative references that have complex semantics > not completely understandable without having the original context of > the document they appear in. Lots of extensions will be like this. What's one itunes extenstion without the others? :) In summary, I agree with Mark. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 16 17:13:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58k8-0003kD-8P for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:13:08 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12741 for ; Tue, 16 Aug 2005 17:13:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GL5gwb096302; Tue, 16 Aug 2005 14:05:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GL5gwp096301; Tue, 16 Aug 2005 14:05:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GL5fOU096294 for ; Tue, 16 Aug 2005 14:05:42 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20050816210535.YABZ9239.mta09-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Tue, 16 Aug 2005 22:05:35 +0100 Received: from cpc3-stok1-5-0-cust152.bagu.cable.ntl.com ([82.11.128.152]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20050816210535.FGWO12116.aamta10-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust152.bagu.cable.ntl.com>; Tue, 16 Aug 2005 22:05:35 +0100 Date: Tue, 16 Aug 2005 22:05:33 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1732718323.20050816220533@djpowell.net> To: Mark Nottingham CC: Henry Story , David Powell , Atom Syntax Subject: Re: Feed History -03 In-Reply-To: <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tuesday, August 16, 2005, 8:00:55 PM, Mark Nottingham wrote: > I very much disagree; relative references should be allowable in > simple extensions, and in fact the rationale that Tim gives is the > reasoning I assumed regarding Atom extensions; if I had known that > the division between simple and complex extensions would be used to > justify a constraint on the use of context in simple extensions, I > would have objected to it. The constraint on the context is the main reason for the distinction between Simple and Structured extensions. Why else would we define two classes of extension if it didn't affect the processing model, and why else would we make Simple extensions language-insensitive (a very similar constraint on context, which is spelt out quite clearly, and therefore presumably not disputed)? > If you're using something like RDF to model feeds, you already have a > number of context-related issues to work through, this isn't an extra > burden. Yeah a few, Structured extensions are obviously a big one (where the lang and base context do need to be preserved). The reason for there being two classes of extensions was to reduce this burden, so that implementations based on RDBMS, RDF, or whatever can process a common class of unknown extensions generically. The burden of requiring the lang and base context to be preserved in a legacy CMS database along with each extension, on the off-chance that they might be significant seemed to great. If you think that the context shouldn't be constrained, then maybe you're right - maybe the constraint was unnecessary; but I think that the current spec does impose that constraint, albeit too subtly, in Section 6.4.1 paragraph 2, and that constraint is what I originally intended. If a significant number of people have not picked up on this (the lack of rationale probably didn't help), and would have disputed it, then I guess that we have a problem. -- Dave From owner-atom-syntax@mail.imc.org Tue Aug 16 17:24:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58uw-0006Os-VM for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:24:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13319 for ; Tue, 16 Aug 2005 17:24:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GLJd44097287; Tue, 16 Aug 2005 14:19:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GLJdLp097286; Tue, 16 Aug 2005 14:19:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GLJcqY097277 for ; Tue, 16 Aug 2005 14:19:39 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so22340nzi for ; Tue, 16 Aug 2005 14:19:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SPpM/So7E5cWeLkPoFrDgE6nSuQsKkWtdbS/9V8aAX1t+jngr0Lm49mrgxfjqZo0WE7tfU9xGs3Eh/031X39Ti1x7+rTfYT8yBPvgiHGzhMWCEvsPlabsX7pjhBzFR16B+ixLgjdFuPJBQcf9k5PWAwH139Mkse/xWZSVxQrS2E= Received: by 10.36.250.19 with SMTP id x19mr5647347nzh; Tue, 16 Aug 2005 14:19:33 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Tue, 16 Aug 2005 14:19:33 -0700 (PDT) Message-ID: <68fba5c505081614197f96873f@mail.gmail.com> Date: Tue, 16 Aug 2005 17:19:33 -0400 From: Robert Sayre To: David Powell Subject: Re: Feed History -03 Cc: Mark Nottingham , Henry Story , Atom Syntax In-Reply-To: <1732718323.20050816220533@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <1732718323.20050816220533@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7GLJdqY097281 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/16/05, David Powell wrote: > The reason for there > being two classes of extensions was to reduce this burden, so that > implementations based on RDBMS, RDF, or whatever can process a common > class of unknown extensions generically. The burden of requiring the > lang and base context to be preserved in a legacy CMS database along > with each extension, on the off-chance that they might be significant > seemed to great. Um, this makes no sense to me. It seems smart to preserve the entry from which an extension came. If the extension has no base URI itself, the one from the entry applies, so you can still find it if you think you need it later. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 16 18:07:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59aX-0000AP-RP for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 18:07:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15546 for ; Tue, 16 Aug 2005 18:07:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GLuNPd001409; Tue, 16 Aug 2005 14:56:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GLuNPH001408; Tue, 16 Aug 2005 14:56:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GLuNCW001402 for ; Tue, 16 Aug 2005 14:56:23 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 63404 invoked by uid 17064); 16 Aug 2005 21:56:22 -0000 Received: from unknown (HELO [192.168.1.35]) ([83.76.37.213]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 Aug 2005 21:56:22 -0000 In-Reply-To: <68fba5c505081612505f0c4a5f@mail.gmail.com> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> Cc: Mark Nottingham , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 23:56:19 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Aug 2005, at 21:50, Robert Sayre wrote: > On 8/16/05, Henry Story wrote: >> On 16 Aug 2005, at 21:00, Mark Nottingham wrote: >>> I very much disagree; relative references should be allowable in >>> simple extensions, and in fact the rationale that Tim gives is the >>> reasoning I assumed regarding Atom extensions; if I had known that >>> the division between simple and complex extensions would be used to >>> justify a constraint on the use of context in simple extensions, I >>> would have objected to it. >> >> The problem is that readers of your xml that wish to store your data >> in some form other than xml (relational database, triple store, >> object oriented database, prolog database,...), and that may >> not at the time of consumption know about your extension will save >> the content in text, which is all the spec says they should do. Since >> they don't at the time know the meaning of fh:prev and >> in particular that it should contain a URI they can't save the >> absolute URI it represents. >> All they will be able to save is relative uri which will be >> meaningless if the context of the >> original document is lost. > > The app should store the relative URI, and it shouldn't lose the > context. relative URI? The application we are speaking about knows nothing of a relative uri. All you have inside your Simple Extension Element is text! See the spec 6.4.1. An application that does not know your extension cannot know that the text inside your extension is to be interpreted as a relative uri. So what you are saying is that any application that wants to process atom with extension elements has to keep the full context of the document in which they found the extension element, even if the document is a 100s of Megabytes long, and even if there is only one extension element inside of it! Or take the case of code that wants to place the feed inside some other xml, which has a base element. What is it to do when it finds an extension element it does not understand? >> >>> If you're using something like RDF to model feeds, you already have >>> a number of context-related issues to work through, this isn't an >>> extra burden. >>> >> >> The point of making extensions is that they should be interpretable >> or at least in part useable >> by parties that don't understand the extension. >> > > It still is. No they are not! See the 2 examples above. >> This is a question of the Atom spec saying that the content of a >> simple extension element is character data. Yet you are now wishing >> to put in relative references that have complex semantics >> not completely understandable without having the original context of >> the document they appear in. > > Lots of extensions will be like this. What's one itunes extenstion > without the others? :) ? > In summary, I agree with Mark. You agree to accept the problems that go with his position, yes. But why bother when there clearly is an easy solution to the problem that works with the current atom format and which I outlined earlier, namely using the link element. I suggested writing the next tag like this: This clearly allows relative uris (if I am not mistaken) without any of the problems we have with the simple extension elements. And it seems to be exactly this type of thing that the link element was designed to do. Henry Story http://blogs.sun.com/roller/page/bblfish/ > Robert Sayre > From owner-atom-syntax@mail.imc.org Tue Aug 16 18:13:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59gw-0001Z1-Vj for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 18:13:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16156 for ; Tue, 16 Aug 2005 18:13:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GM5LWZ001951; Tue, 16 Aug 2005 15:05:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GM5L1T001950; Tue, 16 Aug 2005 15:05:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GM5K01001935 for ; Tue, 16 Aug 2005 15:05:21 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so27178nzi for ; Tue, 16 Aug 2005 15:05:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mk7zE05Aw0cd4iqnZO9TyK0Q6GjgiPExO54XtPdeNjiJm/pRlFtkwE3bhmKIBPqYzl0xjTyDPN57ts7MFbfFHj9Rid4bGO5odEa1yqOfKG1i+NI3VQL1o+UguCBdNh5OyjdgHP1akcRZdcA9T3W1LNQpZAK01wOfaRppnocv8g0= Received: by 10.36.3.6 with SMTP id 6mr30432nzc; Tue, 16 Aug 2005 15:05:15 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Tue, 16 Aug 2005 15:05:15 -0700 (PDT) Message-ID: <68fba5c50508161505444ea7c1@mail.gmail.com> Date: Tue, 16 Aug 2005 18:05:15 -0400 From: Robert Sayre To: Henry Story Subject: Re: Feed History -03 Cc: Mark Nottingham , Atom Syntax In-Reply-To: <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7GM5L01001945 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/16/05, Henry Story wrote: > An application that does not know your extension cannot know that the > text inside > your extension is to be interpreted as a relative uri. So what you > are saying is > that any application that wants to process atom with extension > elements has to keep > the full context of the document in which they found the extension > element, No, Henry, that's not what I'm saying. I'm saying you do have to keep the Base URI of an atom:entry or atom:feed around, for a variety of reasons. The app should keep the extension text as it was entered. > I suggested writing the next tag like this: > > That's what I would do, too. Not my spec, though. Mainly so I could put a title in that said "Entries from August" or whatever. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Aug 16 18:22:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59pO-0003D8-Bd for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 18:22:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16996 for ; Tue, 16 Aug 2005 18:22:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GMEl1E002674; Tue, 16 Aug 2005 15:14:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GMElw5002673; Tue, 16 Aug 2005 15:14:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GMEkGr002666 for ; Tue, 16 Aug 2005 15:14:46 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.174.185]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 71870A320B; Tue, 16 Aug 2005 18:14:45 -0400 (EDT) In-Reply-To: <68fba5c50508161505444ea7c1@mail.gmail.com> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> <68fba5c50508161505444ea7c1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> Cc: Henry Story , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History -03 Date: Tue, 16 Aug 2005 15:14:42 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16/08/2005, at 3:05 PM, Robert Sayre wrote: >> I suggested writing the next tag like this: >> >> > > That's what I would do, too. Not my spec, though. Mainly so I could > put a title in that said "Entries from August" or whatever. For that matter, if Henry's interpretation were correct, the element could be ./archives/archive1.atom And Atom processors would magically know that XML Base applies to the URI therein. It's the magic that I object to; inferring the applicability of context based on the presence or absence of other markup isn't good practice, and will lead to practical problems. E.g., what if I want to have an optional attribute on an empty element? Is it "simple" or "complex"? This interpretation of extensions seems very fragile to me. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 16 18:45:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ABs-0008UE-Bo for atompub-archive@megatron.ietf.org; Tue, 16 Aug 2005 18:45:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17954 for ; Tue, 16 Aug 2005 18:45:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GMe5cJ004302; Tue, 16 Aug 2005 15:40:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7GMe5RW004301; Tue, 16 Aug 2005 15:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7GMe4H7004290 for ; Tue, 16 Aug 2005 15:40:04 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20050816223958.GLX9239.mta09-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com>; Tue, 16 Aug 2005 23:39:58 +0100 Received: from cpc3-stok1-5-0-cust152.bagu.cable.ntl.com ([82.11.128.152]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20050816223958.DKKW17166.aamta12-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust152.bagu.cable.ntl.com>; Tue, 16 Aug 2005 23:39:58 +0100 Date: Tue, 16 Aug 2005 23:39:56 +0100 From: David Powell X-Mailer: The Bat! (v3.51.10) Professional X-Priority: 3 (Normal) Message-ID: <1877306706.20050816233956@djpowell.net> To: Mark Nottingham CC: Robert Sayre , Henry Story , Atom Syntax Subject: Re: Feed History -03 In-Reply-To: <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> <68fba5c50508161505444ea7c1@mail.gmail.com> <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tuesday, August 16, 2005, 11:14:42 PM, Mark Nottingham wrote: > E.g., what if I want to have an optional attribute on an empty > element? Is it "simple" or "complex"? FYI: The first draft of the proposal used an atom:notation="structured" attribute on the extension to indicate the extension class which avoided that problem, but I think it was considered to be too crufty. -- Dave From owner-atom-syntax@mail.imc.org Wed Aug 17 04:25:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5JES-0000BR-Vb for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 04:25:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14791 for ; Wed, 17 Aug 2005 04:25:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7H8F652020995; Wed, 17 Aug 2005 01:15:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7H8F6Uc020994; Wed, 17 Aug 2005 01:15:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7H8F1lO020932 for ; Wed, 17 Aug 2005 01:15:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-100.dti.cegetel.net [217.19.192.100]) by smtp.cegetel.net (Postfix) with SMTP id EC4A91A444C; Wed, 17 Aug 2005 10:14:55 +0200 (CEST) Received: from 194.250.147.107 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Wed, 17 Aug 2005 10:14:56 +0200 (CEST) Message-ID: <1084.194.250.147.107.1124266496.squirrel@ssl-webmail.sitadelle.com> Date: Wed, 17 Aug 2005 10:14:56 +0200 (CEST) Subject: Re: Feed History -03 From: "Thomas Broyer" To: In-Reply-To: <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> <68fba5c50508161505444ea7c1@mail.gmail.com> <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> X-Priority: 3 Importance: Normal Cc: , , X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Mark Nottingham wrote: > For that matter, if Henry's interpretation were correct, the element > could be > > ./archives/archive1.atom > > And Atom processors would magically know that XML Base applies to the > URI therein. It's the magic that I object to; inferring the > applicability of context based on the presence or absence of other > markup isn't good practice, and will lead to practical problems. E.g., > what if I want to have an optional attribute on an empty > element? Is it "simple" or "complex"? FYI, I already rose this up in late May [1]. That was before format-09... [1] http://www.imc.org/atom-syntax/mail-archive/msg15863.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Aug 17 07:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5LvO-0008BG-Pq for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 07:17:39 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22008 for ; Wed, 17 Aug 2005 07:17:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HBAMqQ085214; Wed, 17 Aug 2005 04:10:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HBAMNb085212; Wed, 17 Aug 2005 04:10:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HBAKYi085194 for ; Wed, 17 Aug 2005 04:10:22 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 32511 invoked by uid 17064); 17 Aug 2005 11:10:19 -0000 Received: from unknown (HELO [192.168.1.35]) ([81.62.205.193]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 17 Aug 2005 11:10:19 -0000 In-Reply-To: <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> <68fba5c50508161505444ea7c1@mail.gmail.com> <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C14BE7D-E5E7-49BB-B251-BAB776AEDDD3@bblfish.net> Cc: Robert Sayre , Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Feed History -03 Date: Wed, 17 Aug 2005 13:10:07 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 Aug 2005, at 00:14, Mark Nottingham wrote: > On 16/08/2005, at 3:05 PM, Robert Sayre wrote: > >>> I suggested writing the next tag like this: >>> >>> >>> >> >> That's what I would do, too. Not my spec, though. Mainly so I could >> put a title in that said "Entries from August" or whatever. > > For that matter, if Henry's interpretation were correct, the > element could be > > ./archives/archive1.atom > > And Atom processors would magically know that XML Base applies to > the URI therein. It's the magic that I object to; inferring the > applicability of context based on the presence or absence of other > markup isn't good practice, and will lead to practical problems. > E.g., what if I want to have an optional attribute on an empty > element? Is it "simple" or "complex"? Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? Clearly if the extensions themselves were to use only xlink:link elements that would be easy. (though atom itself does not give a good example by not following that principle). Is there a place that parsers can get information where they can automatically tell that an attribute is a xlink:link copycat? Or how do they tell that the content of an element is a URI? Can DTDs or RelaxNG files help? If they could help, would they be retrievable mechanically by a processor of xml to help it work out how to deal with relative references? Anyway to summarise: if you don't want to use the atom:link element then perhaps it would be best to use the xlink:link attributes. I have only read that spec quickly [1] but this would mean that the following would widely be understood to work with the xml:base. Henry Story [1] http://www.w3.org/TR/2001/REC-xlink-20010627/ > > This interpretation of extensions seems very fragile to me. > > -- > Mark Nottingham http://www.mnot.net/ > From owner-atom-syntax@mail.imc.org Wed Aug 17 10:50:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PEw-0001bS-T7 for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:50:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05301 for ; Wed, 17 Aug 2005 10:50:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HEeZwe054151; Wed, 17 Aug 2005 07:40:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HEeZUd054149; Wed, 17 Aug 2005 07:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HEeYWY054143 for ; Wed, 17 Aug 2005 07:40:34 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7HEeXTW029104 for ; Wed, 17 Aug 2005 08:40:33 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILD00BYSFFHUK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 17 Aug 2005 08:40:30 -0600 (MDT) Received: from [192.168.1.24] ([216.113.202.7]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILD003COFFGYW@mail.sun.net> for atom-syntax@imc.org; Wed, 17 Aug 2005 08:40:29 -0600 (MDT) Date: Wed, 17 Aug 2005 07:40:28 -0700 From: Tim Bray Subject: Re: Feed History -03 In-reply-to: <3C14BE7D-E5E7-49BB-B251-BAB776AEDDD3@bblfish.net> To: Henry Story Cc: Mark Nottingham , Robert Sayre , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <7B382FB1-DB87-4DC2-A192-F37C94790AF3@mnot.net> <0CEBF8DB-9B07-4D44-B654-6DA247B5F688@bblfish.net> <7A2F334F-0027-458D-8E9A-A353D33E91AF@mnot.net> <68fba5c505081612505f0c4a5f@mail.gmail.com> <2576D351-09C0-4CA1-B0B7-D5F92D7CBF66@bblfish.net> <68fba5c50508161505444ea7c1@mail.gmail.com> <78792FB9-079A-4209-90D3-AE29BBF27685@mnot.net> <3C14BE7D-E5E7-49BB-B251-BAB776AEDDD3@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 17, 2005, at 4:10 AM, Henry Story wrote: > Yes. I agree the problem also exists for complex extensions. My > question is the following: > > How can a parser that parses atom and unknown extensions, know when > to apply the xml base to > an extension element automatically? It can't. > Anyway to summarise: if you don't want to use the atom:link element > then perhaps it would > be best to use the xlink:link attributes. I have only read that > spec quickly [1] but this would > mean that the following > > That would work. I haven't been following this discussion closely enough to understand why there's resistance to -Tim From owner-atom-syntax@mail.imc.org Wed Aug 17 13:20:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ram-0001OK-U9 for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 13:20:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12893 for ; Wed, 17 Aug 2005 13:20:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HHEksm067883; Wed, 17 Aug 2005 10:14:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HHEk7b067882; Wed, 17 Aug 2005 10:14:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HHEjGA067852 for ; Wed, 17 Aug 2005 10:14:45 -0700 (PDT) (envelope-from apache@newodin.ietf.org) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E5RUy-0001WJ-57; Wed, 17 Aug 2005 13:14:44 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , atompub mailing list , atompub chair , atompub chair Subject: Protocol Action: 'The Atom Syndication Format' to Proposed Standard Message-Id: Date: Wed, 17 Aug 2005 13:14:44 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has approved the following document: - 'The Atom Syndication Format ' as a Proposed Standard This document is the product of the Atom Publishing Format and Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt Technical Summary: This document describes the Atom format for syndication. It is XML-based and is considered to be the successor to the earlier RSS formats. Its primary use is for web-based content, but is expected to be used for non-web content as well, such as personal news feeds. Working Group Summary: Some members of the working group remain unenthusiastic about some sections of the document, but the chairs strongly believe that there is rough (or better) consensus in support of the document as a whole. For some of the parts with the most contention, there cannot be more than very rough consensus due to basic differences in the way people would design parts of the format, particularly given that we have many models in existence with the different flavors of RSS. For some parts of the document, there is contention about whether or not a particular item should or should not be in the Atom core versus being an extension. For some parts, there is contention whether there should be MUST/SHOULD/MAY leeway for content creators in the presence or absence of an element, or the semantic content of an element; the group really pushed RFC 2119 around during the past few months. Protocol Quality Scott Hollenbeck and the XML Directorate have reviewed the specification for the IESG. Test implementations have confirmed basic protocol soundness. From owner-atom-syntax@mail.imc.org Wed Aug 17 13:41:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Rum-0007vA-4m for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 13:41:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14065 for ; Wed, 17 Aug 2005 13:41:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HHZotq069505; Wed, 17 Aug 2005 10:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HHZoPa069504; Wed, 17 Aug 2005 10:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HHZnjf069490 for ; Wed, 17 Aug 2005 10:35:49 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 3AE1A72403C for ; Wed, 17 Aug 2005 13:35:44 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'atompub mailing list'" Subject: RE: Protocol Action: 'The Atom Syndication Format' to Proposed Standard Date: Wed, 17 Aug 2005 13:35:41 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: Thread-Index: AcWjUVtWI6dzq2JvTA2tW32e4iWOawAAIJ5A Message-Id: <20050817173544.3AE1A72403C@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is excellent news! Finally, we have an openly and formally defined standard for syndication. Wonderful! bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 17 16:10:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5UFB-00085L-Dh for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 16:10:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26827 for ; Wed, 17 Aug 2005 16:10:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HK1V3f084819; Wed, 17 Aug 2005 13:01:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HK1VQd084818; Wed, 17 Aug 2005 13:01:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HK1U5G084812 for ; Wed, 17 Aug 2005 13:01:30 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout11/MantshX 4.0) with ESMTP id j7HK1UNS014186 for ; Wed, 17 Aug 2005 13:01:30 -0700 (PDT) Received: from [10.0.0.100] (fujita.plus.com [84.92.128.107]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j7HK1QOs015334 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 17 Aug 2005 13:01:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <20050817173544.3AE1A72403C@mail.pubsub.com> References: <20050817173544.3AE1A72403C@mail.pubsub.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <807138CB-8BC9-4600-9FCD-84E0AD97A9BB@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Protocol Action: 'The Atom Syndication Format' to Proposed Standard Date: Wed, 17 Aug 2005 21:01:24 +0100 To: atom-syntax X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rar! On 17 Aug 2005, at 6:35 pm, Bob Wyman wrote: > > This is excellent news! Finally, we have an openly and formally > defined > standard for syndication. Wonderful! > > bob wyman > > From owner-atom-syntax@mail.imc.org Wed Aug 17 18:09:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5W5n-0007KN-0z for atompub-archive@megatron.ietf.org; Wed, 17 Aug 2005 18:09:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05904 for ; Wed, 17 Aug 2005 18:08:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HLxj27092988; Wed, 17 Aug 2005 14:59:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7HLxjgO092987; Wed, 17 Aug 2005 14:59:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7HLxhAk092978 for ; Wed, 17 Aug 2005 14:59:43 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so178834nzb for ; Wed, 17 Aug 2005 14:59:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=DphponCbrc01qG9skRErhZWp8AyB8u8Sv4bp8xX6fLvzoaeFYit4Mfw/G/MXsT+7R23KXWGa5B6sOSr9GHVOvaVYiyrXYA0dM9GbrahZ5lJs6Tk6IhtTilqfghlfeIKLDN+mK2ROoXisjPnqYxMAxS6v0HMPsOYu0rkWeqzm09k= Received: by 10.36.247.20 with SMTP id u20mr217991nzh; Wed, 17 Aug 2005 14:59:37 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id c1sm257179nzd.2005.08.17.14.59.37; Wed, 17 Aug 2005 14:59:37 -0700 (PDT) Message-ID: <4303B344.5080908@gmail.com> Date: Wed, 17 Aug 2005 14:59:32 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: FYI: Expires Extension Draft 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: Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt Example: ... 2005-08-16T12:00:00Z ... or ... 2005-08-16T12:00:00Z 20000 ... This is not to be used for caching of Atom documents; nor is it to be used as a mechanism for scheduling updates of local copies of Atom documents. - James From owner-atom-syntax@mail.imc.org Thu Aug 18 07:50:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iuS-00021P-If for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 07:50:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28522 for ; Thu, 18 Aug 2005 07:50:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IBhBhm079650; Thu, 18 Aug 2005 04:43:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IBhBQv079649; Thu, 18 Aug 2005 04:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IBhA5p079637 for ; Thu, 18 Aug 2005 04:43:10 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id AC30B4EED8 for ; Thu, 18 Aug 2005 07:43:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <37C0C935-265C-4A37-B4DA-FEEF93B24EAB@w3.org> From: Karl Dubost Subject: Re: Protocol Action: 'The Atom Syndication Format' to Proposed Standard Date: Thu, 18 Aug 2005 07:43:08 -0400 To: atompub mailing list X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7IBhB5p079643 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 ietf.org id HAA28522 Le 2005-08-17 =E0 13:14, The IESG a =E9crit : > The IESG has approved the following document: > - 'The Atom Syndication Format ' > as a Proposed Standard Congratulations for the good work. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Thu Aug 18 10:37:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lW2-0002N3-JH for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:37:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09187 for ; Thu, 18 Aug 2005 10:37:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IENbum032220; Thu, 18 Aug 2005 07:23:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IENbhE032219; Thu, 18 Aug 2005 07:23:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IENaWU032210 for ; Thu, 18 Aug 2005 07:23:36 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j7IENXCA010811; Thu, 18 Aug 2005 10:23:33 -0400 (EDT) Message-ID: <430499E4.5070109@intertwingly.net> Date: Thu, 18 Aug 2005 10:23:32 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre CC: atom-syntax@imc.org Subject: Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-03.txt] References: <42F914DE.2030706@jabber.org> In-Reply-To: <42F914DE.2030706@jabber.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Peter Saint-Andre wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Transporting Atom Notifications over the > Extensible Messaging and Presence Protocol (XMPP) > Author(s) : P. Saint-Andre, et al. > Filename : draft-saintandre-atompub-notify-03.txt > Pages : 14 > Date : 2005-8-9 Validating the examples I find in that document, modified and issued are not valid, and updated is missing. Also it is recommended that source elements contain an id element, and that entries contain some textual content (either in a summary or in content). - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Aug 18 11:48:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mcb-0005i6-Jz for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 11:48:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13428 for ; Thu, 18 Aug 2005 11:47:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IFf5Eq038721; Thu, 18 Aug 2005 08:41:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IFf5Lq038720; Thu, 18 Aug 2005 08:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IFf4AE038709 for ; Thu, 18 Aug 2005 08:41:04 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 8243F443647; Thu, 18 Aug 2005 09:41:13 -0600 (MDT) Message-ID: <4304AC19.1080002@jabber.org> Date: Thu, 18 Aug 2005 09:41:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby Cc: atom-syntax@imc.org Subject: Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-03.txt] References: <42F914DE.2030706@jabber.org> <430499E4.5070109@intertwingly.net> In-Reply-To: <430499E4.5070109@intertwingly.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050502090904010800030400" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms050502090904010800030400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Peter Saint-Andre wrote: > >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> Title : Transporting Atom Notifications over the >> Extensible Messaging and Presence Protocol (XMPP) >> Author(s) : P. Saint-Andre, et al. >> Filename : draft-saintandre-atompub-notify-03.txt >> Pages : 14 >> Date : 2005-8-9 > > > Validating the examples I find in that document, modified and issued are > not valid, and updated is missing. Also it is recommended that source > elements contain an id element, and that entries contain some textual > content (either in a summary or in content). Thanks, I'll clean those up. Peter --------------ms050502090904010800030400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC BPUwggLdoAMCAQICAwEjfTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA1 MTcxNzQ2MDBaFw0wNjA1MTcxNzQ2MDBaMEIxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6QaezyuQyuya0zB98ew+fDDeO6dbkFE1Td2OrePzTOuSMNHH1 kvpAxpC7m9WtSeeQ874XC9qmPxBurEILQYZrA/IJNUR+kWvJzAJLJK/62xOCOuDuNjLXKv5F BJEeg/uDpiq6K7yfsLcwg5wkxmIGsajYR+maGDlqV7aJeMuTcRTeNHNIBliwToPlIRvQfJbP B3D4tCInHxWeg5BmyqXZgpEPdJ1hyoHB+YvA/0YKAb1Fq9Fq2n6ZC0O70ndkx++OXw65kkYi m6N/dHQ9xjtpOOk6cQu+SKoL2BfU8kBp9bSmIUymn+KqUdwTcge4vFieJ1lWmtMsKUTbLbgh 0P9ZAgMBAAGjgbwwgbkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlv dXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNl cnQub3JnMB0GA1UdEQQWMBSBEnN0cGV0ZXJAamFiYmVyLm9yZzANBgkqhkiG9w0BAQQFAAOC AgEAk+5v9P2B9Zher5QMtmGRSqg+Dkmd2xMoBjPItsR2FFS6waXf3Hv82n4W//9HzM+zAuKv a0kzHY9IHCqcpRVBAqKpN6a6VHb6ZmtwKtj38wmLwMUIqnfvEx4AvP8QJHERLRVn8JL801QT 8Nt1y/6LaOKkFiQUZGvP5m6plXHx2DqL2gfAtZ/VSivSTzkJp3XyDnL04TdKFMY6vPvoT1Ub d48KW+ZA1NE1+h6gxr4jQVUExKeKB25RoxZMXyMqbawnzJZYl2fEkYgQVWVpPZO6NC9u45u4 kyOXNaLjiQwLpCvZj6x87YOQKn1YyiIWXSUFU4ArsaR/BvtVb53IKYE2LE8dPqq/fn1iMCb4 qLesxc+SQWAQB/xiDlVA00eJq+Ulyq4KTFnbARWHgXOqLUo9Uu+GsiK8L6WLf4vr2F8dhDwa tfw7oGjGmGJd0ZO/Yt3Wp7ytutsM+4I3ewlQyRWsXx6zcSHN43FUFZpCJxrfD1k1t9z/MJy/ d2zx7mjjbjcfTykIi8taC2UwdMBAbpNmH4gh+VnrEPgYHOONwBTqL/dfW0Px5pa0Fv/WU/VQ gYep9RLmdDYcwR2bn9XLdVDngMHHTr3Z9LNl1VfQnZg2wi2wvfIrrE0gOtJD7dMPl64Un2Tv L0bvyJrhkiKKdFACad+aOcw1pyWIiDixoYZPJi8wggT1MIIC3aADAgECAgMBI30wDQYJKoZI hvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDUwNTE3MTc0NjAwWhcNMDYwNTE3MTc0NjAw WjBCMR0wGwYDVQQDExRKLiBQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3Rw ZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAukGns8rk MrsmtMwffHsPnww3junW5BRNU3djq3j80zrkjDRx9ZL6QMaQu5vVrUnnkPO+Fwvapj8QbqxC C0GGawPyCTVEfpFrycwCSySv+tsTgjrg7jYy1yr+RQSRHoP7g6Yquiu8n7C3MIOcJMZiBrGo 2Efpmhg5ale2iXjLk3EU3jRzSAZYsE6D5SEb0HyWzwdw+LQiJx8VnoOQZsql2YKRD3SdYcqB wfmLwP9GCgG9RavRatp+mQtDu9J3ZMfvjl8OuZJGIpujf3R0PcY7aTjpOnELvkiqC9gX1PJA afW0piFMpp/iqlHcE3IHuLxYnidZVprTLClE2y24IdD/WQIDAQABo4G8MIG5MAwGA1UdEwEB /wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3Ig RlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYw JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAdBgNVHREEFjAUgRJzdHBl dGVyQGphYmJlci5vcmcwDQYJKoZIhvcNAQEEBQADggIBAJPub/T9gfWYXq+UDLZhkUqoPg5J ndsTKAYzyLbEdhRUusGl39x7/Np+Fv//R8zPswLir2tJMx2PSBwqnKUVQQKiqTemulR2+mZr cCrY9/MJi8DFCKp37xMeALz/ECRxES0VZ/CS/NNUE/Dbdcv+i2jipBYkFGRrz+ZuqZVx8dg6 i9oHwLWf1Uor0k85Cad18g5y9OE3ShTGOrz76E9VG3ePClvmQNTRNfoeoMa+I0FVBMSnigdu UaMWTF8jKm2sJ8yWWJdnxJGIEFVlaT2TujQvbuObuJMjlzWi44kMC6Qr2Y+sfO2DkCp9WMoi Fl0lBVOAK7Gkfwb7VW+dyCmBNixPHT6qv359YjAm+Ki3rMXPkkFgEAf8Yg5VQNNHiavlJcqu CkxZ2wEVh4Fzqi1KPVLvhrIivC+li3+L69hfHYQ8GrX8O6BoxphiXdGTv2Ld1qe8rbrbDPuC N3sJUMkVrF8es3EhzeNxVBWaQica3w9ZNbfc/zCcv3ds8e5o4243H08pCIvLWgtlMHTAQG6T Zh+IIflZ6xD4GBzjjcAU6i/3X1tD8eaWtBb/1lP1UIGHqfUS5nQ2HMEdm5/Vy3VQ54DBx069 2fSzZdVX0J2YNsItsL3yK6xNIDrSQ+3TD5euFJ9k7y9G78ia4ZIiinRQAmnfmjnMNacliIg4 saGGTyYvMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwEjfTAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MTgxNTQx MTNaMCMGCSqGSIb3DQEJBDEWBBSfNzH2YjbKAEmFjWimPUB6+w7/AzBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB I30wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBI30wDQYJKoZIhvcN AQEBBQAEggEAtn35uRWlh1JODklzislKWrEAFAbT5h4SCU2lKF5LDIEe5+5QiuRGci9e5z8R qUizTIdA4CxXpD7vLf2ooVXrOP+0+0UFKEOphGonnKtqAXaW69kz5xC0zAFbxnRT9oAYybsE 1o/cGg6B7tI46L0coDayU9X283ka/E9wumrtzy9Gq5YfkKWFOCMI5rj/vXTAkBwfKLNGUxKc H0o9HraRvTnKg3QBQogeAqfEuQ4wHMoPMXBzU40RBHCtM1PUydGB8tf4SglosHVb98Z33h8t SUqatRLktSP+awnWOYCNFjcHsdY526wc48rkqXD/9JO1TKEyo6sRM3V0bVfwrh+4jgAAAAAA AA== --------------ms050502090904010800030400-- From owner-atom-syntax@mail.imc.org Thu Aug 18 14:26:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5p6E-0000aG-12 for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 14:26:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22045 for ; Thu, 18 Aug 2005 14:26:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIKSgq049387; Thu, 18 Aug 2005 11:20:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IIKSq5049386; Thu, 18 Aug 2005 11:20:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIKRQM049369 for ; Thu, 18 Aug 2005 11:20:27 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by xproxy.gmail.com with SMTP id h32so158074wxd for ; Thu, 18 Aug 2005 11:20:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GzI/5/lRXzk60vgQLWBO0UyoD2VL/EeTUf1eVIke7YI+X2srxfHNCeBMh2Q/7tbzBe0MzHlZYhBPPApzgYiCna8PAijPOIRRvsjZcvkPhdWBwp8/R5pO/BIeEhz4gtsmQhdPPCXQhhULXdXh1PX4iK0qXj2mPYO+SVd0wC8lb9I= Received: by 10.70.56.20 with SMTP id e20mr46542wxa; Thu, 18 Aug 2005 11:20:21 -0700 (PDT) Received: by 10.70.58.2 with HTTP; Thu, 18 Aug 2005 11:20:21 -0700 (PDT) Message-ID: <905f7c910508181120556a10f6@mail.gmail.com> Date: Thu, 18 Aug 2005 14:20:21 -0400 From: Elias Torres Reply-To: elias@torrez.us To: James M Snell Subject: Re: FYI: Expires Extension Draft Cc: atom-syntax@imc.org In-Reply-To: <4303B344.5080908@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4303B344.5080908@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7IIKRQM049377 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I tried commenting on your site, but I have to register to comment. :-( You linked to RSS3 [1] and I spotted something related to this extension that could be used instead. 7 It seems more elegant than having to convert to whatever you specified in your spec. Just a thought. Elias [1] http://www.rss3.org/rss3lite.html On 8/17/05, James M Snell wrote: > > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt > > Example: > > > ... > 2005-08-16T12:00:00Z > ... > > > or > > > ... > 2005-08-16T12:00:00Z > 20000 > ... > > > This is not to be used for caching of Atom documents; nor is it to be > used as a mechanism for scheduling updates of local copies of Atom > documents. > > - James > > From owner-atom-syntax@mail.imc.org Thu Aug 18 14:46:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pPm-0004yT-R8 for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 14:46:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23037 for ; Thu, 18 Aug 2005 14:46:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIfU60050899; Thu, 18 Aug 2005 11:41:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IIfUVM050898; Thu, 18 Aug 2005 11:41:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIfT0o050881 for ; Thu, 18 Aug 2005 11:41:29 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so299579nzb for ; Thu, 18 Aug 2005 11:41:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hQI0CkSTZO9LCgiemSARE7s1z4Q+IRRUNFSwK+39j+/LHgkV/1ajIdEyv2FKrxDWI0eUMba8JFSAA/pkSohEQCYQOdy5mBSlaGiO3Wm2au4lfZVYgZ6DdBXn0aswrQc4LM4A+SxpxaNE2Hmsw0IFa3EVtA/7VUeDyGZgnDWSezo= Received: by 10.36.221.52 with SMTP id t52mr1641957nzg; Thu, 18 Aug 2005 11:41:24 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id i5sm3474962nzi.2005.08.18.11.41.23; Thu, 18 Aug 2005 11:41:24 -0700 (PDT) Message-ID: <4304D651.701@gmail.com> Date: Thu, 18 Aug 2005 11:41:21 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: elias@torrez.us CC: atom-syntax@imc.org Subject: Re: FYI: Expires Extension Draft References: <4303B344.5080908@gmail.com> <905f7c910508181120556a10f6@mail.gmail.com> In-Reply-To: <905f7c910508181120556a10f6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ugh... let's try to avoid even mentioning RSS3. According to the RSS 2.0 spec, the ttl specifies a "a number of minutes that indicates how long a channel can be cached before refreshing from the source." What the spec does not indicate is the number of minutes from when? The moment the feed was last pulled? The moment specified by pubDate? Further, the ttl element is specifically designed for cache control and provide no semantics over when the metadata content of the item expires -- only over when a the RSS feed should be polled again. In contrast, the Expires extension is explicitly NOT for cache-control and MUST NOT be used for scheduling when the feed should be polled again; it's sole purpose is to define expiration semantics for metadata content. The max-age element provides the same basic function as ttl only at a finer grain (miliseconds vs. seconds/minutes/etc) and with less ambiguity (e.g. it is calculated from the moment specified in atom:updated). - James Elias Torres wrote: >I tried commenting on your site, but I have to register to comment. :-( > >You linked to RSS3 [1] and I spotted something related to this >extension that could be used instead. > >7 > >It seems more elegant than having to convert to whatever you specified >in your spec. > >Just a thought. > >Elias > > >[1] http://www.rss3.org/rss3lite.html > >On 8/17/05, James M Snell wrote: > > >>http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt >> >>Example: >> >> >> ... >> 2005-08-16T12:00:00Z >> ... >> >> >>or >> >> >> ... >> 2005-08-16T12:00:00Z >> 20000 >> ... >> >> >>This is not to be used for caching of Atom documents; nor is it to be >>used as a mechanism for scheduling updates of local copies of Atom >>documents. >> >>- James >> >> >> >> > > > From owner-atom-syntax@mail.imc.org Thu Aug 18 14:47:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pQh-0005JQ-JV for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 14:47:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23118 for ; Thu, 18 Aug 2005 14:47:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIhBg5051095; Thu, 18 Aug 2005 11:43:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IIhBFX051094; Thu, 18 Aug 2005 11:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IIhB8g051086 for ; Thu, 18 Aug 2005 11:43:11 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 400E456; Thu, 18 Aug 2005 11:43:06 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7IIh4kv022096; Thu, 18 Aug 2005 11:43:05 -0700 (PDT) Date: Thu, 18 Aug 2005 11:43:04 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: FYI: Expires Extension Draft Message-ID: <3CD276B07788BC2F923BA67C@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <905f7c910508181120556a10f6@mail.gmail.com> References: <4303B344.5080908@gmail.com> <905f7c910508181120556a10f6@mail.gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit RSS 3? Eh? The RSS ttl element is a mess. RSS 3 Lite (could we spell that word correctly?) specifies it not as information about the feed, but as an attempt to remotely control robots. RSS 2 specifies it as a caching hint, but in minutes, not seconds. Regardless it is useless for a feed with a dedicated update schedule, because it requires updating the feed every second (or minute) as the publish time approaches. For more detail, see: That was a proposal, and is *not* part of Atom, but it does have some useful discussion of cache hints. For caching, use the native HTTP cache features. wunder --On August 18, 2005 2:20:21 PM -0400 Elias Torres wrote: > > I tried commenting on your site, but I have to register to comment. :-( > > You linked to RSS3 [1] and I spotted something related to this > extension that could be used instead. > > 7 > > It seems more elegant than having to convert to whatever you specified > in your spec. > > Just a thought. > > Elias > > > [1] http://www.rss3.org/rss3lite.html > > On 8/17/05, James M Snell wrote: >> >> http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt >> >> Example: >> >> >> ... >> 2005-08-16T12:00:00Z >> ... >> >> >> or >> >> >> ... >> 2005-08-16T12:00:00Z >> 20000 >> ... >> >> >> This is not to be used for caching of Atom documents; nor is it to be >> used as a mechanism for scheduling updates of local copies of Atom >> documents. >> >> - James >> >> > > -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 18 15:21:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pxH-0004Pv-Ga for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 15:21:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25427 for ; Thu, 18 Aug 2005 15:21:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IJF6sI054747; Thu, 18 Aug 2005 12:15:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7IJF6Yd054746; Thu, 18 Aug 2005 12:15:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7IJF5gR054724 for ; Thu, 18 Aug 2005 12:15:05 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by xproxy.gmail.com with SMTP id h32so161096wxd for ; Thu, 18 Aug 2005 12:14:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=okSZizZnuSw+tSx8piq6OcCxrU9d0++9YA4LG+eC46tGJl8scDRshrh6d0VF1+aH3po8LFbmlVX1AS7bQBq6uYqrkzh1GMekHdt+O/ERvixIjGu9Ts9dkSWTc3vO/VMZQC96TL58XN2WWrfB2hzERHc6GYcMwI56BzGnPeQfgTY= Received: by 10.70.57.14 with SMTP id f14mr47600wxa; Thu, 18 Aug 2005 12:14:59 -0700 (PDT) Received: by 10.70.58.2 with HTTP; Thu, 18 Aug 2005 12:14:59 -0700 (PDT) Message-ID: <905f7c91050818121435619869@mail.gmail.com> Date: Thu, 18 Aug 2005 15:14:59 -0400 From: Elias Torres Reply-To: elias@torrez.us To: James M Snell Subject: Re: FYI: Expires Extension Draft Cc: atom-syntax@imc.org In-Reply-To: <4304D651.701@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4303B344.5080908@gmail.com> <905f7c910508181120556a10f6@mail.gmail.com> <4304D651.701@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7IJF5gR054739 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I would like to clarify something, I did not even read that spec. I just noticed the "span" attribute that allowed me to specifiy days, weeks, months, etc instead of converting what the meaning of your max-age tag to milliseconds or whatnot. That's all. I didn't mean for us to use ttl as it was meant on that so called spec. I should have been more clear on this. Elias On 8/18/05, James M Snell wrote: > > Ugh... let's try to avoid even mentioning RSS3. > > According to the RSS 2.0 spec, the ttl specifies a "a number of minutes > that indicates how long a channel can be cached before refreshing from > the source." What the spec does not indicate is the number of minutes > from when? The moment the feed was last pulled? The moment specified by > pubDate? Further, the ttl element is specifically designed for cache > control and provide no semantics over when the metadata content of the > item expires -- only over when a the RSS feed should be polled again. > In contrast, the Expires extension is explicitly NOT for cache-control > and MUST NOT be used for scheduling when the feed should be polled > again; it's sole purpose is to define expiration semantics for metadata > content. The max-age element provides the same basic function as ttl > only at a finer grain (miliseconds vs. seconds/minutes/etc) and with > less ambiguity (e.g. it is calculated from the moment specified in > atom:updated). > > - James > > Elias Torres wrote: > > >I tried commenting on your site, but I have to register to comment. :-( > > > >You linked to RSS3 [1] and I spotted something related to this > >extension that could be used instead. > > > >7 > > > >It seems more elegant than having to convert to whatever you specified > >in your spec. > > > >Just a thought. > > > >Elias > > > > > >[1] http://www.rss3.org/rss3lite.html > > > >On 8/17/05, James M Snell wrote: > > > > > >>http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt > >> > >>Example: > >> > >> > >> ... > >> 2005-08-16T12:00:00Z > >> ... > >> > >> > >>or > >> > >> > >> ... > >> 2005-08-16T12:00:00Z > >> 20000 > >> ... > >> > >> > >>This is not to be used for caching of Atom documents; nor is it to be > >>used as a mechanism for scheduling updates of local copies of Atom > >>documents. > >> > >>- James > >> > >> > >> > >> > > > > > > > > From owner-atom-syntax@mail.imc.org Thu Aug 18 17:20:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5roI-0004kW-VF for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 17:20:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04053 for ; Thu, 18 Aug 2005 17:20:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ILBYVH079154; Thu, 18 Aug 2005 14:11:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ILBYtL079153; Thu, 18 Aug 2005 14:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ILBXAs079146 for ; Thu, 18 Aug 2005 14:11:33 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so301711nzi for ; Thu, 18 Aug 2005 14:11:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=aTAOBfohQgovXcn1R/6hFgP5H7LztcDzuCw2ngr8QJLc677pmL5lc2XaKnZ2VaMzrFiYO9qP7yTvHip/Kp8gLiKz2CPr1r5QTwV6ghnhjZkDPuJu/IO6cvva1+9L59NvaXjR8nXnSrNEn5lxkzF+L7aGqD883gt/eohIOwOwcMU= Received: by 10.36.66.15 with SMTP id o15mr1629303nza; Thu, 18 Aug 2005 14:11:28 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Thu, 18 Aug 2005 14:11:28 -0700 (PDT) Message-ID: <68fba5c50508181411634e4d1@mail.gmail.com> Date: Thu, 18 Aug 2005 17:11:28 -0400 From: Robert Sayre To: Atom Syntax Subject: Where's the Registry of Link Relations? Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7ILBYAs079148 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Anyone seen it or know where it will be found? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Aug 18 18:02:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sTD-0000Jv-A6 for atompub-archive@megatron.ietf.org; Thu, 18 Aug 2005 18:02:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06095 for ; Thu, 18 Aug 2005 18:02:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ILu81k082304; Thu, 18 Aug 2005 14:56:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ILu8mm082303; Thu, 18 Aug 2005 14:56:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7ILu78k082255 for ; Thu, 18 Aug 2005 14:56:07 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 18 Aug 2005 21:56:01 -0000 Received: from dsl-084-056-239-170.arcor-ip.net (EHLO hive) [84.56.239.170] by mail.gmx.net (mp033) with SMTP; 18 Aug 2005 23:56:01 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Robert Sayre Cc: Atom Syntax Subject: Re: Where's the Registry of Link Relations? Date: Thu, 18 Aug 2005 23:56:22 +0200 Message-ID: References: <68fba5c50508181411634e4d1@mail.gmail.com> In-Reply-To: <68fba5c50508181411634e4d1@mail.gmail.com> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id SAA06095 * Robert Sayre wrote: >Anyone seen it or know where it will be found? The IANA registry? It will be created some time between now and the publication of the RFC. Same goes for the Atom media type and any other pending IANA actions. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Fri Aug 19 21:48:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ISo-0006SM-Vr for atompub-archive@megatron.ietf.org; Fri, 19 Aug 2005 21:48:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16804 for ; Fri, 19 Aug 2005 21:48:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7K1fCQC092892; Fri, 19 Aug 2005 18:41:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7K1fC3G092891; Fri, 19 Aug 2005 18:41:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7K1fAVq092884 for ; Fri, 19 Aug 2005 18:41:11 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so654512wri for ; Fri, 19 Aug 2005 18:41:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=R+qgIqOiORySXqHLI43FXqk6UFhPZyjKIMiIVqu8ulAI56QocUe5CslrMes72dszoojB17iiIxIfeUH9H4wnt2XxOVNV3AHbeSykN1izEaTlToRz84iVkqLoXNZDt8mgBYi9knOraJm/5qv7JMuSaXgOm0Y0kSlzBKkvbVuHlpU= Received: by 10.54.151.9 with SMTP id y9mr2357690wrd; Fri, 19 Aug 2005 18:41:05 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 15sm958763wrl.2005.08.19.18.41.04; Fri, 19 Aug 2005 18:41:05 -0700 (PDT) Message-ID: <43068A2C.6030309@gmail.com> Date: Fri, 19 Aug 2005 18:41:00 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: OpenSearch and Atom Prototype 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: Content-Transfer-Encoding: 7bit FYI... wanted to experiment a bit. OpenSearch+Atom http://www.snellspace.com/wp/wp-opensearch.php?s=OpenSearch Query Pattern http://www.snellspace.com/wp/wp-opensearch.php?s={searchTerms}&itemstart={startIndex}&itempage={startPage}&itemlimit={count} (I'm using a modified version of the OpenSearch for Wordpress plugin http://www.williamsburger.com/wb/archives/opensearch-v-1-0) - James From owner-atom-syntax@mail.imc.org Sat Aug 20 08:31:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6SVU-0003jj-9C for atompub-archive@megatron.ietf.org; Sat, 20 Aug 2005 08:31:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18538 for ; Sat, 20 Aug 2005 08:31:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7KCKRSg092014; Sat, 20 Aug 2005 05:20:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7KCKR3o092012; Sat, 20 Aug 2005 05:20:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay05.plus.net (pih-relay05.plus.net [212.159.14.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7KCKQOd091920 for ; Sat, 20 Aug 2005 05:20:27 -0700 (PDT) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay05.plus.net with esmtp (Exim) id 1E6SKg-0004Wx-PA for atom-syntax@imc.org; Sat, 20 Aug 2005 13:20:18 +0100 To: atom-syntax@imc.org In-Reply-To: <43068A2C.6030309@gmail.com> Subject: Re: OpenSearch and Atom Prototype From: pmrobinson@gmx.net (Peter Robinson) Date: Sat, 20 Aug 2005 13:20:19 +0100 Message-ID: <1h1lgkm.1xu2y3h19gvimhM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.9) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James M Snell wrote: > FYI... wanted to experiment a bit. > > OpenSearch+Atom > > http://www.snellspace.com/wp/wp-opensearch.php?s=OpenSearch When I updated my feed generator to support atom[1], I just added the RSS2.0 extension elements I was already generating, including OpenSearch. I don't know if any feed consumers actually support it in atom of course... I did noticed just now that OpenSearch 1.1 proposes an OpenSearch autodiscovery mechanism (amongst other things). Regards, Peter [1] -- Peter Robinson From owner-atom-syntax@mail.imc.org Sun Aug 21 00:20:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6hJk-0003VV-Ky for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 00:20:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23026 for ; Sun, 21 Aug 2005 00:20:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7L4DCXi068660; Sat, 20 Aug 2005 21:13:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7L4DC7r068658; Sat, 20 Aug 2005 21:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7L4DAAN068635 for ; Sat, 20 Aug 2005 21:13:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.35] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7L4D37I007837; Sun, 21 Aug 2005 00:13:03 -0400 Message-ID: <4307FF49.6060509@intertwingly.net> Date: Sun, 21 Aug 2005 00:12:57 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> In-Reply-To: <43021E53.1060308@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Sam Ruby wrote: > >> Apparently, consuming tools are welcome to aggressively substitute >> references to the enclosing parent document of any element for any >> references that, when resolved according to xml:base, differ from that >> xml:base only in ways that deal with normalization and fragment >> identifiers. This can only cause confusion if the xml:base in effect >> differs from original xml:base of the document (i.e., the URI used to >> retrieve the document in the first place) in ways other than the >> fragment identifier. > > You've nailed it. Sjoerd, I'd be interested in your comments on this: http://tinyurl.com/9o6y2 - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 21 06:38:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6nDI-0003FI-B1 for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 06:38:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21043 for ; Sun, 21 Aug 2005 06:38:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LAUiww082946; Sun, 21 Aug 2005 03:30:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LAUi4h082940; Sun, 21 Aug 2005 03:30:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LAUhHO082909 for ; Sun, 21 Aug 2005 03:30:43 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7LAUaEN043700; Sun, 21 Aug 2005 12:30:36 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <430857C0.5040206@w3future.com> Date: Sun, 21 Aug 2005 12:30:24 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> In-Reply-To: <4307FF49.6060509@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Sjoerd, I'd be interested in your comments on this: > > http://tinyurl.com/9o6y2 The explanation in the documentation[1] is perfect. And it says "As the current xml:base in effect does not match the URI of the document", but this is not the case in my feed, so I'm not sure why you report a warning? Regarding the solution, my first suggestion would be to change the xml:base to reference the atom document, e.g.: This is also more consistent with the explanation. greetings, Sjoerd [1] http://www.feedvalidator.org/docs/warning/SameDocumentReference.html -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Aug 21 07:22:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6nud-0001ZI-Ap for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 07:22:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22314 for ; Sun, 21 Aug 2005 07:22:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LBHKQ0023051; Sun, 21 Aug 2005 04:17:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LBHKui023050; Sun, 21 Aug 2005 04:17:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LBHJrS023027 for ; Sun, 21 Aug 2005 04:17:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.35] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7LBGtFi000995; Sun, 21 Aug 2005 07:16:56 -0400 Message-ID: <43086295.7070207@intertwingly.net> Date: Sun, 21 Aug 2005 07:16:37 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> In-Reply-To: <430857C0.5040206@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > Sam Ruby wrote: > >> Sjoerd, I'd be interested in your comments on this: >> >> http://tinyurl.com/9o6y2 > > The explanation in the documentation[1] is perfect. And it says "As the > current xml:base in effect does not match the URI of the document", but > this is not the case in my feed, so I'm not sure why you report a warning? URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform xml:base = http://w3future.com/weblog/rss.xml?notransform > Regarding the solution, my first suggestion would be to change the > xml:base to reference the atom document, e.g.: > > ... which would resolve to http://example.com/blog/. Is that what we want here? - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 21 07:30:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6o2M-0002kd-3l for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 07:30:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22583 for ; Sun, 21 Aug 2005 07:30:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LBQMle031984; Sun, 21 Aug 2005 04:26:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LBQMoM031983; Sun, 21 Aug 2005 04:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LBQKw0031956 for ; Sun, 21 Aug 2005 04:26:21 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7LBQ8NV018592; Sun, 21 Aug 2005 13:26:14 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <430864C4.7040106@w3future.com> Date: Sun, 21 Aug 2005 13:25:56 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <43086295.7070207@intertwingly.net> In-Reply-To: <43086295.7070207@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Sjoerd Visscher wrote: > >>Sam Ruby wrote: >> >> >>>Sjoerd, I'd be interested in your comments on this: >>> >>>http://tinyurl.com/9o6y2 >> >>The explanation in the documentation[1] is perfect. And it says "As the >>current xml:base in effect does not match the URI of the document", but >>this is not the case in my feed, so I'm not sure why you report a warning? > > > URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform > xml:base = http://w3future.com/weblog/rss.xml?notransform > Ah, ok, I missed that. (Just to be sure, you added www yourself, or is there a link to the feed somewhere with www in it?) >>Regarding the solution, my first suggestion would be to change the >>xml:base to reference the atom document, e.g.: >> >> > > > ... which would resolve to http://example.com/blog/. Is that what we > want here? The original in your example is . -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Aug 21 08:20:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6ooQ-0002oM-4p for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 08:20:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25199 for ; Sun, 21 Aug 2005 08:20:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LCDONx075726; Sun, 21 Aug 2005 05:13:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LCDO3p075725; Sun, 21 Aug 2005 05:13:24 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7LCDM4U075642 for ; Sun, 21 Aug 2005 05:13:23 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 Aug 2005 12:13:16 -0000 Received: from xdsl-213-196-244-13.netcologne.de (EHLO klangraum) [213.196.244.13] by mail.gmx.net (mp026) with SMTP; 21 Aug 2005 14:13:16 +0200 X-Authenticated: #163624 Date: Sun, 21 Aug 2005 14:13:22 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base abuse Message-ID: <20050821121322.GA3642@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <430857C0.5040206@w3future.com> 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 ietf.org id IAA25199 * Sjoerd Visscher [2005-08-21 13:40]: > Regarding the solution, my first suggestion would be to change > the xml:base to reference the atom document, e.g.: >=20 > >=20 > This is also more consistent with the explanation. Except it=E2=80=99s a @rel=3D'self' link, so you really do want it to resolve to . @rel=3D'self' is the one case where I still wonder how it should be handled. To be helpful and correct, you will want to provide an atom:feed/@xml:base for your feed, and likewise the conscientous will want to provide an atom:link[@rel=3D'self'] for the feed =E2=80=93 n= ow regardless of *how* you write one or the other, if you use both as intended by their specs, then the atom:link is inevitably going to end up a same-document reference. I wonder if that=E2=80=99s really harmful, though. After all, @rel=3D'sel= f' is meant as the URL that should be used for *subscription* when the aggregator does not know where the document came from. This does not in itself imply dereferencing. (Semantics, semantics=E2=80=A6) Further, I expect that in practice, clients will fall back to atom:feed/@xml:base when it exists but atom:link[@rel=3D'self'] does not. In fact, I=E2=80=99ve been wondering whether atom:feed/@xml:base doesn=E2= =80=99t obsolete the purpose of atom:link[@rel=3D'self'], so that the former should have been the SHOULD that the latter is, and the latter not invented at all. It would seem that this notion would also be less controversial when backported to RSS2, as opposed to the item of including an atom:link in an RSS2 feed. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 08:49:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6pGU-0007ct-GW for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 08:49:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26688 for ; Sun, 21 Aug 2005 08:49:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LCgnsx002484; Sun, 21 Aug 2005 05:42:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LCgnSQ002483; Sun, 21 Aug 2005 05:42:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LCgm0Z002449 for ; Sun, 21 Aug 2005 05:42:48 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7LCgeSp089943; Sun, 21 Aug 2005 14:42:41 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <430876B4.1@w3future.com> Date: Sun, 21 Aug 2005 14:42:28 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <20050821121322.GA3642@klangraum> In-Reply-To: <20050821121322.GA3642@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed X-Virus-Scanned: by XS4ALL Virus Scanner 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 ietf.org id IAA26688 A. Pagaltzis wrote: > * Sjoerd Visscher [2005-08-21 13:40]: >=20 >>Regarding the solution, my first suggestion would be to change >>the xml:base to reference the atom document, e.g.: >> >> >> >>This is also more consistent with the explanation. >=20 >=20 > Except it=E2=80=99s a @rel=3D'self' link, so you really do want it to > resolve to . This was about the link in the solution in http://www.feedvalidator.org/docs/warning/SameDocumentReference.html which is not a self link. > In fact, I=E2=80=99ve been wondering whether atom:feed/@xml:base doesn=E2= =80=99t > obsolete the purpose of atom:link[@rel=3D'self'], so that the > former should have been the SHOULD that the latter is, and the > latter not invented at all. It would seem that this notion would > also be less controversial when backported to RSS2, as opposed to > the item of including an atom:link in an RSS2 feed. Not only does is port well to RSS2, it ports well to every single xml=20 document. I think it is good practice, as it makes the infoset of the=20 document context independent. --=20 Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Aug 21 09:11:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6pbQ-0002YT-Ag for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 09:11:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27716 for ; Sun, 21 Aug 2005 09:11:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LD48YY017835; Sun, 21 Aug 2005 06:04:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LD482k017834; Sun, 21 Aug 2005 06:04:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7LD46S4017793 for ; Sun, 21 Aug 2005 06:04:07 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 Aug 2005 13:04:00 -0000 Received: from xdsl-213-196-244-13.netcologne.de (EHLO klangraum) [213.196.244.13] by mail.gmx.net (mp031) with SMTP; 21 Aug 2005 15:04:00 +0200 X-Authenticated: #163624 Date: Sun, 21 Aug 2005 15:04:06 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base abuse Message-ID: <20050821130406.GA3898@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <20050821121322.GA3642@klangraum> <430876B4.1@w3future.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <430876B4.1@w3future.com> 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 ietf.org id JAA27716 * Sjoerd Visscher [2005-08-21 14:50]: >> Except it=E2=80=99s a @rel=3D'self' link, so you really do want it to >> resolve to . >=20 > This was about the link in the solution in > http://www.feedvalidator.org/docs/warning/SameDocumentReference.html > which is not a self link. Sorry for not being clearer. I used the documentation example because that was handier to reference, but I *was* talking about the actual warning emitted. What do you think about what I said? Is @rel=3D'self' being a same-document reference a problem? One thing to note is that when retrieving the document from the location @rel=3D'self' refers to, as the external base URI for atom:feed is the one which @rel=3D'self' also references. So when retrieving the feed from its preferred location, @rel=3D'self' will always implicitly be a same-document reference. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 09:43:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6q6p-0008D5-Ua for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 09:43:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28842 for ; Sun, 21 Aug 2005 09:43:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LDcSAl030396; Sun, 21 Aug 2005 06:38:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LDcSEp030394; Sun, 21 Aug 2005 06:38:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LDcQ1b030377 for ; Sun, 21 Aug 2005 06:38:27 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr3.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7LDcOQr009079; Sun, 21 Aug 2005 15:38:25 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <430883C4.8080604@w3future.com> Date: Sun, 21 Aug 2005 15:38:12 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <20050821121322.GA3642@klangraum> <430876B4.1@w3future.com> <20050821130406.GA3898@klangraum> In-Reply-To: <20050821130406.GA3898@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: > What do you think about what I said? Is @rel='self' being a > same-document reference a problem? No. As long as xml:base is the same as the document URI. > One thing to note is that when retrieving the document from the > location @rel='self' refers to, as the external base URI for > atom:feed is the one which @rel='self' also references. So when > retrieving the feed from its preferred location, @rel='self' will > always implicitly be a same-document reference. Yes, good point! -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Aug 21 10:22:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6qiS-0006CD-HE for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 10:22:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01407 for ; Sun, 21 Aug 2005 10:22:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LEHPvA066133; Sun, 21 Aug 2005 07:17:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LEHPc3066131; Sun, 21 Aug 2005 07:17:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LEHOSj066077 for ; Sun, 21 Aug 2005 07:17:25 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 22 Aug 2005 00:18:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 22 Aug 2005 00:17:17 +1000 Subject: geolocation in atom:author? From: Eric Scheid To: Atom Syntax Message-ID: 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: Content-Transfer-Encoding: 7bit In this example, can anything intelligent be said about the various different locations? Is my intent clear, or are there clear ambiguities? ... location#1 foo location#2 foo location#3 location#4 ... ... e. From owner-atom-syntax@mail.imc.org Sun Aug 21 11:51:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6s6y-0003so-Us for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 11:51:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05941 for ; Sun, 21 Aug 2005 11:51:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LFjPu0023851; Sun, 21 Aug 2005 08:45:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LFjP7a023850; Sun, 21 Aug 2005 08:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LFjKQe023801; Sun, 21 Aug 2005 08:45:21 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 21 Aug 2005 08:45:22 -0700 To: Eric Scheid , Atom Syntax From: Paul Hoffman Subject: Re: geolocation in atom:author? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:17 AM +1000 8/22/05, Eric Scheid wrote: >In this example, can anything intelligent be said about the various >different locations? Is my intent clear, or are there clear ambiguities? > > > ... > location#1 > > foo > location#2 > > > > foo > location#3 > > location#4 > ... > ... > > #2 through #4 seem understandable, but what the heck is #1? "The place where this feed was put together"? "The place where this feed was originally grabbed from"? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Aug 21 13:36:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tjy-0003oG-5h for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 13:36:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09386 for ; Sun, 21 Aug 2005 13:36:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LHTNnk086365; Sun, 21 Aug 2005 10:29:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LHTNAl086364; Sun, 21 Aug 2005 10:29:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LHTMAl086349 for ; Sun, 21 Aug 2005 10:29:22 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.35] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7LHR2Jr015883; Sun, 21 Aug 2005 13:29:21 -0400 Message-ID: <4308B962.9000306@intertwingly.net> Date: Sun, 21 Aug 2005 13:26:58 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <43086295.7070207@intertwingly.net> <430864C4.7040106@w3future.com> In-Reply-To: <430864C4.7040106@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Sam Ruby wrote: > >> Sjoerd Visscher wrote: >> >>> Sam Ruby wrote: >>> >>> >>>> Sjoerd, I'd be interested in your comments on this: >>>> >>>> http://tinyurl.com/9o6y2 >>> >>> >>> The explanation in the documentation[1] is perfect. And it says "As the >>> current xml:base in effect does not match the URI of the document", but >>> this is not the case in my feed, so I'm not sure why you report a >>> warning? >> >> >> URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform >> xml:base = http://w3future.com/weblog/rss.xml?notransform > > Ah, ok, I missed that. (Just to be sure, you added www yourself, or is > there a link to the feed somewhere with www in it?) Your feed is available from both of the URI's mentioned above. The tinyurl quoted above is based on passing the first one to the feed validator. >>> Regarding the solution, my first suggestion would be to change the >>> xml:base to reference the atom document, e.g.: >>> >>> >> >> ... which would resolve to http://example.com/blog/. Is that what we >> want here? > > The original in your example is > > . Not being quite ready to drop the existing suggestion, I simply added another. http://www.feedvalidator.org/docs/warning/SameDocumentReference.html - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 21 14:29:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6uZv-0004uy-HF for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 14:29:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11324 for ; Sun, 21 Aug 2005 14:29:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LIP2Bb019887; Sun, 21 Aug 2005 11:25:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LIP2GL019886; Sun, 21 Aug 2005 11:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LIP1RO019822 for ; Sun, 21 Aug 2005 11:25:01 -0700 (PDT) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay04.plus.net with esmtp (Exim) id 1E6uV3-0005C3-Fz for atom-syntax@imc.org; Sun, 21 Aug 2005 19:24:53 +0100 To: atom-syntax@imc.org (Atom Syntax) In-Reply-To: Subject: Re: geolocation in atom:author? From: pmrobinson@gmx.net (Peter Robinson) Date: Sun, 21 Aug 2005 19:24:51 +0100 Message-ID: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.9) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Hoffman wrote: > At 12:17 AM +1000 8/22/05, Eric Scheid wrote: > > >In this example, can anything intelligent be said about the various > >different locations? Is my intent clear, or are there clear ambiguities? > > > > > > ... > > location#1 > > > > foo > > location#2 > > > > > > > > foo > > location#3 > > > > location#4 > > ... > > ... > > > > > > #2 through #4 seem understandable, but what the heck is #1? "The > place where this feed was put together"? "The place where this feed > was originally grabbed from"? I do something similar, intending it to mean "the location of the items described by this feed" (when there is a single location). I don't know whether any software understands my intent... Regards, Peter -- Peter Robinson From owner-atom-syntax@mail.imc.org Sun Aug 21 15:10:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6vDJ-0002mI-Tw for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 15:10:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13320 for ; Sun, 21 Aug 2005 15:10:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LJ4VSG040059; Sun, 21 Aug 2005 12:04:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJ4Vhe040058; Sun, 21 Aug 2005 12:04:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LJ4T3e040052 for ; Sun, 21 Aug 2005 12:04:30 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr14.xs4all.nl (8.13.3/8.13.3) with ESMTP id j7LJ4MOk060905; Sun, 21 Aug 2005 21:04:22 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <4308D028.8020103@w3future.com> Date: Sun, 21 Aug 2005 21:04:08 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <43086295.7070207@intertwingly.net> <430864C4.7040106@w3future.com> <4308B962.9000306@intertwingly.net> In-Reply-To: <4308B962.9000306@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: >>>URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform >>>xml:base = http://w3future.com/weblog/rss.xml?notransform >> >>Ah, ok, I missed that. (Just to be sure, you added www yourself, or is >>there a link to the feed somewhere with www in it?) > > > Your feed is available from both of the URI's mentioned above. The > tinyurl quoted above is based on passing the first one to the feed > validator. Oh, this is actually interesting. I send a 301 when you use www.w3future.com. It looks like this is handled transparently by your http library, giving you the file at w3future.com. In that case it should be possible to request the actual uri that is used to get the file. And then there's also the Content-Location header, which sets the base URI. This is used with content negotiation. F.e. (I haven't actually implemented this) if you would send a request to http://w3future.com/weblog/ with the header Accept: application/atom+xml I could send you the atom file with this header: Content-Location: http://w3future.com/weblog/rss.xml?notransform Afaik this is how the HTTP spec suggest to implement content negotiation. Then the value of Content-Location should be considered to be the uri of the document. >>>>Regarding the solution, my first suggestion would be to change the >>>>xml:base to reference the atom document, e.g.: >>>> >>>> >>> >>>... which would resolve to http://example.com/blog/. Is that what we >>>want here? >> >>The original in your example is >> >> . > > > Not being quite ready to drop the existing suggestion, I simply added > another. > > http://www.feedvalidator.org/docs/warning/SameDocumentReference.html That's what I meant by saying "first suggestion". -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Aug 21 15:51:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6vqq-00011S-FU for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 15:51:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16106 for ; Sun, 21 Aug 2005 15:51:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LJl1Cv048291; Sun, 21 Aug 2005 12:47:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LJl1pY048290; Sun, 21 Aug 2005 12:47:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LJkvU8048254; Sun, 21 Aug 2005 12:46:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> Date: Sun, 21 Aug 2005 12:46:54 -0700 To: pmrobinson@gmx.net (Peter Robinson), atom-syntax@imc.org (Atom Syntax) From: Paul Hoffman Subject: Extensions at the feed level (Was: Re: geolocation in atom:author?) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:24 PM +0100 8/21/05, Peter Robinson wrote: >I do something similar, intending it to mean "the location of the items >described by this feed" (when there is a single location). Ah, I had missed that. This leads to a question for the mailing list. Does an informative extension that appears at the feed level (as compared to in entries) indicate: a) this information pertains to each entry b) this information pertains to the feed itself c) this information pertains to each entry and to the feed itself d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Aug 21 16:28:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wQf-0006pU-O3 for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 16:28:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17175 for ; Sun, 21 Aug 2005 16:28:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LKMfeU069546; Sun, 21 Aug 2005 13:22:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LKMe0c069545; Sun, 21 Aug 2005 13:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LKMdpd069468; Sun, 21 Aug 2005 13:22:39 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35]) by mta09-winn.ispmail.ntl.com with ESMTP id <20050821202233.DVCO9239.mta09-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>; Sun, 21 Aug 2005 21:22:33 +0100 Received: from cpc3-stok1-5-0-cust152.bagu.cable.ntl.com ([82.11.128.152]) by aamta10-winn.ispmail.ntl.com with ESMTP id <20050821202233.VRZT3432.aamta10-winn.ispmail.ntl.com@cpc3-stok1-5-0-cust152.bagu.cable.ntl.com>; Sun, 21 Aug 2005 21:22:33 +0100 Date: Sun, 21 Aug 2005 21:22:31 +0100 From: David Powell X-Mailer: The Bat! (v3.60.02 Forerunner (Beta)) Professional X-Priority: 3 (Normal) Message-ID: <1061939681.20050821212231@djpowell.net> To: Paul Hoffman CC: pmrobinson@gmx.net (Peter Robinson), atom-syntax@imc.org (Atom Syntax) Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) In-Reply-To: References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.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: Content-Transfer-Encoding: 7bit Sunday, August 21, 2005, 8:46:54 PM, Paul Hoffman wrote: > At 7:24 PM +0100 8/21/05, Peter Robinson wrote: >>I do something similar, intending it to mean "the location of the items >>described by this feed" (when there is a single location). > Ah, I had missed that. This leads to a question for the mailing list. > Does an informative extension that appears at the feed level (as > compared to in entries) indicate: > a) this information pertains to each entry > b) this information pertains to the feed itself > c) this information pertains to each entry and to the feed itself > d) completely unknown unless specified in the extension definition In my RDF model, feed extensions (together with properties such as atom:generator), are considered to be properties of the FeedInstance. EntryInstance's are related to FeedInstance's using containingFeed and sourceFeed properties. (Entry's and Feed's can have multiple EntryInstance's and FeedInstance's, but that's not really relevant...) So, feed extensions don't automatically inherit to entries in the model (unlike atom:author which does), but for a given entry you can locate its feed and take a look at its extension properties, so it isn't like the information is lost. So I'd say b); but as long as you aren't throwing away atom:feed data, that shouldn't prevent an application using feed extensions to do a) or c). I think that the interpretation b) is probably what is supported by section 6 in the absence of any talk about extension inheritance. -- Dave From owner-atom-syntax@mail.imc.org Sun Aug 21 16:50:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wm5-0001xM-KL for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 16:50:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18433 for ; Sun, 21 Aug 2005 16:50:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LKgcO6081710; Sun, 21 Aug 2005 13:42:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LKgcZf081707; Sun, 21 Aug 2005 13:42:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7LKgWPh081588 for ; Sun, 21 Aug 2005 13:42:37 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 Aug 2005 20:42:26 -0000 Received: from xdsl-213-196-244-13.netcologne.de (EHLO klangraum) [213.196.244.13] by mail.gmx.net (mp014) with SMTP; 21 Aug 2005 22:42:26 +0200 X-Authenticated: #163624 Date: Sun, 21 Aug 2005 22:42:31 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Message-ID: <20050821204231.GA6541@klangraum> Mail-Followup-To: Atom Syntax References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id QAA18433 * Paul Hoffman [2005-08-21 21:55]: > Ah, I had missed that. This leads to a question for the mailing > list. Does an informative extension that appears at the feed > level (as compared to in entries) indicate: >=20 > a) this information pertains to each entry >=20 > b) this information pertains to the feed itself >=20 > c) this information pertains to each entry and to the feed > itself >=20 > d) completely unknown unless specified in the extension > definition Atom itself has precedent for both b) and c). So I would say it=E2=80=99s d) =E2=80=93 but also that aggregators should assume b) when= they don=E2=80=99t know any better. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 17:15:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6xAT-0005wa-JO for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 17:15:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19210 for ; Sun, 21 Aug 2005 17:15:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LLADCT097963; Sun, 21 Aug 2005 14:10:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LLADi8097962; Sun, 21 Aug 2005 14:10:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LLAChm097916; Sun, 21 Aug 2005 14:10:12 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id D6AE7724001; Sun, 21 Aug 2005 17:10:06 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Paul Hoffman'" , "'Peter Robinson'" , "'Atom Syntax'" Subject: RE: Extensions at the feed level (Was: Re: geolocation in atom:author?) Date: Sun, 21 Aug 2005 17:10:06 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmiui40/ax7tlWQHeu2rJpQOPXKwACYK/g Message-Id: <20050821211006.D6AE7724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman asked: > Does an informative extension that appears at the feed level > (as compared to in entries) indicate: > a) this information pertains to each entry > b) this information pertains to the feed itself > c) this information pertains to each entry and to the feed itself > d) completely unknown unless specified in the extension definition I believe the correct answer is "e": e) Unless otherwise specified, this information pertains to the feed only. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 18:11:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6y2Q-0006ma-0w for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 18:11:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22013 for ; Sun, 21 Aug 2005 18:11:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LM4P3i030313; Sun, 21 Aug 2005 15:04:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LM4P4x030312; Sun, 21 Aug 2005 15:04:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LM4Lk1030268; Sun, 21 Aug 2005 15:04:21 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050821211006.D6AE7724001@mail.pubsub.com> References: <20050821211006.D6AE7724001@mail.pubsub.com> Date: Sun, 21 Aug 2005 15:04:18 -0700 To: , "'Peter Robinson'" , "'Atom Syntax'" From: Paul Hoffman Subject: RE: Extensions at the feed level (Was: Re: geolocation in atom:author?) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:10 PM -0400 8/21/05, Bob Wyman wrote: >I believe the correct answer is "e": > > e) Unless otherwise specified, this information pertains to the feed only. Er, right. Change that list to: a) this information pertains to each entry (unless otherwise specified) b) this information pertains to the feed itself (unless otherwise specified) c) this information pertains to each entry and to the feed itself (unless otherwise specified) d) completely unknown unless specified in the extension definition --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Aug 21 18:40:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6yUp-00039e-BZ for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 18:40:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23746 for ; Sun, 21 Aug 2005 18:40:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LMZBHb048649; Sun, 21 Aug 2005 15:35:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LMZB6C048648; Sun, 21 Aug 2005 15:35:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LMZAXQ048565 for ; Sun, 21 Aug 2005 15:35:10 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so542189nzi for ; Sun, 21 Aug 2005 15:35:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SSh8yy90LcNpm7bDZIMw6q9nHPLRYLejCrI4n+C6iF7wQ2Mvgxf0AyEPpAAfPglRBqBQaGGoj3CPgOIxEbkixEN01Zc4Mu4TX9yZz0JvNbWLoiHzp/bZhy9nWgkaNeZgeuoGoMTshCccrUK+tFS9FzKRZJQBeAS9lDy1UbtRmxo= Received: by 10.36.148.16 with SMTP id v16mr3456713nzd; Sun, 21 Aug 2005 15:35:04 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 38sm5060154nzk.2005.08.21.15.35.04; Sun, 21 Aug 2005 15:35:04 -0700 (PDT) Message-ID: <43090194.9050300@gmail.com> Date: Sun, 21 Aug 2005 15:35:00 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Peter Robinson , Atom Syntax Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> In-Reply-To: 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: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > At 7:24 PM +0100 8/21/05, Peter Robinson wrote: > >> I do something similar, intending it to mean "the location of the items >> described by this feed" (when there is a single location). > > > Ah, I had missed that. This leads to a question for the mailing list. > Does an informative extension that appears at the feed level (as > compared to in entries) indicate: > > a) this information pertains to each entry > > b) this information pertains to the feed itself > > c) this information pertains to each entry and to the feed itself > > d) completely unknown unless specified in the extension definition > > > --Paul Hoffman, Director > --Internet Mail Consortium > > IMHO, it depends entirely on how the extension is defined. The various extensions I have put together (e.g. comments, expires, etc), the metadata can be placed on the feed/source level but is only relevant on the entry level (same model as ). One could easily imagine, however, that other extensions would apply only on the feed level. It's entirely up to the extension and implementors should make no assumptions. - James From owner-atom-syntax@mail.imc.org Sun Aug 21 19:01:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6yom-0006FH-Mb for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 19:01:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24816 for ; Sun, 21 Aug 2005 19:01:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LMsVBO060065; Sun, 21 Aug 2005 15:54:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LMsVFd060064; Sun, 21 Aug 2005 15:54:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LMsTo8060049 for ; Sun, 21 Aug 2005 15:54:30 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <43090194.9050300@gmail.com> References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> <43090194.9050300@gmail.com> Date: Sun, 21 Aug 2005 15:54:28 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:35 PM -0700 8/21/05, James M Snell wrote: >IMHO, it depends entirely on how the extension is defined. The >various extensions I have put together (e.g. comments, expires, >etc), the metadata can be placed on the feed/source level but is >only relevant on the entry level (same model as ). One >could easily imagine, however, that other extensions would apply >only on the feed level. It's entirely up to the extension and >implementors should make no assumptions. The crux of the question is: what happens when an extension that does not specify the scope appears at the feed level? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Aug 21 19:07:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6yuM-0007HC-NQ for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 19:07:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24921 for ; Sun, 21 Aug 2005 19:07:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LN01cW063342; Sun, 21 Aug 2005 16:00:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LN01xe063339; Sun, 21 Aug 2005 16:00:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LN00IJ063271 for ; Sun, 21 Aug 2005 16:00:00 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id DDF0D724001 for ; Sun, 21 Aug 2005 18:59:54 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: If you want "Fat Pings" just use Atom! Date: Sun, 21 Aug 2005 18:59:54 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C5A682.848C3E70" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmpArXpCl6rX1gRbWCAGGr559Rug== Message-Id: <20050821225954.DDF0D724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C5A682.848C3E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The subject of "Fat Pings" or full content streaming from blogs has come up on the FeedMesh list and in a proposal by Brad Fitzpatrick of LiveJournal. I've responded to the FeedMesh list suggesting that the best way to move forward is to simply use Atom feeds rather than invent new formats. See my response at: http://groups.yahoo.com/group/feedmesh/message/451 The problem being addressed here is that of increasing the efficiency with which feed search and/or monitoring services (like PubSub, Feedster, IceRocket, Technorati, BlogDigger, etc.) obtain posts from the major blog hosting platforms. In the past, most services have limited what they do to simply sending pings. However, while the pinging mechanism works fine in the case of low volume publishers, it simply doesn't scale to the requirements of high volume publishers like the major blog hosting platforms (LiveJournal, TypePad, Blogspot, Bryght, etc.). The problem is that when a service is pinged, it must reach back to the pinging site and retrieve an RSS or Atom file that probably contains many duplicate entries. The service must then filter out the dupes before indexing, publishing, or matching the "new" or "changed" items discovered. LiveJournal has lead for some time in showing a more efficient and effective way for search engines to obtain new and changed postings. What they do is produce an aggregate feed that contains copies of all entries written on any of their public blogs. This feed typically contains as many as 200-300 new entries per minute. But, while that might sound like a great many entries to process each minute, it is massively less than the number of entries that would need to be processed if LiveJournal were to rely on a simple pinging process. The reason is that search engines can focus their ingestion processors only on the aggregate feed and thus never need to deal with the wasted bandwidth and processing that comes from duplicate entries. Of course, LiveJournal benefits as well since the bandwidth and processing cost of serving external search and/or monitoring systems is drastically reduced. At PubSub, because of the way that LiveJournal publishes updates, we find that the cost of processing LiveJournal updates is very much lower than the cost to process entries from other blog hosting services that use traditional content-free ping formats. But, as with most RSS based systems, the LiveJournal system has been based on a polling model. Given the speed with which the feed updates, services like PubSub have been forced to read the LiveJournal feed at least once a minute if not more frequently. Given that the entire (massive) feed must be downloaded very frequently and given that LiveJournal does not currently support RFC3229+feed , there are inevitably duplicates that appear in the feed. Also, the polling services never have any idea what the publishing rate is in the feed and thus can't slack off the frequency with which they poll during "slow" periods. The result is that as the rate at which LiveJournal's users begins to slacken during "slow" periods, the percentage of duplicate entries increases. Clearly, the solution to the problem is to move to a push feed. In this case, LiveJournal would push the data updates to services that were interested in them rather than forcing those services to poll LiveJournal. Brad has proposed a somewhat bent and extended version of Atom which would be streamed over a TCP/IP connection in much the same way that we currently stream FeedMesh data. (I've included a snapshot of his proposed format below.) He defines an "AtomStream" and suggests that individual posts from the various LiveJournal hosted blogs would be included in the stream as a sequence of single-entry feeds. This is a solution that would work. However, I suggest that there is actually no need to do anything other than "vanilla flavored" Atom in order to address the needs here. A stream which began with an atom:feed element and continued with a series of atom:entry elements that contained atom:source elements would be a much more natural solution than the "stream of feeds" that Brad proposes. (A sample of what I think a "proper Atom" format for Brad's sample appears below.) The problem being addressed by "Fat Pings" is very much like the one addressed by the "Atom over XMPP" protocol and is very much like the service that we provide at PubSub.com . I believe it will be an important test of Atom to determine if it is adequate to handle this sort of problem. I would greatly appreciate comments from others on this use of Atom. It should be noted that "Fat Pings" are probably only properly generated by large, trusted blog hosting platforms. One of the essential elements of controlling spam in feeds is the ability to trace back to an actual network resource which can be used to verify the data in a "ping" and can be used, to some extent, to identify the publisher of the data. For a service like PubSub to forgo actual verification that an entry exists as claimed by a ping, we would have to be able to trust the pinger. Normally, creating such trust relationships is very expensive. However, given that the vast majority of posts are made on the large services, we can drastically increase the efficiency of the overall system by having just a few of these hosters/publishers who are permitted the privilege of publishing Fat Pings. It is my hope that in the future we'll be able to rely on Atom's support for Digital Signatures to expand drastically the number of publishers who could be trusted to publish Fat Pings. Brad Proposes: some journal title some name some entry title content I believe that the sample feed above would be better represented as a "simple" Atom feed which contains entries having source elements. Note: My sample is a bit bigger than Brad's since I've included various bits that are required in Atom but that Brad's proposal omits. He readily admits in his postings that he has not yet gone to the effort of ensuring that he is issuing compliant data. I propose the following as an equivelant to Brad's sample: LiveJournal Aggregate Feed 2005-08-21T16:30:02Z Brad tag:livejournal.org,2005:aggregatefeed-1 'Example Feed' tag:livejournal.org,2005:feed-username 2005-08-21T16:30:02Z John Doe some entry title tag:livejournal.org,2003:entry-username-32397 2005-08-21T16:30:02Z 2005-08-21T16:30:02Z This is some content. . . . What do you think? Is there any conceptual problem with streaming basic Atom over TCP/IP, HTTP continuous sessions (probably using chunked content) etc.? Is there any really good reason not just to use Atom as defined? bob wyman ------=_NextPart_000_00AD_01C5A682.848C3E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The subject of “Fat = Pings” or full content streaming from blogs has come up on the FeedMesh list = and in a proposal = by Brad Fitzpatrick of LiveJournal. I’ve responded to the FeedMesh = list suggesting that the best way to move forward is to simply use Atom feeds = rather than invent new formats. See my response at: http://groups= .yahoo.com/group/feedmesh/message/451

 

The problem being addressed = here is that of increasing the efficiency with which feed search and/or = monitoring services (like PubSub, Feedster, IceRocket, Technorati, BlogDigger, = etc.) obtain posts from the major blog hosting platforms. In the past, most services = have limited what they do to simply sending pings. However, while the pinging mechanism works fine in the case of low volume publishers, it simply = doesn’t scale to the requirements of high volume publishers like the major blog = hosting platforms (LiveJournal, TypePad, Blogspot, Bryght, etc.). The problem is = that when a service is pinged, it must reach back to the pinging site and retrieve = an RSS or Atom file that probably contains many duplicate entries. The service = must then filter out the dupes before indexing, publishing, or matching the = “new” or “changed” items discovered.

LiveJournal has lead for = some time in showing a more efficient and effective way for search engines to = obtain new and changed postings. What they do is produce an aggregate feed that = contains copies of all entries written on any of their public blogs. This feed typically contains as many as 200-300 new entries per minute. But, while that = might sound like a great many entries to process each minute, it is massively less = than the number of entries that would need to be processed if LiveJournal were to = rely on a simple pinging process. The reason is that search engines can focus = their ingestion processors only on the aggregate feed and thus never need to = deal with the wasted bandwidth and processing that comes from duplicate = entries. Of course, LiveJournal benefits as well since the bandwidth and processing = cost of serving external search and/or monitoring systems is drastically = reduced. At PubSub, because of the way that LiveJournal publishes updates, we find = that the cost of processing LiveJournal updates is very much lower than the cost = to process entries from other blog hosting services that use traditional = content-free ping formats.

But, as with most RSS based = systems, the LiveJournal system has been based on a polling model. Given the = speed with which the feed updates, services like PubSub have been forced to read = the LiveJournal feed at least once a minute if not more frequently. Given that the = entire (massive) feed must be downloaded very frequently and given that = LiveJournal does not currently support RFC= 3229+feed, there are inevitably duplicates that appear in the feed. Also, the = polling services never have any idea what the publishing rate is in the feed and = thus can’t slack off the frequency with which they poll during = “slow” periods. The result is that as the rate at which LiveJournal’s = users begins to slacken during “slow” periods, the percentage of = duplicate entries increases. Clearly, the solution to the problem is to move to a push = feed. In this case, LiveJournal would push the data updates to services that were interested in them rather than forcing  those services to poll = LiveJournal.

Brad has proposed a = somewhat bent and extended version of Atom which would be streamed over a TCP/IP = connection in much the same way that we currently stream FeedMesh data. (I’ve = included a snapshot of his proposed format below.) He defines an = “AtomStream” and suggests that individual posts from the various LiveJournal hosted = blogs would be included in the stream as a sequence of single-entry feeds. This is a solution that would work… However, I suggest that there is = actually no need to do anything other than “vanilla flavored” Atom in = order to address the needs here. A stream which began with an atom:feed element = and continued with a series of atom:entry elements that contained atom:source elements = would be a much more natural solution than the “stream of feeds” that = Brad proposes. (A sample of what I think a “proper Atom” format = for Brad’s sample appears below.)

The problem being addressed = by “Fat Pings” is very much like the one addressed by the “Atom over XMPP” protocol and is very much like the service that we = provide at PubSub.com.  I believe it = will be an important test of Atom to determine if it is adequate to handle this sort of = problem. I would greatly appreciate comments from others on this use of = Atom.

It should be noted that = “Fat Pings” are probably only properly generated by large, trusted blog = hosting platforms. One of the essential elements of controlling spam in feeds is = the ability to trace back to an actual network resource which can be used to = verify the data in a “ping” and can be used, to some extent, to = identify the publisher of the data. For a service like PubSub to forgo actual = verification that an entry exists as claimed by a ping, we would have to be able to = trust the pinger. Normally, creating such trust relationships is very expensive. = However, given that the vast majority of posts are made on the large services, we = can drastically increase the efficiency of the overall system by having just = a few of these hosters/publishers who are permitted the privilege of = publishing Fat Pings. It is my hope that in the future we’ll be able to rely on = Atom’s support for Digital Signatures to expand drastically the number of = publishers who could be trusted to publish Fat Pings.

 

Brad Proposes:

 

<?xml version=3D'1.0' encoding=3D'utf-8' = ?>
<atomStream>
<time>1124247941</time>
<feed xmlns=3D'http://www.w3.org/2005/Atom'&g= t;
<title type=3D'text'>some journal title</title>
<link href=3D'http://www.livejour= nal.com/users/username/' />
<author><name>some name</name></author>
<entry>
<title>some entry = title</title>
<link href=3D'http://ww= w.livejournal.com/users/username/12345.html' />
<content = type=3D'html'>
content
</content>
</entry>
</feed>

 

I believe that the sample feed above would be better represented as a “simple” Atom feed which contains entries = having source elements. Note: My sample is a bit bigger than Brad’s since = I’ve included various bits that are required in Atom but that Brad’s = proposal omits. He readily admits in his postings that he has not yet gone to the = effort of ensuring that he is issuing compliant = data.

 

I propose the following as an equivelant to = Brad’s sample:

 

<?xml version=3D"1.0" = encoding=3D"utf-8"?>

<feed xmlns=3D"http://www.w3.org/2005/Atom">

   <title>LiveJournal Aggregate = Feed</title>

   = <link href=3D"http://livejournal.org/"/><= /p>

   = <updated>2005-08-21T16:30:02Z </updated>

   <author><name>Brad</name></author>

   = <id>tag:livejournal.org,2005:aggregatefeed-1</id><= /span>

 

<entry = xmlns=3D'http://www.w3.org/2005/Atom'>

   <source>

     <title = type=3Dtext>'Example Feed'</title>

     <link href=3D'http://www.livejournal.com/users/username/'/>

     <link rel=3D'self' type=3D'application/atom+xml'

         href=3D'http://www.livejournal.com/users/username/atom'/>

     <id>tag:livejournal.org,2005:feed-username</id>

     <updated>2005-08-21T16:30:02Z</updated>

     <author><name>John Doe</name></author>

   </source>

   <title> some entry title </title>

   <link rel=3D'alternate' = type=3D'text/html'

        href=3D'http://www.livejournal.com/users/username/12345.html = '/>

   <id>tag:livejournal.org,2003:entry-username-32397</id>

   <published>2005-08-21T16:30:02Z = </published>

   <updated>2005-08-21T16:30:02Z </updated>

   <content = type=3D"html">

         This is = some <b>content</b>.

   = </content>

</entry>

. . .

 

</feed>

 

         =    What do you think? Is there any conceptual problem with streaming basic Atom over TCP/IP, HTTP continuous sessions = (probably using chunked content) etc.? Is there any really good reason not just to = use Atom as defined?

 

         =    bob wyman

 

------=_NextPart_000_00AD_01C5A682.848C3E70-- From owner-atom-syntax@mail.imc.org Sun Aug 21 19:33:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6zJg-0002c7-I7 for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 19:33:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25666 for ; Sun, 21 Aug 2005 19:33:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LNLRJ0075628; Sun, 21 Aug 2005 16:21:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LNLRL0075627; Sun, 21 Aug 2005 16:21:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LNLQKb075611 for ; Sun, 21 Aug 2005 16:21:27 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [172.18.40.35] (nat-147-1.oreilly.com [209.204.147.1]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j7LNLEn1021335; Sun, 21 Aug 2005 19:21:26 -0400 Message-ID: <43090C66.1000006@intertwingly.net> Date: Sun, 21 Aug 2005 19:21:10 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: atom-syntax@imc.org Subject: Re: xml:base abuse References: <4300969C.1060905@w3future.com> <4300A2E7.5010002@w3future.com> <4300B3F0.8020108@intertwingly.net> <4300B8CA.3000806@w3future.com> <4300C3BE.3010209@intertwingly.net> <4300C560.30709@w3future.com> <68fba5c50508150953208b1d5@mail.gmail.com> <20050815173957.GA18058@klangraum> <68fba5c5050815110844247571@mail.gmail.com> <430102B4.3060000@w3future.com> <68fba5c505081521156afd6314@mail.gmail.com> <4301F4E7.7070908@intertwingly.net> <43021E53.1060308@w3future.com> <4307FF49.6060509@intertwingly.net> <430857C0.5040206@w3future.com> <43086295.7070207@intertwingly.net> <430864C4.7040106@w3future.com> <4308B962.9000306@intertwingly.net> <4308D028.8020103@w3future.com> In-Reply-To: <4308D028.8020103@w3future.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: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Sam Ruby wrote: > >>>> URI(doc) = http://www.w3future.com/weblog/rss.xml?notransform >>>> xml:base = http://w3future.com/weblog/rss.xml?notransform >>> >>> Ah, ok, I missed that. (Just to be sure, you added www yourself, or is >>> there a link to the feed somewhere with www in it?) >> >> Your feed is available from both of the URI's mentioned above. The >> tinyurl quoted above is based on passing the first one to the feed >> validator. > > Oh, this is actually interesting. I send a 301 when you use > www.w3future.com. It looks like this is handled transparently by your > http library, giving you the file at w3future.com. In that case it > should be possible to request the actual uri that is used to get the file. Fixed. > And then there's also the Content-Location header, which sets the base > URI. This is used with content negotiation. F.e. (I haven't actually > implemented this) if you would send a request to > http://w3future.com/weblog/ > with the header > Accept: application/atom+xml > I could send you the atom file with this header: > Content-Location: http://w3future.com/weblog/rss.xml?notransform > > Afaik this is how the HTTP spec suggest to implement content > negotiation. Then the value of Content-Location should be considered to > be the uri of the document. I now check for content-location too. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Aug 21 19:33:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6zJz-0002cR-40 for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 19:33:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25675 for ; Sun, 21 Aug 2005 19:33:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LNMkxW076414; Sun, 21 Aug 2005 16:22:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7LNMk2u076412; Sun, 21 Aug 2005 16:22:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7LNMjHP076344 for ; Sun, 21 Aug 2005 16:22:45 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so544355nzi for ; Sun, 21 Aug 2005 16:22:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hs2SR+0PWTDnSgDRyi7zkL8BNM1Xn1L+sIaS6JSnj2mzCKW+FBlCwBjGHBB7Tc58ghJfgJtu+oRs1DNQn9F+5qYshkTGRToFohuWPjBw1Cpocl6hKwfSHQ711MyJEoseTn9anewil3DvOmtqG3+AvgX2Exd97HqlDm2rUet82VI= Received: by 10.36.215.14 with SMTP id n14mr200862nzg; Sun, 21 Aug 2005 16:22:39 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Sun, 21 Aug 2005 16:22:38 -0700 (PDT) Message-ID: <68fba5c5050821162230912d6e@mail.gmail.com> Date: Sun, 21 Aug 2005 19:22:38 -0400 From: Robert Sayre To: Paul Hoffman Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> <43090194.9050300@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7LNMjHP076403 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/21/05, Paul Hoffman wrote: > > At 3:35 PM -0700 8/21/05, James M Snell wrote: > >IMHO, it depends entirely on how the extension is defined. The > >various extensions I have put together (e.g. comments, expires, > >etc), the metadata can be placed on the feed/source level but is > >only relevant on the entry level (same model as ). 4.1.1 "The 'atom:feed' element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed." 4.2.1 "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." > One > >could easily imagine, however, that other extensions would apply > >only on the feed level. It's entirely up to the extension and > >implementors should make no assumptions. > > The crux of the question is: what happens when an extension that does > not specify the scope appears at the feed level? I'm not sure why this question is interesting. What sort of application would need to know? Robert Sayre From owner-atom-syntax@mail.imc.org Sun Aug 21 20:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E70IO-0003hg-KK for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 20:36:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28331 for ; Sun, 21 Aug 2005 20:36:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0Sd5L016640; Sun, 21 Aug 2005 17:28:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M0ScZf016638; Sun, 21 Aug 2005 17:28:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0ScJF016582; Sun, 21 Aug 2005 17:28:38 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 106B3724001; Sun, 21 Aug 2005 20:28:33 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'Paul Hoffman'" Cc: "'Atom WG'" Subject: RE: Extensions at the feed level (Was: Re: geolocation in atom:author?) Date: Sun, 21 Aug 2005 20:28:32 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <68fba5c5050821162230912d6e@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmqYiEr/CrdQngQeq19YQYNfR7rAABPkZg Message-Id: <20050822002833.106B3724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > The crux of the question is: what happens when an extension that > does not specify the scope appears at the feed level? Robert Sayre asked: > I'm not sure why this question is interesting. What sort of > application would need to know? I ask: What should an aggregate feed generator like PubSub do when it finds an entry in a feed that contains unscoped extensions as children of the feed? * Would you expect us to include these extension elements in an atom:source element if we use the entry in one of our feeds? * Should we include in the source elements we generate even things that we don't understand? * What should we do if the entry already has a source element but that source element doesn't include the extension elements? Should we publish the source element as we find it? Or, should we modify the source element to include the extensions? (assuming there are no signatures...) bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 20:39:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E70Lw-0004Fw-TU for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 20:39:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28513 for ; Sun, 21 Aug 2005 20:39:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0YG8Z020021; Sun, 21 Aug 2005 17:34:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M0YGXV020018; Sun, 21 Aug 2005 17:34:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0YFE7019977 for ; Sun, 21 Aug 2005 17:34:15 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 22 Aug 2005 10:35:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 22 Aug 2005 10:34:07 +1000 Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050821162230912d6e@mail.gmail.com> 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: Content-Transfer-Encoding: 7bit On 22/8/05 9:22 AM, "Robert Sayre" wrote: >> The crux of the question is: what happens when an extension that does >> not specify the scope appears at the feed level? > > I'm not sure why this question is interesting. What sort of > application would need to know? a search engine which provides more than simply keyword searching? e. From owner-atom-syntax@mail.imc.org Sun Aug 21 20:57:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E70d0-0006rE-1V for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 20:57:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29058 for ; Sun, 21 Aug 2005 20:57:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0oD4K029636; Sun, 21 Aug 2005 17:50:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M0oDE8029633; Sun, 21 Aug 2005 17:50:13 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7M0oBos029556 for ; Sun, 21 Aug 2005 17:50:12 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 00:50:05 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp014) with SMTP; 22 Aug 2005 02:50:05 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 02:50:12 +0200 From: "A. Pagaltzis" To: Atom WG Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Message-ID: <20050822005012.GA7206@klangraum> Mail-Followup-To: Atom WG References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> <43090194.9050300@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id UAA29058 * Paul Hoffman [2005-08-22 01:00]: > The crux of the question is: what happens when an extension > that does not specify the scope appears at the feed level? Let me step back to look at the larger issue for a moment. That issue is inheritance. atom:author is the only precedent for it in Atom. It works because each entry ALWAYS has at least one author; the override mechanism is simple. Additionally, all Atom processors are aware of it by definition. But atom:author is not a model to emulate. It works only because it falls within a narrowly defined set of circumstances. The WG wisely avoided attempting to specify inheritance for atom:contributor. An entry MAY have no contributors at all, and this would require complications to express if feed-level atom:contributor elements inherited to entries. My point of view is that the default interpretation should avoid forcing extensions to specify complicated mechanisms that the WG avoided introducing when specifying atom:contributor, when an extension element=E2=80=99s semantics are the same as those of atom:contributor. And with that, getting back to your question, the answer seems pretty clear: it depends on whether the extension element is more like atom:contributor, ie defines a property which an entry may or may not have, or more like atom:author, ie defines a property that every entry inevitably has. But because that is a matter of interpretation, I would strongly prefer to say that if the extension does not specify a meaning for an element at the feed level, then the meaning is undefined.=20 On the other, related point, the same principle of avoiding the necessity of complicated override mechanisms is why I say that aggregators should assume that unknown extension elements (which therefore have *unknown* as opposed to *undefined* semantics) pertain only to the feed, not to its entries. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 21:04:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E70jT-0007qv-GD for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 21:04:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29219 for ; Sun, 21 Aug 2005 21:04:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0w7vV034376; Sun, 21 Aug 2005 17:58:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M0w76t034375; Sun, 21 Aug 2005 17:58:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M0w0gj034349 for ; Sun, 21 Aug 2005 17:58:06 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 22 Aug 2005 10:59:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 22 Aug 2005 10:57:56 +1000 Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050822002833.106B3724001@mail.pubsub.com> 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: Content-Transfer-Encoding: 7bit On 22/8/05 10:28 AM, "Bob Wyman" wrote: > What should an aggregate feed generator like PubSub do when it finds > an entry in a feed that contains unscoped extensions as children of the > feed? It's an interesting problem. A pity now that the idea of segregating entry-defaults at the feed level didn't get sufficient momentum. But what if there was an widely known extension developed for just this purpose -- providing entry metadata at the feed level. Possibly in a wrapper, possibly by flagging with an attribute. Like this... ... ... or like this ... ... ... e. From owner-atom-syntax@mail.imc.org Sun Aug 21 21:06:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E70lK-00089a-7g for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 21:06:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29267 for ; Sun, 21 Aug 2005 21:06:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M118md034491; Sun, 21 Aug 2005 18:01:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M118Ut034490; Sun, 21 Aug 2005 18:01:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7M117dO034482 for ; Sun, 21 Aug 2005 18:01:07 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 01:01:00 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp006) with SMTP; 22 Aug 2005 03:01:00 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 03:01:07 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822010107.GB7206@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050821225954.DDF0D724001@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050821225954.DDF0D724001@mail.pubsub.com> 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: * Bob Wyman [2005-08-22 01:05]: > What do you think? Is there any conceptual problem with > streaming basic Atom over TCP/IP, HTTP continuous sessions > (probably using chunked content) etc.? I wonder how you would make sure that the document is well-formed. Since the stream never actually ends and there is no way for a client to signal an intent to close the connection, the at the top would never actually be accompanied by a at the bottom. If you accept that the stream can never be a complete well-formed document, is there any reason not to simply send a stream of concatenated Atom Entry Documents? That would seem like the absolute simplest solution. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 21:39:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E71Hh-0005Ex-Gl for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 21:39:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00340 for ; Sun, 21 Aug 2005 21:39:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1YURi037601; Sun, 21 Aug 2005 18:34:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M1YU6Y037600; Sun, 21 Aug 2005 18:34:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1YTf2037591 for ; Sun, 21 Aug 2005 18:34:30 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so551987nzi for ; Sun, 21 Aug 2005 18:34:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rPlZ2CJ3rqjNPRC2zlCI12VJ9iFEf3F76MKl4UFV6DGIRoD+BgYm1ufhKth+Lo2j4UGr6yRHOL9XM3r8BxT275a+/TZfK9wtuTbvMH210LxO5V4RC662psgb7JCV7JcQgofF3jauGbDP+IqstRlhdCfhCChMPkFRQq37ibZkq7Q= Received: by 10.36.60.18 with SMTP id i18mr3667646nza; Sun, 21 Aug 2005 18:34:24 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Sun, 21 Aug 2005 18:34:24 -0700 (PDT) Message-ID: <3f1451f505082118345e5e18f5@mail.gmail.com> Date: Sun, 21 Aug 2005 21:34:24 -0400 From: Joe Gregorio To: bobwyman@pubsub.com Subject: Re: If you want "Fat Pings" just use Atom! Cc: Atom Syntax In-Reply-To: <20050821225954.DDF0D724001@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050821225954.DDF0D724001@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7M1YUf2037595 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Why not POST the Atom Entry, ala the Atom Publishing Protocol? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Aug 21 21:53:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E71VT-0007ed-Tq for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 21:53:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01183 for ; Sun, 21 Aug 2005 21:53:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1nDZ0044140; Sun, 21 Aug 2005 18:49:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M1nDu3044139; Sun, 21 Aug 2005 18:49:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1nDK2044073 for ; Sun, 21 Aug 2005 18:49:13 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id CBC00724001; Sun, 21 Aug 2005 21:49:07 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Joe Gregorio'" Cc: "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Sun, 21 Aug 2005 21:49:07 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <3f1451f505082118345e5e18f5@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmuaBkJiuLM5rESluN6np1XuLpDAAAHxng Message-Id: <20050822014907.CBC00724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > Why not POST the Atom Entry, ala the Atom Publishing Protocol? This would be an excellent idea if what we were talking about was a low volume site. However, a site like LiveJournal generates hundreds of updates per minute. Right now, on a Sunday evening, they are updating at the rate of 349 entries per minute. During peak periods, they generate much more traffic. Generating 349 POST messages per minute to perhaps 10 or 15 different services means that they would be pumping out thousands of these things per minute. It just isn't reasonable. Using an open TCP/IP socket to carry a stream of Atom Entries results in much greater efficiencies with much reduced bandwidth and processing requirements. At PubSub, we've been experimentally providing "Fat Ping" versions of our FeedMesh feeds to a small group of testers. We publish messages at a rate much higher than LiveJournal does -- since we publish all of LiveJournal's content plus everyone else's. We couldn't even consider Fat Pings if we had to create and tear down a TCP/IP-HTTP session to post each individual entry. There are many situations in which HTTP would work fine for Fat Pings. However, for high-volume sites, it just isn't reasonable. The key, to me, is that we establish the expectation that the Atom format is adequate to the task (whatever the transport) and leave the transport selection as a context dependent decision. Thus, some server/client pairs would exchange streams of Atom entries using the POST based Atom Publishing Protocol while others would exchange essentially the same streams using a more efficient transport mechanism such as streaming raw sockets or even "Atom over XMPP". bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 22:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E71kN-00026P-UQ for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:09:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01749 for ; Sun, 21 Aug 2005 22:09:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1xXU2050829; Sun, 21 Aug 2005 18:59:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M1xX53050828; Sun, 21 Aug 2005 18:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M1xWE8050766 for ; Sun, 21 Aug 2005 18:59:32 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 2FD8A724001; Sun, 21 Aug 2005 21:59:27 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'A. Pagaltzis'" , "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Sun, 21 Aug 2005 21:59:26 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050822010107.GB7206@klangraum> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmtpq4n4BatRNgS46Xw3w2dobUIQABUZSw Message-Id: <20050822015927.2FD8A724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Aristotle Pagaltzis wrote: > I wonder how you would make sure that the document is > well-formed. Since the stream never actually ends and there > is no way for a client to signal an intent to close the connection, > the at the top would never actually be accompanied by a > at the bottom. This is a problem which has become well understood in the use and implementation of the XMPP/Jabber protocols which are based on streaming XML. Basically, what you do is consider the open tag to have a virtual closure and use it primarily as a carrier of stream metadata. In XMPP terminology, your code works at picking "stanzas" out of the stream that can be parsed successfully or unsuccessfully on their own. In an Atom stream, the processor would consider each atom:entry to be a parseable atomic unit. > If you accept that the stream can never be a complete > well-formed document, is there any reason not to simply send a > stream of concatenated Atom Entry Documents? > That would seem like the absolute simplest solution. You could certainly do that, however, you will inevitably want to pass across some stream oriented metadata and you'll eventually realize that much of it is stuff that you can map into an Atom Feed. (i.e. "created date", unique stream id, stream title, etc.). Since we're all in the process of learning how to deal with atom:feed elements anyway, why not just reuse what we've got instead of inventing something new. A rather nice side effect of forming the stream as an atom feed is the simple fact that a "log" of the stream can be written to disk as a well-formed Atom file. Thus, the same tools that you usually use to parse Atom files can be used to parse the log of the stream. It is nice to be able to reuse tools in this way... (Note: At PubSub, the atom files that we serve to people are, in essence, just slightly stripped logs of the proto-"Atom over XMPP" streams that they would have received if they had been listening with that protocol. In our clients we can use the same parser for the stream as we do for atom files. It works out nicely and elegantly.) bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 22:12:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E71nY-0002n4-7q for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:12:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01843 for ; Sun, 21 Aug 2005 22:12:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M281D4055932; Sun, 21 Aug 2005 19:08:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M281iQ055931; Sun, 21 Aug 2005 19:08:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M280ri055867 for ; Sun, 21 Aug 2005 19:08:01 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 8CB6C724001; Sun, 21 Aug 2005 22:07:55 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'A. Pagaltzis'" , "'Atom WG'" Subject: RE: Extensions at the feed level (Was: Re: geolocation in atom:author?) Date: Sun, 21 Aug 2005 22:07:55 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050822005012.GA7206@klangraum> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmtWL9eja+4tL0ShyJ+mOkCTAXfQAB+bWQ Message-Id: <20050822020755.8CB6C724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Aristotle Pagaltzis wrote: > That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a "License" that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculiarities of the legal system. One can copyright an individual thing and one can copyright a collection of things. A claim of copyright in a collection is not, however, necessarily a claim of copyright over the elements of the collection. Similarly, a claim of copyright over an element of the collection doesn't reduce any claim of copyright in the collection itself. If we assume inheritance from feed elements, then without further specification, it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts. What you'd have to do is create two distinct types of claim (one for collection and one for item. That's messy.) I'm sure that copyright and licenses aren't the only problematic contexts here. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 22:19:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E71uT-0003vy-IM for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:19:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02034 for ; Sun, 21 Aug 2005 22:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2Ex5e060298; Sun, 21 Aug 2005 19:14:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M2ExAu060297; Sun, 21 Aug 2005 19:14:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2Exwl060239 for ; Sun, 21 Aug 2005 19:14:59 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id CF2C2724001; Sun, 21 Aug 2005 22:14:53 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: Extensions at the feed level (Was: Re: geolocation inatom:author?) Date: Sun, 21 Aug 2005 22:14:53 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmtmbdu1oErLZIQRSCIyg5bKo/AAACGF4g Message-Id: <20050822021453.CF2C2724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > It's an interesting problem. A pity now that the idea of segregating > entry-defaults at the feed level didn't get sufficient momentum. > But what if there was an widely known extension developed for just > this purpose -- providing entry metadata at the feed level. Possibly > in a wrapper, possibly by flagging with an attribute. It ain't pretty. But, it would definitely help resolve a great deal of ambiguity if there was a means by which publishers could provide this sort of processing hint to intermediaries in the channel. (Consider this sort of thing to be very much like the cache control hints that folk insert in the headers of HTTP packets. Sometimes, you have to give the intermediaries like proxies, publish/subscriber routers or brokers, search engines, etc. some hints to get them to work properly.) bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 22:42:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72GN-0007j9-5t for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:42:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02861 for ; Sun, 21 Aug 2005 22:42:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2bH0E074899; Sun, 21 Aug 2005 19:37:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M2bGdE074895; Sun, 21 Aug 2005 19:37:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2bG8H074828 for ; Sun, 21 Aug 2005 19:37:16 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so556657nzi for ; Sun, 21 Aug 2005 19:37:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qoVDTvymIy1eZEBRk6gHndw1vpE5g/KalkGn4Vw585jm3xsORsAK69Ru2kXlHmMK8x3A2eMGUx0wmZn/gJnqdMgnlYuxIQaV28sWaHhEsIDLoNd/Rl8jLqgke6kZ0hSFHH9WC/NLjYmcoJyniMrXzs8e6f64TWSqwtwH5M0uX+4= Received: by 10.36.24.11 with SMTP id 11mr2289399nzx; Sun, 21 Aug 2005 19:37:10 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Sun, 21 Aug 2005 19:37:10 -0700 (PDT) Message-ID: <3f1451f50508211937d4e3659@mail.gmail.com> Date: Sun, 21 Aug 2005 22:37:10 -0400 From: Joe Gregorio To: bobwyman@pubsub.com Subject: Re: If you want "Fat Pings" just use Atom! Cc: Atom Syntax In-Reply-To: <20050822014907.CBC00724001@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3f1451f505082118345e5e18f5@mail.gmail.com> <20050822014907.CBC00724001@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7M2bG8H074890 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/21/05, Bob Wyman wrote: > Joe Gregorio wrote: > > Why not POST the Atom Entry, ala the Atom Publishing Protocol? > This would be an excellent idea if what we were talking about was a > low volume site. However, a site like LiveJournal generates hundreds of > updates per minute. Right now, on a Sunday evening, they are updating at the > rate of 349 entries per minute. During peak periods, they generate much more > traffic. Generating 349 POST messages per minute to perhaps 10 or 15 > different services means that they would be pumping out thousands of these > things per minute. It just isn't reasonable. > Using an open TCP/IP socket to carry a stream of Atom Entries > results in much greater efficiencies with much reduced bandwidth and > processing requirements. Why can't you keep that socket open, that is the default behavior for HTTP 1.1. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Aug 21 22:46:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72Kc-00006B-5n for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:46:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02974 for ; Sun, 21 Aug 2005 22:46:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2fARH077382; Sun, 21 Aug 2005 19:41:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M2fAfn077379; Sun, 21 Aug 2005 19:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2fAMT077315 for ; Sun, 21 Aug 2005 19:41:10 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so588887nzb for ; Sun, 21 Aug 2005 19:41:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M6VQVoasjQsJePtPzwvbNA7mQ9PDHxmBQiNet0PJoKhOHor60/wn03SnEBIxoL1r3jahY/mNJtDnX6/KV9kfvgB4o8FiNoQCpl6V63C4tfyWLmceB2KTybekzXm4oBZ+tTVs83OGTUTKEqt5Jf5zQk43H8jMvqmYYXYwmY0Dl4E= Received: by 10.36.90.20 with SMTP id n20mr3903152nzb; Sun, 21 Aug 2005 19:41:04 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id r1sm171031nzd.2005.08.21.19.41.03; Sun, 21 Aug 2005 19:41:04 -0700 (PDT) Message-ID: <43093B3B.2070105@gmail.com> Date: Sun, 21 Aug 2005 19:40:59 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'Joe Gregorio'" , "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050822014907.CBC00724001@mail.pubsub.com> In-Reply-To: <20050822014907.CBC00724001@mail.pubsub.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: Content-Transfer-Encoding: 7bit Bob Wyman wrote: >Joe Gregorio wrote: > > >>Why not POST the Atom Entry, ala the Atom Publishing Protocol? >> >> > This would be an excellent idea if what we were talking about was a >low volume site. However, a site like LiveJournal generates hundreds of >updates per minute. Right now, on a Sunday evening, they are updating at the >rate of 349 entries per minute. During peak periods, they generate much more >traffic. Generating 349 POST messages per minute to perhaps 10 or 15 >different services means that they would be pumping out thousands of these >things per minute. It just isn't reasonable. > Using an open TCP/IP socket to carry a stream of Atom Entries >results in much greater efficiencies with much reduced bandwidth and >processing requirements. > At PubSub, we've been experimentally providing "Fat Ping" versions >of our FeedMesh feeds to a small group of testers. We publish messages at a >rate much higher than LiveJournal does -- since we publish all of >LiveJournal's content plus everyone else's. We couldn't even consider Fat >Pings if we had to create and tear down a TCP/IP-HTTP session to post each >individual entry. > There are many situations in which HTTP would work fine for Fat >Pings. However, for high-volume sites, it just isn't reasonable. The key, to >me, is that we establish the expectation that the Atom format is adequate to >the task (whatever the transport) and leave the transport selection as a >context dependent decision. Thus, some server/client pairs would exchange >streams of Atom entries using the POST based Atom Publishing Protocol while >others would exchange essentially the same streams using a more efficient >transport mechanism such as streaming raw sockets or even "Atom over XMPP". > > > First off, as a general FYI, take a look at PaceSimpleNotify... the current version uses basic HTTP POSTs to send one or more individual atom:entry's to a remote endpoint. I'm hoping that the folks on the protocol list will pick this up in discussion in the near future as it is something that I definitely want to see incorporated. Secondly, I believe that the format is more than adequate to support this kind of mechanism. I do not believe that Brad's atomStream container is necessary. Either just stream a bunch of atom:feed or atom:entry elements directly over an open TCP/IP or a persistent (keep-alive) HTTP connection. By no means would I ever suggest a new HTTP connection for each ping. - James From owner-atom-syntax@mail.imc.org Sun Aug 21 22:49:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72Nj-0000WG-Cq for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:49:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03064 for ; Sun, 21 Aug 2005 22:49:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2gd00078534; Sun, 21 Aug 2005 19:42:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M2gdeN078532; Sun, 21 Aug 2005 19:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M2gcPD078461 for ; Sun, 21 Aug 2005 19:42:38 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so557137nzi for ; Sun, 21 Aug 2005 19:42:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=U3HO7Ag8Mtfun36FK3D0kC+eatheL7esJct16RfJQ49LNrMGmDXH0O8id2EXzN4T/zNwKqwZMc8LDzQcgh+m6S84ipPw65HnQXS6zu5rfkNYLitnFrSVlzSDaGykpy1DClmyxYK60BCIzBvNcp97M0mkmc9PdnqYIlX066m/Cak= Received: by 10.36.148.16 with SMTP id v16mr3622649nzd; Sun, 21 Aug 2005 19:42:32 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 24sm3337295nzn.2005.08.21.19.42.32; Sun, 21 Aug 2005 19:42:32 -0700 (PDT) Message-ID: <43093B94.9040406@gmail.com> Date: Sun, 21 Aug 2005 19:42:28 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: Atom WG Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> <43090194.9050300@gmail.com> <20050822005012.GA7206@klangraum> In-Reply-To: <20050822005012.GA7206@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: >And with that, getting back to your question, the answer seems >pretty clear: it depends on whether the extension element is more >like atom:contributor, ie defines a property which an entry may >or may not have, or more like atom:author, ie defines a property >that every entry inevitably has. > >But because that is a matter of interpretation, I would strongly >prefer to say that if the extension does not specify a meaning >for an element at the feed level, then the meaning is undefined. > >On the other, related point, the same principle of avoiding the >necessity of complicated override mechanisms is why I say that >aggregators should assume that unknown extension elements (which >therefore have *unknown* as opposed to *undefined* semantics) >pertain only to the feed, not to its entries. > > > Ok, I retract my earlier comment about apps not making any assumptions about unknown extensions. This is better. Regarding Bob Wyman's separate note about what aggregators like pubsub should do, If the aggregator is generating the source element, the aggregator should include everything it finds in the feed.. even if it does not understand it. If the entry already contains a source element, leave it as is. - James From owner-atom-syntax@mail.imc.org Sun Aug 21 23:07:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72et-00037V-1L for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:07:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03716 for ; Sun, 21 Aug 2005 23:07:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M32Cqx091266; Sun, 21 Aug 2005 20:02:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M32CIp091265; Sun, 21 Aug 2005 20:02:12 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7M32AaH091171 for ; Sun, 21 Aug 2005 20:02:11 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 03:02:04 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp019) with SMTP; 22 Aug 2005 05:02:04 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 05:02:11 +0200 From: "'A. Pagaltzis'" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822030211.GB7722@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050822010107.GB7206@klangraum> <20050822015927.2FD8A724001@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050822015927.2FD8A724001@mail.pubsub.com> 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 ietf.org id XAA03716 * Bob Wyman [2005-08-22 04:00]: > Basically, what you do is consider the open tag to have a > virtual closure and use it primarily as a carrier of stream > metadata. Shades of SGML=E2=80=A6 > You could certainly do that, however, you will inevitably want > to pass across some stream oriented metadata and you'll > eventually realize that much of it is stuff that you can map > into an Atom Feed OT1H, you could put this data in the stream as an empty but complete Atom Feed Document served as the first complete entity in the feed =E2=80=93 > A rather nice side effect of forming the stream as an atom feed > is the simple fact that a "log" of the stream can be written to > disk as a well-formed Atom file. =E2=80=93 but OTOH this is a pretty good point. Of course, the question is whether it is really any more work to receive an empty Atom Feed Document + X * Atom Entry Documents and to insert the Entry Documents into the Feed Document for storage. Note that in the case of prepending an empty Atom Feed Document, all fully received Documents are well-formed entities of their own, so you don=E2=80=99t need a recovering XML parser that can implement the =E2=80=9Cvirtual closing element=E2=80=9D semantic =E2=80=93 all enti= ties can be processed with any run-of-the-mill XML parser. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 23:12:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72k1-0003po-OS for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:12:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03898 for ; Sun, 21 Aug 2005 23:12:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M38AqM095129; Sun, 21 Aug 2005 20:08:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M38A8q095128; Sun, 21 Aug 2005 20:08:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M389RF095082 for ; Sun, 21 Aug 2005 20:08:09 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 5CA09724001; Sun, 21 Aug 2005 23:08:04 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Joe Gregorio'" Cc: "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Sun, 21 Aug 2005 23:08:04 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <3f1451f50508211937d4e3659@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmwmWy4aaVygzeR5aJwh/3OXBbEgAAjw3Q Message-Id: <20050822030804.5CA09724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > Why can't you keep that socket open, that is the default > behavior for HTTP 1.1. In some applications, HTTP 1.1 will work just fine. However, HTTP doesn't add much to the high volume case. It also costs a great deal. For instance, every POST requires a response. This means that you're moving from a pure streaming case to an endless sequence of application level ACK/NAKs that are simply replicating what TCP/IP already does for you. Also, the HTTP headers that would be required simply don't contribute anything useful. The bandwidth overhead of the additional headers as well as the bandwidth, processing and timing problems related to generating responses begins to look pretty nasty when you're moving at hundreds of items per minute or second... One really good reason for using HTTP would be to exploit the existing HTTP infrastructure including proxies, caches, application-level firewalls, etc. However, I'm aware of no such infrastructure components that are designed to handle well permanently open high-bandwidth connections. The HTTP infrastructure is optimized around the normal uses of HTTP. This isn't "normal." One of the really irritating things about the current HTTP infrastructure is that it is very "fragile." This is a problem that has caused unlimited headaches for the folk trying to do "notification over HTTP" (mod-pubsub, KnowNow, various HTTP-based IM/chat systems, etc.). The problem is that HTTP connections, given the current infrastructure and standard components, are very hard to keep open "permanently" or for a very long period of time. One is often considered lucky if you can keep an HTTP connection open for 5 minutes without having to re-initialize... Of course, during the period between when your connection breaks and when you get it re-established, you're losing packets. That means that you have to have a much more robust mechanism for recovering lost messages and that means increased complexity, network traffic, etc. The added complexity and trouble can be justified in some cases; however, not in all cases. HTTP is great in some cases but not all. That's why the IETF has defined BEEP, XMPP, SIP, SIMPLE, etc. in addition to HTTP. One protocol model simply can't suit all needs at all times and in all contexts. Whatever... The point here is that Atom already has defined all that appears to be needed in order to address the "Fat Ping" requirement whether you prefer individual HTTP POSTs, POSTs over HTTP 1.1 connections, XMPP, or raw open TCP/IP sockets. That is a good thing. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 23:30:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E730s-0006Ol-Gq for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:30:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04757 for ; Sun, 21 Aug 2005 23:30:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3QHLH006093; Sun, 21 Aug 2005 20:26:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3QH1B006092; Sun, 21 Aug 2005 20:26:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7M3QFof006016 for ; Sun, 21 Aug 2005 20:26:16 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 03:26:10 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp007) with SMTP; 22 Aug 2005 05:26:10 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 05:26:16 +0200 From: "A. Pagaltzis" To: Robin Cover Cc: Atom Syntax Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Message-ID: <20050822032616.GC7722@klangraum> Mail-Followup-To: Robin Cover , Atom Syntax References: <20050822005012.GA7206@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id XAA04757 * Robin Cover [2005-08-22 05:05]: > On Mon, 22 Aug 2005, A. Pagaltzis wrote: > > That issue is inheritance. > >=20 > > atom:author is the only precedent for it in Atom. >=20 > If "it" in "only precedent for it" refers to inhertance, can > you explain the sense in which "atom:author is the only > precedent" ? >=20 > xml:lang, Sure, then you can also cite xml:base and possibly more. But these are irrelevant =E2=80=93 they they work on a different layer and have no concept of =E2=80=9Cfeed-level=E2=80=9D or =E2=80=9Centry-level.=E2= =80=9D They=E2=80=99re possibly better described as annotations at the XML level, as opposed to metadata at the Atom model level. And with both of them being attributes, the cardinality is trivial and known in advance: zero or one. Thus the override mechanism is universally obvious in advance. They have nothing in common with extension elements as per the semantics defined in the Atom Format specification. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 23:31:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E731y-0006Ru-K4 for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:31:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04764 for ; Sun, 21 Aug 2005 23:31:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3Op7t005200; Sun, 21 Aug 2005 20:24:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3OpxD005199; Sun, 21 Aug 2005 20:24:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3OogY005138 for ; Sun, 21 Aug 2005 20:24:50 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 1DA01724001; Sun, 21 Aug 2005 23:24:45 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'A. Pagaltzis'" , "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Sun, 21 Aug 2005 23:24:45 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050822030211.GB7722@klangraum> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmx/iikH3uFNspQ861ORxQ2+R97wAAEdJA Message-Id: <20050822032445.1DA01724001@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Aristotle Pagaltzis wrote: > Shades of SGML. No! No! Not that! :-) He continues with: > ... many good points .... Basically, there are many really easy ways that one can handle streams of Atom entries. You could prepend an empty feed to the head of the stream, you could use "virtual" end-tags, you could just send entries and rely on the receiver to wrap them up as required, etc... But, since all of these are really easy and none of them really gets in the way of anything rational that I can imagine someone wanting to do, why not just default to doing it the way it is defined in the Atom spec? In that way, we don't have to create one more context-dependent distinction between formats. Complexity is reduced and we can avoid having to read yet-another-specification that looks very, very much like hundreds we've read before. If Atom provides all we need, lets not do something else unless there is a *very* good argument to do so. bob wyman From owner-atom-syntax@mail.imc.org Sun Aug 21 23:32:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7334-0006f6-CP for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:32:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04825 for ; Sun, 21 Aug 2005 23:32:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3Punf005861; Sun, 21 Aug 2005 20:25:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3Pu71005860; Sun, 21 Aug 2005 20:25:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3Ptel005790 for ; Sun, 21 Aug 2005 20:25:55 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so560666nzi for ; Sun, 21 Aug 2005 20:25:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GNP2mg2HNwQxMNwq0V3k4xpSwTsuRk/zryopB63dH124ggRTkqvuSm1CH58RGXbzYhiqHFynjbUtmozyKmYtO+/wql/DZIUHq/ynZUUjagSVJHzLNc1cdKQoZMiMVj7yeJhHA9ALPgY+Bhl1LRz/b0esqXc4uRUZvcZfIuQdn/4= Received: by 10.36.146.20 with SMTP id t20mr3751943nzd; Sun, 21 Aug 2005 20:25:49 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 23sm3317521nzn.2005.08.21.20.25.49; Sun, 21 Aug 2005 20:25:49 -0700 (PDT) Message-ID: <430945B9.1090403@gmail.com> Date: Sun, 21 Aug 2005 20:25:45 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'A. Pagaltzis'" , "'Atom WG'" Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <20050822020755.8CB6C724001@mail.pubsub.com> In-Reply-To: <20050822020755.8CB6C724001@mail.pubsub.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: Content-Transfer-Encoding: 7bit Bob Wyman wrote: >Aristotle Pagaltzis wrote: > > >>That issue is inheritance. >> >> > Let me give an example of problematic inheritance... > Some have suggested that there be a "License" that you can associate >with Atom feeds and entries. However, scoping becomes very important in this >case because of some peculiarities of the legal system. > One can copyright an individual thing and one can copyright a >collection of things. A claim of copyright in a collection is not, however, >necessarily a claim of copyright over the elements of the collection. >Similarly, a claim of copyright over an element of the collection doesn't >reduce any claim of copyright in the collection itself. > If we assume inheritance from feed elements, then without further >specification, it isn't possible to claim copyright in the collection that >is the feed without claiming copyright in its individual parts. What you'd >have to do is create two distinct types of claim (one for collection and one >for item. That's messy.) > I'm sure that copyright and licenses aren't the only problematic >contexts here. > > bob wyman > > > > > From the format text: "If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above." This really does not describe an inheritance model*. This describes a scoping model. If an entry does not contain an author, the author on the feed is said to apply. If the entry does happen to have an author, it doesn't matter if the feed also has an author, it is the author element on the entry that applies to the entry. Same thing with the license extension (for example). If both the feed and entry contain license links, it is the license link on the entry that is relevant to the entry. If the entry does not contain a license, it looks to the feed level. Placing a license on the feed level does not change the license of the entry if the entry already has a license. There is another example of this kind of scoping that we're all intimately familiar with: From Section 5.1 of Namespaces in XML: "The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden by another namespace declaration" (http://www.w3.org/TR/REC-xml-names/#scoping) To directly address Bob's point that "it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts" -- it IS possible if we are looking at this in terms of relevant scope as opposed to inherited properties. Note to self: I need to fix the license spec to address this. Currently the spec limits the license relevance to entries without providing a mechanism for attaching a license to the feed itself. Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... - James * I've called this inheritance in the past but now I do believe that I was mistaken. From owner-atom-syntax@mail.imc.org Sun Aug 21 23:43:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73Dq-00087G-Qy for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:43:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05203 for ; Sun, 21 Aug 2005 23:43:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3dabR014542; Sun, 21 Aug 2005 20:39:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3dant014541; Sun, 21 Aug 2005 20:39:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7M3dYmZ014468 for ; Sun, 21 Aug 2005 20:39:34 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 03:39:29 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp029) with SMTP; 22 Aug 2005 05:39:29 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 05:39:35 +0200 From: "'A. Pagaltzis'" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822033935.GD7722@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050822030211.GB7722@klangraum> <20050822032445.1DA01724001@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050822032445.1DA01724001@mail.pubsub.com> 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 ietf.org id XAA05203 * Bob Wyman [2005-08-22 05:25]: > If Atom provides all we need, lets not do something else unless > there is a *very* good argument to do so. I=E2=80=99m not inventing anything. Atom Entry Documents are part of the spec and Atom Feed Documents may legally be empty. And a consumer of a stream according to your proposition does not get away without implementing some special ability to be able to interpret it correctly anyway =E2=80=93 you are using =E2=80=9Cplain Atom= =E2=80=9D at the cost of requiring a specifically abled XML parser. My proposition requires a trivial amount of extra semantics implemented at the application logic level; yours requires extra semantics at the protocol logic level (the protocol being XML). I think doing this in application logic is so cheap that reaching for the protocol logic is unwarranted. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sun Aug 21 23:43:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73Dr-00087U-GZ for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:43:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05206 for ; Sun, 21 Aug 2005 23:43:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3aBoK012457; Sun, 21 Aug 2005 20:36:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3aBCA012456; Sun, 21 Aug 2005 20:36:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3a9pI012373 for ; Sun, 21 Aug 2005 20:36:10 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so594326nzb for ; Sun, 21 Aug 2005 20:36:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YrKK9BW1hWMFmJNNtC6AM7HiSgiqzqiJsqErSP8L2+DOLmL8EX44j7Yl/pOwM8XLHdCloX8ATbGCaD2MTYsAoYAExxmZlkPE2CVpGhpKPmwIGvN5Ikg3uKni3xHjWVeUIouIZKhzZUjYButWy8DYdA62jPkbB7q8KdWhEAltd0o= Received: by 10.36.221.9 with SMTP id t9mr3309367nzg; Sun, 21 Aug 2005 20:36:03 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id r15sm1076680nza.2005.08.21.20.36.03; Sun, 21 Aug 2005 20:36:03 -0700 (PDT) Message-ID: <4309481E.8020203@gmail.com> Date: Sun, 21 Aug 2005 20:35:58 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: Robin Cover , Atom Syntax Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <20050822005012.GA7206@klangraum> <20050822032616.GC7722@klangraum> In-Reply-To: <20050822032616.GC7722@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id XAA05206 A. Pagaltzis wrote: >* Robin Cover [2005-08-22 05:05]: > =20 > >>On Mon, 22 Aug 2005, A. Pagaltzis wrote: >> =20 >> >>>That issue is inheritance. >>> >>>atom:author is the only precedent for it in Atom. >>> =20 >>> >>If "it" in "only precedent for it" refers to inhertance, can >>you explain the sense in which "atom:author is the only >>precedent" ? >> >>xml:lang, >> =20 >> > >Sure, then you can also cite xml:base and possibly more. But >these are irrelevant =E2=80=93 they they work on a different layer and >have no concept of =E2=80=9Cfeed-level=E2=80=9D or =E2=80=9Centry-level.= =E2=80=9D They=E2=80=99re >possibly better described as annotations at the XML level, as >opposed to metadata at the Atom model level. > > =20 > And yet in the spec we constrain the relevance of xml:lang and xml:base=20 to specific elements. Sure, they operate on the XML level, but they do=20 have relevance on the feed/entry level. Not that this changes your=20 argument, it's just an observation that xml:lang and xml:base are not=20 entirely dissimilar to atom:author. - James From owner-atom-syntax@mail.imc.org Sun Aug 21 23:50:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73Ka-0000c6-Ku for atompub-archive@megatron.ietf.org; Sun, 21 Aug 2005 23:50:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05490 for ; Sun, 21 Aug 2005 23:50:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3iN2n017468; Sun, 21 Aug 2005 20:44:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3iNOr017467; Sun, 21 Aug 2005 20:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3iMQX017406 for ; Sun, 21 Aug 2005 20:44:22 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so561993nzi for ; Sun, 21 Aug 2005 20:44:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bWUiZmFt8JBzFGVGGNwBpQkobYATr/8VUe5FWQgquCSMyGCN/iPVjywQSKPZYeyld/PgGYEySS1j1xAHMEfk7fHfJq5ABob3KHelwAU2ZXLoMxZYxNKG4tWYabeeF7+6r4BoY+LV5GKpVwK+MCqenlmfGZMduToKWNJIEQonnuE= Received: by 10.36.10.20 with SMTP id 20mr1213798nzj; Sun, 21 Aug 2005 20:44:17 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 5sm5349023nzk.2005.08.21.20.44.16; Sun, 21 Aug 2005 20:44:17 -0700 (PDT) Message-ID: <43094A0D.9090609@gmail.com> Date: Sun, 21 Aug 2005 20:44:13 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'A. Pagaltzis'" , "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050822032445.1DA01724001@mail.pubsub.com> In-Reply-To: <20050822032445.1DA01724001@mail.pubsub.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: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Basically, there are many really easy ways that one can handle >streams of Atom entries. You could prepend an empty feed to the head of the >stream, you could use "virtual" end-tags, you could just send entries and >rely on the receiver to wrap them up as required, etc... But, since all of >these are really easy and none of them really gets in the way of anything >rational that I can imagine someone wanting to do, why not just default to >doing it the way it is defined in the Atom spec? In that way, we don't have >to create one more context-dependent distinction between formats. Complexity >is reduced and we can avoid having to read yet-another-specification that >looks very, very much like hundreds we've read before. If Atom provides all >we need, lets not do something else unless there is a *very* good argument >to do so. > > bob wyman > > > > +1. The basic format gives us everything we need to enable this. Even looking back over my PaceSimpleNotify proposal.. in which I introduce a notification element used to identify the action that has occurred on the element (e.g. create, update or delete), I can see that there really is no need to have that element. - James From owner-atom-syntax@mail.imc.org Mon Aug 22 00:00:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E73UU-000299-Nl for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 00:00:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05792 for ; Mon, 22 Aug 2005 00:00:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M3qqMR022652; Sun, 21 Aug 2005 20:52:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M3qql6022650; Sun, 21 Aug 2005 20:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7M3qp61022580 for ; Sun, 21 Aug 2005 20:52:51 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 03:52:45 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp010) with SMTP; 22 Aug 2005 05:52:45 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 05:52:52 +0200 From: "'A. Pagaltzis'" To: "'Atom WG'" Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Message-ID: <20050822035252.GE7722@klangraum> Mail-Followup-To: 'Atom WG' References: <20050822020755.8CB6C724001@mail.pubsub.com> <430945B9.1090403@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430945B9.1090403@gmail.com> 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: * James M Snell [2005-08-22 05:30]: > Second note to self: After thinking about this a bit more, I > would also need a way of specifying a null license (e.g. the > lack of a license). For instance, what if an entry that does > not contain a license is aggregated into a feed that has a > license. The original lack-of-license still applies to that > entry regardless of what is specified on the feed level. Golly > Bob, you're right, this is rather messy ain't it. Hmm... This is exactly the point I was making about atom:contributor. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 22 00:41:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E747q-0007xl-Mw for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 00:41:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07359 for ; Mon, 22 Aug 2005 00:41:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M4aKD4048784; Sun, 21 Aug 2005 21:36:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M4aK0x048779; Sun, 21 Aug 2005 21:36:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m70095e42.tmodns.net [66.94.9.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M4aJDt048742 for ; Sun, 21 Aug 2005 21:36:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 60CF399D7; Sun, 21 Aug 2005 23:27:39 -0500 (CDT) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20615-05; Sun, 21 Aug 2005 23:27:38 -0500 (CDT) Received: from [10.224.12.90] (90.12.224.10.in-addr.arpa [10.224.12.90]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sun, 21 Aug 2005 23:27:38 -0500 (CDT) Message-ID: <43095641.1090700@intertwingly.net> Date: Mon, 22 Aug 2005 00:36:17 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" Cc: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> In-Reply-To: <20050822010107.GB7206@klangraum> 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: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: > * Bob Wyman [2005-08-22 01:05]: > >>What do you think? Is there any conceptual problem with >>streaming basic Atom over TCP/IP, HTTP continuous sessions >>(probably using chunked content) etc.? > > I wonder how you would make sure that the document is > well-formed. Since the stream never actually ends and there is no > way for a client to signal an intent to close the connection, the > at the top would never actually be accompanied by a > at the bottom. > > If you accept that the stream can never be a complete well-formed > document, is there any reason not to simply send a stream of > concatenated Atom Entry Documents? > > That would seem like the absolute simplest solution. I think the keyword in the above is "complete". SAX is a popular API for dealing with streaming XML (and there are a number of "pull parsing" APIs too). It makes individual elements available to your application as they are read. If at any point, the SAX parser determines that your feed is not well formed, it throws an error at that point. With a HTTP client library and SAX, the "absolute simplest solution" is what Bob is describing: a single document that never completes. Note that if your application were to discard all the data it receives before it encouters the first entry, the stream from there on out would be identical. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 22 00:42:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7490-0008Bp-MD for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 00:42:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07434 for ; Mon, 22 Aug 2005 00:42:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M4aALl048671; Sun, 21 Aug 2005 21:36:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M4aAqR048670; Sun, 21 Aug 2005 21:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m70095e42.tmodns.net [66.94.9.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M4a910048611 for ; Sun, 21 Aug 2005 21:36:09 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 54ACC99D7; Sun, 21 Aug 2005 23:27:26 -0500 (CDT) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20614-05; Sun, 21 Aug 2005 23:27:25 -0500 (CDT) Received: from [10.224.12.90] (90.12.224.10.in-addr.arpa [10.224.12.90]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sun, 21 Aug 2005 23:27:25 -0500 (CDT) Message-ID: <43095633.5020008@intertwingly.net> Date: Mon, 22 Aug 2005 00:36:03 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio Cc: bobwyman@pubsub.com, Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> In-Reply-To: <3f1451f505082118345e5e18f5@mail.gmail.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: Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > Why not POST the Atom Entry, ala the Atom Publishing Protocol? Essentially, LiveJournal is making this data available to anybody who wishes to access it, without any need to register or to invent a unique API. I can, and have, accessed the LiveJournal stream from behind both a firewall and a NAT device. Doing so requires the client to initiate the request. Therefore, if you really wanted to turn this around, the client would need to initiate a POST, and the server would need to return the "Fat Pings" as the response. I talked to Brad - in fact, I had independently made the same suggestion that Bob did. Brad indicated that if there were clients with different requirements, he was amenable to accommodating each - endpoints are cheap. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Aug 22 01:47:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E759v-0001Hq-Pi for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 01:47:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10084 for ; Mon, 22 Aug 2005 01:47:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M5YQIh096318; Sun, 21 Aug 2005 22:34:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M5YQig096317; Sun, 21 Aug 2005 22:34:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7M5YOhK096209 for ; Sun, 21 Aug 2005 22:34:25 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 05:34:19 -0000 Received: from xdsl-213-196-221-213.netcologne.de (EHLO klangraum) [213.196.221.213] by mail.gmx.net (mp004) with SMTP; 22 Aug 2005 07:34:19 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 07:34:26 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822053426.GA8900@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <43095641.1090700@intertwingly.net> 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 ietf.org id BAA10084 * Sam Ruby [2005-08-22 06:45]: > SAX is a popular API for dealing with streaming XML (and there > are a number of "pull parsing" APIs too). Of course =E2=80=93 using a DOM parser is impossible with either approach anyway. > With a HTTP client library and SAX, the "absolute simplest > solution" is what Bob is describing: a single document that > never completes. That can be argued both ways, I think. The important point is that the connection can and almost certainly will be closed in the middle of an entry document. With a single, endless document, the application will have to backtrack, discarding events until it has thrown away the last seen start-element event for the incomplete entry, then close the feed element. With a series of concatenated complete documents, it can simply discard everything that belongs to the current incomplete Entry Document. There are implicit checkpoints in the stream. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 22 03:46:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7714-0003ld-HC for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 03:46:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28852 for ; Mon, 22 Aug 2005 03:46:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M7aOuq012350; Mon, 22 Aug 2005 00:36:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7M7aOhA012349; Mon, 22 Aug 2005 00:36:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7M7aNrZ012237 for ; Mon, 22 Aug 2005 00:36:24 -0700 (PDT) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by ptb-relay01.plus.net with esmtp (Exim) id 1E76qu-00048h-BV for atom-syntax@imc.org; Mon, 22 Aug 2005 08:36:16 +0100 To: atom-syntax@imc.org (Atom Syntax) In-Reply-To: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> Subject: Re: geolocation in atom:author? From: pmrobinson@gmx.net (Peter Robinson) Date: Mon, 22 Aug 2005 08:36:16 +0100 Message-ID: <1h1oszv.1efm9koujf3mbM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.9) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter Robinson wrote: > I do something similar, intending it to mean "the location of the items > described by this feed" (when there is a single location). > To the person looking for items near Park Avenue & 38th, New York. The third bit of s_geo is a radius (in km) and it's required. Try this: http://www.ticketswitch.com/cgi-bin/atom_feed.exe?s_geo=40.75:-73.98:10 Regards, Big Brother From owner-atom-syntax@mail.imc.org Mon Aug 22 10:13:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7D2w-0000Wc-Oa for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 10:13:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17776 for ; Mon, 22 Aug 2005 10:13:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MDx7br036494; Mon, 22 Aug 2005 06:59:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MDx7M4036493; Mon, 22 Aug 2005 06:59:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MDx6vn036355 for ; Mon, 22 Aug 2005 06:59:07 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 80607 messnum 3317861 invoked from network[83.70.255.222/83-70-255-222.b-ras1.prp.dublin.eircom.net]); 22 Aug 2005 13:58:59 -0000 Received: from 83-70-255-222.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.255.222) by mail05.svc.cra.dublin.eircom.net (qp 80607) with SMTP; 22 Aug 2005 13:58:59 -0000 Message-ID: <4309DA22.2040803@dehora.net> Date: Mon, 22 Aug 2005 14:58:58 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'A. Pagaltzis'" , "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050822015927.2FD8A724001@mail.pubsub.com> In-Reply-To: <20050822015927.2FD8A724001@mail.pubsub.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Aristotle Pagaltzis wrote: > >>I wonder how you would make sure that the document is >>well-formed. Since the stream never actually ends and there >>is no way for a client to signal an intent to close the connection, >>the at the top would never actually be accompanied by a >> at the bottom. > > This is a problem which has become well understood in the use and > implementation of the XMPP/Jabber protocols which are based on streaming > XML. It is: every XMPP server has a hack to deal with it ;) > Basically, what you do is consider the open tag to have a virtual > closure and use it primarily as a carrier of stream metadata. In XMPP > terminology, your code works at picking "stanzas" out of the stream that can > be parsed successfully or unsuccessfully on their own. In an Atom stream, > the processor would consider each atom:entry to be a parseable atomic unit. How XMPP does that opening stanza thing and then proceeds to not close it is not a design to be emulated (imvho). The opening stanza should arrived and be closed. >>If you accept that the stream can never be a complete >>well-formed document, is there any reason not to simply send a >>stream of concatenated Atom Entry Documents? >>That would seem like the absolute simplest solution. > > You could certainly do that, however, you will inevitably want to > pass across some stream oriented metadata and you'll eventually realize that > much of it is stuff that you can map into an Atom Feed. (i.e. "created > date", unique stream id, stream title, etc.). Since we're all in the process > of learning how to deal with atom:feed elements anyway, why not just reuse > what we've got instead of inventing something new. In the Atom case, I don't see why you need to keep the atom:feed open. Just send it once and then send entries in the raw. > A rather nice side effect of forming the stream as an atom feed is > the simple fact that a "log" of the stream can be written to disk as a > well-formed Atom file. Thus, the same tools that you usually use to parse > Atom files can be used to parse the log of the stream. It is nice to be able > to reuse tools in this way... (Note: At PubSub, the atom files that we serve > to people are, in essence, just slightly stripped logs of the proto-"Atom > over XMPP" streams that they would have received if they had been listening > with that protocol. In our clients we can use the same parser for the stream > as we do for atom files. It works out nicely and elegantly.) For high load scenarios using Atom/XMPP to decouple the atom processing from xmpp stream handling you can use the log you're talking about as a poor-man's message queue. cheers Bill From owner-atom-syntax@mail.imc.org Mon Aug 22 10:33:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DMP-0004d5-7a for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 10:33:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19541 for ; Mon, 22 Aug 2005 10:33:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MER6Tp062359; Mon, 22 Aug 2005 07:27:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MER6wx062357; Mon, 22 Aug 2005 07:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MER4rC062277 for ; Mon, 22 Aug 2005 07:27:04 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so610255nzi for ; Mon, 22 Aug 2005 07:26:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NGh6MuDpTFqRgWzlvO54nFD4xf0fdGfRzO+1bw7w+2GHX7VNMHRfdWbdLDp+S5/P1MyFNZaR2SKlwrDdeIz6R4baqoXT/51unmRzhVFI3w09qE6pkk0e5fgRsVXQTS9aTpjtw6TnQIRk4bW+CRi9TcVhW5ABOx8SI+wrEzn4qM4= Received: by 10.36.57.11 with SMTP id f11mr4160895nza; Mon, 22 Aug 2005 07:26:59 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Mon, 22 Aug 2005 07:26:59 -0700 (PDT) Message-ID: <3f1451f505082207262ab386df@mail.gmail.com> Date: Mon, 22 Aug 2005 10:26:59 -0400 From: Joe Gregorio To: Sam Ruby Subject: Re: If you want "Fat Pings" just use Atom! Cc: bobwyman@pubsub.com, Atom Syntax In-Reply-To: <43095633.5020008@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MER6rC062352 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/22/05, Sam Ruby wrote: > Joe Gregorio wrote: > > Why not POST the Atom Entry, ala the Atom Publishing Protocol? > > Essentially, LiveJournal is making this data available to anybody who > wishes to access it, without any need to register or to invent a unique API. Ahh, I had thought this was a more dedicated ping traffic stream. The never ending Atom document makes much more sense now. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 22 11:59:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ehw-0005BS-L7 for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 11:59:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24393 for ; Mon, 22 Aug 2005 11:59:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MFnBwk012568; Mon, 22 Aug 2005 08:49:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MFnBVW012567; Mon, 22 Aug 2005 08:49:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MFnAAt012492 for ; Mon, 22 Aug 2005 08:49:11 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 75130 messnum 11067345 invoked from network[83.70.255.222/83-70-255-222.b-ras1.prp.dublin.eircom.net]); 22 Aug 2005 15:49:03 -0000 Received: from 83-70-255-222.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.255.222) by mail11.svc.cra.dublin.eircom.net (qp 75130) with SMTP; 22 Aug 2005 15:49:03 -0000 Message-ID: <4309F3ED.9020302@dehora.net> Date: Mon, 22 Aug 2005 16:49:01 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James M Snell CC: bobwyman@pubsub.com, "'A. Pagaltzis'" , "'Atom WG'" Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <20050822020755.8CB6C724001@mail.pubsub.com> <430945B9.1090403@gmail.com> In-Reply-To: <430945B9.1090403@gmail.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit James M Snell wrote: > > Bob Wyman wrote: > >> Aristotle Pagaltzis wrote: >> >> >>> That issue is inheritance. >>> >> >> Let me give an example of problematic inheritance... >> Some have suggested that there be a "License" that you can associate >> with Atom feeds and entries. However, scoping becomes very important >> in this >> case because of some peculiarities of the legal system. >> One can copyright an individual thing and one can copyright a >> collection of things. A claim of copyright in a collection is not, >> however, >> necessarily a claim of copyright over the elements of the collection. >> Similarly, a claim of copyright over an element of the collection doesn't >> reduce any claim of copyright in the collection itself. >> If we assume inheritance from feed elements, then without further >> specification, it isn't possible to claim copyright in the collection >> that >> is the feed without claiming copyright in its individual parts. What >> you'd >> have to do is create two distinct types of claim (one for collection >> and one >> for item. That's messy.) >> I'm sure that copyright and licenses aren't the only problematic >> contexts here. >> >> bob wyman >> >> >> >> >> > From the format text: "If an atom:entry element does not contain > atom:author elements, then the atom:author elements of the contained > atom:source element are considered to apply. In an Atom Feed Document, > the atom:author elements of the containing atom:feed element are > considered to apply to the entry if there are no atom:author elements in > the locations described above." > > This really does not describe an inheritance model*. This describes a > scoping model. If an entry does not contain an author, the author on > the feed is said to apply. "scope" v "inheritance": call what you like, it's still undefined. 1. We didn't do that, I imagine because it was 'simpler' to say nothing than introduce formalism. The only person that has tried to formally define the relationship is Henry afaik. Unless we have defined clearly the semantics of the relationship between a feed and a entry*, we're hosed if we start trying to figure out the logical implications of domain and range of metadata - whatever we conclude, unless it gets baked into a spec as a patch, somebody with running code will be sure to conclude otherwise. Coincidentally I posted a rant about this kind of specification on xml-dev the other day mentioning feed/entry. 2. It's easy to be tricked by the document structure into thinking there is some form of natural scoping mechanism. If Atom looked like this atom:feed atom:feed-metadata-container atom:entries-container atom:entry or atom:feed atom:entries-container atom:entry@rel='feed-metadata' atom:entry We probably wouldn't be having this discussion. > Second note to self: After thinking about this a bit more, I would also > need a way of specifying a null license (e.g. the lack of a license). > For instance, what if an entry that does not contain a license is > aggregated into a feed that has a license. The original lack-of-license > still applies to that entry regardless of what is specified on the feed > level. Golly Bob, you're right, this is rather messy ain't it. Hmm... This is not new ground for the WG. We've been through it and my understanding is that feed level metadata does not inherit/cascade/scope over entries. I seem to recall thinking that atom:author percolating down from the feed is essentially broken, but the consensus was it should do that. It's an exception, not a precedent. As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. [I hope the folks working on the APP are paying attention.] cheers Bill * Tangentially touched upon here: http://www.dehora.net/journal/2004/06/atomrss_relating_entries_and_feeds.html. From owner-atom-syntax@mail.imc.org Mon Aug 22 12:36:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FI2-0005fc-97 for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:36:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27174 for ; Mon, 22 Aug 2005 12:36:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGPxQq035394; Mon, 22 Aug 2005 09:25:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGPx6q035393; Mon, 22 Aug 2005 09:25:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGPwdC035316 for ; Mon, 22 Aug 2005 09:25:58 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id B3C5D7C; Mon, 22 Aug 2005 09:25:51 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7MGPikv029743; Mon, 22 Aug 2005 09:25:50 -0700 (PDT) Date: Mon, 22 Aug 2005 09:25:48 -0700 From: Walter Underwood To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <127C04ACE8B75734E683D17F@Wunders-Computer.local> In-Reply-To: <43095641.1090700@intertwingly.net> References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 22, 2005 12:36:17 AM -0400 Sam Ruby wrote: > With a HTTP client library and SAX, the "absolute simplest solution" is > what Bob is describing: a single document that never completes. Except that an endless document can't be legal XML, because XML requires the root element to balance. An endless document never closes it. So, the endless document cannot be legal Atom. Worse, there is no chance for error recovery. One error, and the rest of the stream might not be parsable. So, it is simple, but busted. The standard trick here is to use a sequence of small docs, separated by ASCII form-feed characters. That character is not legal within an XML document, so it allows the stream to resyncronize on that character. Besides, form-feed actually has almost the right semantics -- start a new page. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Mon Aug 22 12:37:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FIc-0005hj-P2 for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:37:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27220 for ; Mon, 22 Aug 2005 12:37:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGTVXd037670; Mon, 22 Aug 2005 09:29:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGTV2W037669; Mon, 22 Aug 2005 09:29:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGTSe9037574 for ; Mon, 22 Aug 2005 09:29:30 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so868742wra for ; Mon, 22 Aug 2005 09:29:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=agjURa78hBS8b+7xgdUPMtP48NqG8lm0V74WQKfsJDguvdFBFvToVjfIJGzblCV35eFHI49FpVcGvflxCxJaGJPrjUNfT5yOvGTxT9sbk0CQH4xDI5rY7EphQRoNeqgI1b3HRzpgI3UYxJcmr1S97+td0F2/6iZk4ovHVufa7Ds= Received: by 10.54.33.27 with SMTP id g27mr3938957wrg; Mon, 22 Aug 2005 09:29:23 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 29sm2209470wrl.2005.08.22.09.29.22; Mon, 22 Aug 2005 09:29:23 -0700 (PDT) Message-ID: <4309FD5F.4030200@gmail.com> Date: Mon, 22 Aug 2005 09:29:19 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: bobwyman@pubsub.com, "'A. Pagaltzis'" , "'Atom WG'" Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) References: <20050822020755.8CB6C724001@mail.pubsub.com> <430945B9.1090403@gmail.com> <4309F3ED.9020302@dehora.net> In-Reply-To: <4309F3ED.9020302@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 ietf.org id MAA27220 Bill de h=D3ra wrote: >As we have no processing model for this, my answer to Paul's question is >that feed level extensions do not inherit/cascade/scope over entry level >ones, irrespective of whether they're foreign or not, and that the best >way to think about atom:author is as a frozen accident. > > =20 > Ok, this is absolutely fine. I'll go back through and update my various=20 extension proposals to reflect this train of thought.=20 - James From owner-atom-syntax@mail.imc.org Mon Aug 22 12:49:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FUC-0007NQ-Q3 for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:49:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27610 for ; Mon, 22 Aug 2005 12:49:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGeuSq044677; Mon, 22 Aug 2005 09:40:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGetEg044676; Mon, 22 Aug 2005 09:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MGesdB044610 for ; Mon, 22 Aug 2005 09:40:54 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 16:40:46 -0000 Received: from xdsl-213-196-240-254.netcologne.de (EHLO klangraum) [213.196.240.254] by mail.gmx.net (mp022) with SMTP; 22 Aug 2005 18:40:46 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 18:40:29 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822164029.GA20813@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <127C04ACE8B75734E683D17F@Wunders-Computer.local> 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 ietf.org id MAA27610 * Walter Underwood [2005-08-22 18:35]: > The standard trick here is to use a sequence of small docs, > separated by ASCII form-feed characters. That character is not > legal within an XML document, so it allows the stream to > resyncronize on that character. Ooh! I like this =E2=80=93 simple and very clever. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 22 12:57:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Fbq-0000ba-DX for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:57:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28077 for ; Mon, 22 Aug 2005 12:57:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGpBWP050808; Mon, 22 Aug 2005 09:51:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGpBd2050805; Mon, 22 Aug 2005 09:51:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MGpAPL050743 for ; Mon, 22 Aug 2005 09:51:11 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 40112 messnum 5766166 invoked from network[83.70.255.222/83-70-255-222.b-ras1.prp.dublin.eircom.net]); 22 Aug 2005 16:51:04 -0000 Received: from 83-70-255-222.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.255.222) by mail12.svc.cra.dublin.eircom.net (qp 40112) with SMTP; 22 Aug 2005 16:51:04 -0000 Message-ID: <430A0276.4000909@dehora.net> Date: Mon, 22 Aug 2005 17:51:02 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> In-Reply-To: <127C04ACE8B75734E683D17F@Wunders-Computer.local> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > The standard trick here is to use a sequence of small docs, separated > by ASCII form-feed characters. That character is not legal within an > XML document, so it allows the stream to resyncronize on that character. > Besides, form-feed actually has almost the right semantics -- start a > new page. In XMPP, you can reset on seeing , assuming you don't have atom:feed left hanging. You probably won't need atom:feed there anyway - feeds are very much artefacts of going over HTTP. cheers Bill From owner-atom-syntax@mail.imc.org Mon Aug 22 13:04:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FiL-0001WT-OL for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:04:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28352 for ; Mon, 22 Aug 2005 13:03:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGuulv054414; Mon, 22 Aug 2005 09:56:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MGuuxX054413; Mon, 22 Aug 2005 09:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MGuuV8054403 for ; Mon, 22 Aug 2005 09:56:56 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 15499 invoked by uid 17064); 22 Aug 2005 16:56:56 -0000 Received: from unknown (HELO [192.168.1.35]) ([62.203.207.95]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 22 Aug 2005 16:56:56 -0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <4309FD5F.4030200@gmail.com> References: <20050822020755.8CB6C724001@mail.pubsub.com> <430945B9.1090403@gmail.com> <4309F3ED.9020302@dehora.net> <4309FD5F.4030200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9A615E27-F56E-44CB-815D-D100C6CE60BA@bblfish.net> From: Henry Story Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Date: Mon, 22 Aug 2005 18:56:53 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.734) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MGuuV8054408 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 ietf.org id NAA28352 On 22 Aug 2005, at 18:29, James M Snell wrote: > > Bill de h=D3ra wrote: > > >> As we have no processing model for this, my answer to Paul's =20 >> question is >> that feed level extensions do not inherit/cascade/scope over entry =20 >> level >> ones, irrespective of whether they're foreign or not, and that the =20 >> best >> way to think about atom:author is as a frozen accident. >> >> +1 >> > Ok, this is absolutely fine. I'll go back through and update my =20 > various extension proposals to reflect this train of thought. > - James > From owner-atom-syntax@mail.imc.org Mon Aug 22 13:23:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G0m-0005iC-DQ for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:23:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29484 for ; Mon, 22 Aug 2005 13:23:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MHFvmT066192; Mon, 22 Aug 2005 10:15:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MHFvHQ066191; Mon, 22 Aug 2005 10:15:57 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7MHFtsO066112 for ; Mon, 22 Aug 2005 10:15:56 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 Aug 2005 17:15:47 -0000 Received: from xdsl-213-196-240-254.netcologne.de (EHLO klangraum) [213.196.240.254] by mail.gmx.net (mp024) with SMTP; 22 Aug 2005 19:15:47 +0200 X-Authenticated: #163624 Date: Mon, 22 Aug 2005 19:15:28 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050822171528.GA21179@klangraum> Mail-Followup-To: 'Atom Syntax' References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <430A0276.4000909@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <430A0276.4000909@dehora.net> 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 ietf.org id NAA29484 * Bill de h=C3=93ra [2005-08-22 19:00]: > In XMPP, you can reset on seeing , Really? ]]> Or maybe ]]> These are probably the only exceptions (I might be missing some, though), but they=E2=80=99re enough to demonstrate that you will need to write a parser, even if only a relatively simple one. Using a character which is illegal in XML and can never be part of a well-formed document as a separator is a clever way to avoid having to do *any* parsing *whatsoever*. You just scan the stream for the character and start over when you see it, end of story. No need to keep state or look for patterns or anything else. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 22 13:41:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GIU-0000Yw-Hr for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:41:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00244 for ; Mon, 22 Aug 2005 13:41:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MHZtI8078893; Mon, 22 Aug 2005 10:35:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MHZsGp078892; Mon, 22 Aug 2005 10:35:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MHZrOv078819 for ; Mon, 22 Aug 2005 10:35:54 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so671535nzb for ; Mon, 22 Aug 2005 10:35:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YuBI8djp3qlwYP6TZjj6TUQpzP0bfAh3T8KMi9duZRe8CT2yxhrufKF6lBj4Z3yNnde+3gOXCZCCzuTde0MSCNH5DkE+dt5M4269Im7buN34zGIwZqHnsdYIr1gIJEmBG9Lz+s+Dbl9I6G11zkeTGs09RwazIsXEjn7VE0EaUg0= Received: by 10.36.224.78 with SMTP id w78mr4568193nzg; Mon, 22 Aug 2005 10:35:48 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id i5sm44726nzi.2005.08.22.10.35.48; Mon, 22 Aug 2005 10:35:48 -0700 (PDT) Message-ID: <430A0CF0.9060002@gmail.com> Date: Mon, 22 Aug 2005 10:35:45 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <20050822164029.GA20813@klangraum> In-Reply-To: <20050822164029.GA20813@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id NAA00244 A. Pagaltzis wrote: >* Walter Underwood [2005-08-22 18:35]: > =20 > >>The standard trick here is to use a sequence of small docs, >>separated by ASCII form-feed characters. That character is not >>legal within an XML document, so it allows the stream to >>resyncronize on that character. >> =20 >> > >Ooh! I like this =E2=80=93 simple and very clever. > >Regards, > =20 > +1.. this seems a very elegant solution. - James From owner-atom-syntax@mail.imc.org Mon Aug 22 13:47:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GOg-0001is-5j for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:47:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00534 for ; Mon, 22 Aug 2005 13:47:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MHexBF082478; Mon, 22 Aug 2005 10:40:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MHex5I082477; Mon, 22 Aug 2005 10:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MHexGk082414 for ; Mon, 22 Aug 2005 10:40:59 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 86BBF72402A; Mon, 22 Aug 2005 13:40:53 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Walter Underwood'" , "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Mon, 22 Aug 2005 13:40:52 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <127C04ACE8B75734E683D17F@Wunders-Computer.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWnOIyrNdWI++mTROKANmOgG9cXMgABpauQ Message-Id: <20050822174053.86BBF72402A@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > Except that an endless document can't be legal XML, because XML > requires the root element to balance. An endless document never closes > it. So, the endless document cannot be legal Atom. Worse, there > is no chance for error recovery. One error, and the rest of the > stream might not be parsable. It's not quite as bad as you suggest. In fact, in an Atom streaming application, clients should be expecting that that element could arrive at any moment. This is how the server would announce that it is terminating the stream. Servers might want to do this to shed load, shut-down for maintenance, etc. So, it isn't right to say that the document "never closes." In fact, I think the reason for the closure will typically be that there is a network error or that the client (or some infrastructure component serving the client) voluntarily stops reading the document. In these cases, it is reasonable to suggest that the client should have procedures to recover a partial document. Also, it should be noted that error recovery can be simplified greatly if one is working with chunked content flowing over continuous HTTP sessions. If one makes a simple rule that HTTP Chunk data will only be inserted into the feed *in between* atom:entry elements, then you are provided with the "framing" data needed to recover from any parse errors with individual entries. This simple rule could be adopted by those who are streaming over raw TCP/IP sockets as well. Perhaps what we need is "Atom over Continuous HTTP" to be defined in addition to the "Atom over XMPP" specification. I'm afraid that the point that is being argued is a fairly fine technical detail that really shouldn't be allowed to get in the way of implementing practical and useful systems. We have a great deal of industry experience with this sort of XML streaming model if only because the Jabber folk and the fact that the IETF has approved XMPP as an RFC. These "endless" documents are not actually endless. We simply need to import some existing knowledge about how to do partial document error recovery and we're where we need to be. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 22 14:09:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Gji-0006bN-O5 for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:09:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01956 for ; Mon, 22 Aug 2005 14:09:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MI1tXw095902; Mon, 22 Aug 2005 11:01:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MI1tcO095901; Mon, 22 Aug 2005 11:01:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MI1sqd095835 for ; Mon, 22 Aug 2005 11:01:54 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so637946nzi for ; Mon, 22 Aug 2005 11:01:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A1OU3d8GCEKYpjtZ40C/TTLfG8IEKcANT/MwIBfHRGoHwYvjrFHVPSz3i6dZLIESEigQqY1c8oVjOeyW2zFj1NL4f3e+B7YiKm7htkLWFfaZY7sdy4kQZwlMIg2Fic0/CdAz6BKzdXxbNI9+abJTTqu6C1hgCNoHUZTFR6JvwNQ= Received: by 10.36.5.16 with SMTP id 16mr4335241nze; Mon, 22 Aug 2005 11:01:45 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Mon, 22 Aug 2005 11:01:45 -0700 (PDT) Message-ID: <3f1451f505082211012faddb4a@mail.gmail.com> Date: Mon, 22 Aug 2005 14:01:45 -0400 From: Joe Gregorio To: James M Snell Subject: Re: If you want "Fat Pings" just use Atom! Cc: "A. Pagaltzis" , Atom Syntax In-Reply-To: <430A0CF0.9060002@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <20050822164029.GA20813@klangraum> <430A0CF0.9060002@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MI1sqd095894 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/22/05, James M Snell wrote: > +1.. this seems a very elegant solution. +1. Indeed both solutions, the never ending feed, and the FF separated entries both have their advantages. The FF separated stream has the advantage of being able to synchronize mid-stream. The never ending feed has the advantage that you are only initializing a SAX parser instance just once. Interestingly enough the FF separated entries method would also work when storing a large quantity of entries in a single flat file where appending an entry needs to be fast. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 22 14:26:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7H0b-0001gy-QN for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:26:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02807 for ; Mon, 22 Aug 2005 14:26:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MILQmO008334; Mon, 22 Aug 2005 11:21:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MILQ4X008331; Mon, 22 Aug 2005 11:21:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MILPN8008305 for ; Mon, 22 Aug 2005 11:21:25 -0700 (PDT) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j7MILLXk017711; Mon, 22 Aug 2005 11:21:21 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:21:21 -0700 Received: from [172.16.1.2] ([172.24.28.109]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:21:20 -0700 In-Reply-To: <43095641.1090700@intertwingly.net> References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89F3FF7B-053A-44B2-BCA7-12B31F80629C@bea.com> Cc: "A. Pagaltzis" , "'Atom Syntax'" Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: If you want "Fat Pings" just use Atom! Date: Mon, 22 Aug 2005 11:21:19 -0700 To: Sam Ruby X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 22 Aug 2005 18:21:21.0015 (UTC) FILETIME=[4BBCF070:01C5A746] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.8.22.19 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yep; an existance proof is server push, which is very similar (but not XML-based); http://wp.netscape.com/assist/net_sites/pushpull.html On 21/08/2005, at 9:36 PM, Sam Ruby wrote: > > A. Pagaltzis wrote: > >> * Bob Wyman [2005-08-22 01:05]: >> >> >>> What do you think? Is there any conceptual problem with >>> streaming basic Atom over TCP/IP, HTTP continuous sessions >>> (probably using chunked content) etc.? >>> >> >> I wonder how you would make sure that the document is >> well-formed. Since the stream never actually ends and there is no >> way for a client to signal an intent to close the connection, the >> at the top would never actually be accompanied by a >> at the bottom. >> >> If you accept that the stream can never be a complete well-formed >> document, is there any reason not to simply send a stream of >> concatenated Atom Entry Documents? >> >> That would seem like the absolute simplest solution. >> > > I think the keyword in the above is "complete". > > SAX is a popular API for dealing with streaming XML (and there are a > number of "pull parsing" APIs too). It makes individual elements > available to your application as they are read. If at any point, the > SAX parser determines that your feed is not well formed, it throws an > error at that point. > > With a HTTP client library and SAX, the "absolute simplest > solution" is > what Bob is describing: a single document that never completes. > > Note that if your application were to discard all the data it receives > before it encouters the first entry, the stream from there on out > would > be identical. > > - Sam Ruby > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Mon Aug 22 14:30:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7H44-0002Dw-1M for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:30:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03006 for ; Mon, 22 Aug 2005 14:30:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MINkFR010018; Mon, 22 Aug 2005 11:23:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MINkHx010017; Mon, 22 Aug 2005 11:23:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MINjXr010002 for ; Mon, 22 Aug 2005 11:23:46 -0700 (PDT) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j7MINhXk018317; Mon, 22 Aug 2005 11:23:43 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:23:43 -0700 Received: from [172.16.1.2] ([172.24.28.109]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:23:43 -0700 In-Reply-To: <20050822030804.5CA09724001@mail.pubsub.com> References: <20050822030804.5CA09724001@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1ED2243E-9D40-4A63-8C3C-298D8FB7F198@bea.com> Cc: "'Joe Gregorio'" , "'Atom Syntax'" Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: If you want "Fat Pings" just use Atom! Date: Mon, 22 Aug 2005 11:23:37 -0700 To: X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 22 Aug 2005 18:23:43.0140 (UTC) FILETIME=[A0737E40:01C5A746] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.8.22.19 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just as a data point, this should become less of a problem as event- loop based HTTP implementations become more popular; with them, the number of connections you can hold open is only practically limited by available memory (to keep fairly small amounts of connection- specific state). This technique can allow tens to hundreds of thousands of concurrent connections, leading to multi-hour HTTP connections (if both sides want them). On 21/08/2005, at 8:08 PM, Bob Wyman wrote: > The > problem is that HTTP connections, given the current infrastructure and > standard components, are very hard to keep open "permanently" or > for a very > long period of time. One is often considered lucky if you can keep > an HTTP > connection open for 5 minutes without having to re-initialize... -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Mon Aug 22 14:44:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HHP-0004gC-Nj for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:44:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03623 for ; Mon, 22 Aug 2005 14:44:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MIXaRe015988; Mon, 22 Aug 2005 11:33:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MIXaa1015986; Mon, 22 Aug 2005 11:33:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MIXZMU015930 for ; Mon, 22 Aug 2005 11:33:35 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id C690AC7 for ; Mon, 22 Aug 2005 11:33:30 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7MIXTkv001855 for ; Mon, 22 Aug 2005 11:33:30 -0700 (PDT) Date: Mon, 22 Aug 2005 11:33:32 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <0D879441EC1915045A40E9A3@Wunders-Computer.local> In-Reply-To: <3f1451f505082211012faddb4a@mail.gmail.com> References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <20050822164029.GA20813@klangraum> <430A0CF0.9060002@gmail.com> <3f1451f505082211012faddb4a@mail.gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 22, 2005 2:01:45 PM -0400 Joe Gregorio wrote: > Interestingly enough the FF separated entries method would also work > when storing a large quantity of entries in a single flat file where > appending an entry needs to be fast. The original application was logfiles in XML. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Mon Aug 22 15:46:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IFX-00089l-Si for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:46:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08311 for ; Mon, 22 Aug 2005 15:46:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MJdDmD034503; Mon, 22 Aug 2005 12:39:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MJdDxS034502; Mon, 22 Aug 2005 12:39:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7MJdBjI034489 for ; Mon, 22 Aug 2005 12:39:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 25310 messnum 7068796 invoked from network[83.70.255.222/83-70-255-222.b-ras1.prp.dublin.eircom.net]); 22 Aug 2005 19:39:05 -0000 Received: from 83-70-255-222.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.255.222) by mail01.svc.cra.dublin.eircom.net (qp 25310) with SMTP; 22 Aug 2005 19:39:05 -0000 Message-ID: <430A29D7.1010406@dehora.net> Date: Mon, 22 Aug 2005 20:39:03 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <430A0276.4000909@dehora.net> <20050822171528.GA21179@klangraum> In-Reply-To: <20050822171528.GA21179@klangraum> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=UTF-8 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 ietf.org id PAA08311 A. Pagaltzis wrote: > * Bill de h=C3=93ra [2005-08-22 19:00]: >=20 >>In XMPP, you can reset on seeing , >=20 >=20 > Really? Really. And I've even seen the two test cases below... >=20 > > ]]> >=20 > Or maybe >=20 > > ]]> ... which are cute. I forget I didn't have an opening tag, or a buffer for the entry. Oh wait, I do ;) > These are probably the only exceptions (I might be missing some, > though), but they=E2=80=99re enough to demonstrate that you will need t= o > write a parser, even if only a relatively simple one. You already have an XML parser, that's not the problem; the problem is managing the stream buffer off the wire for a protocol model that has no underlying concept of an octet frame. I've written enough XMPP code to understand why the BEEP/MIME crowd might frown at it - manipulating infosets right on top on sockets make for funky code and isn't my notion of what "bits on the wire" should be ;) [Incidentally this is a non-problem for APP because we're piggy backing on HTTP octets...] > Using a character which is illegal in XML and can never be part > of a well-formed document as a separator is a clever way to avoid > having to do *any* parsing *whatsoever*. You just scan the stream > for the character and start over when you see it, end of story. > No need to keep state or look for patterns or anything else. I see all the +1s, but don't understand why reinventing multi-part MIME with formfeeds as a special case for Atom is more attractive that an infinite list of entries whose closing atom:feed tag never arrives. Still, I think this discussion is valuable: it speaks volumes on the use of XML for wire protocols, especially for the single document school of thought. cheers Bill From owner-atom-syntax@mail.imc.org Mon Aug 22 18:07:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KRo-0001TN-2E for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 18:07:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23625 for ; Mon, 22 Aug 2005 18:07:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MM1BSf069994; Mon, 22 Aug 2005 15:01:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MM1Be8069993; Mon, 22 Aug 2005 15:01:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ptb-relay04.plus.net (ptb-relay02.plus.net [212.159.14.213]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MM194o069902; Mon, 22 Aug 2005 15:01:10 -0700 (PDT) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by ptb-relay04.plus.net with esmtp (Exim) id 1E7KLo-0002yZ-FC; Mon, 22 Aug 2005 23:01:04 +0100 To: bobwyman@pubsub.com (Bob Wyman), phoffman@imc.org ('Paul Hoffman'), atom-syntax@imc.org ('Atom Syntax') In-Reply-To: <20050821211006.D6AE7724001@mail.pubsub.com> Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) From: pmrobinson@gmx.net (Peter Robinson) Date: Mon, 22 Aug 2005 23:01:04 +0100 Message-ID: <1h1px0m.tdn9113ntn2mM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.9) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bob Wyman wrote: > Paul Hoffman asked: > > Does an informative extension that appears at the feed level > > (as compared to in entries) indicate: > > a) this information pertains to each entry > > b) this information pertains to the feed itself > > c) this information pertains to each entry and to the feed itself > > d) completely unknown unless specified in the extension definition > > I believe the correct answer is "e": > > e) Unless otherwise specified, this information pertains to the feed only. I agree. Once you've accepted that there's a difference between "the feed itself" and "the set of all past, present and future articles in the feed" (which there certainly is in the general case) then you really have to accept e) as the only possibility for unknown metadata in the feed head section. Regards, Peter -- Peter Robinson From owner-atom-syntax@mail.imc.org Mon Aug 22 18:39:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Kwi-0002us-5u for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 18:39:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28235 for ; Mon, 22 Aug 2005 18:39:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MMWHPO089606; Mon, 22 Aug 2005 15:32:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MMWHEU089605; Mon, 22 Aug 2005 15:32:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MMWF62089593 for ; Mon, 22 Aug 2005 15:32:16 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7MMWFWR023634 for ; Mon, 22 Aug 2005 16:32:15 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILN00JRXALRCF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 22 Aug 2005 16:32:15 -0600 (MDT) Received: from [192.168.0.100] ([64.201.216.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILN00JTNALQPY@mail.sun.net> for atom-syntax@imc.org; Mon, 22 Aug 2005 16:32:14 -0600 (MDT) Date: Mon, 22 Aug 2005 15:32:17 -0700 From: Tim Bray Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) In-reply-to: <20050821204231.GA6541@klangraum> To: "A. Pagaltzis" Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=WINDOWS-1252; format=flowed References: <1h1ns87.1tioxt4tifp2fM%pmrobinson@gmx.net> <20050821204231.GA6541@klangraum> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MMWG62089599 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 ietf.org id SAA28235 On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote: > * Paul Hoffman [2005-08-21 21:55]: > >> Ah, I had missed that. This leads to a question for the mailing >> list. Does an informative extension that appears at the feed >> level (as compared to in entries) indicate: >> d) completely unknown unless specified in the extension >> definition > > Atom itself has precedent for both b) and c). So I would say > it=92s d) =96 but also that aggregators should assume b) when they > don=92t know any better. Right, the only possible answer. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 22 19:15:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7LVP-0000Na-AR for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 19:15:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03823 for ; Mon, 22 Aug 2005 19:14:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MN0ZGh006391; Mon, 22 Aug 2005 16:00:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MN0ZWx006390; Mon, 22 Aug 2005 16:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MN0ZWB006328 for ; Mon, 22 Aug 2005 16:00:35 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id C43C172405F; Mon, 22 Aug 2005 19:00:29 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'James M Snell'" Cc: "'A. Pagaltzis'" , "'Atom WG'" Subject: RE: Extensions at the feed level (Was: Re: geolocation in atom:author?) Date: Mon, 22 Aug 2005 19:00:29 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <430945B9.1090403@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWmyTGO3T3/0onwTiu/ILKnoBGZzQAnX/0A Message-Id: <20050822230029.C43C172405F@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > Second note to self: After thinking about this a bit more, I would > also need a way of specifying a null license (e.g. the lack of a license). > For instance, what if an entry that does not contain a license is > aggregated into a feed that has a license. The original > lack-of-license still applies to that entry regardless of what is > specified on the feed level. Golly Bob, you're right, this is > rather messy ain't it. Hmm... My apologies for not having more clearly pointed this out in my original message. The problem is exacerbated for folk like us at PubSub since we would feel completely comfortable in claiming copyright over the "collection" of entries that we pass along to our subscribers, however, there is *no way* that we could even hint at claiming copyright over the individual entries themselves. If statements made at the feed level are "inherited by" or "in the scope of" the entries, then we would not be able to assert a copyright claim at the feed level since it would "leak" down to the entries. Of course, one might argue that since we at PubSub will virtually always ensure that any entry we publish has an atom:source element, one could argue that we don't have to worry about this scope leakage. But, we're a special case in this regard. The general issue of scope exists in cases where the atom:source element is not present. bob wyman From owner-atom-syntax@mail.imc.org Mon Aug 22 19:41:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Lv4-0006ma-FQ for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 19:41:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05008 for ; Mon, 22 Aug 2005 19:41:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MNaGZR027252; Mon, 22 Aug 2005 16:36:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MNaGUl027250; Mon, 22 Aug 2005 16:36:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MNaE3w027188 for ; Mon, 22 Aug 2005 16:36:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so672480nzi for ; Mon, 22 Aug 2005 16:36:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hS9r3AZmlVyeuo7e3iblboxp1YY8KybcrB1pA4qVKqrAW+0tyZBBgyU+H9+c2yRa3QaUawXfuhJ80k4mf+0zPGYj3t0ZYeCPph68CGUCnTggbV/mjaX/8QXvl2nBQBj+I7pvwMCjczpzdiuEbQu+l783TRCPA7ubDNMVBfmCrS8= Received: by 10.36.222.75 with SMTP id u75mr837617nzg; Mon, 22 Aug 2005 16:36:09 -0700 (PDT) Received: by 10.37.12.28 with HTTP; Mon, 22 Aug 2005 16:36:08 -0700 (PDT) Message-ID: <68fba5c505082216364e582e5d@mail.gmail.com> Date: Mon, 22 Aug 2005 19:36:09 -0400 From: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: Extensions at the feed level (Was: Re: geolocation in atom:author?) Cc: James M Snell , bobwyman@pubsub.com, "A. Pagaltzis" , Atom WG In-Reply-To: <4309F3ED.9020302@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050822020755.8CB6C724001@mail.pubsub.com> <430945B9.1090403@gmail.com> <4309F3ED.9020302@dehora.net> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7MNaF3w027237 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 ietf.org id TAA05008 On 8/22/05, Bill de h=D3ra wrote:=20 > As we have no processing model for this, my answer to Paul's question i= s > that feed level extensions do not inherit/cascade/scope over entry leve= l > ones, irrespective of whether they're foreign or not, and that the best > way to think about atom:author is as a frozen accident. I always assumed (and objected, mildly) that the atom:author stuff was the WG's way of saying you had better write something similar to this code, which I spotted in the wild (ooh, what's this? A rarely seen RDF parser... sshh): item.author =3D getRDFTargetValue(ds, itemResource, DC_CREATOR) || getRDFTargetValue(ds, channel, DC_CREATOR) || theFeed.title || item.author; I didn't really agree that we should say anything about it, but most other folks did, and I see it more as a fact of life than something that could be cleared up with a formal model. There will always be some new extension getting wedged in the search sequence. Which reminds me, I should write a patch for iTunesRSS. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Aug 22 19:54:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7M7V-0001Y0-Ed for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 19:54:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05441 for ; Mon, 22 Aug 2005 19:54:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MNnAVU034311; Mon, 22 Aug 2005 16:49:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7MNnAHr034310; Mon, 22 Aug 2005 16:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7MNnArm034302 for ; Mon, 22 Aug 2005 16:49:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout07/MantshX 4.0) with ESMTP id j7MNnAlU013727; Mon, 22 Aug 2005 16:49:10 -0700 (PDT) Received: from [10.0.0.100] (fujita.plus.com [84.92.128.107]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j7MNn6Po010462 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 22 Aug 2005 16:49:09 -0700 (PDT) In-Reply-To: <20050821225954.DDF0D724001@mail.pubsub.com> References: <20050821225954.DDF0D724001@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 00:49:07 +0100 To: bobwyman@pubsub.com X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just out of interest, how well does any of this work with caches and proxies? Graham From owner-atom-syntax@mail.imc.org Mon Aug 22 20:36:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MmM-0002Ew-AB for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 20:36:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07086 for ; Mon, 22 Aug 2005 20:36:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N0TcDS049870; Mon, 22 Aug 2005 17:29:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N0TcZr049868; Mon, 22 Aug 2005 17:29:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N0TbZH049856 for ; Mon, 22 Aug 2005 17:29:37 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7N0TbTW013657 for ; Mon, 22 Aug 2005 18:29:37 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILN00L8NG1BFT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 22 Aug 2005 18:29:36 -0600 (MDT) Received: from [192.168.0.100] ([64.201.216.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILN00JE2G1APY@mail.sun.net> for atom-syntax@imc.org; Mon, 22 Aug 2005 18:29:35 -0600 (MDT) Date: Mon, 22 Aug 2005 17:29:38 -0700 From: Tim Bray Subject: Re: If you want "Fat Pings" just use Atom! In-reply-to: <3f1451f505082207262ab386df@mail.gmail.com> To: Joe Gregorio Cc: Sam Ruby , bobwyman@pubsub.com, Atom Syntax Message-id: <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: >> Essentially, LiveJournal is making this data available to anybody who >> wishes to access it, without any need to register or to invent a >> unique API. > > Ahh, I had thought this was a more dedicated ping traffic stream. The > never ending Atom document makes much more sense now. It's got another advantage. You connect and ask for the feed. You get ....... goes on forever ........ and none of the entry documents need to redeclare the Atom namespace, which saves quite a few bytes after the first hundred thousand or so entries. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 22 21:01:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NAl-00087x-US for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:01:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08258 for ; Mon, 22 Aug 2005 21:01:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N0uFAf065912; Mon, 22 Aug 2005 17:56:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N0uFHf065911; Mon, 22 Aug 2005 17:56:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N0uEPu065898 for ; Mon, 22 Aug 2005 17:56:14 -0700 (PDT) (envelope-from gerph@gerph.org) Received: from [62.56.55.57] (helo=buttercup.gerph.org) by anchor-post-33.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1E7N5G-000MIB-9w; Tue, 23 Aug 2005 00:56:13 +0000 Received: by buttercup.gerph.org (Postfix, from userid 1000) id A002F188D49; Tue, 23 Aug 2005 01:55:35 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 51C5CC6A1; Tue, 23 Aug 2005 01:55:35 +0100 (BST) Date: Tue, 23 Aug 2005 01:55:34 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: Tim Bray Cc: Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! In-Reply-To: <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> Message-ID: References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Aug 2005, Tim Bray wrote: > On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: > >>> Essentially, LiveJournal is making this data available to anybody who >>> wishes to access it, without any need to register or to invent a unique >>> API. >> >> Ahh, I had thought this was a more dedicated ping traffic stream. The >> never ending Atom document makes much more sense now. > > It's got another advantage. You connect and ask for the feed. You get > > > ....... goes on forever ........ > > and none of the entry documents need to redeclare the Atom namespace, which > saves quite a few bytes after the first hundred thousand or so entries. -Tim I'm a little confused by all this discussion of never-ending XML documents, mainly because my understanding is that without the well-formedness checks the content might as well be free form, and the elements within the document may rely on parts that have 'yet to arrive'. Taking as an example the atom:author element, with the above example of a never-ending document any atom:entry elements which exist would be quite valid in containing no atom:author element because they're not required to have one if the atom:feed element contains such an author. And because the feed has not yet finished the reading application cannot know that the document is invalid (or not - the atom:author element may arrive at some point in the future). What I'm trying to say is that a never-ending 'atom' feed is ... * not parsable as XML because it is not well-formed * not parsable as Atom because the Atom constraints may not be satisfiable (the author example is what I'm thinking of) For very specialist use it might be sensible, but as Atom and XML are quite well defined as to what they contain and such a stream isn't Atom or XML. -- Gerph ... I need a friend, to make me happy; Not stand here on my own. From owner-atom-syntax@mail.imc.org Mon Aug 22 21:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NMw-0002Sp-TV for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:14:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08763 for ; Mon, 22 Aug 2005 21:14:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N18MrT071751; Mon, 22 Aug 2005 18:08:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N18MnK071750; Mon, 22 Aug 2005 18:08:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N18KYM071675 for ; Mon, 22 Aug 2005 18:08:21 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so1030445wri for ; Mon, 22 Aug 2005 18:08:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=M2X4xF3EAK9DVAAMAiRlCYxi6MRbomVKIVBhqKywOCnIIoCZeokdOPsL1lyVRd3UfdehNfycrCtMocJepoWKiRjpaZMLy7whH6i6biXPwuqEwf8v0uj/zWa+OtZj//LAwISUgg6P91Qx1Fsr2vfWi0dohXmfiLTsxxJGJvcUeGg= Received: by 10.54.43.24 with SMTP id q24mr1843698wrq; Mon, 22 Aug 2005 18:08:12 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id d61sm5767360wra.2005.08.22.18.08.11; Mon, 22 Aug 2005 18:08:12 -0700 (PDT) Message-ID: <430A76F7.3000906@gmail.com> Date: Mon, 22 Aug 2005 18:08:07 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Fletcher CC: Tim Bray , Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> In-Reply-To: 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: Content-Transfer-Encoding: 7bit Justin Fletcher wrote: > I'm a little confused by all this discussion of never-ending XML > documents, mainly because my understanding is that without the > well-formedness checks the content might as well be free form, and the > elements within the document may rely on parts that have 'yet to arrive'. > > Taking as an example the atom:author element, with the above example > of a never-ending document any atom:entry elements which exist would > be quite valid in containing no atom:author element because they're > not required to have one if the atom:feed element contains such an > author. And because the feed has not yet finished the reading > application cannot know that the document is invalid (or not - the > atom:author element may arrive at some point in the future). > If an atom:feed contains an author element, it is required by the spec to appear before any atom:entry elements in the atom:feed. (http://www.atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.4.1.1) so this isn't a problem. Further, the spec really does not define any metadata that would be dependent on parts yet-to-arrive. There could be a challenge with same-document links that use fragment identifiers, but that's about it. - James From owner-atom-syntax@mail.imc.org Mon Aug 22 21:15:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NOO-0002jo-Ld for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:15:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08820 for ; Mon, 22 Aug 2005 21:15:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1Bd8P073646; Mon, 22 Aug 2005 18:11:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N1Bd6w073643; Mon, 22 Aug 2005 18:11:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1BcQh073579 for ; Mon, 22 Aug 2005 18:11:38 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so679661nzi for ; Mon, 22 Aug 2005 18:11:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NIqNonEEZi33ZzTKjQAFId4vyvsX/A1eDyns7+MXs4McLabxpREs/2er8xbyEckvMvveZxEVukDLPjlnHky/fzs0oI2WRQ/nz4ab3kalj4c/ysS4lrtLGkAmNxL+1Ckj/wz36mLTRDUMrrCKoqGzBFVaq/9JXuJ9PW1fwBTKb5w= Received: by 10.36.10.20 with SMTP id 20mr2115014nzj; Mon, 22 Aug 2005 18:11:32 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Mon, 22 Aug 2005 18:11:32 -0700 (PDT) Message-ID: <3f1451f505082218112715db4e@mail.gmail.com> Date: Mon, 22 Aug 2005 21:11:32 -0400 From: Joe Gregorio To: Justin Fletcher Subject: Re: If you want "Fat Pings" just use Atom! Cc: Tim Bray , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7N1BcQh073638 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/22/05, Justin Fletcher wrote: > > On Mon, 22 Aug 2005, Tim Bray wrote: > > > On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: > > > >>> Essentially, LiveJournal is making this data available to anybody who > >>> wishes to access it, without any need to register or to invent a unique > >>> API. > >> > >> Ahh, I had thought this was a more dedicated ping traffic stream. The > >> never ending Atom document makes much more sense now. > > > > It's got another advantage. You connect and ask for the feed. You get > > > > > > ....... goes on forever ........ > > > > and none of the entry documents need to redeclare the Atom namespace, which > > saves quite a few bytes after the first hundred thousand or so entries. -Tim > > I'm a little confused by all this discussion of never-ending XML > documents, mainly because my understanding is that without the > well-formedness checks the content might as well be free form, and the > elements within the document may rely on parts that have 'yet to arrive'. Not at all: """The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Its element children consist of metadata elements *followed by* zero or more atom:entry child elements.""" http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.1.1 -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Aug 22 21:25:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NXL-0004Yc-CO for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:25:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09274 for ; Mon, 22 Aug 2005 21:25:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1GHPM076169; Mon, 22 Aug 2005 18:16:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N1GHWP076168; Mon, 22 Aug 2005 18:16:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1GGB7076146 for ; Mon, 22 Aug 2005 18:16:16 -0700 (PDT) (envelope-from gerph@gerph.org) Received: from [62.56.55.57] (helo=buttercup.gerph.org) by anchor-post-35.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1E7NJn-000DWB-Ij; Tue, 23 Aug 2005 01:11:14 +0000 Received: by buttercup.gerph.org (Postfix, from userid 1000) id A54F8188D49; Tue, 23 Aug 2005 02:15:39 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 9D252C6A1; Tue, 23 Aug 2005 02:15:39 +0100 (BST) Date: Tue, 23 Aug 2005 02:15:39 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: James M Snell Cc: Tim Bray , Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! In-Reply-To: <430A76F7.3000906@gmail.com> Message-ID: References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Aug 2005, James M Snell wrote: > Justin Fletcher wrote: > >> I'm a little confused by all this discussion of never-ending XML documents, >> mainly because my understanding is that without the well-formedness checks >> the content might as well be free form, and the elements within the >> document may rely on parts that have 'yet to arrive'. >> >> Taking as an example the atom:author element, with the above example of a >> never-ending document any atom:entry elements which exist would be quite >> valid in containing no atom:author element because they're not required to >> have one if the atom:feed element contains such an author. And because the >> feed has not yet finished the reading application cannot know that the >> document is invalid (or not - the atom:author element may arrive at some >> point in the future). >> > If an atom:feed contains an author element, it is required by the spec to > appear before any atom:entry elements in the atom:feed. > (http://www.atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.4.1.1) > so this isn't a problem. Further, the spec really does not define any > metadata that would be dependent on parts yet-to-arrive. There could be a > challenge with same-document links that use fragment identifiers, but that's > about it. Ah; I misread that in the specification. Thanks. It's just the lack of well-formedness that is an issue in my head then. -- Gerph ... Things get better second time around. From owner-atom-syntax@mail.imc.org Mon Aug 22 21:27:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Na0-0004v5-EL for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:27:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09356 for ; Mon, 22 Aug 2005 21:27:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1NVMp080554; Mon, 22 Aug 2005 18:23:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N1NV5V080553; Mon, 22 Aug 2005 18:23:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N1NUZI080510 for ; Mon, 22 Aug 2005 18:23:31 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so680634nzi for ; Mon, 22 Aug 2005 18:23:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gQzHuZ64L0AkPxrH5aMDY9lZpWxw5IyBJjBl8tUfFSfCExTzoVrCkW3AChTgcwx9DNC9wXfOyrdGlKxgRHO4K/8eNKZbtiTQxqb4EiDoUqczdlLGbjgGaEMZa4BXawuH/w0ipFXvNu0p2F6ZyZbJc0ZqZ/05hc4WAXc3WRjZC8Q= Received: by 10.36.10.20 with SMTP id 20mr2122573nzj; Mon, 22 Aug 2005 18:23:25 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id 8sm3932464nzn.2005.08.22.18.23.24; Mon, 22 Aug 2005 18:23:25 -0700 (PDT) Message-ID: <430A7A88.2000807@gmail.com> Date: Mon, 22 Aug 2005 18:23:20 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Fletcher CC: Tim Bray , Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> In-Reply-To: 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: Content-Transfer-Encoding: 7bit Justin Fletcher wrote: > > Ah; I misread that in the specification. Thanks. It's just the lack of > well-formedness that is an issue in my head then. > Hey, that's better than what I can claim. For me, it's usually the lack of well-formedness in my head that's the issue ;-) - James From owner-atom-syntax@mail.imc.org Mon Aug 22 22:44:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7OmU-00058B-AM for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 22:44:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24753 for ; Mon, 22 Aug 2005 22:44:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N2cH7m030022; Mon, 22 Aug 2005 19:38:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N2cHcV030021; Mon, 22 Aug 2005 19:38:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N2cGmH030006 for ; Mon, 22 Aug 2005 19:38:16 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7N2cFTW005094 for ; Mon, 22 Aug 2005 20:38:16 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILN00J7FLZQ2W@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 22 Aug 2005 20:38:15 -0600 (MDT) Received: from [192.168.1.102] ([24.72.92.157]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILN00JI5LZPPY@mail.sun.net> for atom-syntax@imc.org; Mon, 22 Aug 2005 20:38:14 -0600 (MDT) Date: Mon, 22 Aug 2005 19:38:15 -0700 From: Tim Bray Subject: Re: If you want "Fat Pings" just use Atom! In-reply-to: To: Justin Fletcher Cc: James M Snell , Atom Syntax Message-id: <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 22, 2005, at 6:15 PM, Justin Fletcher wrote: > Ah; I misread that in the specification. Thanks. It's just the lack > of well-formedness that is an issue in my head then. If you encounter a busted tag on the Nth entry, per the XML spec that's a fatal error and you can't process any more. But I'm pretty sure that there's nothing in the XML specifications that says you can't process the material before the breakage occurs. Given that the overwhelming majority of these are going to be machine generated by production applications, I suspect the amount of breakage at the well-formedness level to be low. -Tim From owner-atom-syntax@mail.imc.org Mon Aug 22 23:14:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7PF3-0002an-Cd for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 23:14:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26086 for ; Mon, 22 Aug 2005 23:14:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N35DH5049215; Mon, 22 Aug 2005 20:05:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N35DY7049214; Mon, 22 Aug 2005 20:05:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N35ChM049129 for ; Mon, 22 Aug 2005 20:05:13 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7N356d24866; Tue, 23 Aug 2005 12:05:06 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id ce3e703e_1382_11da_80d3_0030482533a1_31179; Tue, 23 Aug 2005 12:05:48 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0034FF; 23 Aug 05 12:06:00 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 23 Aug 05 12:05:27 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0034FD; 23 Aug 05 12:05:17 +0900 Message-Id: <6.0.0.20.2.20050823120032.09450810@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 23 Aug 2005 12:01:11 +0900 To: "A. Pagaltzis" , "'Atom Syntax'" From: Martin Duerst Subject: Re: If you want "Fat Pings" just use Atom! In-Reply-To: <20050822171528.GA21179@klangraum> References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <430A0276.4000909@dehora.net> <20050822171528.GA21179@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 02:15 05/08/23, A. Pagaltzis wrote: >Using a character which is illegal in XML and can never be part >of a well-formed document as a separator is a clever way to avoid >having to do *any* parsing *whatsoever*. You just scan the stream >for the character and start over when you see it, end of story. >No need to keep state or look for patterns or anything else. Well, modulo character encoding issues, that is. An FF will look differently in UTF-16 than in ASCII-based encodings. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon Aug 22 23:41:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Pfb-00085Q-CF for atompub-archive@megatron.ietf.org; Mon, 22 Aug 2005 23:41:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27409 for ; Mon, 22 Aug 2005 23:41:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N3a28u068658; Mon, 22 Aug 2005 20:36:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N3a2us068657; Mon, 22 Aug 2005 20:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N3a1LE068594 for ; Mon, 22 Aug 2005 20:36:02 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id D9C2AC6; Mon, 22 Aug 2005 20:35:56 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7N3Ztkv009260; Mon, 22 Aug 2005 20:35:56 -0700 (PDT) Date: Mon, 22 Aug 2005 20:35:58 -0700 From: Walter Underwood To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: In-Reply-To: <6.0.0.20.2.20050823120032.09450810@itmail.it.aoyama.ac.jp> References: <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <430A0276.4000909@dehora.net> <20050822171528.GA21179@klangraum> <6.0.0.20.2.20050823120032.09450810@itmail.it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 23, 2005 12:01:11 PM +0900 Martin Duerst wrote: > > Well, modulo character encoding issues, that is. An FF will > look differently in UTF-16 than in ASCII-based encodings. Fine. Use two NULs. That is either one illegal UTF-16(BE or LE) character or two illegal characters in ASCII or UTF-8. Of course, a transport level multi-payload system would be preferred. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 23 00:02:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Pzc-0003o9-Pq for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:02:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28093 for ; Tue, 23 Aug 2005 00:02:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N3sRoZ079975; Mon, 22 Aug 2005 20:54:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N3sRFE079974; Mon, 22 Aug 2005 20:54:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7N3sQ1E079904 for ; Mon, 22 Aug 2005 20:54:26 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 Aug 2005 03:54:18 -0000 Received: from xdsl-213-196-254-23.netcologne.de (EHLO klangraum) [213.196.254.23] by mail.gmx.net (mp023) with SMTP; 23 Aug 2005 05:54:18 +0200 X-Authenticated: #163624 Date: Tue, 23 Aug 2005 05:54:19 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050823035419.GA24155@klangraum> Mail-Followup-To: 'Atom Syntax' References: <430A0276.4000909@dehora.net> <20050822171528.GA21179@klangraum> <6.0.0.20.2.20050823120032.09450810@itmail.it.aoyama.ac.jp> <20050821225954.DDF0D724001@mail.pubsub.com> <20050822010107.GB7206@klangraum> <43095641.1090700@intertwingly.net> <127C04ACE8B75734E683D17F@Wunders-Computer.local> <430A0276.4000909@dehora.net> <20050822171528.GA21179@klangraum> <430A29D7.1010406@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20050823120032.09450810@itmail.it.aoyama.ac.jp> <430A29D7.1010406@dehora.net> 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 ietf.org id AAA28093 * Bill de h=C3=93ra [2005-08-22 21:45]: > ... which are cute. I forget I didn't have an opening tag, or a > buffer for the entry. Oh wait, I do ;) Sure. I didn=E2=80=99t say it was impossible. I was just saying that you have to do more than scan the stream for the sequence =E2=80=9C=E2= =80=9D. > You already have an XML parser, that's not the problem; The point is that if you get broken XML at some point, the parser may be left in a state where it never closes an entry. Using an illegal-in-XML character allows resynching without reconnecting to the stream. > [Incidentally this is a non-problem for APP because we're piggy > backing on HTTP octets...] Which Fat Pings are doing as well=E2=80=A6 > I see all the +1s, but don't understand why reinventing > multi-part MIME with formfeeds as a special case for Atom is > more attractive that an infinite list of entries whose closing > atom:feed tag never arrives. Purely for the resynchronization aspect. If you believe that it=E2=80=99s not an issue, then sure, there=E2=80=99s a lot less difference between the two options. * Martin Duerst [2005-08-23 05:10]: > Well, modulo character encoding issues, that is. An FF will > look differently in UTF-16 than in ASCII-based encodings. Depends on whether you specify a single encoding for all entries at the HTTP level or not. For this application, I would do just that, in which case, as a bonus, non-UTF-8 streams would get to avoid resending the XML preamble over and over and over. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 23 00:37:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QXP-00027K-6m for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:37:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29115 for ; Tue, 23 Aug 2005 00:37:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N4Rbst000323; Mon, 22 Aug 2005 21:27:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N4RbqG000321; Mon, 22 Aug 2005 21:27:37 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7N4RZA7000251 for ; Mon, 22 Aug 2005 21:27:36 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 Aug 2005 04:27:28 -0000 Received: from xdsl-213-196-254-23.netcologne.de (EHLO klangraum) [213.196.254.23] by mail.gmx.net (mp028) with SMTP; 23 Aug 2005 06:27:28 +0200 X-Authenticated: #163624 Date: Tue, 23 Aug 2005 06:27:29 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050823042729.GB24155@klangraum> Mail-Followup-To: Atom Syntax References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> 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 ietf.org id AAA29115 * Tim Bray [2005-08-23 02:35]: > It's got another advantage. You connect and ask for the feed. > You get >=20 > > ....... goes on forever ........ >=20 > and none of the entry documents need to redeclare the Atom > namespace, which saves quite a few bytes after the first > hundred thousand or so entries. -Tim Hmm. That=E2=80=99s the first really solid pro-single-doc argument I see=E2=80= =A6 And one I don=E2=80=99t think can be argued about, /realistically/. =E2=80=A2 The ^L separation makes a lot of sense for logfiles, but less so for TCP-carried connections which ensure a basic level of data integrity. (With logfiles on disk all bets are off.) =E2=80=A2 =E2=80=9CJust discard the last incomplete document=E2=80=9D log= ic can be implemented without require separate documents by processing and flushing the stack so far whenever an atom:entry start-element event is seen. I still dislike the idea of a =E2=80=9Cvirtual closing tag=E2=80=9D =E2=80= =93 it ain=E2=80=99t 1995 anymore, after all. And I still think separate documents would be cleaner and would require a bit less special case logic to process. But this *is* an application where saving bytes is a serious enough concern, and I suppose that so long as the only thing missing is exactly one atom:feed end-element event, the special case is simple enough that I guess it=E2=80=99s acceptable. Ugh. Reality. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 23 01:09:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7R2K-0007Lu-6Y for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 01:09:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00032 for ; Tue, 23 Aug 2005 01:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N4u205018592; Mon, 22 Aug 2005 21:56:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N4u2wu018591; Mon, 22 Aug 2005 21:56:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7N4u1VZ018512 for ; Mon, 22 Aug 2005 21:56:02 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 23 Aug 2005 04:55:55 -0000 Received: from dsl-084-056-224-252.arcor-ip.net (EHLO hive) [84.56.224.252] by mail.gmx.net (mp005) with SMTP; 23 Aug 2005 06:55:55 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 06:56:19 +0200 Message-ID: References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> In-Reply-To: <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id BAA00032 * Tim Bray wrote: >If you encounter a busted tag on the Nth entry, per the XML spec =20 >that's a fatal error and you can't process any more. That's a bit misleading, a fatal error just means that the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature and further processing would be implementation-defined. So this scenario is unconstrained by the XML specifications. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Tue Aug 23 02:06:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Rvz-0001gL-4c for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 02:06:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08580 for ; Tue, 23 Aug 2005 02:06:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N60Bdn081704; Mon, 22 Aug 2005 23:00:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N60B8B081703; Mon, 22 Aug 2005 23:00:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N60AoA081613 for ; Mon, 22 Aug 2005 23:00:10 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from BOBSLAPTOP (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 40D07724149; Tue, 23 Aug 2005 02:00:05 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" , "'A. Pagaltzis'" Cc: "'Atom Syntax'" Subject: RE: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 01:59:59 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWnU3Nk4jD2v5KRSCCN+wdDS/RwjwAUjOPg In-Reply-To: <430A29D7.1010406@dehora.net> Message-Id: <20050823060005.40D07724149@mail.pubsub.com> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7N60AoA081696 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 ietf.org id CAA08580 Bill de h=D3ra wrote: > the problem is managing the stream buffer off the wire for a > protocol model that has no underlying concept of an octet frame. > I've written enough XMPP code to understand why the BEEP/MIME crowd > might frown at it Framing is, in fact, an exceptionally important issue. Fortunately, HTTP offers us some framing capability in the form of chunked delivery. T= his is much more light weight than what BEEP provides since HTTP assumes TCP/= IP as a transport layer while BEEP did not. The HTTP chunked delivery method would be vastly superior to the suggestions for doing thing like including form-feeds or sequences of nul= ls as entry boundary markers. If you accept a simple rule that says that you will insert HTTP chunk length markers between each entry sent in a "never-ending" Atom file, you get something like the feed I show below. Simply strip out the chunk length data prior to stuffing data into your X= ML parser. If an entry appears to continue beyond a chunk boundary, discard that entry and continue by reading the next chunk. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 for more information on this method. Note that RFC2616 says: "All HTTP/1.= 1 applications MUST be able to receive and decode the "chunked" transfer-coding,..." Note: the chunk lengths are not "correct" in the following example. GET /never-ending-feed.xml HTTP/1.1 HTTP/1.1 200 OK Date: Fri Apr 8 17:41:11 2005 Server: FeedMesh/0.1 Connection: close Transfer-Encoding: chunked Content-Type: application/xml; charset=3Dutf-8 ab ... a8 ... 93 ... And so forth until finally you get a , the connection closes, or y= ou close the connection. This is simple, requires no new specifications and provides for robust er= ror recovery in that broken entries can be easily detected and discarded. bob wyman From owner-atom-syntax@mail.imc.org Tue Aug 23 02:46:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7SYC-0000me-Pa for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 02:46:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17202 for ; Tue, 23 Aug 2005 02:46:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N6f5aL020152; Mon, 22 Aug 2005 23:41:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N6f5eJ020151; Mon, 22 Aug 2005 23:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N6f4dg020113 for ; Mon, 22 Aug 2005 23:41:04 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-15.adsl-net.finnetcom.net ([217.140.228.15]:56440 "EHLO [217.140.228.15]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1229901AbVHWGlC convert rfc822-to-8bit (ORCPT ); Tue, 23 Aug 2005 09:41:02 +0300 In-Reply-To: <20050823042729.GB24155@klangraum> References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <20050823042729.GB24155@klangraum> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <8c36e09d3633f1bd6c4f50cb1b33a7a0@iki.fi> Cc: Atom Syntax From: Henri Sivonen Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 09:40:44 +0300 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.622) 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 ietf.org id CAA17202 On Aug 23, 2005, at 07:27, A. Pagaltzis wrote: > I still dislike the idea of a =93virtual closing tag=94 =96 it ain=92t > 1995 anymore, after all. You seem to be thinking that an XML parser needs to consider the whole=20 document before reporting data to the app. This is not the case. If you have a document that lacks the end tag, the fatal error is hit=20 when the data stream ends. All the subtrees rooted at children of the=20 document element will be just fine. Try it with any streaming SAX=20 parser. In this case, the data stream ends only if either party decides to=20 close the connection. The parser will never know how long the document=20 would have been. From the parsers point of view it looks like a broken=20 stream while reading a finite doc. There's nothing in the XML spec=20 requiring the app to throw away the data structures it has already=20 built when the parser reports the error. --=20 Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue Aug 23 04:47:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7URA-0006MV-Dd for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 04:47:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21796 for ; Tue, 23 Aug 2005 04:47:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7N8YJiu014400; Tue, 23 Aug 2005 01:34:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7N8YJJt014399; Tue, 23 Aug 2005 01:34:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7N8Y3Wp014080 for ; Tue, 23 Aug 2005 01:34:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 8477 messnum 5760930 invoked from network[83.70.255.222/83-70-255-222.b-ras1.prp.dublin.eircom.net]); 23 Aug 2005 08:33:57 -0000 Received: from 83-70-255-222.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.255.222) by mail12.svc.cra.dublin.eircom.net (qp 8477) with SMTP; 23 Aug 2005 08:33:57 -0000 Message-ID: <430ADF71.5090702@dehora.net> Date: Tue, 23 Aug 2005 09:33:53 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Joe Gregorio , Sam Ruby , bobwyman@pubsub.com, Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> In-Reply-To: <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> X-Enigmail-Version: 0.92.0.0 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: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: > >>> Essentially, LiveJournal is making this data available to anybody who >>> wishes to access it, without any need to register or to invent a >>> unique API. >> >> >> Ahh, I had thought this was a more dedicated ping traffic stream. The >> never ending Atom document makes much more sense now. > > > It's got another advantage. You connect and ask for the feed. You get > > > ....... goes on forever ........ > > and none of the entry documents need to redeclare the Atom namespace, > which saves quite a few bytes after the first hundred thousand or so > entries. -Tim Any value in using this to exercise the PaceBatch? If it dealt with the use-case in terms of bulk transfer that would make it more compelling imo. cheers Bill From owner-atom-syntax@mail.imc.org Tue Aug 23 09:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ys0-0005l5-5P for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 09:31:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03148 for ; Tue, 23 Aug 2005 09:31:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDNdlN065760; Tue, 23 Aug 2005 06:23:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NDNdOo065759; Tue, 23 Aug 2005 06:23:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDNcxu065744 for ; Tue, 23 Aug 2005 06:23:38 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7NDNcWR014136 for ; Tue, 23 Aug 2005 07:23:38 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILO00ALUFVDXI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 23 Aug 2005 07:23:38 -0600 (MDT) Received: from [192.168.0.100] ([64.201.216.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILO00L4EFVC4V@mail.sun.net> for atom-syntax@imc.org; Tue, 23 Aug 2005 07:23:37 -0600 (MDT) Date: Tue, 23 Aug 2005 06:23:40 -0700 From: Tim Bray Subject: Re: If you want "Fat Pings" just use Atom! In-reply-to: <20050823042729.GB24155@klangraum> To: "A. Pagaltzis" Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <20050823042729.GB24155@klangraum> X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7NDNcxu065748 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 ietf.org id JAA03148 On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote: >> It's got another advantage. You connect and ask for the feed. >> You get >> >> >> ....... goes on forever ........ >> >> and none of the entry documents need to redeclare the Atom >> namespace, which saves quite a few bytes after the first >> hundred thousand or so entries. -Tim > > That=92s the first really solid pro-single-doc argument I see=85 There's another. You don't have to create a new XML parser for each =20 of the entries. In most programming environments, that's a time-=20 saver. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 23 09:31:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ys4-0005mo-6w for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 09:31:20 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03156 for ; Tue, 23 Aug 2005 09:31:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDPlAf066541; Tue, 23 Aug 2005 06:25:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NDPlSF066540; Tue, 23 Aug 2005 06:25:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDPkRq066530 for ; Tue, 23 Aug 2005 06:25:46 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7NDPjWR016019 for ; Tue, 23 Aug 2005 07:25:45 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILO00LK1FYXFT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 23 Aug 2005 07:25:45 -0600 (MDT) Received: from [192.168.0.100] ([64.201.216.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILO00L4RFYW4V@mail.sun.net> for atom-syntax@imc.org; Tue, 23 Aug 2005 07:25:45 -0600 (MDT) Date: Tue, 23 Aug 2005 06:25:48 -0700 From: Tim Bray Subject: Re: If you want "Fat Pings" just use Atom! In-reply-to: To: Bjoern Hoehrmann Cc: atom-syntax@imc.org Message-id: <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote: >> If you encounter a busted tag on the Nth entry, per the XML spec >> that's a fatal error and you can't process any more. > > That's a bit misleading, a fatal error just means that the XML > processor must report the error to the application and that the > processor is not required by the XML specification to continue > processing; doing so is however an optional feature and further > processing would be implementation-defined. So this scenario is > unconstrained by the XML specifications. No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal error". -Tim From owner-atom-syntax@mail.imc.org Tue Aug 23 10:03:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZNA-00058P-Q6 for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:03:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05535 for ; Tue, 23 Aug 2005 10:03:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDvV89077702; Tue, 23 Aug 2005 06:57:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NDvV0D077701; Tue, 23 Aug 2005 06:57:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NDvTGM077651 for ; Tue, 23 Aug 2005 06:57:30 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 23 Aug 2005 13:57:23 -0000 Received: from dsl-084-056-224-252.arcor-ip.net (EHLO hive) [84.56.224.252] by mail.gmx.net (mp015) with SMTP; 23 Aug 2005 15:57:23 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 15:57:47 +0200 Message-ID: References: <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> In-Reply-To: <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id KAA05535 * Tim Bray wrote: >> That's a bit misleading, a fatal error just means that the XML >> processor must report the error to the application and that the >> processor is not required by the XML specification to continue >> processing; doing so is however an optional feature and further >> processing would be implementation-defined. So this scenario is >> unconstrained by the XML specifications. > >No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal =20 >error". -Tim Yes, exactly what I wrote... --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Tue Aug 23 10:03:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZNC-000590-Cg for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:03:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05540 for ; Tue, 23 Aug 2005 10:03:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDwTek078081; Tue, 23 Aug 2005 06:58:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NDwT8Z078080; Tue, 23 Aug 2005 06:58:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NDwTED078034 for ; Tue, 23 Aug 2005 06:58:29 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (rwcrmhc14) with SMTP id <2005082313582301400hg028e>; Tue, 23 Aug 2005 13:58:23 +0000 Date: Tue, 23 Aug 2005 07:58:21 -0600 Subject: Re: If you want "Fat Pings" just use Atom! Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20050823035419.GA24155@klangraum> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote: > * Martin Duerst [2005-08-23 05:10]: >> Well, modulo character encoding issues, that is. An FF will >> look differently in UTF-16 than in ASCII-based encodings. > Depends on whether you specify a single encoding for all entries > at the HTTP level or not. For this application, I would do just > that, in which case, as a bonus, non-UTF-8 streams would get to > avoid resending the XML preamble over and over and over. Of course, if you do that, you won't be able to keep signatures for entries originally published in an encoding other than the one you've chosen. If one were to want to signal an encoding change mid-stream, how might that work with what's been proposed thus far? From owner-atom-syntax@mail.imc.org Tue Aug 23 10:27:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Zkh-0002LW-SH for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:27:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07593 for ; Tue, 23 Aug 2005 10:27:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NEMRQ3092576; Tue, 23 Aug 2005 07:22:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NEMRiv092575; Tue, 23 Aug 2005 07:22:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7NEMPjs092511 for ; Tue, 23 Aug 2005 07:22:26 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 Aug 2005 14:22:20 -0000 Received: from xdsl-213-196-254-23.netcologne.de (EHLO klangraum) [213.196.254.23] by mail.gmx.net (mp002) with SMTP; 23 Aug 2005 16:22:20 +0200 X-Authenticated: #163624 Date: Tue, 23 Aug 2005 16:22:09 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <20050823142209.GA9082@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050823035419.GA24155@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id KAA07593 * Antone Roundy [2005-08-23 16:05]: > Of course, if you do that, you won't be able to keep signatures > for entries originally published in an encoding other than the > one you've chosen. Why is that a concern for a site publishing a stream of its own users=E2=80=99 posts? Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 23 10:31:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZoM-0002wp-GR for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:31:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07748 for ; Tue, 23 Aug 2005 10:31:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NER32o095902; Tue, 23 Aug 2005 07:27:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NER3Gl095901; Tue, 23 Aug 2005 07:27:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NER38p095832 for ; Tue, 23 Aug 2005 07:27:03 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 0E39522; Tue, 23 Aug 2005 07:26:58 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7NEQvkv017982; Tue, 23 Aug 2005 07:26:57 -0700 (PDT) Date: Tue, 23 Aug 2005 07:27:01 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: If you want "Fat Pings" just use Atom! Message-ID: <683C78BB88AC5A6E8A64E554@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <8c36e09d3633f1bd6c4f50cb1b33a7a0@iki.fi> References: <20050821225954.DDF0D724001@mail.pubsub.com> <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <20050823042729.GB24155@klangraum> <8c36e09d3633f1bd6c4f50cb1b33a7a0@iki.fi> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 23, 2005 9:40:44 AM +0300 Henri Sivonen wrote: > There's nothing in the XML spec requiring the app to throw away the data > structures it has already built when the parser reports the error. There is also nothing requiring it. It is optional. The only reqired behavior is to report the error and stop creating parsed information. Otherwise, "results are undefined" according to the spec. The spec does require that normal processing stop at the error. The parser can make data past the error available, but it "must not continue to pass character data and information about the document's logical structure to the application in the normal way". This still feels like a hack to me. An unterminated document is not well-formed, and is not XML or Atom. Doing this should require another RFC that says, "we didn't really mean that it had to be XML." wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 23 10:53:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7a9I-0007Dp-W4 for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:53:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08650 for ; Tue, 23 Aug 2005 10:53:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NEmbAH009086; Tue, 23 Aug 2005 07:48:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NEmb8R009084; Tue, 23 Aug 2005 07:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NEma3I009071 for ; Tue, 23 Aug 2005 07:48:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id j7NEmZea021996; Tue, 23 Aug 2005 07:48:35 -0700 (PDT) Received: from [10.0.0.11] (host-84-9-132-129.bulldogdsl.com [84.9.132.129]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j7NEmVns013197 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 23 Aug 2005 07:48:34 -0700 (PDT) In-Reply-To: References: <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <084A81CA-3006-455B-BFCA-16A75C08C00A@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 15:48:33 +0100 To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 Aug 2005, at 2:57 pm, Bjoern Hoehrmann wrote: >> No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal >> error". -Tim >> > > Yes, exactly what I wrote... "the XML processor must report the error to the application and that the processor is not required by the XML specification to continue processing; doing so is however an optional feature and further processing would be implementation-defined" vs "Once a fatal error is detected, however, the processor must not continue normal processing (i.e., it must not continue to pass character data and information about the document's logical structure to the application in the normal way)." Graham From owner-atom-syntax@mail.imc.org Tue Aug 23 11:19:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aZ8-0004I9-Au for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:19:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09690 for ; Tue, 23 Aug 2005 11:19:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NF8gL0021412; Tue, 23 Aug 2005 08:08:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NF8gqM021411; Tue, 23 Aug 2005 08:08:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7NF8fME021341 for ; Tue, 23 Aug 2005 08:08:41 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 23 Aug 2005 15:08:35 -0000 Received: from dsl-084-056-235-236.arcor-ip.net (EHLO hive) [84.56.235.236] by mail.gmx.net (mp015) with SMTP; 23 Aug 2005 17:08:35 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Graham Cc: atom-syntax Subject: Re: If you want "Fat Pings" just use Atom! Date: Tue, 23 Aug 2005 17:08:58 +0200 Message-ID: <18emg1hasnsgknmucinje27iiv22o56qb1@hive.bjoern.hoehrmann.de> References: <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> <084A81CA-3006-455B-BFCA-16A75C08C00A@mac.com> In-Reply-To: <084A81CA-3006-455B-BFCA-16A75C08C00A@mac.com> X-Mailer: Forte Agent 3.0/32.763 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 ietf.org id LAA09690 * Graham wrote: >"the XML processor must report the error to the application and that the >processor is not required by the XML specification to continue >processing; doing so is however an optional feature and further >processing would be implementation-defined" > >vs > >"Once a fatal error is detected, however, the processor must not =20 >continue normal processing (i.e., it must not continue to pass =20 >character data and information about the document's logical structure =20 >to the application in the normal way)." Yes, the normal way could be for example to have the illformed flag on each event not set, and an unnormal way would be to have the flag set. In particular, "the processor MAY make unprocessed data from the document (with intermingled character data and markup) available to the application" and there is no constraint on what the application may or must not do with such data. --=20 Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld= .de 68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/=20 From owner-atom-syntax@mail.imc.org Tue Aug 23 11:39:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7as4-0007f4-4t for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 11:39:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10510 for ; Tue, 23 Aug 2005 11:39:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NFTF95032928; Tue, 23 Aug 2005 08:29:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NFTFX1032926; Tue, 23 Aug 2005 08:29:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NFTEZu032901 for ; Tue, 23 Aug 2005 08:29:14 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7NFTDWR001513 for ; Tue, 23 Aug 2005 09:29:13 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0ILO009XULOPVZ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 23 Aug 2005 09:29:13 -0600 (MDT) Received: from [192.168.0.100] ([64.201.216.28]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0ILO00JI6LOOPY@mail.sun.net> for atom-syntax@imc.org; Tue, 23 Aug 2005 09:29:13 -0600 (MDT) Date: Tue, 23 Aug 2005 08:29:15 -0700 From: Tim Bray Subject: Re: If you want "Fat Pings" just use Atom! In-reply-to: To: Bjoern Hoehrmann Cc: atom-syntax@imc.org Message-id: <84A13E7A-EA5A-4451-9183-1AD9DF0C11F1@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <3f1451f505082118345e5e18f5@mail.gmail.com> <43095633.5020008@intertwingly.net> <3f1451f505082207262ab386df@mail.gmail.com> <279D121A-4CAF-4A2B-8ACE-A43C34DEDB52@sun.com> <430A76F7.3000906@gmail.com> <42FC6123-9804-4415-9063-3A726BD77B72@Sun.COM> <352F3C28-1E76-4385-B953-7344A9F31151@Sun.COM> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote: >>> That's a bit misleading, a fatal error just means that the XML >>> processor must report the error to the application and that the >>> processor is not required by the XML specification to continue >>> processing; doing so is however an optional feature... >>> >> >> No. See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal >> error". -Tim >> > > Yes, exactly what I wrote... No. The specification clearly *forbids* proceeding with normal processing. If you get a busted element in a feed, you'd better close that connection and open another one. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 23 18:16:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7h4F-0008BS-Oy for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 18:16:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15938 for ; Tue, 23 Aug 2005 18:16:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NM9dGW061563; Tue, 23 Aug 2005 15:09:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7NM9dXx061562; Tue, 23 Aug 2005 15:09:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7NM9bHC061495 for ; Tue, 23 Aug 2005 15:09:37 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i27so1118391wra for ; Tue, 23 Aug 2005 15:09:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=Ijr09SHKJSpdaHnelCR4YUZ49ZVZSg1L4rryvuiBN1BzXf6Iqsdr6YSSIBu/MdCClnUZQl6JFxYeqvlunyQzSBtRY9NJ6LVtFJiogsvrVI7jT2aEL63ZRIXcEQ5l7nAIWaJRnmNrlRTTJm8+c+/xci9x0Pu9O4sbeqIhpuZRcC4= Received: by 10.54.32.60 with SMTP id f60mr4346268wrf; Tue, 23 Aug 2005 15:09:28 -0700 (PDT) Received: from ?192.168.1.100? ([67.181.221.143]) by mx.gmail.com with ESMTP id g5sm39345wra.2005.08.23.15.09.26; Tue, 23 Aug 2005 15:09:26 -0700 (PDT) Message-ID: <430B9E91.2050907@gmail.com> Date: Tue, 23 Aug 2005 15:09:21 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Updated License and Expires Extensions 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: Content-Transfer-Encoding: 7bit I've updated the License and Expiration Extension Proposals to reflect the recent discussion about metadata inheritance. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-02.txt http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-01.txt The license draft explicitly states that license links on the feed level are NOT inherited by entries. Likewise, the expires draft states that 'expires' and 'max-age' elements on the feed level only affects the metadata of the feed and not the contained elements. - James From owner-atom-syntax@mail.imc.org Tue Aug 23 23:08:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7lcv-0006bV-52 for atompub-archive@megatron.ietf.org; Tue, 23 Aug 2005 23:08:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26771 for ; Tue, 23 Aug 2005 23:08:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O32qDw033157; Tue, 23 Aug 2005 20:02:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O32qT1033154; Tue, 23 Aug 2005 20:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O32poq033130 for ; Tue, 23 Aug 2005 20:02:52 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id B85FD4EEEF for ; Tue, 23 Aug 2005 23:02:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2D79235F-EB86-46F8-B90F-8E6E242BDECF@w3.org> From: Karl Dubost Subject: Re: geolocation in atom:author? Date: Tue, 23 Aug 2005 23:02:50 -0400 To: Atom Syntax X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7O32qoq033142 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 ietf.org id XAA26771 Le 05-08-21 =E0 11:45, Paul Hoffman a =E9crit : > At 12:17 AM +1000 8/22/05, Eric Scheid wrote: > #2 through #4 seem understandable, but what the heck is #1? "The =20 > place where this feed was put together"? "The place where this feed =20 > was originally grabbed from"? hmmm really? > > foo > location#2 > What is location#2? a. The usual location of the author as in the place is living =20 right now? b. The place of his origins? c. The place where he's blogging right now? d. The place he was when he had written the story that he will =20 published in a few seconds but two days late with regards to the =20 event date? I say that because for example in my case. a. My apartment, Montr=E9al, Canada b. Rouen, France c. Cafe Laika, Montr=E9al, Canada d. London, UK There's exactly the same kind of problems with photos. The location =20 where the photos is taken, or the location of (one or more) regions =20 in the photos. It's not that easy to answer at any level. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Wed Aug 24 02:09:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7oS2-0005ss-9H for atompub-archive@megatron.ietf.org; Wed, 24 Aug 2005 02:09:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12340 for ; Wed, 24 Aug 2005 02:09:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O64g52008889; Tue, 23 Aug 2005 23:04:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O64gmo008888; Tue, 23 Aug 2005 23:04:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O64fCg008875 for ; Tue, 23 Aug 2005 23:04:41 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.45.41] (210.193.203.50) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 24 Aug 2005 16:05:50 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 24 Aug 2005 16:04:39 +1000 Subject: Re: geolocation in atom:author? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2D79235F-EB86-46F8-B90F-8E6E242BDECF@w3.org> 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: Content-Transfer-Encoding: 7bit On 24/8/05 1:02 PM, "Karl Dubost" wrote: >> >> >> foo >> location#2 >> > > What is location#2? > a. The usual location of the author as in the place is living > right now? > b. The place of his origins? > c. The place where he's blogging right now? > d. The place he was when he had written the story that he will > published in a few seconds but two days late with regards to the > event date? c. and d. would be in their respective entries b. that would be or some variant a. as a general statement, that matches closely with a semantic reading: here is a feed by an author who, unless stated otherwise in specific entries, can be found at . At least for purposes of this particular feed. e. From owner-atom-syntax@mail.imc.org Wed Aug 24 02:11:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7oTZ-0006yH-MX for atompub-archive@megatron.ietf.org; Wed, 24 Aug 2005 02:11:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13859 for ; Wed, 24 Aug 2005 02:11:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O63sOU008592; Tue, 23 Aug 2005 23:03:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O63sli008591; Tue, 23 Aug 2005 23:03:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O63qIb008368 for ; Tue, 23 Aug 2005 23:03:53 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.45.41] (210.193.203.50) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 24 Aug 2005 16:04:26 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 24 Aug 2005 16:03:14 +1000 Subject: Re: geolocation in atom:author? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: 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: Content-Transfer-Encoding: 7bit On 22/8/05 1:45 AM, "Paul Hoffman" wrote: >> >> location#1 > > #2 through #4 seem understandable, but what the heck is #1? > [a] "The place where this feed was put together"? > [b] "The place where this feed was originally grabbed from"? [a] would suffer the AOL problem, no? According to my webserver logs, I have several million visitors from Virginia, and quite a few less from the other 49 US states. [b] similarly. who cares where the server hardware is. My intention is perhaps better expressed with this example: Memoirs from Paris, France location#1 = Paris, France Some old digger location#2 = Suva, Fiji Thus, the feed is a collection of entries to do with some place in France, written by some old fart laying on the beach in Sunny Fiji. Occasionally he might write an entry regarding a location in London, UK, and occasionally he might write an entry during a quick popover to Sydney, Australia. Nonetheless, if you are looking for a which could be loosely categorised as regarding Paris France, then this is one such feed. e. From owner-atom-syntax@mail.imc.org Wed Aug 24 05:20:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rQz-0004fz-1d for atompub-archive@megatron.ietf.org; Wed, 24 Aug 2005 05:20:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08840 for ; Wed, 24 Aug 2005 05:20:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O9ETrI078629; Wed, 24 Aug 2005 02:14:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7O9ETIU078628; Wed, 24 Aug 2005 02:14:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7O9ERNV078575 for ; Wed, 24 Aug 2005 02:14:28 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j7O9ELd24495; Wed, 24 Aug 2005 18:14:21 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 9071c848_147f_11da_8d2d_0030482533a1_406; Wed, 24 Aug 2005 18:15:07 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0037FC; 24 Aug 05 18:15:18 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 24 Aug 05 18:15:08 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.66) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0037F9; 24 Aug 05 18:15:05 +0900 Message-Id: <6.0.0.20.2.20050824161923.0639e630@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 24 Aug 2005 16:21:16 +0900 To: Antone Roundy , atom-syntax@imc.org From: Martin Duerst Subject: Re: If you want "Fat Pings" just use Atom! In-Reply-To: References: <20050823035419.GA24155@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 22:58 05/08/23, Antone Roundy wrote: > >On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote: >> For this application, I would do just >> that, in which case, as a bonus, non-UTF-8 streams would get to >> avoid resending the XML preamble over and over and over. > >Of course, if you do that, you won't be able to keep signatures for entries originally published in an encoding other than the one you've chosen. Wrong, unfortunately. XML Signature requires to transcode to UTF-8 before signing, exactly to protect against such problems. >If one were to want to signal an encoding change mid-stream, how might that work with what's been proposed thus far? You can't change an encoding midstream in an XML entity. You can use different encodings for different external entities, though. Regrads, Martin. From owner-atom-syntax@mail.imc.org Wed Aug 24 18:17:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83YX-0000vC-7g for atompub-archive@megatron.ietf.org; Wed, 24 Aug 2005 18:17:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25755 for ; Wed, 24 Aug 2005 18:17:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OM7LMb055618; Wed, 24 Aug 2005 15:07:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7OM7LJL055617; Wed, 24 Aug 2005 15:07:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7OM7K4P055611 for ; Wed, 24 Aug 2005 15:07:20 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.173.195]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 3DB1FA32D2 for ; Wed, 24 Aug 2005 18:07:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Feed History: stateful -> incremental? Date: Wed, 24 Aug 2005 15:07:15 -0700 To: Atom Syntax X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just bouncing an idea around; it seems that there's a fair amount of confusion / fuzziness caused by the term 'stateful'. Would people prefer the term 'incremental'? I.e., instead of a "stateful feed", it would be an "incremental feed"; fh:stateful would become fh:incremental. Worth it? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 25 02:33:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8BJ8-0003bT-LC for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 02:33:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02399 for ; Thu, 25 Aug 2005 02:33:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7P6PGDN033919; Wed, 24 Aug 2005 23:25:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7P6PGmM033918; Wed, 24 Aug 2005 23:25:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7P6PFP7033907 for ; Wed, 24 Aug 2005 23:25:15 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so285283rnf for ; Wed, 24 Aug 2005 23:25:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=oUzvW8UnhspDF93GbTNfS5Te9wFVa6n/Q0nxFQsTejYaWfmy0octxEjV9z1jBNDFHDh5GCvTZfw4Kn2OLrBBgFKsy/Y3qIxk/m380V2TuxB39khdVK0SQGgcljq+E2ZDUsvoovqD9XowskLB7tJnDzvcIsp7PejAxWEG6RNTTT4= Received: by 10.38.209.5 with SMTP id h5mr882021rng; Wed, 24 Aug 2005 23:25:15 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id j20sm1619485rnf.2005.08.24.23.25.15; Wed, 24 Aug 2005 23:25:15 -0700 (PDT) Message-ID: <430D6448.9040703@gmail.com> Date: Wed, 24 Aug 2005 23:25:12 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Don't Aggregrate Me 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: Content-Transfer-Encoding: 7bit Up to this point, the vast majority of use cases for Atom feeds is the traditional syndicated content case. A bunch of content updates that are designed to be distributed and aggregated within Feed readers or online aggregators, etc. But with Atom providing a much more flexible content model that allows for data that may not be suitable for display within a feed reader or online aggregator, I'm wondering what the best way would be for a publisher to indicate that a feed should not be aggregated? For example, suppose I build an application that depends on an Atom feed containing binary content (e.g. a software update feed). I don't really want aggregators pulling and indexing that feed and attempting to display it within a traditional feed reader. What can I do? Does the following work? ... no Should I use a processing instruction instead? ... I dunno. What do you all think? Am I just being silly or does any of this actually make a bit of sense? - James From owner-atom-syntax@mail.imc.org Thu Aug 25 06:08:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8EeZ-0000Gn-PW for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 06:08:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10578 for ; Thu, 25 Aug 2005 06:08:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PA0ug0016042; Thu, 25 Aug 2005 03:00:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PA0uDT016041; Thu, 25 Aug 2005 03:00:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from krusty.greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PA0sQJ016020 for ; Thu, 25 Aug 2005 03:00:55 -0700 (PDT) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.26] (burns.greenbytes.de [192.168.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by krusty.greenbytes.de (Postfix) with ESMTP id 5CAE3572ACCE; Thu, 25 Aug 2005 12:00:52 +0200 (CEST) In-Reply-To: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Stefan Eissing Subject: Re: Feed History: stateful -> incremental? Date: Thu, 25 Aug 2005 12:00:52 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Am 25.08.2005 um 00:07 schrieb Mark Nottingham: > > Just bouncing an idea around; it seems that there's a fair amount of > confusion / fuzziness caused by the term 'stateful'. Would people > prefer the term 'incremental'? > I.e., instead of a "stateful feed", it would be an "incremental feed"; > fh:stateful would become fh:incremental. I would prefer to name such a feed a "chunked" feed. So, that would make it fh:chunked=(true|false). That leaves the "history" analogy a bit behind, I'm afraid. So a "chunked feed" would be a history if "fh:order=publish-time"? Maybe not worth it, just a thought. I see one use of feed histories in making normal feed documents very small and still being able to offer a rather long list of entries. Clients checking for updates would just get a tiny document (2 entries maybe) iff they do not use HTTP caching or ETag validation. Could this be some transfer-volume saver? //Stefan From owner-atom-syntax@mail.imc.org Thu Aug 25 06:35:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8F4m-0007kR-KK for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 06:35:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11433 for ; Thu, 25 Aug 2005 06:35:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PAMDUL024161; Thu, 25 Aug 2005 03:22:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PAMDau024160; Thu, 25 Aug 2005 03:22:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7PAMCAB024149 for ; Thu, 25 Aug 2005 03:22:13 -0700 (PDT) (envelope-from iand@internetalchemy.org) Received: (qmail 52309 invoked from network); 25 Aug 2005 10:22:12 -0000 Received: from unknown (HELO ?172.30.2.11?) (unknown) by unknown with SMTP; 25 Aug 2005 10:22:12 -0000 X-pair-Authenticated: 62.172.77.66 Message-ID: <430D9BD3.6030406@internetalchemy.org> Date: Thu, 25 Aug 2005 11:22:11 +0100 From: Ian Davis User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Atom Syntax Subject: Re: Feed History: stateful -> incremental? References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> In-Reply-To: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24/08/2005 23:07, Mark Nottingham wrote: > > Just bouncing an idea around; it seems that there's a fair amount of > confusion / fuzziness caused by the term 'stateful'. Would people > prefer the term 'incremental'? > > I.e., instead of a "stateful feed", it would be an "incremental feed"; > fh:stateful would become fh:incremental. > > Worth it? What about "partial"? Ian From owner-atom-syntax@mail.imc.org Thu Aug 25 06:52:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8FLo-0005B0-Pv for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 06:52:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12133 for ; Thu, 25 Aug 2005 06:52:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PAiwes032263; Thu, 25 Aug 2005 03:44:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PAiwrI032262; Thu, 25 Aug 2005 03:44:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PAivWq032249 for ; Thu, 25 Aug 2005 03:44:58 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1E8FE5-0002BE-00; Thu, 25 Aug 2005 11:44:53 +0100 Date: Thu, 25 Aug 2005 11:44:53 +0100 From: James Aylett To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050825104453.GD27648@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <430D6448.9040703@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430D6448.9040703@gmail.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 24, 2005 at 11:25:12PM -0700, James M Snell wrote: > For example, suppose I build an application that depends on an Atom feed > containing binary content (e.g. a software update feed). I don't really > want aggregators pulling and indexing that feed and attempting to > display it within a traditional feed reader. What can I do? I like the use case, but I don't see why you would want to disallow aggregators to pull the feed. Assuming it's not commercial (in which case the feed would require authorisation or something), wouldn't it make sense to have an aggregation feed that does software upgrade rollups across a range of products, eg: for feeding out to desktop machines in a corporation? The 'display within a feed reader' is more of an issue, but if you type your content right the reader won't do anything bad with it. After all, someone can still subscribe their reader directly to the feed. I don't think we need this (but I still like the use case :-). James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu Aug 25 08:51:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HC9-0005IL-EI for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:51:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15958 for ; Thu, 25 Aug 2005 08:50:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PChrXI076560; Thu, 25 Aug 2005 05:43:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PChrm6076559; Thu, 25 Aug 2005 05:43:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7PChpBR076513 for ; Thu, 25 Aug 2005 05:43:52 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 Aug 2005 12:43:43 -0000 Received: from xdsl-81-173-229-185.netcologne.de (EHLO klangraum) [81.173.229.185] by mail.gmx.net (mp024) with SMTP; 25 Aug 2005 14:43:43 +0200 X-Authenticated: #163624 Date: Thu, 25 Aug 2005 14:43:43 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050825124343.GA14989@klangraum> Mail-Followup-To: Atom Syntax References: <430D6448.9040703@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <430D6448.9040703@gmail.com> 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 ietf.org id IAA15958 * James M Snell [2005-08-25 08:35]: > I don't really want aggregators pulling and indexing that feed > and attempting to display it within a traditional feed reader. Why, though? There=E2=80=99s no reason aggregators couldn=E2=80=99t at some point beco= me more capable of doing something useful with unknown content types (cf. mail clients), and even before, subscribing in an aggregator is a useful debugging venue in a cinch. I think what you need is no more than a way to say =E2=80=9Cthis doesn=E2= =80=99t contain human-readable content.=E2=80=9D I don=E2=80=99t know that I=E2=80= =99d try to put this fact into the feed in machine-readable form. I=E2=80=99d be inclined to just supply an atom:subtitle for the feed saying that there=E2=80=99s nothing to read here, sorry. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 25 09:54:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IB8-0008AA-69 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 09:54:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18365 for ; Thu, 25 Aug 2005 09:54:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PDjRe7099273; Thu, 25 Aug 2005 06:45:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PDjRMR099272; Thu, 25 Aug 2005 06:45:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PDjPH1099195 for ; Thu, 25 Aug 2005 06:45:25 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so176843nzi for ; Thu, 25 Aug 2005 06:45:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gRHwpHrbUcifrBzcC8nv2RKVejL4+SYdzRrWZfpVI1vUYiFr+UuA3zEfCGhpOeEVv8jEIkm4qe2hIngxlUlDStQCSLR9XIQlNsKJIBVyO3mUjUyXLYD9xGdFYxfIwDokuE2GNHXMqUOUZUvfLrvQBjgsf0Me0K1Rhjz5g9Jh15c= Received: by 10.36.227.59 with SMTP id z59mr84478nzg; Thu, 25 Aug 2005 06:45:19 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Thu, 25 Aug 2005 06:45:19 -0700 (PDT) Message-ID: <3f1451f505082506454322cfa4@mail.gmail.com> Date: Thu, 25 Aug 2005 09:45:19 -0400 From: Joe Gregorio To: James M Snell Subject: Re: Don't Aggregrate Me Cc: Atom Syntax In-Reply-To: <430D6448.9040703@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <430D6448.9040703@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PDjQH1099265 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/25/05, James M Snell wrote: > > Up to this point, the vast majority of use cases for Atom feeds is the > traditional syndicated content case. A bunch of content updates that > are designed to be distributed and aggregated within Feed readers or > online aggregators, etc. But with Atom providing a much more flexible > content model that allows for data that may not be suitable for display > within a feed reader or online aggregator, I'm wondering what the best > way would be for a publisher to indicate that a feed should not be > aggregated? > > For example, suppose I build an application that depends on an Atom feed > containing binary content (e.g. a software update feed). I don't really > want aggregators pulling and indexing that feed and attempting to > display it within a traditional feed reader. What can I do? First, on this scenario, I would be inclined to make the firmware an enclosure and not included base64. But I still can see a scenario you might be serving up queries via Atom and those queries could be 'heavy'. There are, of course, several things you could do: 1. Cache the results. 2. Support ETags 3. Support ETags and 'fake' them so that they change only once a day, maybe once a week even. There are undoubtedly others, but the more important part is that your 'do not aggregate' doesn't really solve the problem. I could, for example, take one of your heavy search feeds, convert it to HTML via XSLT and include that via iframe in my home page. *That* traffic is going to be a lot worse than an aggregator subscription and wouldn't fit the definition of 'aggregation'. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu Aug 25 10:23:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IdG-0001Om-Fs for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 10:23:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20348 for ; Thu, 25 Aug 2005 10:23:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEGUR2011924; Thu, 25 Aug 2005 07:16:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PEGUjD011923; Thu, 25 Aug 2005 07:16:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEGTIs011876 for ; Thu, 25 Aug 2005 07:16:29 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so25280wra for ; Thu, 25 Aug 2005 07:16:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BVs0TigUA3d/0gWUyUwrHr1EAhIxkjpi8MjqFquGPsjqzNfsG2rcqvm3AsVzCK0Dcihh43KGlJh6ZwiptrnOgIgh6GPy/A/xWw2aHcz1GuqFDdNLn5S/q0pv8nDea/Y0T0xKeMWmX7dlSwExXPys2xh9nTyo2yp8C1LcCGzDSgw= Received: by 10.54.120.1 with SMTP id s1mr1993157wrc; Thu, 25 Aug 2005 07:16:19 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 29sm33762wrl.2005.08.25.07.16.18; Thu, 25 Aug 2005 07:16:19 -0700 (PDT) Message-ID: <430DD2AD.30506@gmail.com> Date: Thu, 25 Aug 2005 07:16:13 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: Atom Syntax Subject: Re: Don't Aggregrate Me References: <430D6448.9040703@gmail.com> <20050825124343.GA14989@klangraum> In-Reply-To: <20050825124343.GA14989@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id KAA20348 A. Pagaltzis wrote: >* James M Snell [2005-08-25 08:35]: > =20 > >>I don't really want aggregators pulling and indexing that feed >>and attempting to display it within a traditional feed reader. >> =20 >> > >Why, though? > >There=E2=80=99s no reason aggregators couldn=E2=80=99t at some point bec= ome more >capable of doing something useful with unknown content types (cf. >mail clients), and even before, subscribing in an aggregator is a >useful debugging venue in a cinch. > >I think what you need is no more than a way to say =E2=80=9Cthis doesn=E2= =80=99t >contain human-readable content.=E2=80=9D I don=E2=80=99t know that I=E2=80= =99d try to put >this fact into the feed in machine-readable form. I=E2=80=99d be incline= d >to just supply an atom:subtitle for the feed saying that there=E2=80=99s >nothing to read here, sorry. > > =20 > Good points but it's more than just the handling of human-readable=20 content. That's one use case but there are others. Consider, for=20 example, if I was producing a feed that contained javascript and CSS=20 styles that would otherwise be unwise for an online aggregator to try to=20 display (e.g. the now famous Platypus prank...=20 http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely). =20 Typically aggregators and feed readers are (rightfully) recommended to=20 strip scripts and styles from the content in order to reliably display=20 the information. But, it is foreseeable that applications could be=20 built that rely on these types of mechanism within the feed content. =20 For example, I may want to create a feed that provides the human=20 interaction for a workflow process -- each entry contains a form that=20 uses javascript for validation and perhaps some CSS styles for=20 formatting. Such a feed would likely require authentication to access,=20 so maybe that is enough? I dunno, I'm just kinda scratching my head on=20 this wondering if there is any actual need here. My instincts are=20 telling me no, but... - James From owner-atom-syntax@mail.imc.org Thu Aug 25 10:31:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IlZ-0003yx-7L for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 10:31:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20871 for ; Thu, 25 Aug 2005 10:31:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEMbDm012602; Thu, 25 Aug 2005 07:22:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PEMblC012601; Thu, 25 Aug 2005 07:22:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEMarb012588 for ; Thu, 25 Aug 2005 07:22:37 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from BOBSLAPTOP (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 70A08724257; Thu, 25 Aug 2005 10:22:29 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'James M Snell'" , "'Atom Syntax'" Subject: RE: Don't Aggregrate Me Date: Thu, 25 Aug 2005 10:22:22 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWpP/K25acIDZLPThmHzK78il/dywAP5FlQ In-Reply-To: <430D6448.9040703@gmail.com> Message-Id: <20050825142229.70A08724257@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > Does the following work? > > ... > no > I think it is important to recognize that there are at least two kinds of aggregator. The most common is the desktop "end-point" aggregator that consumes feeds from various sources and then presents or processes them locally. The second kind of "aggregator" would be something like PubSub -- a channel intermediary that serves as an aggregating (and potentially caching) router that forwards messages on toward end-point aggregators. Your syntax seems only focused on the end-point aggregators. Without clarifying the expected behavior of intermediary aggregators, your proposal would tend to cause some significant confusion in the system. Should PubSub aggregate and/or route entries that come from feeds marked "no-aggregate"? If not, why not? From the publisher's point of view, an intermediary aggregator like PubSub should be indistinguishable from the channel itself. bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 25 10:54:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8J7F-00028A-E1 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 10:54:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21741 for ; Thu, 25 Aug 2005 10:54:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEluDI016087; Thu, 25 Aug 2005 07:47:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PEluIB016086; Thu, 25 Aug 2005 07:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEltVt016079 for ; Thu, 25 Aug 2005 07:47:55 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 80823 invoked by uid 17064); 25 Aug 2005 14:47:55 -0000 Received: from unknown (HELO [192.168.1.35]) ([62.203.5.176]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2005 14:47:55 -0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <3f1451f505082506454322cfa4@mail.gmail.com> References: <430D6448.9040703@gmail.com> <3f1451f505082506454322cfa4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 16:47:53 +0200 To: Joe Gregorio , Atom Syntax X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 Aug 2005, at 15:45, Joe Gregorio wrote: > > On 8/25/05, James M Snell wrote: > >> >> Up to this point, the vast majority of use cases for Atom feeds is >> the >> traditional syndicated content case. A bunch of content updates that >> are designed to be distributed and aggregated within Feed readers or >> online aggregators, etc. But with Atom providing a much more >> flexible >> content model that allows for data that may not be suitable for >> display >> within a feed reader or online aggregator, I'm wondering what the >> best >> way would be for a publisher to indicate that a feed should not be >> aggregated? >> >> For example, suppose I build an application that depends on an >> Atom feed >> containing binary content (e.g. a software update feed). I don't >> really >> want aggregators pulling and indexing that feed and attempting to >> display it within a traditional feed reader. What can I do? >> > > First, on this scenario, I would be inclined to make the firmware > an enclosure > and not included base64. +1 definitely. > > But I still can see a scenario you might be serving up queries via > Atom and those > queries could be 'heavy'. There are, of course, several things you > could do: > > 1. Cache the results. > 2. Support ETags > 3. Support ETags and 'fake' them so that they change only once a > day, maybe > once a week even. > I would put the following as the most obvious solution 0. have the content link to the file either by using enclosures or content by reference such as There should be a golden rule: never place binary content in xml. It is ugly and completely unnecessary. Do we put base64 encoded stuff in html? No: that is why there are things like Henry > There are undoubtedly others, but the more important part is that > your 'do not > aggregate' doesn't really solve the problem. I could, for example, > take one of your > heavy search feeds, convert it to HTML via XSLT and include that > via iframe > in my home page. *That* traffic is going to be a lot worse than an > aggregator > subscription and wouldn't fit the definition of 'aggregation'. > > -joe > > -- > Joe Gregorio http://bitworking.org > From owner-atom-syntax@mail.imc.org Thu Aug 25 11:02:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JFM-0004dn-Bv for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 11:02:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22090 for ; Thu, 25 Aug 2005 11:02:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PEvPT8017266; Thu, 25 Aug 2005 07:57:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PEvOxi017265; Thu, 25 Aug 2005 07:57:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7PEvNk2017248 for ; Thu, 25 Aug 2005 07:57:23 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 Aug 2005 14:57:16 -0000 Received: from xdsl-81-173-229-185.netcologne.de (EHLO klangraum) [81.173.229.185] by mail.gmx.net (mp013) with SMTP; 25 Aug 2005 16:57:16 +0200 X-Authenticated: #163624 Date: Thu, 25 Aug 2005 16:57:18 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050825145718.GA15966@klangraum> Mail-Followup-To: Atom Syntax References: <430D6448.9040703@gmail.com> <20050825124343.GA14989@klangraum> <430DD2AD.30506@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <430DD2AD.30506@gmail.com> 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 ietf.org id LAA22090 * James M Snell [2005-08-25 16:20]: > I dunno, I'm just kinda scratching my head on this wondering if > there is any actual need here. My instincts are telling me no, > but... Seems to me that your instincts are right. :-) I=E2=80=99m not sure why, in the scenarios you describe, it would be *necessary* to prevent generic aggregators from trying to access the feed. It feels to me somewhat analogous of an attempt to add a feature for XML documents not intended to be requested by a human with a browser. What=E2=80=99s the point? Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 25 11:12:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JP2-0006y0-FA for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 11:12:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22410 for ; Thu, 25 Aug 2005 11:12:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PF6cDK018052; Thu, 25 Aug 2005 08:06:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PF6c9t018051; Thu, 25 Aug 2005 08:06:38 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7PF6ZEP018036 for ; Thu, 25 Aug 2005 08:06:36 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 Aug 2005 15:06:30 -0000 Received: from xdsl-81-173-229-185.netcologne.de (EHLO klangraum) [81.173.229.185] by mail.gmx.net (mp002) with SMTP; 25 Aug 2005 17:06:30 +0200 X-Authenticated: #163624 Date: Thu, 25 Aug 2005 17:06:30 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050825150630.GB15966@klangraum> Mail-Followup-To: Atom Syntax References: <430D6448.9040703@gmail.com> <3f1451f505082506454322cfa4@mail.gmail.com> <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> 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: * Henry Story [2005-08-25 16:55]: > Do we put base64 encoded stuff in html? No: that is why there > are things like > :-) Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 25 11:13:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JQJ-0007uv-Es for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 11:13:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22438 for ; Thu, 25 Aug 2005 11:13:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PF6S36018028; Thu, 25 Aug 2005 08:06:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PF6SDa018027; Thu, 25 Aug 2005 08:06:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PF6RQR018014 for ; Thu, 25 Aug 2005 08:06:27 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i36so32708wra for ; Thu, 25 Aug 2005 08:06:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XhP35PWNxc+NUwdhk4Zwhh6FBCCt1JeQTfkQ/WMmVCGV6Pnk5/AQXhG2bE0QUBuK4LbYhOecjv/ibxJliKoswErXoUK39dRYv8rj8EOln3Mp8O0tEfNVjZDgrOG6WGqkf6sXOqEJ6rztgLY7gDZEmoAocL7Fo7Q+TIjBCLmKeVQ= Received: by 10.54.7.26 with SMTP id 26mr2031761wrg; Thu, 25 Aug 2005 08:06:18 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 66sm2030059wra.2005.08.25.08.06.18; Thu, 25 Aug 2005 08:06:18 -0700 (PDT) Message-ID: <430DDE66.1090800@gmail.com> Date: Thu, 25 Aug 2005 08:06:14 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: Atom Syntax Subject: Re: Don't Aggregrate Me References: <430D6448.9040703@gmail.com> <20050825124343.GA14989@klangraum> <430DD2AD.30506@gmail.com> <20050825145718.GA15966@klangraum> In-Reply-To: <20050825145718.GA15966@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id LAA22438 A. Pagaltzis wrote: >* James M Snell [2005-08-25 16:20]: > =20 > >>I dunno, I'm just kinda scratching my head on this wondering if >>there is any actual need here. My instincts are telling me no, >>but... >> =20 >> > >Seems to me that your instincts are right. :-) > >I=E2=80=99m not sure why, in the scenarios you describe, it would be >*necessary* to prevent generic aggregators from trying to access >the feed. > >It feels to me somewhat analogous of an attempt to add a > feature for XML documents not intended to be >requested by a human with a browser. What=E2=80=99s the point? > > =20 > Heh... true. Hadn't considered that ;-) Ah well, I've had my moment of=20 idiocy for the week ..... hopefully it's the only one ;-) - James From owner-atom-syntax@mail.imc.org Thu Aug 25 11:59:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K8y-00067p-6e for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 11:59:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26008 for ; Thu, 25 Aug 2005 11:59:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFqmcg023671; Thu, 25 Aug 2005 08:52:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PFqmno023670; Thu, 25 Aug 2005 08:52:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PFqmYa023645 for ; Thu, 25 Aug 2005 08:52:48 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc13) with SMTP id <20050825155233013005dgcne>; Thu, 25 Aug 2005 15:52:42 +0000 Date: Thu, 25 Aug 2005 09:52:31 -0600 Subject: Re: Feed History: stateful -> incremental? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> Message-Id: <3F119C3C-1580-11DA-A95D-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, August 24, 2005, at 04:07 PM, Mark Nottingham wrote: > Just bouncing an idea around; it seems that there's a fair amount of > confusion / fuzziness caused by the term 'stateful'. Would people > prefer the term 'incremental'? > > I.e., instead of a "stateful feed", it would be an "incremental feed"; > fh:stateful would become fh:incremental. > > Worth it? > I think it's worth seeing if a term can be found that has a more intuitively understandable meaning. It might be helpful to explore the kinds of names that describe non-stateful feeds too--if a better term can be found for that, it could be used instead (and just reverse true & false). Brainstorming a little: Stateful: sliding window, most recent segment, segment, stream, entry stream, appendable, appending, augmentable, augmenting Non-stateful: uh...stateful? ("what you just downloaded represents the current state of the entire feed"), current state, current, snapshot, fixed entry, set entry, replacable, replacing, entry replacing, non-appending, non-augmenting From owner-atom-syntax@mail.imc.org Thu Aug 25 12:14:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KNR-0000Uf-3Z for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:14:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26959 for ; Thu, 25 Aug 2005 12:14:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG7xAu024689; Thu, 25 Aug 2005 09:07:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PG7xSp024688; Thu, 25 Aug 2005 09:07:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG7w1o024672 for ; Thu, 25 Aug 2005 09:07:58 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (rwcrmhc14) with SMTP id <2005082516075301400hbda1e>; Thu, 25 Aug 2005 16:07:53 +0000 Date: Thu, 25 Aug 2005 10:07:51 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <430D6448.9040703@gmail.com> Message-Id: <6352C044-1582-11DA-A95D-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 25, 2005, at 12:25 AM, James M Snell wrote: > Up to this point, the vast majority of use cases for Atom feeds is the > traditional syndicated content case. A bunch of content updates that > are designed to be distributed and aggregated within Feed readers or > online aggregators, etc. But with Atom providing a much more flexible > content model that allows for data that may not be suitable for > display within a feed reader or online aggregator, I'm wondering what > the best way would be for a publisher to indicate that a feed should > not be aggregated? > > For example, suppose I build an application that depends on an Atom > feed containing binary content (e.g. a software update feed). I don't > really want aggregators pulling and indexing that feed and attempting > to display it within a traditional feed reader. What can I do? > In that particular use case, I'd expect entries something like this: ... Patch for MySoftware This patch updated MySoftware version 1.0.1 to version 1.0.2 k3jafidf8adf... Looking at this, my thoughts are: 1) Feed readers that can't handle the content type are just going to display the summary or title anyway, so it's not going to hurt anything. 2) People whose feed readers can't handle the patches probably aren't going to subscribe to this feed anyway. Instead they'll subscribe to your other feed (?) which gives them a link to use to download the patch: ... Patch for MySoftware This patch updated MySoftware version 1.0.1 to version 1.0.2 I don't think we need anything special to tell aggregators to beware content that they don't know how to handle in this feed. That should be marked clearly enough by @type. More in a separate message... From owner-atom-syntax@mail.imc.org Thu Aug 25 12:17:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KPT-0001c6-NZ for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:17:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27134 for ; Thu, 25 Aug 2005 12:16:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGCH2r025066; Thu, 25 Aug 2005 09:12:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGCHgv025065; Thu, 25 Aug 2005 09:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGCGYM025056 for ; Thu, 25 Aug 2005 09:12:17 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id DFC9BA34F4; Thu, 25 Aug 2005 12:12:15 -0400 (EDT) In-Reply-To: References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2030B24C-2B22-483A-A7C1-9697D7C14B4C@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History: stateful -> incremental? Date: Thu, 25 Aug 2005 09:12:13 -0700 To: Stefan Eissing X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25/08/2005, at 3:00 AM, Stefan Eissing wrote: > Am 25.08.2005 um 00:07 schrieb Mark Nottingham: > >> Just bouncing an idea around; it seems that there's a fair amount >> of confusion / fuzziness caused by the term 'stateful'. Would >> people prefer the term 'incremental'? >> I.e., instead of a "stateful feed", it would be an "incremental >> feed"; fh:stateful would become fh:incremental. > > I would prefer to name such a feed a "chunked" feed. So, that would > make it fh:chunked=(true|false). Hmm. I tend to shy away from 'chunked', because that already has meaning in HTTP, and while the format isn't dependant upon HTTP, it might get confusing (witness "bindings" and "properties" in the Web services world). > That leaves the "history" analogy a bit behind, I'm afraid. So a > "chunked feed" would be a history if "fh:order=publish-time"? Maybe > not worth it, just a thought. I totally see an ordering extension being useful, but I think it's orthogonal to fh. > I see one use of feed histories in making normal feed documents > very small and still being able to offer a rather long list of > entries. Clients checking for updates would just get a tiny > document (2 entries maybe) iff they do not use HTTP caching or ETag > validation. Could this be some transfer-volume saver? Hopefully. I think one of the reasons people publish such big feeds right now is that they want to make sure people will see entries if they haven't checked in a while. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Aug 25 12:17:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KPa-0001dl-01 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:17:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27140 for ; Thu, 25 Aug 2005 12:17:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG96MX024822; Thu, 25 Aug 2005 09:09:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PG9628024821; Thu, 25 Aug 2005 09:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PG95SQ024777 for ; Thu, 25 Aug 2005 09:09:05 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so48417wra for ; Thu, 25 Aug 2005 09:08:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nGELD+BKUx8HAUJbH2+NKfHl6YWONbJhV0IaeOi5dYJ0zhH+Y8afYr66qTdasNT0rXO9iZ6xyWAN2ylaWoFjUXKvkriME5STH5P1znXlmiEZtGSp9pGfbNynbSDam+V2T/ukQEU/nOMcn87791OrABqUetrvLmbIwhaB+h2ThWM= Received: by 10.54.100.1 with SMTP id x1mr2087965wrb; Thu, 25 Aug 2005 09:08:57 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 24sm2323964wrl.2005.08.25.09.08.45; Thu, 25 Aug 2005 09:08:48 -0700 (PDT) Message-ID: <430DECF6.8030409@gmail.com> Date: Thu, 25 Aug 2005 09:08:22 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Davis CC: Mark Nottingham , Atom Syntax Subject: Re: Feed History: stateful -> incremental? References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> <430D9BD3.6030406@internetalchemy.org> In-Reply-To: <430D9BD3.6030406@internetalchemy.org> 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: Content-Transfer-Encoding: 7bit Just brainstorming... (hey, I already threw out one harebrained idea this week, what's one more?) Perhaps something as simple as a single empty element (like fh:archive) that describes the general behavior of the feed. e.g. or - James Ian Davis wrote: > > On 24/08/2005 23:07, Mark Nottingham wrote: > >> >> Just bouncing an idea around; it seems that there's a fair amount of >> confusion / fuzziness caused by the term 'stateful'. Would people >> prefer the term 'incremental'? >> >> I.e., instead of a "stateful feed", it would be an "incremental >> feed"; fh:stateful would become fh:incremental. >> >> Worth it? > > > What about "partial"? > > Ian > > From owner-atom-syntax@mail.imc.org Thu Aug 25 12:22:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KUi-00065x-G9 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:22:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27397 for ; Thu, 25 Aug 2005 12:22:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGEvgq025271; Thu, 25 Aug 2005 09:14:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGEvt2025270; Thu, 25 Aug 2005 09:14:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGEv86025257 for ; Thu, 25 Aug 2005 09:14:57 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (rwcrmhc12) with SMTP id <2005082516144801400kiumre>; Thu, 25 Aug 2005 16:14:52 +0000 Date: Thu, 25 Aug 2005 10:14:47 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <430DD2AD.30506@gmail.com> Message-Id: <5B06C656-1583-11DA-A95D-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 25, 2005, at 08:16 AM, James M Snell wrote: > Good points but it's more than just the handling of human-readable > content. That's one use case but there are others. Consider, for > example, if I was producing a feed that contained javascript and CSS > styles that would otherwise be unwise for an online aggregator to try > to display (e.g. the now famous Platypus prank... > http://diveintomark.org/archives/2003/06/12/ > how_to_consume_rss_safely). Typically aggregators and feed readers > are (rightfully) recommended to strip scripts and styles from the > content in order to reliably display the information. But, it is > foreseeable that applications could be built that rely on these types > of mechanism within the feed content. For example, I may want to > create a feed that provides the human interaction for a workflow > process -- each entry contains a form that uses javascript for > validation and perhaps some CSS styles for formatting. For that, you'd either need to use a less sophisticated feed reader that didn't strip anything out (and only use it to subscribe to fully trusted feeds, like internal feeds), or a more sophisticated feed reader that allowed you to turn off the stripping of "potentially dangerous" stuff, or to configure exactly what was, or better yet, wasn't, stripped (perhaps and a feed by feed basis). The stripping-or-not behavior should be controlled from the client side, so I don't see any point in providing a mechanism for the publisher to provide hints about whether or not to strip things out. That would probably only benefit malicious publishers at the expense of brain-dead clients: ... From owner-atom-syntax@mail.imc.org Thu Aug 25 12:48:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KuB-0006Ty-Qu for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:48:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29259 for ; Thu, 25 Aug 2005 12:48:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGbCrL028668; Thu, 25 Aug 2005 09:37:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGbC0n028667; Thu, 25 Aug 2005 09:37:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGbCmg028660 for ; Thu, 25 Aug 2005 09:37:12 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 22849 invoked by uid 17064); 25 Aug 2005 16:37:11 -0000 Received: from unknown (HELO [192.168.1.35]) ([62.203.5.176]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2005 16:37:11 -0000 In-Reply-To: <20050825150630.GB15966@klangraum> References: <430D6448.9040703@gmail.com> <3f1451f505082506454322cfa4@mail.gmail.com> <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> <20050825150630.GB15966@klangraum> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 18:37:06 +0200 To: "A. Pagaltzis" , Eric Scheid X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 Aug 2005, at 17:06, A. Pagaltzis wrote: > > * Henry Story [2005-08-25 16:55]: > >> Do we put base64 encoded stuff in html? No: that is why there >> are things like >> >> > > > !!! That really does exist?! Yes: http://www.ietf.org/rfc/rfc2397.txt But apparently only for very short data fragments (a few k at most). And it does not give me anything very intersting when I look at it in either Safari or Firefox. Thanks for pointing this out. :-) > :-) > > Regards, > -- > Aristotle Pagaltzis // > From owner-atom-syntax@mail.imc.org Thu Aug 25 13:00:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L5w-0001wT-1Y for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:00:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00136 for ; Thu, 25 Aug 2005 13:00:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGouiK030552; Thu, 25 Aug 2005 09:50:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGou0f030551; Thu, 25 Aug 2005 09:50:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGjgHV029987; Thu, 25 Aug 2005 09:45:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050825142229.70A08724257@mail.pubsub.com> References: <20050825142229.70A08724257@mail.pubsub.com> Date: Thu, 25 Aug 2005 09:45:39 -0700 To: , "'James M Snell'" , "'Atom Syntax'" From: Paul Hoffman Subject: RE: Don't Aggregrate Me Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:22 AM -0400 8/25/05, Bob Wyman wrote: >James M Snell wrote: >> Does the following work? >> >> ... >> no >> > I think it is important to recognize that there are at least two >kinds of aggregator. The most common is the desktop "end-point" aggregator >that consumes feeds from various sources and then presents or processes them >locally. The second kind of "aggregator" would be something like PubSub -- a >channel intermediary that serves as an aggregating (and potentially caching) >router that forwards messages on toward end-point aggregators. > Your syntax seems only focused on the end-point aggregators. Without >clarifying the expected behavior of intermediary aggregators, your proposal >would tend to cause some significant confusion in the system. Should PubSub >aggregate and/or route entries that come from feeds marked "no-aggregate"? >If not, why not? From the publisher's point of view, an intermediary >aggregator like PubSub should be indistinguishable from the channel itself. +1 to Bob's comments. I can see reasons why I would want my firmware updates aggregated through an intermediary. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Aug 25 13:00:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L5w-0001wU-1Y for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:00:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00138 for ; Thu, 25 Aug 2005 13:00:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGpNX3030601; Thu, 25 Aug 2005 09:51:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGpNZs030600; Thu, 25 Aug 2005 09:51:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGpMfi030589 for ; Thu, 25 Aug 2005 09:51:22 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 9882E5A for ; Thu, 25 Aug 2005 09:51:17 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7PGp7kv029187 for ; Thu, 25 Aug 2005 09:51:17 -0700 (PDT) Date: Thu, 25 Aug 2005 09:51:12 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: In-Reply-To: <430D6448.9040703@gmail.com> References: <430D6448.9040703@gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I can see reasonable uses for this, like marking a feed of local disk errors as not of general interest. I would not be surprised to see RSS/Atom catch on for system monitoring. Search engines see this all the time -- just because it is HTML doesn't mean it is the primary content on the site. Log analysis reports are one good example. /robots.txt is one approach. Wouldn't hurt to have a recommendation for whether Atom clients honor that. A long time ago, I proposed a Robots PI, similar to the Robots meta tag. That would get around the "only webmaster can edit" problem with /robots.txt. The Robots PI did not catch on, but I've still got the proposal somewhere. wunder --On August 24, 2005 11:25:12 PM -0700 James M Snell wrote: > > Up to this point, the vast majority of use cases for Atom feeds is the traditional syndicated content case. A bunch of content updates that are designed to be distributed and aggregated within Feed readers or online aggregators, etc. But with Atom providing a much more flexible content model that allows for data that may not be suitable for display within a feed reader or online aggregator, I'm wondering what the best way would be for a publisher to indicate that a feed should not be aggregated? > > For example, suppose I build an application that depends on an Atom feed containing binary content (e.g. a software update feed). I don't really want aggregators pulling and indexing that feed and attempting to display it within a traditional feed reader. What can I do? > > Does the following work? > > > ... > no > > > Should I use a processing instruction instead? > > > > ... > > > I dunno. What do you all think? Am I just being silly or does any of this actually make a bit of sense? > > - James > > -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 25 13:01:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L6e-0002Be-8T for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:01:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00189 for ; Thu, 25 Aug 2005 13:01:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PGtFM7031397; Thu, 25 Aug 2005 09:55:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PGtEWY031382; Thu, 25 Aug 2005 09:55:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7PGt9S3031198 for ; Thu, 25 Aug 2005 09:55:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 Aug 2005 16:55:03 -0000 Received: from xdsl-81-173-229-185.netcologne.de (EHLO klangraum) [81.173.229.185] by mail.gmx.net (mp003) with SMTP; 25 Aug 2005 18:55:03 +0200 X-Authenticated: #163624 Date: Thu, 25 Aug 2005 18:55:01 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050825165501.GC15966@klangraum> Mail-Followup-To: Atom Syntax References: <430D6448.9040703@gmail.com> <3f1451f505082506454322cfa4@mail.gmail.com> <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> <20050825150630.GB15966@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 ietf.org id NAA00189 * Henry Story [2005-08-25 18:40]: > And it does not give me anything very intersting when I look at > it in either Safari or Firefox. Of course not =E2=80=93 it=E2=80=99s the infamous transparent single-pixe= l GIF. :-) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Aug 25 13:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LCl-00040B-Q1 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:08:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00452 for ; Thu, 25 Aug 2005 13:07:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PH1pYV032222; Thu, 25 Aug 2005 10:01:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PH1pgk032221; Thu, 25 Aug 2005 10:01:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PH1oMj032214 for ; Thu, 25 Aug 2005 10:01:50 -0700 (PDT) (envelope-from mark.nottingham@bea.com) Received: from [172.16.1.2] (sj-ez-63-96-162-1.bea.com [63.96.162.1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E2928A34F3; Thu, 25 Aug 2005 13:01:49 -0400 (EDT) In-Reply-To: References: <430D6448.9040703@gmail.com> <3f1451f505082506454322cfa4@mail.gmail.com> <8992C0EC-BA27-4BE9-BEF1-76AE2AB82D65@bblfish.net> <20050825150630.GB15966@klangraum> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "A. Pagaltzis" , Eric Scheid , Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 10:01:46 -0700 To: Henry Story X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It works in both Safari and Firefox; it's just that that particular data: URI is a 1x1 blank gif ;) On 25/08/2005, at 9:37 AM, Henry Story wrote: > > > On 25 Aug 2005, at 17:06, A. Pagaltzis wrote: > >> >> * Henry Story [2005-08-25 16:55]: >> >> >>> Do we put base64 encoded stuff in html? No: that is why there >>> are things like >>> >>> >>> >> >> >> >> > > !!! That really does exist?! > Yes: > http://www.ietf.org/rfc/rfc2397.txt > > But apparently only for very short data fragments (a few k at > most). And it does not give me anything > very intersting when I look at it in either Safari or Firefox. > > Thanks for pointing this out. :-) > > >> :-) >> >> Regards, >> -- >> Aristotle Pagaltzis // >> >> > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Thu Aug 25 13:16:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LKc-0006jo-7S for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:16:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00880 for ; Thu, 25 Aug 2005 13:15:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHAYZW033361; Thu, 25 Aug 2005 10:10:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PHAYsG033360; Thu, 25 Aug 2005 10:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from krusty.greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHAW7N033344 for ; Thu, 25 Aug 2005 10:10:33 -0700 (PDT) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.3] (H3b3e.h.pppool.de [85.72.59.62]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by krusty.greenbytes.de (Postfix) with ESMTP id 847F5583F96A; Thu, 25 Aug 2005 19:10:28 +0200 (CEST) In-Reply-To: <2030B24C-2B22-483A-A7C1-9697D7C14B4C@mnot.net> References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> <2030B24C-2B22-483A-A7C1-9697D7C14B4C@mnot.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4d747c7340014fedf69997b3aa820dd9@greenbytes.de> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Stefan Eissing Subject: Re: Feed History: stateful -> incremental? Date: Thu, 25 Aug 2005 19:10:25 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Am 25.08.2005 um 18:12 schrieb Mark Nottingham: > On 25/08/2005, at 3:00 AM, Stefan Eissing wrote: >> Am 25.08.2005 um 00:07 schrieb Mark Nottingham: >> >>> Just bouncing an idea around; it seems that there's a fair amount of >>> confusion / fuzziness caused by the term 'stateful'. Would people >>> prefer the term 'incremental'? >>> I.e., instead of a "stateful feed", it would be an "incremental >>> feed"; fh:stateful would become fh:incremental. >> >> I would prefer to name such a feed a "chunked" feed. So, that would >> make it fh:chunked=(true|false). > > Hmm. I tend to shy away from 'chunked', because that already has > meaning in HTTP, and while the format isn't dependant upon HTTP, it > might get confusing (witness "bindings" and "properties" in the Web > services world). Seeing it as a data structure "fh" introduces a single-linked list of documents which the whole feed is composed of. I think such a document needs its own term. A single document could be named a "feed fragement". The first document "head fragment"? Not very snappy. Let's see. If the whole feed is atom, then the fragments are "particals"? "feedytrons"? Are we perhaps talking about a "split feed" (fh:split=true/false? the german term for a fragment is "splitter", btw.) It has been a long day, i should stop now. From owner-atom-syntax@mail.imc.org Thu Aug 25 13:49:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LrK-0002VV-2m for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 13:49:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03811 for ; Thu, 25 Aug 2005 13:49:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHfdjO036004; Thu, 25 Aug 2005 10:41:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PHfdPZ036003; Thu, 25 Aug 2005 10:41:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PHfc3j035992 for ; Thu, 25 Aug 2005 10:41:38 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc14) with SMTP id <2005082517412501400skno6e>; Thu, 25 Aug 2005 17:41:30 +0000 Date: Thu, 25 Aug 2005 11:41:24 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <74AC4054-158F-11DA-A95D-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I can see reasonable uses for this, like marking a feed of local disk > errors > as not of general interest. "This is not published data" - Security by obscurity^H^H^H^H^H^H^H^H^H saying "please" - < http://www-cs-faculty.stanford.edu/~knuth/> (see the second link from the bottom) This certainly wouldn't be useful as a security measure. But yeah, a way to tell the big republishing aggregators that you'd prefer they didn't republish the feed could be useful, in case they somehow go ahold of the URL of a non-sensitive (and thus non- encrypted and authentication-protected), but not-intended-for-public-consumption feed. Ideally though, such feeds should probably be password protected, since that wouldn't require aggregator support for an extension element. From owner-atom-syntax@mail.imc.org Thu Aug 25 15:46:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Nfq-0006Wl-BH for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:46:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11173 for ; Thu, 25 Aug 2005 15:46:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJcoT2047155; Thu, 25 Aug 2005 12:38:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJcoBc047149; Thu, 25 Aug 2005 12:38:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJckB5047081 for ; Thu, 25 Aug 2005 12:38:46 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 37C064EEC7; Thu, 25 Aug 2005 15:38:43 -0400 (EDT) In-Reply-To: <20050825104453.GD27648@tartarus.org> References: <430D6448.9040703@gmail.com> <20050825104453.GD27648@tartarus.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 15:38:45 -0400 To: James Aylett X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PJckB5047114 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 ietf.org id PAA11173 Le 05-08-25 =E0 06:44, James Aylett a =E9crit : > I like the use case, but I don't see why you would want to disallow > aggregators to pull the feed. You might want it for many reasons. One of my reasons which worries =20 me more and more, is that some aggregators, bots do not respect the =20 Creative Common license (or at least the way I understand it). http://creativecommons.org/licenses/by-nc-sa/1.0/ Attribution *No commercial Use* *Share A Like* When an aggregator or a service starts to do business with my feeds =20 (Ads, data mining) IMHO it violates the license. Though there are not =20 many ways to block the bots. * Some don't respect robots.txt * Blocking IP very difficult for the common user * Reading the Creative License by I don't know how many bots/=20 services respect it As James said, also, it might be something you are developing for an =20 application and not suitable for aggregation. :/ Many issues. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Thu Aug 25 15:55:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Nob-0007zf-Po for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:55:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11749 for ; Thu, 25 Aug 2005 15:55:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJh2Xn047617; Thu, 25 Aug 2005 12:43:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJh2oY047616; Thu, 25 Aug 2005 12:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJh2hQ047609 for ; Thu, 25 Aug 2005 12:43:02 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 4A6074EEC7; Thu, 25 Aug 2005 15:43:01 -0400 (EDT) In-Reply-To: References: <430D6448.9040703@gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Atom Syntax From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 15:43:03 -0400 To: Walter Underwood X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PJh2hQ047611 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 ietf.org id PAA11749 Le 05-08-25 =E0 12:51, Walter Underwood a =E9crit : > /robots.txt is one approach. Wouldn't hurt to have a recommendation > for whether Atom clients honor that. Not many honor it. A while ago I had this list from http://varchars.com/blog/node/view/59 The Good BlogPulse NITLE Blog Spider Yahoo! Slurp The Bad Blogdigger Bloglines fastbuzz Feedster Crawler LiveJournal.com NIF PubSub Oddbot Syndic8 Technoratibot --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Thu Aug 25 16:05:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NyP-0004O0-1w for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:05:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14503 for ; Thu, 25 Aug 2005 16:05:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJxmPf049679; Thu, 25 Aug 2005 12:59:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PJxmdb049678; Thu, 25 Aug 2005 12:59:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PJxlJJ049667 for ; Thu, 25 Aug 2005 12:59:48 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 7E0D17244BD; Thu, 25 Aug 2005 15:59:42 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Karl Dubost'" , "'James Aylett'" Cc: "'Atom Syntax'" Subject: RE: Don't Aggregrate Me Date: Thu, 25 Aug 2005 15:59:40 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcWprl0FnvL175rpRZ2Am+2+1KpQ+AAADWYg Message-Id: <20050825195942.7E0D17244BD@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Karl Dubost wrote: > One of my reasons which worries me more and more, is that some > aggregators, bots do not respect the Creative Common license (or > at least the way I understand it). Your understanding of Creative Commons is apparently a bit non-optimal -- even though many people seem to believe as you do. The reality is that a Creative Commons license cannot be used to restrict access to data. It can only be used to relax constraints that might otherwise exist. A Creative Commons license that says "no commercial use" is not prohibiting commercial use, rather, it is saying that the license does not grant commercial use. (The distinction between "prohibiting" use and "not granting" a right to use is very important.) A "no commercial use" CC license merely says that "other constraints" i.e. copyright, etc. continue to have force. Thus, if copyright applies to the content, and one has a non-commercial use CC license on that content, one would assume that the copyright restrictions which would tend to limit commercial use would still apply. It is important to re-iterate that a CC License only *grants* rights, it does not restrict, deny, or constrain them in any way. Thus, you can't say: "The aggregator failed to respect the CC non-commercial use attribute." You must say: "The aggregator failed to respect the copyright." bob wyman From owner-atom-syntax@mail.imc.org Thu Aug 25 16:20:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OCw-0004m7-DO for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:20:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16473 for ; Thu, 25 Aug 2005 16:20:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKBif0050657; Thu, 25 Aug 2005 13:11:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PKBiWm050656; Thu, 25 Aug 2005 13:11:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKBhHo050649 for ; Thu, 25 Aug 2005 13:11:43 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D21A24EF90 for ; Thu, 25 Aug 2005 16:11:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <20050825195942.7E0D17244BD@mail.pubsub.com> References: <20050825195942.7E0D17244BD@mail.pubsub.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <623514A5-494D-44BE-9CAD-E9BC8DF6CCE9@w3.org> From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 16:11:45 -0400 To: Atom Syntax X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PKBhHo050651 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 ietf.org id QAA16473 Bob, Thanks for the explanation. Much appreciated. Le 05-08-25 =E0 15:59, Bob Wyman a =E9crit : > Karl Dubost wrote: > >> One of my reasons which worries me more and more, is that some >> aggregators, bots do not respect the Creative Common license (or >> at least the way I understand it). > It is important to re-iterate that a CC License only *grants* > rights, it does not restrict, deny, or constrain them in any way. =20 > Thus, you > can't say: "The aggregator failed to respect the CC non-commercial use > attribute." You must say: "The aggregator failed to respect the =20 > copyright." Then I can tell that many aggregators use our content in a commercial =20 way without me granting them this right. ;) Thanks again for the precision. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Thu Aug 25 16:25:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OIO-0006SO-3f for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:25:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16908 for ; Thu, 25 Aug 2005 16:25:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKIbY3051250; Thu, 25 Aug 2005 13:18:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PKIbbQ051249; Thu, 25 Aug 2005 13:18:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKIaN9051235 for ; Thu, 25 Aug 2005 13:18:37 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so98838wra for ; Thu, 25 Aug 2005 13:18:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MBnAWiFxgDYUBg4dG3rhL8cgc+YuwzZxSusU9RGOynEBOxau8D4NCr2BvgjfpFKxzCw1jgTfbZkGGNOosIqaCkW07JFoSkBHDbcZ5g6ypgwSNM0lRpzkoSEuKv/g+h/YdbZ6N0UXMDAy35BewbNf999DHd/Ka3TDGQ04wV6eUYk= Received: by 10.54.33.2 with SMTP id g2mr2411840wrg; Thu, 25 Aug 2005 13:18:19 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 27sm3493546wrl.2005.08.25.13.18.15; Thu, 25 Aug 2005 13:18:18 -0700 (PDT) Message-ID: <430E2782.7010402@gmail.com> Date: Thu, 25 Aug 2005 13:18:10 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'Karl Dubost'" , "'James Aylett'" , "'Atom Syntax'" Subject: Re: Don't Aggregrate Me References: <20050825195942.7E0D17244BD@mail.pubsub.com> In-Reply-To: <20050825195942.7E0D17244BD@mail.pubsub.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: Content-Transfer-Encoding: 7bit Bob Wyman wrote: >Karl Dubost wrote: > > >>One of my reasons which worries me more and more, is that some >>aggregators, bots do not respect the Creative Common license (or >>at least the way I understand it). >> >> > Your understanding of Creative Commons is apparently a bit >non-optimal -- even though many people seem to believe as you do. > The reality is that a Creative Commons license cannot be used to >restrict access to data. It can only be used to relax constraints that might >otherwise exist. A Creative Commons license that says "no commercial use" is >not prohibiting commercial use, rather, it is saying that the license does >not grant commercial use. (The distinction between "prohibiting" use and >"not granting" a right to use is very important.) A "no commercial use" CC >license merely says that "other constraints" i.e. copyright, etc. continue >to have force. Thus, if copyright applies to the content, and one has a >non-commercial use CC license on that content, one would assume that the >copyright restrictions which would tend to limit commercial use would still >apply. > It is important to re-iterate that a CC License only *grants* >rights, it does not restrict, deny, or constrain them in any way. Thus, you >can't say: "The aggregator failed to respect the CC non-commercial use >attribute." You must say: "The aggregator failed to respect the copyright." > > bob wyman > > Point granted but that's splitting hairs a bit. The intention of not granting commercial use rights is to deny the right to use the material for commercial purposes. For example, if I have not granted you permission to enter my home, and you enter anyway, you're trespassing just as much as if I ordered you directly to stay out. Regardless, the point that Karl was making still stands. At the very least, aggregators should respect robots.txt. Doing so would allow publishers to restrict who is allowed to pull their feed. - James From owner-atom-syntax@mail.imc.org Thu Aug 25 16:43:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OZ1-0006aD-Ve for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:43:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17840 for ; Thu, 25 Aug 2005 16:43:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKPBed051695; Thu, 25 Aug 2005 13:25:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PKPB4P051694; Thu, 25 Aug 2005 13:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKPBww051688 for ; Thu, 25 Aug 2005 13:25:11 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 14969 invoked by uid 17064); 25 Aug 2005 20:25:11 -0000 Received: from unknown (HELO [192.168.1.35]) ([62.203.5.176]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2005 20:25:11 -0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <430E2782.7010402@gmail.com> References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 22:25:08 +0200 To: James M Snell , Atom Syntax X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mhh. I have not looked into this. But is not every desktop aggregator a robot? Henry On 25 Aug 2005, at 22:18, James M Snell wrote: > At the very least, aggregators should respect robots.txt. Doing so > would allow publishers to restrict who is allowed to pull their feed. > > - James > From owner-atom-syntax@mail.imc.org Thu Aug 25 16:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Oov-00026w-VU for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 16:59:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18726 for ; Thu, 25 Aug 2005 16:59:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKrucA053999; Thu, 25 Aug 2005 13:53:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PKruqd053998; Thu, 25 Aug 2005 13:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PKruLG053990 for ; Thu, 25 Aug 2005 13:53:56 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 04DD5DB for ; Thu, 25 Aug 2005 13:53:51 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7PKrmkv002647 for ; Thu, 25 Aug 2005 13:53:50 -0700 (PDT) Date: Thu, 25 Aug 2005 13:53:53 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <80DD2BC2BD6B772E18253743@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: <430D6448.9040703@gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PKruLG053993 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 ietf.org id QAA18726 --On August 25, 2005 3:43:03 PM -0400 Karl Dubost wrote: > Le 05-08-25 =C3=A0 12:51, Walter Underwood a =C3=A9crit : >> /robots.txt is one approach. Wouldn't hurt to have a recommendation >> for whether Atom clients honor that. >=20 > Not many honor it. I'm not surprised. There seems to be a new generation of robots that hasn't learned much from the first generation. The Robots mailing list is silent these day. That is why we should make a recommendation about it. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 25 17:20:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8P8m-00026n-00 for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 17:20:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20506 for ; Thu, 25 Aug 2005 17:20:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLC6bX055315; Thu, 25 Aug 2005 14:12:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLC6pF055314; Thu, 25 Aug 2005 14:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLC5Nl055300 for ; Thu, 25 Aug 2005 14:12:05 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 89955D9; Thu, 25 Aug 2005 14:12:00 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7PLBxkv002881; Thu, 25 Aug 2005 14:11:59 -0700 (PDT) Date: Thu, 25 Aug 2005 14:12:04 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: In-Reply-To: <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would call desktop clients "clients" not "robots". The distinction is how they add feeds to the polling list. Clients add them because of human decisions. Robots discover them mechanically and add them. So, clients should act like browsers, and ignore robots.txt. Robots.txt is not very widely deployed (around 5% of sites), but it does work OK for general web content. wunder --On August 25, 2005 10:25:08 PM +0200 Henry Story wrote: > > Mhh. I have not looked into this. But is not every desktop aggregator a robot? > > Henry > > On 25 Aug 2005, at 22:18, James M Snell wrote: >> At the very least, aggregators should respect robots.txt. Doing so >> would allow publishers to restrict who is allowed to pull their feed. >> >> - James >> > > -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Thu Aug 25 17:21:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PAG-0002fy-DO for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 17:21:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20611 for ; Thu, 25 Aug 2005 17:21:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLELT8055445; Thu, 25 Aug 2005 14:14:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLELdx055444; Thu, 25 Aug 2005 14:14:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLEJ5a055435 for ; Thu, 25 Aug 2005 14:14:20 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so190553wra for ; Thu, 25 Aug 2005 14:14:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hhrxPuRtVHOR0yCf64YPgBsdW18rs3tckNXznOydTCGBh2SzJTX274OHrGHI2t47HvTFFfpyjtGAa4Y4IAFxYJqi5Q++bvI7UBQ0fbG6oGEI+BeXtAsfXV4O0IK0AScGaHCqZUjhrM7VdKkcUTGcu3YMyNOiWdsVj3P0RRGvy4o= Received: by 10.54.151.7 with SMTP id y7mr1709940wrd; Thu, 25 Aug 2005 14:14:07 -0700 (PDT) Received: by 10.54.104.17 with HTTP; Thu, 25 Aug 2005 14:14:06 -0700 (PDT) Message-ID: <540e3732050825141448cfbcd7@mail.gmail.com> Date: Thu, 25 Aug 2005 16:14:06 -0500 From: "Roger B." To: Henry Story Subject: Re: Don't Aggregrate Me Cc: Atom Syntax In-Reply-To: <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7PLEK5a055438 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Mhh. I have not looked into this. But is not every desktop aggregator > a robot? Henry: Depends on who you ask. (See the Newsmonster debates from a couple years ago.) Right now, I obey all wildcard and/or my-user-agent-specific directives I find in robots.txt. If I were writing a desktop app, I would ignore any wildcard directives, and obey the specific stuff.. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Thu Aug 25 17:30:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PIm-0003jC-Vf for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 17:30:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21262 for ; Thu, 25 Aug 2005 17:30:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLK588055842; Thu, 25 Aug 2005 14:20:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLK5mJ055841; Thu, 25 Aug 2005 14:20:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLK48i055831 for ; Thu, 25 Aug 2005 14:20:04 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so34825wra for ; Thu, 25 Aug 2005 14:19:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=V9xkxPF01rrfcbTgBFCtPemTh8cVcASfxNbjrYRq+RnT0sg6VSVnFKjbyHt7h8JKNyyo8th5lt7X23+/aD30obrf33FIPXCgVWSxguZW8VXho20QqOgYCLWrG6yATgid+LlPrndiu6OW0+iilq/BUKmU2akTrehcRICerNPI8iE= Received: by 10.54.34.33 with SMTP id h33mr1651851wrh; Thu, 25 Aug 2005 14:19:59 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id g9sm3673058wra.2005.08.25.14.19.58; Thu, 25 Aug 2005 14:19:59 -0700 (PDT) Message-ID: <430E35F9.1000006@gmail.com> Date: Thu, 25 Aug 2005 14:19:53 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Don't Aggregrate Me References: <430D6448.9040703@gmail.com> <80DD2BC2BD6B772E18253743@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <80DD2BC2BD6B772E18253743@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id RAA21262 Walter Underwood wrote: >--On August 25, 2005 3:43:03 PM -0400 Karl Dubost wrote: > =20 > >>Le 05-08-25 =C3=A0 12:51, Walter Underwood a =C3=A9crit : >> =20 >> >>>/robots.txt is one approach. Wouldn't hurt to have a recommendation >>>for whether Atom clients honor that. >>> =20 >>> >>Not many honor it. >> =20 >> > >I'm not surprised. There seems to be a new generation of robots that >hasn't learned much from the first generation. The Robots mailing list >is silent these day. That is why we should make a recommendation about i= t. > > =20 > +1 - James From owner-atom-syntax@mail.imc.org Thu Aug 25 17:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PWX-0001dX-0S for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 17:44:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22039 for ; Thu, 25 Aug 2005 17:44:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLYKkD056817; Thu, 25 Aug 2005 14:34:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLYK10056815; Thu, 25 Aug 2005 14:34:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLYJLx056808 for ; Thu, 25 Aug 2005 14:34:19 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 60418 invoked by uid 17064); 25 Aug 2005 21:34:19 -0000 Received: from unknown (HELO [192.168.1.35]) ([62.203.5.176]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 Aug 2005 21:34:19 -0000 In-Reply-To: References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E4BD869-A7CB-4CEF-A921-C8E496386AC1@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Don't Aggregrate Me Date: Thu, 25 Aug 2005 23:34:13 +0200 To: Walter Underwood , "'Roger B.'" X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, I see how one is meant to look at it. But I can imagine desktop aggregators becoming more independent when searching for information... Perhaps at that point they should start reading robots.txt... Henry On 25 Aug 2005, at 23:12, Walter Underwood wrote: > > I would call desktop clients "clients" not "robots". The > distinction is > how they add feeds to the polling list. Clients add them because of > human decisions. Robots discover them mechanically and add them. > > So, clients should act like browsers, and ignore robots.txt. > > Robots.txt is not very widely deployed (around 5% of sites), but it > does work OK for general web content. > > wunder > > --On August 25, 2005 10:25:08 PM +0200 Henry Story > wrote: > > >> >> Mhh. I have not looked into this. But is not every desktop >> aggregator a robot? >> >> Henry >> >> On 25 Aug 2005, at 22:18, James M Snell wrote: >> >>> At the very least, aggregators should respect robots.txt. Doing so >>> would allow publishers to restrict who is allowed to pull their >>> feed. >>> >>> - James >>> >>> >> >> >> > > > > -- > Walter Underwood > Principal Software Architect, Verity > From owner-atom-syntax@mail.imc.org Thu Aug 25 17:59:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Pl1-0007SP-8z for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 17:59:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22780 for ; Thu, 25 Aug 2005 17:59:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLo3ve057671; Thu, 25 Aug 2005 14:50:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PLo3ae057670; Thu, 25 Aug 2005 14:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PLo302057654 for ; Thu, 25 Aug 2005 14:50:03 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (rwcrmhc12) with SMTP id <2005082521495701400klnuce>; Thu, 25 Aug 2005 21:49:57 +0000 Date: Thu, 25 Aug 2005 15:49:55 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, August 25, 2005, at 03:12 PM, Walter Underwood wrote: > I would call desktop clients "clients" not "robots". The distinction is > how they add feeds to the polling list. Clients add them because of > human decisions. Robots discover them mechanically and add them. > > So, clients should act like browsers, and ignore robots.txt. > How could this all be related to aggregators that accept feed URL submissions? I'd imagine the desired behavior is the same as for crawlers--should they check for robots.txt at the root of any domain where a feed is submitted? How about cases where the feed is hosted on a site other than the website that it's tied to (for example, a service like FeedBurner) so some other site's robot.txt controls access to the feed (...or at least tries to)? We've already rejected the idea of trying to build DRM into feeds--is there some way to sidestep the legal complexities and problems that would arise from trying to to that and at the same time enable machine readable statements about what the publisher wants to allow others to do with the feed, and things they want to prohibit, into the feed? If we're not qualified to design an extension to do that, is there someone else who is qualified, and who cares enough to do it? From owner-atom-syntax@mail.imc.org Thu Aug 25 18:59:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Qgb-0000Hr-Dc for atompub-archive@megatron.ietf.org; Thu, 25 Aug 2005 18:59:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26133 for ; Thu, 25 Aug 2005 18:59:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PMpDKv062638; Thu, 25 Aug 2005 15:51:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7PMpDZ5062637; Thu, 25 Aug 2005 15:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7PMpCcD062626 for ; Thu, 25 Aug 2005 15:51:12 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 35FE9725817; Thu, 25 Aug 2005 18:51:07 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Cc: "'Walter Underwood'" Subject: RE: Don't Aggregrate Me Date: Thu, 25 Aug 2005 18:51:06 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcWpwdzpvy9NhU2QSzmxRTCO/r9mjgAA281w Message-Id: <20050825225107.35FE9725817@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > How could this all be related to aggregators that accept feed URL > submissions? My impression has always been that robots.txt was intended to stop robots that crawl a site (i.e. they read one page, extract the URLs from it and then read those pages). I don't believe robots.txt is intended to stop processes that simply fetch one or more specific URLs with known names. At PubSub we *never* "crawl" to discover feed URLs. The only feeds we know about are: 1. Feeds that have announced their presence with a ping 2. Feeds that have been announced to us via a FeedMesh message. 3. Feeds that have been manually submitted to us via our "add-feed" page. We don't crawl. I do not think we qualify as a "robot" in the sense that is relevant to robots.txt. It would appear that Walter Underwood of Verity would agree with me since he says in his recent post that: "I would call desktop clients "clients" not "robots". The distinction is how they add feeds to the polling list. Clients add them because of human decisions. Robots discover them mechanically and add them." If Walter is correct, then he must agree with me that robots.txt does not apply to PubSub! (and, we should not be on his "bad" list.... Walter? Please take us off the list...) bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 00:53:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8WDj-0006qY-S1 for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 00:53:39 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13281 for ; Fri, 26 Aug 2005 00:53:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q4lP7X094210; Thu, 25 Aug 2005 21:47:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7Q4lPAl094209; Thu, 25 Aug 2005 21:47:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q4lNHn094168 for ; Thu, 25 Aug 2005 21:47:24 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id i3so55852wra for ; Thu, 25 Aug 2005 21:47:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=goWylugnzPv4tklaRuv+MiAQZogc19kPOC9mxaTTtoR4WsUizzwne4p9lnJaAVZtN5dQXrmCWFFnHsd3HszktrPnm88vdaQs42pir5ZSUsuU3d61Z/BHaipkOUZw1LIQ0at87ZDuZimM/cqKM77EvKHlgiUB6ce6Dt5rdprylbo= Received: by 10.54.49.34 with SMTP id w34mr2958059wrw; Thu, 25 Aug 2005 21:47:18 -0700 (PDT) Received: by 10.54.104.17 with HTTP; Thu, 25 Aug 2005 21:47:18 -0700 (PDT) Message-ID: <540e373205082521477a9e5012@mail.gmail.com> Date: Thu, 25 Aug 2005 23:47:18 -0500 From: "Roger B." To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me In-Reply-To: <20050825225107.35FE9725817@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> <20050825225107.35FE9725817@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7Q4lOHn094204 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob: It's one thing to ignore a wildcard rule in robots.txt. I don't think its a good idea, but I can at least see a valid argument for it. However, if I put something like: User-agent: PubSub Disallow: / ...in my robots.txt and you ignore it, then you very much belong on the Bad List. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Fri Aug 26 02:03:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8XJd-0000yl-C4 for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 02:03:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19535 for ; Fri, 26 Aug 2005 02:03:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q5ttgr020709; Thu, 25 Aug 2005 22:55:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7Q5ttu7020708; Thu, 25 Aug 2005 22:55:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7Q5tsEu020671 for ; Thu, 25 Aug 2005 22:55:54 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from BOBSLAPTOP (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 4C3FA725B43; Fri, 26 Aug 2005 01:55:49 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Roger B.'" , Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 01:55:41 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <540e373205082521477a9e5012@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWp+ty5lf2nuWBKSTeScmUCIev1cAAByAOg Message-Id: <20050826055549.4C3FA725B43@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger Benningfield wrote: > However, if I put something like: > User-agent: PubSub > Disallow: / > ...in my robots.txt and you ignore it, then you very much > belong on the Bad List. I don't think so. The reason is that I believe that robots.txt has nothing to do with any service I provide or process that we run. Thus, I can't imagine why I would even look in the file. Remember, PubSub never does anything that a desktop client doesn't do. We only look at feeds that have pinged us or that someone has explicitly loaded into our system using "add-feed." We NEVER crawl. We're not a robot and thus I can't see why we would even look at robots.txt. Does your browser look at robots.txt before fetching a page? Does you desktop aggregator look at it before fetching a feed? I don't think so! But, should a crawler like Google, Yahoo! or Technorati respect robots.txt? YES! bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 06:49:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8bm1-0000CZ-5b for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 06:49:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10434 for ; Fri, 26 Aug 2005 06:49:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QAe47B028105; Fri, 26 Aug 2005 03:40:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QAe4Z3028104; Fri, 26 Aug 2005 03:40:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QAe3el028084 for ; Fri, 26 Aug 2005 03:40:03 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 26 Aug 2005 20:41:07 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 26 Aug 2005 20:39:59 +1000 Subject: Re: Don't Aggregrate Me From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050826055549.4C3FA725B43@mail.pubsub.com> 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: Content-Transfer-Encoding: 7bit On 26/8/05 3:55 PM, "Bob Wyman" wrote: > Remember, PubSub never does > anything that a desktop client doesn't do. Periodic re-fetching is a robotic behaviour, common to both desktop aggregators and server based aggregators. Robots.txt was established to minimise harm caused by automatic behaviour, whether by excluding non-idempotent URL, avoiding tarpits of endless dynamic links, and such forth. While true that each of these scenarios involve crawling new links, the base principle at stake is to prevent harm caused by automatic or robotic behaviour. That can include extremely frequent periodic re-fetching, a scenario which didn't really exist when robots.txt was first put together. e. From owner-atom-syntax@mail.imc.org Fri Aug 26 10:50:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fXd-0005aJ-Jo for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 10:50:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24742 for ; Fri, 26 Aug 2005 10:50:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEgwEP012105; Fri, 26 Aug 2005 07:42:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QEgwdB012104; Fri, 26 Aug 2005 07:42:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEgvm2012087 for ; Fri, 26 Aug 2005 07:42:58 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (rwcrmhc12) with SMTP id <2005082614425201400kr40pe>; Fri, 26 Aug 2005 14:42:52 +0000 Date: Fri, 26 Aug 2005 08:42:50 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, August 26, 2005, at 04:39 AM, Eric Scheid wrote: > On 26/8/05 3:55 PM, "Bob Wyman" wrote: >> Remember, PubSub never does >> anything that a desktop client doesn't do. > > Periodic re-fetching is a robotic behaviour, common to both desktop > aggregators and server based aggregators. Robots.txt was established to > minimise harm caused by automatic behaviour, whether by excluding > non-idempotent URL, avoiding tarpits of endless dynamic links, and such > forth. While true that each of these scenarios involve crawling new > links, > the base principle at stake is to prevent harm caused by automatic or > robotic behaviour. That can include extremely frequent periodic > re-fetching, > a scenario which didn't really exist when robots.txt was first put > together. I'm with Bob on this. If a person publishes a feed without limiting access to it, they either don't know what they're doing, or they're EXPECTING it to be polled on a regular basis. As long as PubSub doesn't poll too fast, the publisher is getting exactly what they should be expecting. Any feed client, whether a desktop aggregator or aggregation service, that polls too fast ("extremely frequent re-fetching" above) is breaking the rules of feed consuming etiquette--we don't need robots.txt to tell feed consumers to slow down. From owner-atom-syntax@mail.imc.org Fri Aug 26 10:55:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fbw-0006kU-Qy for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 10:55:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24963 for ; Fri, 26 Aug 2005 10:55:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QEnCph012712; Fri, 26 Aug 2005 07:49:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QEnCYc012711; Fri, 26 Aug 2005 07:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7QEnACf012696 for ; Fri, 26 Aug 2005 07:49:11 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Aug 2005 14:49:01 -0000 Received: from xdsl-81-173-224-221.netcologne.de (EHLO klangraum) [81.173.224.221] by mail.gmx.net (mp009) with SMTP; 26 Aug 2005 16:49:01 +0200 X-Authenticated: #163624 Date: Fri, 26 Aug 2005 16:47:35 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me Message-ID: <20050826144734.GA23804@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> <20050825225107.35FE9725817@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050825225107.35FE9725817@mail.pubsub.com> 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 ietf.org id KAA24963 * Bob Wyman [2005-08-26 01:00]: > My impression has always been that robots.txt was intended to > stop robots that crawl a site (i.e. they read one page, extract > the URLs from it and then read those pages). I don't believe > robots.txt is intended to stop processes that simply fetch one > or more specific URLs with known names. I have to side with Bob here. Web Robots (also called =E2=80=9CWanderers=E2=80=9D or =E2=80=9CSpider= s=E2=80=9D) are Web client programs that automatically traverse the Web=E2=80=99s hypertext structure by retrieving a document, and recursively retrieving all documents that are referenced. Note that =E2=80=9Crecursively=E2=80=9D here doesn=E2=80=99t limit the= definition to any specific traversal algorithm; even if a robot applies some heuristic to the selection and order of documents to visit and spaces out requests over a long space of time, it qualifies to be called a robot. =E2=80=93 PubSub is not a robot by the definition of the `robots.txt` I-D. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 26 11:13:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ftJ-00033t-1D for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:13:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25868 for ; Fri, 26 Aug 2005 11:13:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QF5A6l014082; Fri, 26 Aug 2005 08:05:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QF5Ado014081; Fri, 26 Aug 2005 08:05:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QF59Mt014056 for ; Fri, 26 Aug 2005 08:05:09 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id A1E3EDB for ; Fri, 26 Aug 2005 08:05:04 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7QF53kv016163 for ; Fri, 26 Aug 2005 08:05:04 -0700 (PDT) Date: Fri, 26 Aug 2005 08:05:09 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me Message-ID: <0383F5BAD2B4356443D86C73@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <540e373205082521477a9e5012@mail.gmail.com> References: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> <20050825225107.35FE9725817@mail.pubsub.com> <540e373205082521477a9e5012@mail.gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There are no wildcards in /robots.txt, only path prefixes and user-agent names. There is one special user-agent, "*", which means "all". I can't think of any good reason to always ignore the disallows for *. I guess it is OK to implement the parts of a spec that you want. Just don't answer "yes" when someone asks if you honor robots.txt. A lot of spiders allow the admin to override /robots.txt for specific sites, or better, for specific URLs. wunder --On August 25, 2005 11:47:18 PM -0500 "Roger B." wrote: > > Bob: It's one thing to ignore a wildcard rule in robots.txt. I don't > think its a good idea, but I can at least see a valid argument for it. > However, if I put something like: > > User-agent: PubSub > Disallow: / > > ...in my robots.txt and you ignore it, then you very much belong on > the Bad List. > > -- > Roger Benningfield > > -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 26 11:26:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g6N-000657-2A for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:26:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26718 for ; Fri, 26 Aug 2005 11:26:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QFLBFF016007; Fri, 26 Aug 2005 08:21:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QFLBL3016006; Fri, 26 Aug 2005 08:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QFLA6b015993 for ; Fri, 26 Aug 2005 08:21:10 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 3121653; Fri, 26 Aug 2005 08:21:05 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7QFL3kv016366; Fri, 26 Aug 2005 08:21:04 -0700 (PDT) Date: Fri, 26 Aug 2005 08:21:08 -0700 From: Walter Underwood To: Atom Syntax , robots@mccmedia.com Subject: Re: Don't Aggregrate Me Message-ID: <25CBE6EAD588237E52DE964C@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm adding robots@mccmedia.com to this dicussion. That is the classic list for robots.txt discussion. Robots list: this is a discussion about the interactions of /robots.txt and clients or robots that fetch RSS feeds. "Atom" is a new format in the RSS family. --On August 26, 2005 8:39:59 PM +1000 Eric Scheid wrote: > While true that each of these scenarios involve crawling new links, > the base principle at stake is to prevent harm caused by automatic or > robotic behaviour. That can include extremely frequent periodic re-fetching, > a scenario which didn't really exist when robots.txt was first put together. It was a problem then: In 1993 and 1994 there have been occasions where robots have visited WWW servers where they weren't welcome for various reasons. Sometimes these reasons were robot specific, e.g. certain robots swamped servers with rapid-fire requests, or retrieved the same files repeatedly. In other situations robots traversed parts of WWW servers that weren't suitable, e.g. very deep virtual trees, duplicated information, temporary information, or cgi-scripts with side-effects (such as voting). I see /robots.txt as a declaration by the publisher (webmaster) that robots are not welcome at those URLs. Web robots do not solely depend on automatic link discovery, and haven't for at least ten years. Infoseek had a public "Add URL" page. /robots.txt was honored regardless of whether the link was manually added or automatically discovered. A crawling service (robot) should warn users that the URL, Atom or otherwise, is disallowed by robots.txt. Report that on the status page for that feed. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 26 12:39:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hFG-00042V-Ee for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 12:39:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00907 for ; Fri, 26 Aug 2005 12:39:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGXaDr023906; Fri, 26 Aug 2005 09:33:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QGXa20023905; Fri, 26 Aug 2005 09:33:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGXZ9Q023897 for ; Fri, 26 Aug 2005 09:33:36 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id ABDB67264E8; Fri, 26 Aug 2005 12:33:28 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 12:33:27 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqTrH5krJCKVwbQ+yjBmmuLwcBpwADGixw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Message-Id: <20050826163328.ABDB67264E8@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > I'm with Bob on this. If a person publishes a feed without limiting > access to it, they either don't know what they're doing, or they're > EXPECTING it to be polled on a regular basis. As long as PubSub > doesn't poll too fast, the publisher is getting exactly what they > should be expecting. Because PubSub aggregates content for thousands of others, it removes significant bandwidth load from publishers' sites. We only read a feed from a site in response to an explicit ping from that site or, for those sites that don't ping, we poll them on a scheduled basis. In fact, we read scheduled, non-pinging feeds less frequently than most desktop systems would. No one can claim that we do anything but reduce the load on publishers systems. It should also be noted that we support gzip compression, RFC3229+Feed, conditional-gets, etc. and thus do all the things necessary to reduce our load on publishers sites in the event that we actually do fetch data from them. This is a good thing and not something that robots.txt was intended to prevent. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 12:56:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hV7-0000nn-7k for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 12:56:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01591 for ; Fri, 26 Aug 2005 12:56:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGpa9q025823; Fri, 26 Aug 2005 09:51:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QGpaeu025822; Fri, 26 Aug 2005 09:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QGpWoa025810 for ; Fri, 26 Aug 2005 09:51:33 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so392243wra for ; Fri, 26 Aug 2005 09:51:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lMONK1EzIYsm7WKfcaONi/wHirdK7iOjTG8WSfzIot/ZDG0hW47rjaBI8NDPXVGz7WkykOAPlcG0Nz9Xfji16YNNeyafH/44OqaL/68uJIGGnbTBBn8s+DELWgfx/3r1PjMD12bQInoKmtw5VfceiZkkA8yT39ekElntxPIhPwc= Received: by 10.54.41.55 with SMTP id o55mr3479438wro; Fri, 26 Aug 2005 09:51:26 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 38sm1586346wrl.2005.08.26.09.51.20; Fri, 26 Aug 2005 09:51:26 -0700 (PDT) Message-ID: <430F487E.7050804@gmail.com> Date: Fri, 26 Aug 2005 09:51:10 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me References: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> <20050825225107.35FE9725817@mail.pubsub.com> <540e373205082521477a9e5012@mail.gmail.com> <0383F5BAD2B4356443D86C73@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <0383F5BAD2B4356443D86C73@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok, so this discussion has definitely been interesting... let's see if we can turn it into something actionable. 1. Desktop aggregators and services like pubsub really do not fall into the same category as robots/crawlers and therefore should not necessarily be paying attention to robots.txt 2. However, desktop aggregators and services like pubsub do perform automated pulls against a server and therefore can be abusive to a server. 3. Therefore, it would be helpful if there were a way for publishers to define rules that aggregators and readers should follow. So how about something like this: Add a new link rel="readers" whose href points to a robots.txt-like file that either allows or disallows the aggregator for specific URI's and establishes polling rate preferences User-agent: {aggregator-ua} Origin: {ip-address} Allow: {uri} Disallow: {uri} Frequency: {rate} [{penalty}] Max-Requests: {num-requests} {period} [{penalty}] The User-agent, Allow and Disallow fields have the same basic definition as in robots.txt. The Origin field specifies an IP address so that rules for specific IP's can be established The Frequency establishes the allowed polling rate for the IP or User-agent. The optional {penalty} specifies the number of miliseconds that will be added to the frequency for each violation The Max-Requests establishes the maximum number of requests within a set period of time. The optional {penalty} specifies the number of miliseconds that will be added to the frequency for each violation Example, ... readers.txt, User-agent: Some-Reader Allow: /blog/my-atom-feed.atom Disallow: /blog/someotherfeed.atom Frequency: 3600000 1800000 # wait at least an hour between requests, add 30 minutes for each violation Max-Requests: 10 86400000 3600000 # maximum of ten requests within a 24-hour period, add 1 hour to the period for each violation Some-Reader is allowed to get my-atom.feed.atom but is not allowed to pull someotherfeed.atom If Some-Reader polls the feed more frequently than once in an hour, it must wait 1 hr and 30 minutes before the next poll. If it polls within that period, it goes up to 2 hrs. If it polls appropriately, it goes back down to 1 hr. If Some-Reader polls more than 10 times in a 24 hour period, the rate goes up to no more than 10 times in a 25 hour period; then a 26 hour period, etc. If the reader behaves, it reverts back to the 10 per 24 hour period. The path's specified in the Allow and Disallow fields are relative to the base URI of the readers.txt file... e.g., in the example above, they are relative to www.example.com. Thoughts? - James Walter Underwood wrote: >There are no wildcards in /robots.txt, only path prefixes and user-agent >names. There is one special user-agent, "*", which means "all". >I can't think of any good reason to always ignore the disallows for *. > >I guess it is OK to implement the parts of a spec that you want. >Just don't answer "yes" when someone asks if you honor robots.txt. > >A lot of spiders allow the admin to override /robots.txt for specific >sites, or better, for specific URLs. > >wunder > >--On August 25, 2005 11:47:18 PM -0500 "Roger B." wrote: > > > >>Bob: It's one thing to ignore a wildcard rule in robots.txt. I don't >>think its a good idea, but I can at least see a valid argument for it. >>However, if I put something like: >> >>User-agent: PubSub >>Disallow: / >> >>...in my robots.txt and you ignore it, then you very much belong on >>the Bad List. >> >>-- >>Roger Benningfield >> >> >> >> > > > >-- >Walter Underwood >Principal Software Architect, Verity > > > > From owner-atom-syntax@mail.imc.org Fri Aug 26 13:18:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hqK-0006D6-MB for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 13:18:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02335 for ; Fri, 26 Aug 2005 13:18:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHC3tt027994; Fri, 26 Aug 2005 10:12:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QHC3CA027993; Fri, 26 Aug 2005 10:12:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from newman.implex.net (newman.implex.net [209.224.0.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QHC2SR027987 for ; Fri, 26 Aug 2005 10:12:02 -0700 (PDT) (envelope-from blaine@jrcorps.com) Received: from mail.jrcorps.com [69.54.36.67] by newman.implex.net with ESMTP (SMTPD-8.21) id AD7F04D4; Fri, 26 Aug 2005 12:12:31 -0500 Received: by mail.jrcorps.com (Postfix, from userid 99) id 9A38389174; Fri, 26 Aug 2005 12:13:08 -0500 (CDT) Received: from CPE-24-94-197-193.mn.res.rr.com (CPE-24-94-197-193.mn.res.rr.com [24.94.197.193]) by webmail.jrcorps.com (Horde MIME library) with HTTP; Fri, 26 Aug 2005 12:13:08 -0500 Message-ID: <20050826121308.qhd4fnxav34k0048@webmail.jrcorps.com> Date: Fri, 26 Aug 2005 12:13:08 -0500 From: blaine@jrcorps.com To: Atom Syntax Subject: Atom for internal use? , etc MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-JR-Corps-Rocks: At JRCorps.com X-Originating-IP: 24.94.197.193 X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I am developing a web app framework and am using a RSSesque xml format to allow the application layer talk to a higher layer. XSL is used to combine this and then passes it on up to the gui layer. I would like to move to Atom instead of RSS since Atom seems to encapsulate more things. I would like to be able to be fully atom compliant, and not just some atomesque flavor. Here is an issue I am having.... * Nested feeds and A bit back I posted about nested feeds. I took the advice given and made separate sibling feed tags instead of having feeds of feeds. The problem comes in connecting them at the XSL level. I can't use since the xml i need to reference is not at a different location, but inside of a parent node that holds all the sibling application feed nodes. In practice, this parent node basically represents a content area on a webpage. Is there an attribute to the LINK tag I can use as some sort of id that i can assign to the feed tag and link to it via the link tag? I read the spec and couldn't really find one. Here is an example. Products and Products Options are two differnt feeds within this parent tag. 1 Atom Sweatshirt 1 small 2 medium 3 large Any thoughts? Thanks in advance. Blaine From owner-atom-syntax@mail.imc.org Fri Aug 26 14:28:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iwZ-0001MV-Uh for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:28:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05342 for ; Fri, 26 Aug 2005 14:28:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIL4tp035718; Fri, 26 Aug 2005 11:21:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIL4OT035717; Fri, 26 Aug 2005 11:21:04 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7QIL310035690 for ; Fri, 26 Aug 2005 11:21:03 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Aug 2005 18:20:54 -0000 Received: from xdsl-84-44-228-243.netcologne.de (EHLO klangraum) [84.44.228.243] by mail.gmx.net (mp009) with SMTP; 26 Aug 2005 20:20:54 +0200 X-Authenticated: #163624 Date: Fri, 26 Aug 2005 20:20:08 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Atom for internal use? , etc Message-ID: <20050826182008.GA26822@klangraum> Mail-Followup-To: Atom Syntax References: <20050826121308.qhd4fnxav34k0048@webmail.jrcorps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050826121308.qhd4fnxav34k0048@webmail.jrcorps.com> 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: * blaine@jrcorps.com [2005-08-26 19:20]: > Is there an attribute to the LINK tag I can use as some sort of id that i can > assign to the feed tag and link to it via the link tag? My first thought would be to use xml:id on the feed element and a fragment identifier in the @href. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 26 14:53:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jKS-0008PE-Tu for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 14:53:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06533 for ; Fri, 26 Aug 2005 14:53:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIkNbD038608; Fri, 26 Aug 2005 11:46:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QIkNue038607; Fri, 26 Aug 2005 11:46:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QIkNcg038587 for ; Fri, 26 Aug 2005 11:46:23 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by xproxy.gmail.com with SMTP id h31so320870wxd for ; Fri, 26 Aug 2005 11:46:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=egQR+zfuDEEwlGb6jGaxw5xJH8iCrfPPWjau060pK5ufv4zycsHYVRydoAk9IGSknEL2PvPbepnJRK4R0ZcfuKrI53kjPTwRdg+ehmw7L4XoLU4uJsJNpBisBTJtGtXMar+GrZYjtZalKGClppyldxoLyG6zkuOcEXyymXcNUUY= Received: by 10.70.96.4 with SMTP id t4mr55539wxb; Fri, 26 Aug 2005 11:46:17 -0700 (PDT) Received: by 10.70.124.6 with HTTP; Fri, 26 Aug 2005 11:46:17 -0700 (PDT) Message-ID: <14be96d305082611465d157c8@mail.gmail.com> Date: Fri, 26 Aug 2005 14:46:17 -0400 From: Mark Pilgrim To: "Roger B." Subject: Re: Don't Aggregrate Me Cc: Henry Story , Atom Syntax In-Reply-To: <540e3732050825141448cfbcd7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> <540e3732050825141448cfbcd7@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QIkNcg038602 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/25/05, Roger B. wrote: > > Mhh. I have not looked into this. But is not every desktop aggregator > > a robot? > > Henry: Depends on who you ask. (See the Newsmonster debates from a > couple years ago.) As I am the one who kicked off the Newsmonster debates a couple years ago, I would like to throw in my opinion here. My opinion has not changed, and it is this: 1. If a user gives a feed URL to a program (aggregator, aggregator service, ping service, whatever), the program may request it and re-request it as often as it likes. This is not "robotic" behavior in the robots.txt sense. The program has been given instructions to request a URL, and it does so, perhaps repeatedly. This covers the most common case of a desktop or web-based feed reader or aggregator that reads feeds and nothing else. 2. If a user gives a feed URL to a program *and then the program finds all the URLs in that feed and requests them too*, the program needs to support robots.txt exclusions for all the URLs other than the original URL it was given. This is robotic behavior; it's exactly the same as requesting an HTML page, scraping it for links, and then requesting each of those scraped URLs. The fact that the original URL pointed to an HTML document or an XML document is immaterial; they are clearly the same use case. Programs such as wget may fall into either category, depending on command line options. The user can request a single resource (category 1), or can instruct wget to recursive through links and effectively mirror a remote site (category 2). Section 9.1 of the wget manual describes its behavior in the case of category 2: http://www.delorie.com/gnu/docs/wget/wget_41.html """ For instance, when you issue: wget -r http://www.server.com/ First the index of `www.server.com' will be downloaded. If Wget finds that it wants to download more documents from that server, it will request `http://www.server.com/robots.txt' and, if found, use it for further downloads. `robots.txt' is loaded only once per each server. """ So wget downloads the URL it was explicitly given, but then if it's going to download any other autodiscovered URLs, it checks robots.txt to make sure that's OK. Bringing this back to feeds, aggregators can fall into either category (1 or 2, above). At the moment, the vast majority of aggregators fall into category 1. *However*, what Newsmonster did 2 years ago pushed it into category 2 in some cases. It had a per-feed option to prefetch and cache the actual HTML pages linked by excerpt-only feeds. When it fetched the feed, Newsmonster would go out and also fetch the page pointed to by the item's element. This is actually a very useful feature; my only problem with it was that it did not respect robots.txt *when it went outside the original feed URL and fetched other resources*. Nor is this limited to prefetching HTML pages. The same problem arises with aggregators that automatically download *any* linked content, such as enclosures. The end user gave their aggregator the URL of a feed, so the aggregator may poll that feed from now until the end of time (or 410 Gone, whichever comes first :). But if the aggregator reads that feed and subsequently decides to request resources other than the original feed URL (like .mp3 files), the aggregator should support robots.txt for those other URLs. (And before you say "but my aggregator is nothing but a podcast client, and the feeds are nothing but links to enclosures, so it's obvious that the publisher wanted me to download them" -- WRONG! The publisher might want that, or they might not. They might publish a few selected files on a high-bandwidth server where anything goes, and other files on a low-bandwidth server where they would prefer that users explicitly click the link to download the file if they really want it. Or they might want some types of clients (like personal desktop aggregators) to download those files and other types of clients (like centralized aggregation services) not to download them. Or someone might set up a malicious feed that intentionally pointed to large files on someone else's server... a kind of platypus DoS attack. Or any number of other scenarios. So how do you, as a client, know what to do? robots.txt.) -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri Aug 26 15:29:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jtI-000185-On for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:29:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09855 for ; Fri, 26 Aug 2005 15:29:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJMLmW043218; Fri, 26 Aug 2005 12:22:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJMLVm043217; Fri, 26 Aug 2005 12:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJMKja043207 for ; Fri, 26 Aug 2005 12:22:20 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id A15897D; Fri, 26 Aug 2005 12:22:15 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7QJMEkv019796; Fri, 26 Aug 2005 12:22:15 -0700 (PDT) Date: Fri, 26 Aug 2005 12:22:20 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me Message-ID: In-Reply-To: <430F487E.7050804@gmail.com> References: <2C9650E6-15B2-11DA-A95D-003065EA6144@geckotribe.com> <20050825225107.35FE9725817@mail.pubsub.com> <540e373205082521477a9e5012@mail.gmail.com> <0383F5BAD2B4356443D86C73@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <430F487E.7050804@gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 26, 2005 9:51:10 AM -0700 James M Snell wrote: > Add a new link rel="readers" whose href points to a robots.txt-like file that > either allows or disallows the aggregator for specific URI's and establishes > polling rate preferences > > User-agent: {aggregator-ua} > Origin: {ip-address} > Allow: {uri} > Disallow: {uri} > Frequency: {rate} [{penalty}] > Max-Requests: {num-requests} {period} [{penalty}] No, on several counts. 1. Big, scalable spiders don't work like that. They don't do aggregate frequencies or rates. They may have independent crawlers visiting the same host. Yes, they try to be good citizens, but you can't force WWW search folk to redesign their spiders. 2. Frequencies and rates don't work well with either HTTP caching or with publishing schedules. Things are much cleaner with a single model (max-age and/or expires). 3. This is trying to be a remote-control for spiders instead of describing some characteristic of the content. We've rejected the remote control approach in Atom. 4. What happens when there are conflicting specs in this file, in robots.txt, and in a Google Sitemap? 5. Specifying all this detail is pointless if the spider ignores it. You still need to have enforceable rate controls in your webserver to handle busted or bad citizen robots. 6. Finally, this sort of thing has been proposed a few times and never caught on. By itself, that is a weak argument, but I think the causes are pretty strong (above). There are some proprietary extensions to robots.txt: Yahoo crawl-delay: Google wildcard disallows: It looks like MSNbot does crawl-delay and an extension-only wildcard: wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Fri Aug 26 15:32:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jwK-0001xk-Va for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:32:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09998 for ; Fri, 26 Aug 2005 15:32:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJRLkp043700; Fri, 26 Aug 2005 12:27:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJRL2X043699; Fri, 26 Aug 2005 12:27:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJRLFx043692 for ; Fri, 26 Aug 2005 12:27:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout03/MantshX 4.0) with ESMTP id j7QJRH8O013544; Fri, 26 Aug 2005 12:27:17 -0700 (PDT) Received: from [192.168.1.101] (host-84-9-131-254.bulldogdsl.com [84.9.131.254]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j7QJREjc022952 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Aug 2005 12:27:16 -0700 (PDT) In-Reply-To: <14be96d305082611465d157c8@mail.gmail.com> References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> <540e3732050825141448cfbcd7@mail.gmail.com> <14be96d305082611465d157c8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Don't Aggregrate Me Date: Fri, 26 Aug 2005 20:27:05 +0100 To: Mark Pilgrim X-Mailer: Apple Mail (2.733) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Aug 2005, at 7:46 pm, Mark Pilgrim wrote: > 2. If a user gives a feed URL to a program *and then the program finds > all the URLs in that feed and requests them too*, the program needs to > support robots.txt exclusions for all the URLs other than the original > URL it was given. ... > (And before you say "but my aggregator is nothing but a podcast > client, and the feeds are nothing but links to enclosures, so it's > obvious that the publisher wanted me to download them" -- WRONG! The > publisher might want that, or they might not ... So you're saying browsers should check robots.txt before downloading images? Graham From owner-atom-syntax@mail.imc.org Fri Aug 26 15:40:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k3u-0005Xc-Jk for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:40:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10720 for ; Fri, 26 Aug 2005 15:40:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJY3qi044682; Fri, 26 Aug 2005 12:34:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJY3HT044681; Fri, 26 Aug 2005 12:34:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJY2Ke044671 for ; Fri, 26 Aug 2005 12:34:02 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i35so313458wra for ; Fri, 26 Aug 2005 12:33:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=W9HNMNeBbXP0jxigu1dQwX2M7mte3795VKbRmVvJ6SIiSoOfzYHwT/dHtmzDGCYMfdGu9YOr+zRQEXW56WZJpz0kzXxUR4Vbny14vWr7mag8qLSyO9bF+17ifcifa6MgifFhfYqCkalPrlf2gHeWKIxriQNCNtLv7pEta5LY+4A= Received: by 10.54.111.11 with SMTP id j11mr3650573wrc; Fri, 26 Aug 2005 12:33:57 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id d7sm3684045wra.2005.08.26.12.33.55; Fri, 26 Aug 2005 12:33:57 -0700 (PDT) Message-ID: <430F6E9E.3030104@gmail.com> Date: Fri, 26 Aug 2005 12:33:50 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Mark Pilgrim , atom-syntax Subject: Re: Don't Aggregrate Me References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> <540e3732050825141448cfbcd7@mail.gmail.com> <14be96d305082611465d157c8@mail.gmail.com> <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.com> In-Reply-To: <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.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: Content-Transfer-Encoding: 7bit Graham wrote: > >> (And before you say "but my aggregator is nothing but a podcast >> client, and the feeds are nothing but links to enclosures, so it's >> obvious that the publisher wanted me to download them" -- WRONG! The >> publisher might want that, or they might not ... > > > So you're saying browsers should check robots.txt before downloading > images? > ... and stylesheets, framesets, embedded objects, etc? - James From owner-atom-syntax@mail.imc.org Fri Aug 26 15:41:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k4i-0005om-3W for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 15:41:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10758 for ; Fri, 26 Aug 2005 15:41:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJZLec044832; Fri, 26 Aug 2005 12:35:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QJZLhm044829; Fri, 26 Aug 2005 12:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QJZL5E044804 for ; Fri, 26 Aug 2005 12:35:21 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 9CECD4EF90; Fri, 26 Aug 2005 15:35:19 -0400 (EDT) In-Reply-To: <20050825225107.35FE9725817@mail.pubsub.com> References: <20050825225107.35FE9725817@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <58C3F552-674E-4FF4-B3D2-0171F40A4FBC@w3.org> Cc: Atom Syntax From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Fri, 26 Aug 2005 15:35:23 -0400 To: X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QJZL5E044813 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 ietf.org id PAA10758 Le 05-08-25 =E0 18:51, Bob Wyman a =E9crit : > At PubSub we *never* "crawl" to discover feed URLs. The only feeds > we know about are: > 1. Feeds that have announced their presence with a ping > 2. Feeds that have been announced to us via a FeedMesh message. > 3. Feeds that have been manually submitted to us via our "add-=20 > feed" > page. > We don't crawl. - How one who has previously submitted a feed URL remove it from the =20 index? (Change of opinions) - How someone who's not mastering the ping (built-in in the service, =20 the software) but doesn't want his/her feed being indexed by the =20 service. > I do not think we qualify as a "robot" in the sense that is =20 > relevant > to robots.txt. It would appear that Walter Underwood of Verity =20 > would agree > with me since he says in his recent post that: "I would call =20 > desktop clients > "clients" not "robots". The distinction is how they add feeds to =20 > the polling > list. Clients add them because of human decisions. Robots discover =20 > them > mechanically and add them." If Walter is correct, then he must =20 > agree with me > that robots.txt does not apply to PubSub! (and, we should not be on =20 > his > "bad" list.... Walter? Please take us off the list...) It does apply, except if you give a possibility to each subscribers =20 to ban a specific URIs. I think it's one of the main issue of the Web, too many implicit =20 contracts. That's good because it helps to make the things easier, =20 but at the same time, it means creating the infrastructure to deny =20 explicitly. I guess the Feed industry is not eager too much to do =20 that, because implicit data mining is one big part of the business. Basically imagine this scenario, when you go out every morning from =20 your house, we take a photo of you and the way you are dress. It =20 helps us to know how the people of this area are dressed then to =20 create shops around. That will help us to send you appropriate =20 catalogs of clothes you like, and to park a car with an ads with the =20 products you usually like. Do you have the right to say "No, I don't want to take a photo =20 of me every morning for that purpose"? --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Fri Aug 26 16:49:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8l8m-0005zk-CS for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:49:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21906 for ; Fri, 26 Aug 2005 16:49:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKem0w051913; Fri, 26 Aug 2005 13:40:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QKemJK051912; Fri, 26 Aug 2005 13:40:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKemtn051900 for ; Fri, 26 Aug 2005 13:40:48 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id EE443727173; Fri, 26 Aug 2005 16:40:28 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Mark Pilgrim'" , "'Roger B.'" Cc: "'Henry Story'" , "'Atom Syntax'" Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 16:40:26 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqcFsEnnxDGCmATCucsXagEczOlQADDGaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <14be96d305082611465d157c8@mail.gmail.com> Message-Id: <20050826204028.EE443727173@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote (among other things): > (And before you say "but my aggregator is nothing but a podcast > client, and the feeds are nothing but links to enclosures, so > it's obvious that the publisher wanted me to download them" -- WRONG! I agree with just about everything that Mark wrote in his post. However, I'm finding it very difficult to accept this bit about enclosures (podcasts.) It seems to me that the very name "enclosure" implies that the resources pointed to are to be considered part and parcel of the original entry. In fact, I think one might even argue that if you *didn't* download the enclosed items that you had created a "derivative work" that didn't represent the item that was intended to be syndicated... Others have pointed out the problem with links to images, stylesheets, CSS files, etc. And, what about the numerous proposals for "linking" one feed to another? What about the remote content pointed to by a src attribute in an atom:content element? Should PubSub be able to read that remote content when indexing and/or matching the entry? It strikes me that not all URIs are created equally and not everything that looks like crawling is really "crawling." I am firm in believing that URI's in tags are the stuff of crawlers but the URIs in tags, enclosures, media-rss objects, tags, etc. seem to be qualitatively different. I think "crawling" URI's found in tags, tags and enclosures isn't crawling... Or... Is there something I'm missing here? bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 16:53:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lCy-0008IF-7U for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:53:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22094 for ; Fri, 26 Aug 2005 16:53:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKmT5S052434; Fri, 26 Aug 2005 13:48:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QKmTUX052433; Fri, 26 Aug 2005 13:48:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QKmRoB052419 for ; Fri, 26 Aug 2005 13:48:28 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so2499wra for ; Fri, 26 Aug 2005 13:48:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hpsAPnAToYZllS7qmIx/HNX9lQtlmPxaYN3gPOgW6/mpLonSV2y8tZ8Wmxk+lRRAkcWy7zQwhN/CMB9Qdnwd0q5vLV1NcUAj2V4BEaDAiKra9qnxzq8+C5NxSiwDPqngwxfKGQiWyXlcg2TgR2UyQ5iPLL3tvbijt9N/Pb9NUK0= Received: by 10.54.44.48 with SMTP id r48mr3849825wrr; Fri, 26 Aug 2005 13:48:22 -0700 (PDT) Received: by 10.54.104.17 with HTTP; Fri, 26 Aug 2005 13:48:22 -0700 (PDT) Message-ID: <540e373205082613483836db28@mail.gmail.com> Date: Fri, 26 Aug 2005 15:48:22 -0500 From: "Roger B." To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me In-Reply-To: <20050826055549.4C3FA725B43@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <540e373205082521477a9e5012@mail.gmail.com> <20050826055549.4C3FA725B43@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QKmSoB052428 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Remember, PubSub never does > anything that a desktop client doesn't do. Bob: What about FeedMesh? If I ping blo.gs, they pass that ping along to you, and PubSub fetches my feed, then PubSub is doing something a desktop client doesn't do. It's following a link found in one place and retrieving/indexing/polling a document somewhere else... sounds distinctly spidery to me. But honestly, I'm not interested in nit-picking anyone's definition of "robot". To me, it's a matter of being friendly to the people providing all that content... if they make a point of telling me to stay away, I'm going to stay away. Let's say I'm absolutely convinced that my republishing aggregator isn't a spider, for whatever reason. Fine, I'm going to ignore any "*" directives in robots.txt. But I'm not going to ignore the file entirely, because if someone goes to the trouble to add an entry specifically for me, then that's a hint-and-a-half that I need to leave him alone. We've got a mechanism that allows any user with his own domain and a text editor to tell us whether or not he wants us messing with his stuff. I think it's foolish to ignore that. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Fri Aug 26 17:14:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lX7-0005wr-Nc for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:14:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23062 for ; Fri, 26 Aug 2005 17:14:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QL5KwM054024; Fri, 26 Aug 2005 14:05:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QL5K1m054023; Fri, 26 Aug 2005 14:05:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7QL5ILK054011 for ; Fri, 26 Aug 2005 14:05:18 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Aug 2005 21:05:09 -0000 Received: from xdsl-84-44-228-243.netcologne.de (EHLO klangraum) [84.44.228.243] by mail.gmx.net (mp014) with SMTP; 26 Aug 2005 23:05:09 +0200 X-Authenticated: #163624 Date: Fri, 26 Aug 2005 23:04:35 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: Don't Aggregrate Me Message-ID: <20050826210435.GA28184@klangraum> Mail-Followup-To: 'Atom Syntax' References: <14be96d305082611465d157c8@mail.gmail.com> <20050826204028.EE443727173@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050826204028.EE443727173@mail.pubsub.com> 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: * Bob Wyman [2005-08-26 22:50]: > It strikes me that not all URIs are created equally and not > everything that looks like crawling is really "crawling." @xlink:type? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Fri Aug 26 17:57:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mCe-0004wg-6D for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:57:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24739 for ; Fri, 26 Aug 2005 17:57:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QLndjv057602; Fri, 26 Aug 2005 14:49:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QLndSk057601; Fri, 26 Aug 2005 14:49:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QLnc11057573 for ; Fri, 26 Aug 2005 14:49:38 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id BBA8572C3CB; Fri, 26 Aug 2005 17:49:32 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Roger B.'" , Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 17:49:31 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqgNvLvKN6mWIgS2iXXQ5Hu0FvjAABDszQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <540e373205082613483836db28@mail.gmail.com> Message-Id: <20050826214932.BBA8572C3CB@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger Benningfield wrote: > We've got a mechanism that allows any user with his own domain > and a text editor to tell us whether or not he wants us messing with > his stuff. I think it's foolish to ignore that. The problem is that we have *many* such mechanisms. Robots.txt is only one. Others have been mentioned on this list in the past. Others are buried in obscure posts that you really have to dig to find. How do we decide which mechanisms to use? Also, since I don't think robots.txt was intended to be used for services like the aggregators we're discussing, I believe that for us to encourage people to use it in the way you suggest would be an abuse of the robots.txt system. > Bob: What about FeedMesh? If I ping blo.gs, they pass that ping > along to you, and PubSub fetches my feed, then PubSub is doing > something a desktop client doesn't do. Wrong. Some desktop clients *do* work like FeedMesh. Consider the Shrook distributed checking system[1]. FeedMesh and PubSub work very much like Shrook's desktop clients do. In the Shrook system, all the desktop clients report back updates that they have found to a central service that then distributes the update info to other clients. The result is that the amount of polling that goes on is drastically reduced and the freshness of data is increased since every client benefits from the polling of all other clients. Although no single client might poll a site more frequently than once an hour, if you have 60 Shrook clients each polling once an hour, each client is getting the effect of polling every minute... The Shrook model is basically the same as the FeedMesh model except that in FeedMesh you typically ask for info on ALL sites whereas in Shrook, you typically only get updates for a smaller, enumerated set of feeds. However, the number of feeds you monitor does not change the basic nature of the distributed checking system. Shrook and FeedMesh are, as far as I'm concerned, largely indistinguishable in this area. (There are some detail differences of course. For instance, Shrook worries about client privacy issues that aren't relevant in the FeedMesh case.) Remember, PubSub only deals with data from Pings and from sites that have been manually added to our system. We don't do any web scraping and we don't follow links to find other blogs. Also, we filter out of our system feeds that originate with services that are known to scrape web pages and inject data that was not intended by the original publisher to appear in feeds. (Often, people try to get around partial feeds by "filling in the missing bits by scraping from blog's websites.) Thus, we filter out any feed that comes from a service like Technorati since they scrape blogs and inject scraped content into feeds without the explicit approval or consent of the publishers of the sites they scraped. bob wyman [1] http://www.fondantfancies.com/apps/shrook/distfaq.php From owner-atom-syntax@mail.imc.org Fri Aug 26 17:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mDs-00050o-WD for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 17:58:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24775 for ; Fri, 26 Aug 2005 17:58:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QLrIsJ058055; Fri, 26 Aug 2005 14:53:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QLrIrL058054; Fri, 26 Aug 2005 14:53:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QLrI0P058042 for ; Fri, 26 Aug 2005 14:53:18 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 651B972C3D9; Fri, 26 Aug 2005 17:53:12 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Karl Dubost'" Cc: "'Atom Syntax'" Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 17:53:11 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqdUs7C+Zu4MJLTx+BYfUyNGLpRgADPFXg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <58C3F552-674E-4FF4-B3D2-0171F40A4FBC@w3.org> Message-Id: <20050826215312.651B972C3D9@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Karl Dubost wrote: > - How one who has previously submitted a feed URL remove it from > the index? (Change of opinions) If you are the publisher of a feed and you don't want us to monitor your content, complain to us and we'll filter you out. Folk do this every once in a while. Send us an email using the contact information on our site. (Sorry I don't want to put an email address in a mailing list post... We get enough spam already.) > - How someone who's not mastering the ping (built-in in the > service, the software) but doesn't want his/her feed being indexed by > the service. Providers of hosted blogging solutions or of stand-alone system should feel a responsibility to do a better job of educating their users as to the impact of configuration options (or the lack of options.) There are many blogging systems that don't support pings and others which normally provide pings but allow users to turn them off. Some systems, like LiveJournal even allow you to have a blog but mark it "private" so that only your friends can read it and pings aren't generated. What might not be happening as well as it could is the process by which service or software providers are educating their users. Services should work harder to educate their users. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 18:33:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ml8-00011G-IE for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 18:33:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28578 for ; Fri, 26 Aug 2005 18:33:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMQQEt063915; Fri, 26 Aug 2005 15:26:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QMQQsm063914; Fri, 26 Aug 2005 15:26:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMQPjf063906 for ; Fri, 26 Aug 2005 15:26:25 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id C88124EF23; Fri, 26 Aug 2005 18:26:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <20050826215312.651B972C3D9@mail.pubsub.com> References: <20050826215312.651B972C3D9@mail.pubsub.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <514B7BD6-7232-4138-9197-1A87BBD9EEE1@w3.org> From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Fri, 26 Aug 2005 18:26:29 -0400 To: bobwyman@pubsub.com, Atom Syntax X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7QMQPjf063908 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 ietf.org id SAA28578 Le 05-08-26 =E0 17:53, Bob Wyman a =E9crit : > Karl Dubost wrote: > >> - How one who has previously submitted a feed URL remove it from >> the index? (Change of opinions) > If you are the publisher of a feed and you don't want us to =20 > monitor > your content, complain to us and we'll filter you out. Folk do this =20 > every > once in a while. Send us an email using the contact information on =20 > our site. > (Sorry I don't want to put an email address in a mailing list =20 > post... We get > enough spam already.) Where it is said? What you just said ;) http://www.pubsub.com/help.php http://www.pubsub.com/faqs.php You see educating users is not obvious it seems ;) No offense, it =20 just shows that it is not an easy accessible information. And there's =20 a need to educate Services too. >> - How someone who's not mastering the ping (built-in in the >> service, the software) but doesn't want his/her feed being indexed by >> the service. >> > Providers of hosted blogging solutions or of stand-alone system > should feel a responsibility to do a better job of educating their =20 > users as > to the impact of configuration options (or the lack of options.) =20 > There are > many blogging systems that don't support pings and others which =20 > normally > provide pings but allow users to turn them off. Some systems, like > LiveJournal even allow you to have a blog but mark it "private" so =20 > that only > your friends can read it and pings aren't generated. What might not be > happening as well as it could is the process by which service or =20 > software > providers are educating their users. Services should work harder to =20 > educate > their users. That doesn't solve the problem, when a third party - add my feed to such a service - send a ping to a service. Scenario: I'm a weblogger, I browse and see in my referer a link to my site. I =20 go to the site, and see that the guy talked about me. He has a Feed =20 but he's not indexed yet by PubSub, Technorati and others. I take the =20 freedom to add his feed URL to the service and/or to ping the service =20 because I want to know when this guy talk about me the next time. Well the problem is that this guy doesn't want to be indexed by =20 these services. How does he block the service? BTW, it's a real scenario. --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Fri Aug 26 19:07:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nHt-0004Pr-Ol for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:07:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00244 for ; Fri, 26 Aug 2005 19:07:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMxdNc066973; Fri, 26 Aug 2005 15:59:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7QMxdV6066972; Fri, 26 Aug 2005 15:59:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7QMxcKu066959 for ; Fri, 26 Aug 2005 15:59:39 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 8DDAC72C55D; Fri, 26 Aug 2005 18:59:33 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Karl Dubost'" , "'Atom Syntax'" Subject: RE: Don't Aggregrate Me Date: Fri, 26 Aug 2005 18:59:32 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqjTGlGFNhk8lDRfaBQhU/WNiCwwAAcaKg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <514B7BD6-7232-4138-9197-1A87BBD9EEE1@w3.org> Message-Id: <20050826225933.8DDAC72C55D@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Karl Dubost points out that it is hard to figure out what email address to send messages to if you want to "de-list" from PubSub...: Karl, Please, accept my apologies for this. I could have sworn we had the policy prominently displayed on the site. I know we used to have it there. This must have been lost when we did a site redesign last November! I'm really surprised that it has taken this long to notice that it is gone. I'll see that we get it back up. > You see educating users is not obvious it seems ;) No offense, it > just shows that it is not an easy accessible information. And > there's a need to educate Services too. Point taken. I'll get it fixed. It's a weekend now. Give me a few days... I'm not sure, but I think it makes sense to put this on the "add-feed" page at: http://www.pubsub.com/add_feed.php . Do you agree? > Scenario: > I take the freedom to add his feed URL to the service and/or to ping > the service because I want to know when this guy talk about me the > next time. Well the problem is that this guy doesn't want to be indexed > by these services. How does he block the service? Yes, forged pings or unauthorized third-party pings are a real issue. Unfortunately, the current design of the pinging system gives us absolutely no means to determine if a ping is authorized by the publisher. This is one of many, many issues that I hope that this Working Group will be willing to take up once it gets the protocol worked out and has time to think about these issues. I argued last year that we should develop a blogging or syndication architecture document in much the same way that the TAG documented the web architecture and in the way that most decent standards groups usually produce some sort of reference architecture document. There are many pieces of the syndication infrastructure that are being ignored or otherwise not being given enough attention. Pinging is one of them. Some solutions, like requiring that pings be "signed" would work from a technical point of view, but are probably not practical except in some limited cases. (e.g. Signatures may make sense as a way to enable "Fat Pings" from small or personal blog sites. In that case, the benefit of the "Fat Ping" might override the cost and complexity of generating the signature.) Some have also proposed the equivalent of a "do-not-call" list that folk could register with. We might also set up something like FeedMesh where service providers shared updates concerning which bloggers had asked to be filtered out. (That means you would only have to notify one service to get pulled from them all -- a real benefit to users.) Or, we could define extensions to Atom to express these things... There are many options. Today, we do the best we can with what we have. Hopefully, we'll all maintain enough interest in these issues to continue the process of working them out. bob wyman From owner-atom-syntax@mail.imc.org Fri Aug 26 23:56:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8roL-0000cg-PV for atompub-archive@megatron.ietf.org; Fri, 26 Aug 2005 23:56:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10567 for ; Fri, 26 Aug 2005 23:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3onC2094199; Fri, 26 Aug 2005 20:50:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7R3onfa094198; Fri, 26 Aug 2005 20:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7R3olOU094187 for ; Fri, 26 Aug 2005 20:50:48 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 27 Aug 2005 13:51:51 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 27 Aug 2005 13:50:41 +1000 Subject: Re: Don't Aggregrate Me From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050826204028.EE443727173@mail.pubsub.com> 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: Content-Transfer-Encoding: 7bit On 27/8/05 6:40 AM, "Bob Wyman" wrote: > I think "crawling" URI's found in tags, > tags and enclosures isn't crawling... Or... Is there something I'm > missing here? crawling tags isn't a huge problem because it doesn't lead to a recursive situation. Same withh stylesheets. Mark's point with enclosures is that they tend to be big and the basic principle involved is to minimise harm, not minimise a certain behaviour know to cause harm sometimes. Following tags which lead to more or documents, which can also contain more tags, and thus recursive behaviour, is definitely crawling behaviour which is covered by robots.txt e. From owner-atom-syntax@mail.imc.org Sat Aug 27 13:58:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E94wO-000642-Gu for atompub-archive@megatron.ietf.org; Sat, 27 Aug 2005 13:58:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22351 for ; Sat, 27 Aug 2005 13:58:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RHqXfU023100; Sat, 27 Aug 2005 10:52:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7RHqXGg023099; Sat, 27 Aug 2005 10:52:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7RHqWOu023074 for ; Sat, 27 Aug 2005 10:52:32 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 32F03A32A9; Sat, 27 Aug 2005 13:52:30 -0400 (EDT) In-Reply-To: <4d747c7340014fedf69997b3aa820dd9@greenbytes.de> References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> <2030B24C-2B22-483A-A7C1-9697D7C14B4C@mnot.net> <4d747c7340014fedf69997b3aa820dd9@greenbytes.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <059251F7-4598-41BB-869E-65809F19E026@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Feed History: stateful -> incremental? Date: Sat, 27 Aug 2005 10:52:28 -0700 To: Stefan Eissing X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25/08/2005, at 10:10 AM, Stefan Eissing wrote: > Seeing it as a data structure "fh" introduces a single-linked list > of documents which the whole feed is composed of. I think such a > document needs its own term. > > A single document could be named a "feed fragement". The first > document "head fragment"? Not very snappy. Let's see. If the whole > feed is atom, then the fragments are "particals"? "feedytrons"? Are > we perhaps talking about a "split feed" (fh:split=true/false? the > german term for a fragment is "splitter", btw.) That's one thing to be named. I was trying to come up with a term for the whole, conceptual feed (that indicates its components have this nature); that's why I came up with "incremental." I.e., in usage: "That's a foo feed; you can walk back its previous elements and build the whole feed." And, "That's not a foo feed; the document you fetch is the whole feed." "Incremental" works pretty well there (although it has a lot of syllables); "sliding" (as suggested by James) also fits, but it is a bit evocative of time, which I'd like to avoid (despite the use of 'history' in the document title :-/). (BTW, "incremental" isn't my term; it was suggested privately by an implementor) -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Aug 29 01:43:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9cQW-00020Z-Au for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 01:43:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03489 for ; Mon, 29 Aug 2005 01:43:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T5YuRa066712; Sun, 28 Aug 2005 22:34:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7T5YuHh066711; Sun, 28 Aug 2005 22:34:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7T5Yt2O066705 for ; Sun, 28 Aug 2005 22:34:55 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so974415rng for ; Sun, 28 Aug 2005 22:34:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FiDKng/OizsuEEyNLSTK2J9vnN8hHKpchTaKB4fF56ZaCJja5m7VOo+8TUgpp+cwkIgU1M03eKTR8cGGjlM7KHyRtuN9e+F6L/q7P92R42KGM6POtjTMKgbH8Z+oEZnEl6XLQTDZwupV0TzRrmKiZPm9nShY7xT4A+XJSz4Pagw= Received: by 10.38.9.35 with SMTP id 35mr155256rni; Sun, 28 Aug 2005 22:34:54 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id h18sm4271374rnb.2005.08.28.22.34.54; Sun, 28 Aug 2005 22:34:54 -0700 (PDT) Message-ID: <43129E77.3090303@gmail.com> Date: Sun, 28 Aug 2005 22:34:47 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Stefan Eissing , Atom Syntax Subject: Re: Feed History: stateful -> incremental? References: <6FA1514F-572F-4C82-8ED1-FDED9E981FFB@mnot.net> <2030B24C-2B22-483A-A7C1-9697D7C14B4C@mnot.net> <4d747c7340014fedf69997b3aa820dd9@greenbytes.de> <059251F7-4598-41BB-869E-65809F19E026@mnot.net> In-Reply-To: <059251F7-4598-41BB-869E-65809F19E026@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > > "Incremental" works pretty well there (although it has a lot of > syllables); "sliding" (as suggested by James) also fits, but it is a > bit evocative of time, which I'd like to avoid (despite the use of > 'history' in the document title :-/). > And "incremental" isn't evocative of time ;-) ;-) Either way, It definitely works better than "stateful". - James From owner-atom-syntax@mail.imc.org Mon Aug 29 12:18:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mL6-0001s4-7s for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 12:18:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18966 for ; Mon, 29 Aug 2005 12:18:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGCPo6017473; Mon, 29 Aug 2005 09:12:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TGCPB1017472; Mon, 29 Aug 2005 09:12:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGCOep017461 for ; Mon, 29 Aug 2005 09:12:25 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by xproxy.gmail.com with SMTP id h31so600207wxd for ; Mon, 29 Aug 2005 09:12:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nIbw/YOirivfIEXdVfm8SNxUfwkdoCwiyyUT106al+vld7c8kP0x1Gz/XGlei7e9YybyMjh6R18tzMSb/ToseMUi8659ylvRXnKeN+BBcIBfVBL2oWUFptr+Lie9mmEgliLN2NYx5DZWRAA+yVs5zor/3RsFFCI4ZJ/8nurMr54= Received: by 10.70.62.12 with SMTP id k12mr102128wxa; Mon, 29 Aug 2005 09:12:19 -0700 (PDT) Received: by 10.70.124.6 with HTTP; Mon, 29 Aug 2005 09:12:09 -0700 (PDT) Message-ID: <14be96d3050829091220c2d7d3@mail.gmail.com> Date: Mon, 29 Aug 2005 12:12:09 -0400 From: Mark Pilgrim To: Graham Subject: Re: Don't Aggregrate Me Cc: atom-syntax In-Reply-To: <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> <540e3732050825141448cfbcd7@mail.gmail.com> <14be96d305082611465d157c8@mail.gmail.com> <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7TGCPep017466 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/26/05, Graham wrote: > > (And before you say "but my aggregator is nothing but a podcast > > client, and the feeds are nothing but links to enclosures, so it's > > obvious that the publisher wanted me to download them" -- WRONG! The > > publisher might want that, or they might not ... > > So you're saying browsers should check robots.txt before downloading > images? It's sad that such an inane dodge would even garner any attention at all, much less require a response. http://www.robotstxt.org/wc/faq.html """ What is a WWW robot? A robot is a program that automatically traverses the Web's hypertext structure by retrieving a document, and recursively retrieving all documents that are referenced. Note that "recursive" here doesn't limit the definition to any specific traversal algorithm; even if a robot applies some heuristic to the selection and order of documents to visit and spaces out requests over a long space of time, it is still a robot. Normal Web browsers are not robots, because they are operated by a human, and don't automatically retrieve referenced documents (other than inline images). Web robots are sometimes referred to as Web Wanderers, Web Crawlers, or Spiders. These names are a bit misleading as they give the impression the software itself moves between sites like a virus; this not the case, a robot simply visits sites by requesting documents from them. """ On a more personal note, I would like to thank you for reminding me why there will never be an Atom Implementor's Guide. http://diveintomark.org/archives/2004/08/16/specs -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Mon Aug 29 12:46:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mlo-0007G0-QL for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 12:46:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20244 for ; Mon, 29 Aug 2005 12:46:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGdf5Y019198; Mon, 29 Aug 2005 09:39:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TGdfbd019197; Mon, 29 Aug 2005 09:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGdebn019190 for ; Mon, 29 Aug 2005 09:39:41 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc14) with SMTP id <2005082916393401400smrloe>; Mon, 29 Aug 2005 16:39:34 +0000 Date: Mon, 29 Aug 2005 10:39:33 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <14be96d3050829091220c2d7d3@mail.gmail.com> Message-Id: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 29, 2005, at 10:12 AM, Mark Pilgrim wrote: > On 8/26/05, Graham wrote: >>> (And before you say "but my aggregator is nothing but a podcast >>> client, and the feeds are nothing but links to enclosures, so it's >>> obvious that the publisher wanted me to download them" -- WRONG! The >>> publisher might want that, or they might not ... >> >> So you're saying browsers should check robots.txt before downloading >> images? ... > Normal Web browsers are not robots, because they are operated by a > human, and don't automatically retrieve referenced documents (other > than inline images). As has been suggested, to "inline images", we need to add frame documents, stylesheets, Java applets, external JavaScript code, objects such as Flash files, etc., etc., etc. The question is, with respect to feed readers, do external feed content (), enclosures, etc. fall into the same exceptions category or not? If not, then what's the best mechanism for telling feed readers whether they can download them automatically--robots.txt, another file like robots.txt, or something in the XML? I'd prefer something in the XML. A possibility: ... ... From owner-atom-syntax@mail.imc.org Mon Aug 29 13:00:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mzn-0001RJ-5i for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:00:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21093 for ; Mon, 29 Aug 2005 13:00:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGqgAj019977; Mon, 29 Aug 2005 09:52:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TGqgnw019976; Mon, 29 Aug 2005 09:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TGqfw7019968 for ; Mon, 29 Aug 2005 09:52:42 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-250-63.hsd1.ut.comcast.net[67.169.250.63]) by comcast.net (sccrmhc11) with SMTP id <2005082916523601100llbnme>; Mon, 29 Aug 2005 16:52:36 +0000 Date: Mon, 29 Aug 2005 10:52:34 -0600 Subject: Re: Don't Aggregrate Me Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> Message-Id: <4C468347-18AD-11DA-BDDF-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, August 29, 2005, at 10:39 AM, Antone Roundy wrote: > More robust would be: ...enabling extension elements to be named in @target without requiring a list of @target values to be maintained anywhere. From owner-atom-syntax@mail.imc.org Mon Aug 29 13:22:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nKv-0005SA-3U for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:22:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22021 for ; Mon, 29 Aug 2005 13:22:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7THFxro021929; Mon, 29 Aug 2005 10:15:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7THFx01021928; Mon, 29 Aug 2005 10:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7THFvBH021909 for ; Mon, 29 Aug 2005 10:15:57 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Aug 2005 17:15:51 -0000 Received: from xdsl-81-173-173-191.netcologne.de (EHLO klangraum) [81.173.173.191] by mail.gmx.net (mp033) with SMTP; 29 Aug 2005 19:15:51 +0200 X-Authenticated: #163624 Date: Mon, 29 Aug 2005 19:15:57 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me Message-ID: <20050829171557.GB7501@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> <4C468347-18AD-11DA-BDDF-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C468347-18AD-11DA-BDDF-003065EA6144@geckotribe.com> 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 ietf.org id NAA22021 * Antone Roundy [2005-08-29 19:00]: > More robust would be: > > ...enabling extension elements to be named in @target without > requiring a list of @target values to be maintained anywhere. Is it wise to require either XPath support in consumers or to formulate a hackneyed XPath subset specifically for this purpose? And what about namespaced elements? And what about intermediaries which transcribe the content into a document with different NS prefixes? I think sticking to just an @ext:auto-download attribute applicable to single elements is the wise thing to do. Of course, I wonder if we can=E2=80=99t simply use @xlink:type for the purpose=E2=80=A6 (I admit ignorance of the specifics of XLink, so this idea might be useless.) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 29 13:45:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9nhI-000224-HA for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 13:45:28 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23214 for ; Mon, 29 Aug 2005 13:45:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7THc1cQ024688; Mon, 29 Aug 2005 10:38:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7THc1ra024687; Mon, 29 Aug 2005 10:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7THc1la024659 for ; Mon, 29 Aug 2005 10:38:01 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 1F8F623 for ; Mon, 29 Aug 2005 10:37:56 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7THbokv009426 for ; Mon, 29 Aug 2005 10:37:56 -0700 (PDT) Date: Mon, 29 Aug 2005 10:40:06 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me Message-ID: <9BEDB2A263E5274CDFFAE823@diva.verity.com> In-Reply-To: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> References: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Monday, August 29, 2005 10:39:33 AM -0600 Antone Roundy wrote: > As has been suggested, to "inline images", we need to add frame documents, > stylesheets, Java applets, external JavaScript code, objects such as Flash > files, etc., etc., etc. The question is, with respect to feed readers, do > external feed content (), enclosures, etc. fall into > the same exceptions category or not? Of course a feed reader can read the feed, and anything required to make it readable. Duh. And all this time, I thought robots.txt was simple. robots.txt is a polite hint from the publisher that a robot (not a human) probably should avoid those URLs. Humans can do any stupid thing they want, and probably will. The robots.txt spec is silent on what to do with URLs manually-added to a robot. The normal approach is to deny those, with a message that they are disallowed by robots.txt, and offer some way to override that. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Aug 29 14:15:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oAH-0008FQ-MH for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:15:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24835 for ; Mon, 29 Aug 2005 14:15:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TI9rVk027995; Mon, 29 Aug 2005 11:09:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TI9r2f027994; Mon, 29 Aug 2005 11:09:53 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with SMTP id j7TI9pMP027984 for ; Mon, 29 Aug 2005 11:09:52 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Aug 2005 18:09:45 -0000 Received: from xdsl-81-173-173-191.netcologne.de (EHLO klangraum) [81.173.173.191] by mail.gmx.net (mp009) with SMTP; 29 Aug 2005 20:09:45 +0200 X-Authenticated: #163624 Date: Mon, 29 Aug 2005 20:09:51 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050829180951.GA7721@klangraum> Mail-Followup-To: atom-syntax References: <20050825195942.7E0D17244BD@mail.pubsub.com> <430E2782.7010402@gmail.com> <5BEF213E-8E9D-498D-9B00-C722339F7F4E@bblfish.net> <540e3732050825141448cfbcd7@mail.gmail.com> <14be96d305082611465d157c8@mail.gmail.com> <3F5E8D83-453B-44D8-9F45-FF0746D2626D@mac.com> <14be96d3050829091220c2d7d3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <14be96d3050829091220c2d7d3@mail.gmail.com> 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 ietf.org id OAA24835 * Mark Pilgrim [2005-08-29 18:20]: > On 8/26/05, Graham wrote: > > So you're saying browsers should check robots.txt before > > downloading images? >=20 > It's sad that such an inane dodge would even garner any > attention at all, much less require a response. I=E2=80=99m with you on how robots.txt is to be interpreted, but to a point there is a point to the dodge. F.ex, your example of pointing an enclosure to a large file on a foreign server in order to perform a DoS against it is equally practicable by pointing an to it from a high traffic site. The distinction between what=E2=80=99s inline content and what=E2=80=99s = not really is more arbitrary than inherent. Of course, that=E2=80=99s just splitting hairs, since it doesn=E2=80=99t = actually make a difference to the interpretation. Crawlers generally don=E2=80=99t traverse img/@src references, and the few that do, such as Google=E2=80=99s and Yahoo=E2=80=99s image search services, respect robot= s.txt. Further, aggregation services do not retrieve images referenced in the content of the feeds they consume. So why should they retrieve enclosures? Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 29 14:19:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oEC-0000uX-1S for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 14:19:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25183 for ; Mon, 29 Aug 2005 14:19:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TIEG8Y028486; Mon, 29 Aug 2005 11:14:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TIEGpO028485; Mon, 29 Aug 2005 11:14:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7TIEEsT028472 for ; Mon, 29 Aug 2005 11:14:14 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Aug 2005 18:14:08 -0000 Received: from xdsl-81-173-173-191.netcologne.de (EHLO klangraum) [81.173.173.191] by mail.gmx.net (mp008) with SMTP; 29 Aug 2005 20:14:08 +0200 X-Authenticated: #163624 Date: Mon, 29 Aug 2005 20:14:14 +0200 From: "A. Pagaltzis" To: Eric Scheid Cc: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <20050829181414.GB7721@klangraum> Mail-Followup-To: Eric Scheid , Atom Syntax References: <20050829171557.GB7501@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: * Eric Scheid [2005-08-29 19:55]: > @xlink:type is used to describe the architecture of the links > involved, whether they be 'simple' (from here to somewhere) or > more complicated arrangements (that thing there is linked to > that other thing there, but only one way, but also via some > third thing). It isn't used to control access, and it's not > extensible. Fishing around deeper in my intuitions I find that what I was actually thinking about was the hubub about how XHTML2 would make the inline/external distinction explicit for *all* links (to the point where gets replaced by

). What mechanism is that based on? Could the same thing be reused here? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Aug 29 15:24:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pFW-0000du-JC for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:24:55 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01123 for ; Mon, 29 Aug 2005 15:24:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TJJ8pK036044; Mon, 29 Aug 2005 12:19:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7TJJ8Md036043; Mon, 29 Aug 2005 12:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7TJJ7kf036036 for ; Mon, 29 Aug 2005 12:19:07 -0700 (PDT) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 2AB434EEB7; Mon, 29 Aug 2005 15:19:06 -0400 (EDT) In-Reply-To: <20050826225933.8DDAC72C55D@mail.pubsub.com> References: <20050826225933.8DDAC72C55D@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <6B4128F9-D01B-4406-9FE9-10BD1E1E080C@w3.org> Cc: Atom Syntax From: Karl Dubost Subject: Re: Don't Aggregrate Me Date: Mon, 29 Aug 2005 15:19:12 -0400 To: bobwyman@pubsub.com X-Mailer: Apple Mail (2.733) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7TJJ7kf036038 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 ietf.org id PAA01123 Le 05-08-26 =E0 18:59, Bob Wyman a =E9crit : > Karl, Please, accept my apologies for this. I could have sworn we > had the policy prominently displayed on the site. I know we used to =20 > have it > there. This must have been lost when we did a site redesign last =20 > November! > I'm really surprised that it has taken this long to notice that it =20 > is gone. > I'll see that we get it back up. Thank you very much for your honest answer. Much appreciated. >> You see educating users is not obvious it seems ;) No offense, it >> just shows that it is not an easy accessible information. And >> there's a need to educate Services too. >> > Point taken. I'll get it fixed. It's a weekend now. Give me a few > days... I'm not sure, but I think it makes sense to put this on the > "add-feed" page at: http://www.pubsub.com/add_feed.php . Do you agree? Yes I guess a warning here plus a way of saying to users that they =20 can change their mind later on might be useful. > Yes, forged pings or unauthorized third-party pings are a real > issue. Unfortunately, the current design of the pinging system =20 > gives us > absolutely no means to determine if a ping is authorized by the =20 > publisher. Exact. We will run into Identification problems if we go further, =20 with big privacy issues. > I argued last year that we should develop a blogging or =20 > syndication > architecture document in much the same way that the TAG documented =20 > the web > architecture and in the way that most decent standards groups usually > produce some sort of reference architecture document. Yes I remember that. I remember you talking about it at the New-York =20 meeting, we had in May 2004. > Some solutions, like requiring that pings be "signed" would work > from a technical point of view, but are probably not practical =20 > except in > some limited cases. (e.g. Signatures may make sense as a way to =20 > enable "Fat > Pings" from small or personal blog sites. The thing is that a unique solution will not be enough. I may want to be able - to =93authorize=94 services A, B and C to do things with my conten= t, - but to forbid services X, Y and Z to use my content. Right now it's very hard to do that, except if you are a geek and you =20 can block bots by their IP address and hoping that this IP will not =20 change. It's why I would think that having services respecting =20 license of contents would be a first step. In a service which aggregates the news from different sources. Some =20 of the sources might be licensed for commercial use and some others =20 not at all. Flickr has the start of a very interesting =20 acknowledgement of that somehow. http://www.flickr.com/creativecommons/ * Maybe services like PubSub, Technorati, Bloglines, etc. should =20 display the license in the search results. That would be a first step. * Second step would be to not use the content in a commercial =20 activity if it has been marked as such. (data mining, marketing =20 profile, etc.) --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon Aug 29 21:26:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9utT-000280-VJ for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 21:26:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28575 for ; Mon, 29 Aug 2005 21:26:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U1JYOA093889; Mon, 29 Aug 2005 18:19:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U1JYP4093888; Mon, 29 Aug 2005 18:19:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U1JXou093881 for ; Mon, 29 Aug 2005 18:19:33 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1109621rnf for ; Mon, 29 Aug 2005 18:19:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Csjn64OwV874rvqXlNpWnWgzEuivTP+EMmYjzj9xpDcuTx+3b59PGPAGV4RcTKDskqlypPOpT8Q0NkM3G1F7eRdCVwq3Pd7Pb0wrFYtkt86a0O9s79GSv5dah0iBjez1faMgVCRJ8CoRWC5GiQcneAFzyRUthfoD2e44DXOcvE8= Received: by 10.38.11.62 with SMTP id 62mr45173rnk; Mon, 29 Aug 2005 18:19:33 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 73sm4737283rna.2005.08.29.18.19.32; Mon, 29 Aug 2005 18:19:33 -0700 (PDT) Message-ID: <4313B41C.9010906@gmail.com> Date: Mon, 29 Aug 2005 18:19:24 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" CC: atom-syntax@imc.org Subject: Re: Don't Aggregrate Me References: <7A538B85-18AB-11DA-BDDF-003065EA6144@geckotribe.com> <4C468347-18AD-11DA-BDDF-003065EA6144@geckotribe.com> <20050829171557.GB7501@klangraum> In-Reply-To: <20050829171557.GB7501@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id VAA28575 ??? - James A. Pagaltzis wrote: >* Antone Roundy [2005-08-29 19:00]: > =20 > >>More robust would be: >> >>...enabling extension elements to be named in @target without >>requiring a list of @target values to be maintained anywhere. >> =20 >> > >Is it wise to require either XPath support in consumers or to >formulate a hackneyed XPath subset specifically for this purpose? >And what about namespaced elements? And what about intermediaries >which transcribe the content into a document with different NS >prefixes? > >I think sticking to just an @ext:auto-download attribute >applicable to single elements is the wise thing to do. > >Of course, I wonder if we can=E2=80=99t simply use @xlink:type for the >purpose=E2=80=A6 (I admit ignorance of the specifics of XLink, so this >idea might be useless.) > >Regards, > =20 > From owner-atom-syntax@mail.imc.org Mon Aug 29 21:49:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9vFu-0004r1-N4 for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 21:49:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29483 for ; Mon, 29 Aug 2005 21:49:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U1dfob095179; Mon, 29 Aug 2005 18:39:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U1dfOc095178; Mon, 29 Aug 2005 18:39:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U1db3k095158 for ; Mon, 29 Aug 2005 18:39:40 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 30 Aug 2005 11:40:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 30 Aug 2005 11:39:04 +1000 Subject: Re: Don't Aggregrate Me From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4313B41C.9010906@gmail.com> 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: Content-Transfer-Encoding: 7bit On 30/8/05 11:19 AM, "James M Snell" wrote: > x:follow="no" /> > x:follow="yes" /> > > > Why not an XML version of the HTML robots META tags - so we can also specify NOINDEX, NOARCHIVE as well as NOFOLLOW? Someone wrote up "A Robots Processing Instruction for XML Documents" http://atrus.org/writings/technical/robots_pi/spec-199912__/ That's a PI though, and I have no idea how well supported they are. I'd prefer a namespaced XML vocabulary. e. From owner-atom-syntax@mail.imc.org Mon Aug 29 22:11:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9vac-0003PJ-0C for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 22:11:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00412 for ; Mon, 29 Aug 2005 22:11:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U25IJ2096979; Mon, 29 Aug 2005 19:05:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U25IwO096978; Mon, 29 Aug 2005 19:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U25ILU096969 for ; Mon, 29 Aug 2005 19:05:18 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1116820rnf for ; Mon, 29 Aug 2005 19:05:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=imECeAepj2L9o5kPBleQe6ZtW3SqZNyHGIKC5LRkydVc6PrPftb24nYQcN/M+UG6tlqvabBsNnVHMoR/TchKra2eFaSgL302YJy0bHEXiYYgELLEKFc9RKdgLDNH1QNXFxDORy+Vhtl2MZeFGTKA/ehydpWo1eKgeVLCKcvhdso= Received: by 10.38.101.25 with SMTP id y25mr63998rnb; Mon, 29 Aug 2005 19:05:17 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id z1sm7866662rne.2005.08.29.19.05.17; Mon, 29 Aug 2005 19:05:17 -0700 (PDT) Message-ID: <4313BED5.2010506@gmail.com> Date: Mon, 29 Aug 2005 19:05:09 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Don't Aggregrate Me References: In-Reply-To: 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: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 30/8/05 11:19 AM, "James M Snell" wrote: > > > >>>x:follow="no" /> >>>x:follow="yes" /> >> >> >> >> >> > >Why not an XML version of the HTML robots META tags - so we can also specify >NOINDEX, NOARCHIVE as well as NOFOLLOW? > >Someone wrote up "A Robots Processing Instruction for XML Documents" > http://atrus.org/writings/technical/robots_pi/spec-199912__/ >That's a PI though, and I have no idea how well supported they are. I'd >prefer a namespaced XML vocabulary. > > >e. > > > > That's kinda where I was going with x:follow="no|yes". An x:archive="no|yes" would also make some sense but could also be handled with HTTP caching (e.g. set the referenced content to expire immediately). x:index="no|yes" doesn't seem to make a lot of sense in this case. x:follow="no|yes" seems to me to be the only one that makes a lot of sense. - James From owner-atom-syntax@mail.imc.org Mon Aug 29 22:52:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wED-0003ge-MO for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 22:52:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02215 for ; Mon, 29 Aug 2005 22:51:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U2j1iu001714; Mon, 29 Aug 2005 19:45:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U2j1k6001713; Mon, 29 Aug 2005 19:45:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U2j06G001704 for ; Mon, 29 Aug 2005 19:45:00 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 30 Aug 2005 12:46:06 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 30 Aug 2005 12:44:59 +1000 Subject: Re: Don't Aggregrate Me From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4313BED5.2010506@gmail.com> 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: Content-Transfer-Encoding: 7bit On 30/8/05 12:05 PM, "James M Snell" wrote: > That's kinda where I was going with x:follow="no|yes". An > x:archive="no|yes" would also make some sense but could also be handled > with HTTP caching (e.g. set the referenced content to expire > immediately). x:index="no|yes" doesn't seem to make a lot of sense in > this case. x:follow="no|yes" seems to me to be the only one that makes > a lot of sense. x:index could be used to prevent purely ephemeral dross cluttering up the uber-aggregators. A feed which gives minute by minute weather data for example. robots NOARCHIVE is used by search engines, particularly google, to control whether they present a 'cached' page, which seems sensible. e. From owner-atom-syntax@mail.imc.org Mon Aug 29 23:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9x6N-00018D-IF for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 23:47:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04463 for ; Mon, 29 Aug 2005 23:47:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U3fsCT007480; Mon, 29 Aug 2005 20:41:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U3fs3W007479; Mon, 29 Aug 2005 20:41:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U3frkL007468 for ; Mon, 29 Aug 2005 20:41:53 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 51BD35A for ; Mon, 29 Aug 2005 20:41:48 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7U3flkv017429 for ; Mon, 29 Aug 2005 20:41:47 -0700 (PDT) Date: Mon, 29 Aug 2005 20:41:56 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 30, 2005 11:39:04 AM +1000 Eric Scheid wrote: > > Someone wrote up "A Robots Processing Instruction for XML Documents" > http://atrus.org/writings/technical/robots_pi/spec-199912__/ > That's a PI though, and I have no idea how well supported they are. I'd > prefer a namespaced XML vocabulary. That was me. I think it makes perfect sense as a PI. But I think reuse via namespaces is oversold. For example, we didn't even try to use Dublin Core tags in Atom. PI support is required by the XML spec -- "must be passed to the application." wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Mon Aug 29 23:55:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xDu-0003dS-Ep for atompub-archive@megatron.ietf.org; Mon, 29 Aug 2005 23:55:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04625 for ; Mon, 29 Aug 2005 23:55:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U3oiS8008316; Mon, 29 Aug 2005 20:50:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U3oibH008315; Mon, 29 Aug 2005 20:50:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U3ohe7008308 for ; Mon, 29 Aug 2005 20:50:43 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id BC5A75A; Mon, 29 Aug 2005 20:50:38 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7U3obkv017549; Mon, 29 Aug 2005 20:50:37 -0700 (PDT) Date: Mon, 29 Aug 2005 20:50:46 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Don't Aggregrate Me Message-ID: <33BCD2B8AC0F5A1B34AA3028@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <4313BED5.2010506@gmail.com> References: <4313BED5.2010506@gmail.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 29, 2005 7:05:09 PM -0700 James M Snell wrote: > x:index="no|yes" doesn't seem to make a lot of sense in this case. It makes just as much sense as it does for HTML files. Maybe it is a whole group of Atom test cases. Maybe it is a feed of reboot times for the server. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 30 00:14:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xVh-00005I-4F for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 00:14:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05357 for ; Tue, 30 Aug 2005 00:14:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U484kN010288; Mon, 29 Aug 2005 21:08:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U4845A010287; Mon, 29 Aug 2005 21:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U483FJ010269 for ; Mon, 29 Aug 2005 21:08:03 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so609396nzi for ; Mon, 29 Aug 2005 21:07:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V5swZ5sVdOo+5xF21szyCFF+tIPlOihokQRYjVajx8yIyJwLcdBi/xJxBm+Y0x4JaPeVVbkApyxkgpzBkv+KQBlhjeArPYr9uctCnCBJVQmOhHlakBNtDcCGlFeCPK/zT0/k4dhST0cQdY4ou6VqS54FSu16NBGkl/MSDfRta54= Received: by 10.36.74.20 with SMTP id w20mr1402178nza; Mon, 29 Aug 2005 21:07:58 -0700 (PDT) Received: by 10.36.65.8 with HTTP; Mon, 29 Aug 2005 21:07:58 -0700 (PDT) Message-ID: <3f1451f505082921077dfed1f7@mail.gmail.com> Date: Tue, 30 Aug 2005 00:07:58 -0400 From: Joe Gregorio To: Walter Underwood Subject: Re: Don't Aggregrate Me Cc: Atom Syntax In-Reply-To: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7U483FJ010281 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/29/05, Walter Underwood wrote: > That was me. I think it makes perfect sense as a PI. But I think reuse > via namespaces is oversold. For example, we didn't even try to use > Dublin Core tags in Atom. Speak for yourself :) http://bitworking.org/news/Not_Invented_Here -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue Aug 30 00:45:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xzk-0005qK-R1 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 00:45:13 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06425 for ; Tue, 30 Aug 2005 00:45:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U4bao2013295; Mon, 29 Aug 2005 21:37:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U4bato013294; Mon, 29 Aug 2005 21:37:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U4baXD013285 for ; Mon, 29 Aug 2005 21:37:36 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i35so777204wra for ; Mon, 29 Aug 2005 21:37:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=peb4l3NTPsXAvQ0znwHag3Sgfn4pOAPeE3sujjFde4JvEWq5rgAudsrigIkkWAGdUw+bd+/8dgIZ6FiHW38UrAhiGmGq6cLhenwJ/92ahAD2XhTQXFSRXlDCe68Zqv3bUaFd+i26xKxh2lEZaCSMGZCv+acMccrbmHRN5b4Flno= Received: by 10.54.111.11 with SMTP id j11mr6881806wrc; Mon, 29 Aug 2005 21:37:30 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 26sm12161154wrl.2005.08.29.21.37.29; Mon, 29 Aug 2005 21:37:30 -0700 (PDT) Message-ID: <4313E281.1040908@gmail.com> Date: Mon, 29 Aug 2005 21:37:21 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Don't Aggregrate Me References: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: >--On August 30, 2005 11:39:04 AM +1000 Eric Scheid wrote: > > >>Someone wrote up "A Robots Processing Instruction for XML Documents" >> http://atrus.org/writings/technical/robots_pi/spec-199912__/ >>That's a PI though, and I have no idea how well supported they are. I'd >>prefer a namespaced XML vocabulary. >> >> > >That was me. I think it makes perfect sense as a PI. But I think reuse >via namespaces is oversold. For example, we didn't even try to use >Dublin Core tags in Atom. > >PI support is required by the XML spec -- "must be passed to the >application." > > > The challenge here is that there is nothing which requires that PI's be persisted by the application. In other words, should an aggregator like pubsub.com preserve PI's in an Atom document when it aggregates entries on to end consumers? Where should the PI go? If an aggregator pulls in multple entries from multiple feeds, what should it do if those feeds have different nofollow, noindex and noarchive PI's? Also, is the PI reflective of the document in which they appear or the content that is linked to by the document? e.g. is it the atom:entry that shouldn't be indexed or the link href that shouldn't be indexed or both... or does putting the PI on the document level have a different meaning that putting it on the link level? etc etc Having x:index="yes|no", x:archive="yes|no", x:follow="yes|no" attributes on the link and content elements provides a very simple mechanism that a) fits within the existing defined Atom extensibility model and b) is unambiguous in it's meaning. It also allows us to include atom:entry elements within SOAP Envelopes which are not allowed to carry processing instructions. -1 to using PI's for this. Let's not introduce a third way of extending Atom... with appologies to Monty Python: "There are TWO ways of extending Atom.... link relations and namespaces... and PI's... There are THREE ways of extending Atom......" - James From owner-atom-syntax@mail.imc.org Tue Aug 30 01:58:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9z96-0004YB-UF for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 01:58:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08912 for ; Tue, 30 Aug 2005 01:58:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U5oDvu018541; Mon, 29 Aug 2005 22:50:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7U5oD9j018540; Mon, 29 Aug 2005 22:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7U5oC8Z018533 for ; Mon, 29 Aug 2005 22:50:13 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from BOBSLAPTOP (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 290F672410D for ; Tue, 30 Aug 2005 01:50:03 -0400 (EDT) Reply-To: From: "Bob Wyman" To: Subject: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 01:49:57 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C5AD05.2034A550" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcWtJqcKieid6a/GSNCJgDTwfX07sA== Message-Id: <20050830055003.290F672410D@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C5AD05.2034A550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm sorry, but I can't go on without complaining. Microsoft has proposed extensions which turn RSS V2.0 feeds into lists and we've got folk who are proposing much the same for Atom (i.e. stateful, incremental or partitioned feeds). I think they are wrong. Feeds aren't lists and Lists aren't feeds. It seems to me that if you want a "Top 10" list, then you should simply create an entry that provides your Top 10. Then, insert that entry in your feed so that the rest of us can read it. If you update the list, then just replace the entry in your feed. If you create a new list (Top 34?) then insert that in the feed along with the "Top10" list. What is the problem? Why don't folk see that lists are the stuff of entries - not feeds? Remember, "It's about the entries, Stupid." I think the reason we've got this pull to turn feeds into Lists is simply because we don't have a commonly accepted "list" schema. So, the idea is to repurpose what we've got. Folk are too scared or tired to try to get a new thing defined and through the process, so they figure that they will just overload the definition of something that already exists. I think that's wrong. If we want "Lists" then we should define lists and not muck about with Atom. If everyone is too tired to do the job properly and define a real list as a well defined schema for something that can be the payload of a content element, then why not just use OPML as the list format? What is a search engine or a matching engine supposed to return as a result if it find a match for a user query in an entry that comes from a list-feed? Should it return the entire feed or should it return just the entry/item that contained the stuff in the users' query? What should an aggregating intermediary like PubSub do when it finds a match in an element of a list-feed? Is there some way to return an entire feed without building a feed of feeds? Given that no existing aggregator supports feeds as entries, how can an intermediary aggregator/filter return something the client will understand? You might say that the search/matching engine should only present the matching entry in its results. But, if you do that what happens is that you lose the important semantic data that comes from knowing the position the matched entry had in the original list-feed. There is no way to preserve that order-dependence information without private extensions at present. I'm sorry but I simply can't see that it makes sense to encourage folk to break important rules of Atom by redefining feeds to be lists. If we want "lists" we should define what they look like and put them in entries. Keep your hands off the feeds. Feeds aren't lists - they are feeds. bob wyman ------=_NextPart_000_0067_01C5AD05.2034A550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sorry, but I = can’t go on without complaining.  Microsoft has proposed extensions which = turn RSS V2.0 feeds into lists and we’ve got folk who are proposing = much the same for Atom (i.e. stateful, incremental or partitioned feeds)… I = think they are wrong. Feeds aren’t lists and Lists aren’t feeds. = It seems to me that if you want a “Top 10” list, then you should = simply create an entry that provides your Top 10. Then, insert that entry in = your feed so that the rest of us can read it. If you update the list, then just = replace the entry in your feed. If you create a new list (Top 34?) then insert = that in the feed along with the “Top10” list. =

What is the problem? Why = don’t folk see that lists are the stuff of entries – not feeds? = Remember, “It’s about the entries, Stupid…”

I think the reason = we’ve got this pull to turn feeds into Lists is simply because we don’t have = a commonly accepted “list” schema. So, the idea is to = repurpose what we’ve got. Folk are too scared or tired to try to get a new thing = defined and through the process, so they figure that they will just overload the definition of something that already exists. I think that’s wrong. = If we want “Lists” then we should define lists and not muck about with = Atom. If everyone is too tired to do the job properly and define a real list = as a well defined schema for something that can be the payload of a content = element, then why not just use OPML as the list = format?

 

What is a search engine or = a matching engine supposed to return as a result if it find a match for a = user query in an entry that comes from a list-feed? Should it return the = entire feed or should it return just the entry/item that contained the stuff in the = users’ query? What should an aggregating intermediary like PubSub do when it = finds a match in an element of a list-feed? Is there some way to return an = entire feed without building a feed of feeds? Given that no existing aggregator = supports feeds as entries, how can an intermediary aggregator/filter return = something the client will understand?

You might say that the search/matching engine should only present the matching entry in its = results. But, if you do that what happens is that you lose the important semantic = data that comes from knowing the position the matched entry had in the = original list-feed. There is no way to preserve that order-dependence information = without private extensions at present.

I’m sorry but I = simply can’t see that it makes sense to encourage folk to break important rules of = Atom by redefining feeds to be lists. If we want “lists” we should = define what they look like and put them in entries. Keep your hands off the = feeds. Feeds aren’t lists – they are = feeds.

 

    &nbs= p;       bob wyman

 

 

------=_NextPart_000_0067_01C5AD05.2034A550-- From owner-atom-syntax@mail.imc.org Tue Aug 30 07:00:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA3rM-0002ek-8G for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 07:00:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04803 for ; Tue, 30 Aug 2005 07:00:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UAqjKq050148; Tue, 30 Aug 2005 03:52:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UAqjJY050147; Tue, 30 Aug 2005 03:52:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UAqifG050141 for ; Tue, 30 Aug 2005 03:52:44 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 6909 invoked by uid 17064); 30 Aug 2005 10:52:44 -0000 Received: from unknown (HELO [192.168.1.40]) ([62.203.1.95]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 30 Aug 2005 10:52:44 -0000 In-Reply-To: <20050830055003.290F672410D@mail.pubsub.com> References: <20050830055003.290F672410D@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Cc: From: Henry Story Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 12:52:41 +0200 To: X-Mailer: Apple Mail (2.734) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7UAqifG050142 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 ietf.org id HAA04803 +1 I completely agree with Bob again. Though my preference of course would be to put RDF in the content. RDF has structures for ordered lists. It probably has vocabularies =20 for songs. It has vocabulary to specify the author of a work, etc... And with =20 foaf you could also specify which of the artists was your friend. In short you =20 can mix the different RDF vocabularies out there in well understood ways. For those of you new to RDF but au fait with Java, I have just =20 written up a blog that should help explain exactly why RDF is so powerful: http://blogs.sun.com/roller/page/bblfish?=20 entry=3Djava_annotations_the_semantic_web In short: RDF can be mapped directly onto Java Beans. Just as Beans =20 can be plugged together, so RDF markup can be plugged together. Welcome to the world =20 of OO xml. Henry Story On 30 Aug 2005, at 07:49, Bob Wyman wrote: > I=92m sorry, but I can=92t go on without complaining. Microsoft has =20 > proposed extensions which turn RSS V2.0 feeds into lists and we=92ve =20 > got folk who are proposing much the same for Atom (i.e. stateful, =20 > incremental or partitioned feeds)=85 I think they are wrong. Feeds =20 > aren=92t lists and Lists aren=92t feeds. It seems to me that if you =20 > want a =93Top 10=94 list, then you should simply create an entry that =20 > provides your Top 10. Then, insert that entry in your feed so that =20 > the rest of us can read it. If you update the list, then just =20 > replace the entry in your feed. If you create a new list (Top 34?) =20 > then insert that in the feed along with the =93Top10=94 list. > > What is the problem? Why don=92t folk see that lists are the stuff of =20 > entries =96 not feeds? Remember, =93It=92s about the entries, Stupid=85= =94 > > I think the reason we=92ve got this pull to turn feeds into Lists is =20 > simply because we don=92t have a commonly accepted =93list=94 schema. S= o, =20 > the idea is to repurpose what we=92ve got. Folk are too scared or =20 > tired to try to get a new thing defined and through the process, so =20 > they figure that they will just overload the definition of =20 > something that already exists. I think that=92s wrong. If we want =20 > =93Lists=94 then we should define lists and not muck about with Atom. =20 > If everyone is too tired to do the job properly and define a real =20 > list as a well defined schema for something that can be the payload =20 > of a content element, then why not just use OPML as the list format? > > > > What is a search engine or a matching engine supposed to return as =20 > a result if it find a match for a user query in an entry that comes =20 > from a list-feed? Should it return the entire feed or should it =20 > return just the entry/item that contained the stuff in the users=92 =20 > query? What should an aggregating intermediary like PubSub do when =20 > it finds a match in an element of a list-feed? Is there some way to =20 > return an entire feed without building a feed of feeds? Given that =20 > no existing aggregator supports feeds as entries, how can an =20 > intermediary aggregator/filter return something the client will =20 > understand? > > You might say that the search/matching engine should only present =20 > the matching entry in its results. But, if you do that what happens =20 > is that you lose the important semantic data that comes from =20 > knowing the position the matched entry had in the original list-=20 > feed. There is no way to preserve that order-dependence information =20 > without private extensions at present. > > I=92m sorry but I simply can=92t see that it makes sense to encourage =20 > folk to break important rules of Atom by redefining feeds to be =20 > lists. If we want =93lists=94 we should define what they look like and = =20 > put them in entries. Keep your hands off the feeds. Feeds aren=92t =20 > lists =96 they are feeds. > > > > bob wyman > > > > > > From owner-atom-syntax@mail.imc.org Tue Aug 30 07:31:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA4Kv-00032l-3z for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 07:31:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06689 for ; Tue, 30 Aug 2005 07:31:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UBNVSQ053790; Tue, 30 Aug 2005 04:23:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UBNVhM053789; Tue, 30 Aug 2005 04:23:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UBNVil053783 for ; Tue, 30 Aug 2005 04:23:31 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout08/MantshX 4.0) with ESMTP id j7UBNZ5m027424; Tue, 30 Aug 2005 04:23:35 -0700 (PDT) Received: from [10.0.0.9] (host-83-146-12-185.bulldogdsl.com [83.146.12.185]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j7UBNRm2009698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Aug 2005 04:23:30 -0700 (PDT) In-Reply-To: <20050830055003.290F672410D@mail.pubsub.com> References: <20050830055003.290F672410D@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E793DC8-3AF2-4AAC-817D-AD30D0B65659@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 12:23:23 +0100 To: bobwyman@pubsub.com X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit How would this apply to the most problematic example of a list feed, the BBC news headline page: http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml Which has the top stories first (amongst other structure) and is a hell of a lot more usable in news readers that preserve order. Graham From owner-atom-syntax@mail.imc.org Tue Aug 30 08:30:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA5G7-0000tX-4G for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 08:30:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09516 for ; Tue, 30 Aug 2005 08:30:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UCLI5u058551; Tue, 30 Aug 2005 05:21:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UCLIn1058550; Tue, 30 Aug 2005 05:21:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UCLIxM058544 for ; Tue, 30 Aug 2005 05:21:18 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 52066 invoked by uid 17064); 30 Aug 2005 12:21:18 -0000 Received: from unknown (HELO [192.168.1.40]) ([62.203.1.95]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 30 Aug 2005 12:21:18 -0000 In-Reply-To: <3E793DC8-3AF2-4AAC-817D-AD30D0B65659@mac.com> References: <20050830055003.290F672410D@mail.pubsub.com> <3E793DC8-3AF2-4AAC-817D-AD30D0B65659@mac.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24942DFB-7864-4953-BBC3-06CCC5F71C82@bblfish.net> Cc: bobwyman@pubsub.com, Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 14:21:15 +0200 To: Graham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mhh. Good point too. For some reason though, this is starting to make me think that a feed is an entry again... Henry On 30 Aug 2005, at 13:23, Graham wrote: > > How would this apply to the most problematic example of a list > feed, the BBC news headline page: > > http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml > > Which has the top stories first (amongst other structure) and is a > hell of a lot more usable in news readers that preserve order. > > Graham > From owner-atom-syntax@mail.imc.org Tue Aug 30 16:11:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACSF-0005b5-Fz for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 16:11:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07816 for ; Tue, 30 Aug 2005 16:11:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UK24D4008832; Tue, 30 Aug 2005 13:02:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UK246P008831; Tue, 30 Aug 2005 13:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UK23DQ008825 for ; Tue, 30 Aug 2005 13:02:04 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.163.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id B7B1EA32D0; Tue, 30 Aug 2005 16:02:02 -0400 (EDT) In-Reply-To: <20050830055003.290F672410D@mail.pubsub.com> References: <20050830055003.290F672410D@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> Cc: X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 13:01:57 -0700 To: X-Mailer: Apple Mail (2.734) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7UK24DQ008826 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 ietf.org id QAA07816 Sorry, Bob I disagree. I tried to introduce a rigid concept of what a =20 feed is much earlier, and people pushed back; as a result, Atom =20 doesn't have a firm definition of the nature of a feed. As a result, =20 we can't go and say what it can't be at a later date. Besides which, I think the use cases for Atom-as-list are powerful, =20 and just beginning to be seen. E.g., Netflix allows you to subscribe =20 to your Queue: http://www.netflix.com/RSSFeeds Are you saying that when/if Netflix switches over to Atom, they =20 shouldn't use it for the Queue? It sounds like you've got use cases for Atom that other use cases =20 (e.g., lists) make difficult to work with. Banning those other use =20 cases makes things easier for you, but I don't think it's good for =20 Atom overall. Cheers, On 29/08/2005, at 10:49 PM, Bob Wyman wrote: > I=92m sorry, but I can=92t go on without complaining. Microsoft has =20 > proposed extensions which turn RSS V2.0 feeds into lists and we=92ve =20 > got folk who are proposing much the same for Atom (i.e. stateful, =20 > incremental or partitioned feeds)=85 I think they are wrong. Feeds =20 > aren=92t lists and Lists aren=92t feeds. It seems to me that if you =20 > want a =93Top 10=94 list, then you should simply create an entry that =20 > provides your Top 10. Then, insert that entry in your feed so that =20 > the rest of us can read it. If you update the list, then just =20 > replace the entry in your feed. If you create a new list (Top 34?) =20 > then insert that in the feed along with the =93Top10=94 list. > > What is the problem? Why don=92t folk see that lists are the stuff of =20 > entries =96 not feeds? Remember, =93It=92s about the entries, Stupid=85= =94 > > I think the reason we=92ve got this pull to turn feeds into Lists is =20 > simply because we don=92t have a commonly accepted =93list=94 schema. S= o, =20 > the idea is to repurpose what we=92ve got. Folk are too scared or =20 > tired to try to get a new thing defined and through the process, so =20 > they figure that they will just overload the definition of =20 > something that already exists. I think that=92s wrong. If we want =20 > =93Lists=94 then we should define lists and not muck about with Atom. =20 > If everyone is too tired to do the job properly and define a real =20 > list as a well defined schema for something that can be the payload =20 > of a content element, then why not just use OPML as the list format? > > > > What is a search engine or a matching engine supposed to return as =20 > a result if it find a match for a user query in an entry that comes =20 > from a list-feed? Should it return the entire feed or should it =20 > return just the entry/item that contained the stuff in the users=92 =20 > query? What should an aggregating intermediary like PubSub do when =20 > it finds a match in an element of a list-feed? Is there some way to =20 > return an entire feed without building a feed of feeds? Given that =20 > no existing aggregator supports feeds as entries, how can an =20 > intermediary aggregator/filter return something the client will =20 > understand? > > You might say that the search/matching engine should only present =20 > the matching entry in its results. But, if you do that what happens =20 > is that you lose the important semantic data that comes from =20 > knowing the position the matched entry had in the original list-=20 > feed. There is no way to preserve that order-dependence information =20 > without private extensions at present. > > I=92m sorry but I simply can=92t see that it makes sense to encourage =20 > folk to break important rules of Atom by redefining feeds to be =20 > lists. If we want =93lists=94 we should define what they look like and = =20 > put them in entries. Keep your hands off the feeds. Feeds aren=92t =20 > lists =96 they are feeds. > > > > bob wyman > > > > > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 30 16:15:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EACVe-0006xa-6a for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 16:15:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08021 for ; Tue, 30 Aug 2005 16:15:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UKAR7J009403; Tue, 30 Aug 2005 13:10:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UKARgk009402; Tue, 30 Aug 2005 13:10:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UKAQKE009394 for ; Tue, 30 Aug 2005 13:10:27 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i32so856415wra for ; Tue, 30 Aug 2005 13:10:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dONby5zOxpxEPWn0zFVgjOhgUpMBB4liSVIQMySOQMo0lWHykKS5Rr/75tWhGab9iJvMCKCYOsioegj/p7ZWh1ueEt6Uc9Xz92ImPdEtKM+KFpGUaBJIZTpEVMsbFeKmkxaHCaYzqPwpJ9ZHl2t+G8av/DiTSg3ccp2VBqzX6dU= Received: by 10.54.144.8 with SMTP id r8mr4165013wrd; Tue, 30 Aug 2005 13:10:21 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id d7sm8152961wra.2005.08.30.13.10.20; Tue, 30 Aug 2005 13:10:21 -0700 (PDT) Message-ID: <4314BD24.406@gmail.com> Date: Tue, 30 Aug 2005 13:10:12 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: bobwyman@pubsub.com, atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. References: <20050830055003.290F672410D@mail.pubsub.com> <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> In-Reply-To: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > Sorry, Bob I disagree. I tried to introduce a rigid concept of what a > feed is much earlier, and people pushed back; as a result, Atom > doesn't have a firm definition of the nature of a feed. As a result, > we can't go and say what it can't be at a later date. > > Besides which, I think the use cases for Atom-as-list are powerful, > and just beginning to be seen. E.g., Netflix allows you to subscribe > to your Queue: > http://www.netflix.com/RSSFeeds > > Are you saying that when/if Netflix switches over to Atom, they > shouldn't use it for the Queue? > > It sounds like you've got use cases for Atom that other use cases > (e.g., lists) make difficult to work with. Banning those other use > cases makes things easier for you, but I don't think it's good for > Atom overall. +1 on every point. - James From owner-atom-syntax@mail.imc.org Tue Aug 30 17:10:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADNf-0004yq-TY for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:10:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09924 for ; Tue, 30 Aug 2005 17:10:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UL4Abk013269; Tue, 30 Aug 2005 14:04:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UL4AwS013268; Tue, 30 Aug 2005 14:04:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UL49dU013262 for ; Tue, 30 Aug 2005 14:04:09 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout09/MantshX 4.0) with ESMTP id j7UL49a5013586; Tue, 30 Aug 2005 14:04:09 -0700 (PDT) Received: from [10.0.0.9] (host-83-146-12-185.bulldogdsl.com [83.146.12.185]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j7UL464C003797 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Aug 2005 14:04:08 -0700 (PDT) In-Reply-To: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> References: <20050830055003.290F672410D@mail.pubsub.com> <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 22:04:02 +0100 To: Mark Nottingham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Aug 2005, at 9:01 pm, Mark Nottingham wrote: > It sounds like you've got use cases for Atom that other use cases > (e.g., lists) make difficult to work with. Banning those other use > cases makes things easier for you, but I don't think it's good for > Atom overall. But conceptually Bob is absolutely correct. An ordered list is just an entry that gets updated regularly. There's absolutely no reason for Netflix to create an individual entry for each DVD. It's a hack that makes it look better in most aggregators. Nothing more. It would be good if Atom were flexible enough to cope where there isn't a 1:1 mapping between publications and items of information, by subdividing entries into chapters or something, but as Mark Pilgrim said somewhere, Atom deals with none of the interesting problems with syndication (Atom = RSS3). Graham From owner-atom-syntax@mail.imc.org Tue Aug 30 17:17:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADTj-0006bs-H7 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:17:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10195 for ; Tue, 30 Aug 2005 17:17:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULA4u9013997; Tue, 30 Aug 2005 14:10:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ULA4qq013996; Tue, 30 Aug 2005 14:10:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [69.90.230.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULA3RV013981 for ; Tue, 30 Aug 2005 14:10:03 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 2DB257244B5; Tue, 30 Aug 2005 17:09:57 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Mark Nottingham'" Cc: Subject: RE: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 17:09:55 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcWtnbDxg0ZH+ujKShuWH8M3SHD1QwACBQRA Message-Id: <20050830210957.2DB257244B5@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: >Are you saying that when/if Netflix switches over to Atom, they > shouldn't use it for the Queue? No. I'm saying that if Netflix switches over to Atom, what they should do is insert the Queue information, as a list, into a single entry within the feed. This will not only preserve the nature of Atom feeds as "feeds" but also allow NetFlix a number of new and potentially interesting opportunities for providing data to customers. Most important among these will be the ability to include multiple lists in the feed (i.e. in addition to the Queue, they could also include their "Top 10" list as well as a set of "recommendations" based on user experience. They might even include a list of "10 most recent transactions on your account") Each list would be a distinct entry. To make life easier on aggregators, each entry "type" should probably use the same atom:id across "versions." This allows the aggregators to discard earlier, now out of date entries. NetFlix would also be able to intermix information such as the "Queue List" with non-list entries. For instance, they might have a "Message from NetFlix" that they want to include in the feed or, they might include a series of movie reviews that were carefully selected for the specific user. Basically, by using entries for lists instead of converting the entire feed into a list, NetFlix is able to offer a much richer and much more satisfying experience to their users. The ability of Atom to carry both lists and non-lists as entries means that Atom is able to offer a much more flexible and powerful mechanism to NetFlix than can be had from the less-capable RSS V2.0 solution. I think that if I were NetFlix, I would want to have the opportunity to experiment with and find ways to exploit this powerful capability. The richer the opportunity for communications between NetFlix and their customers, the greater the opportunity they have to generate revenues. The alternative to using entries rather than feeds would be creating multiple feeds per user. That strikes me as a solution which is ugly on its face and unquestionably increases the complexity of the system for both NetFlix and its customers. The "list-in-entry" solution is much more elegant and much more powerful. bob wyman From owner-atom-syntax@mail.imc.org Tue Aug 30 17:41:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADr2-0005PG-C9 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:41:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11084 for ; Tue, 30 Aug 2005 17:41:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULZefO016165; Tue, 30 Aug 2005 14:35:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ULZevb016164; Tue, 30 Aug 2005 14:35:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULZdvf016150 for ; Tue, 30 Aug 2005 14:35:40 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.6.171.35]) by smtp.cegetel.net (Postfix) with ESMTP id 319041A40DE; Tue, 30 Aug 2005 23:35:34 +0200 (CEST) Message-ID: <4314D126.4060507@cegetel.net> Date: Tue, 30 Aug 2005 23:35:34 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050712) MIME-Version: 1.0 To: bobwyman@pubsub.com Cc: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. References: <20050830055003.290F672410D@mail.pubsub.com> In-Reply-To: <20050830055003.290F672410D@mail.pubsub.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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 ietf.org id RAA11084 Bob Wyman wrote: > > I=92m sorry, but I can=92t go on without complaining. Microsoft has=20 > proposed extensions which turn RSS V2.0 feeds into lists and we=92ve go= t=20 > folk who are proposing much the same for Atom (i.e. stateful,=20 > incremental or partitioned feeds)=85 I think they are wrong. Feeds=20 > aren=92t lists and Lists aren=92t feeds. It seems to me that if you wan= t a=20 > =93Top 10=94 list, then you should simply create an entry that provides= =20 > your Top 10. Then, insert that entry in your feed so that the rest of=20 > us can read it. If you update the list, then just replace the entry in=20 > your feed. If you create a new list (Top 34?) then insert that in the=20 > feed along with the =93Top10=94 list. > Henry Story also proposed atom:id to be "order-related": ... tag:first-in-list Some entry ... tag:second-in-list Another entry ... and a bit later: ... tag:first-in-list Another entry ... tag:second-in-list Yet another entry ... Note how tag:first-in-list entry now represents "Another entry" while it=20 were previously "Some entry", and tag:second-in-list now is "Yet another=20 entry" while it were "Another entry". --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Aug 30 17:46:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADwW-0007Ud-3O for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:46:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11247 for ; Tue, 30 Aug 2005 17:46:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULfX6t016573; Tue, 30 Aug 2005 14:41:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ULfXwv016572; Tue, 30 Aug 2005 14:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULfWKe016559 for ; Tue, 30 Aug 2005 14:41:32 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id BE4824C; Tue, 30 Aug 2005 14:41:27 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7ULfQkv001409; Tue, 30 Aug 2005 14:41:27 -0700 (PDT) Date: Tue, 30 Aug 2005 14:41:37 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. Message-ID: In-Reply-To: <20050830055003.290F672410D@mail.pubsub.com> References: <20050830055003.290F672410D@mail.pubsub.com> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7ULfWKe016566 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 ietf.org id RAA11247 --On August 30, 2005 1:49:57 AM -0400 Bob Wyman wro= te: > I=E2=80=99m sorry, but I can=E2=80=99t go on without complaining. Micr= osoft has proposed > extensions which turn RSS V2.0 feeds into lists and we=E2=80=99ve got f= olk who are > proposing much the same for Atom (i.e. stateful, incremental or partiti= oned > feeds)=E2=80=A6 I think they are wrong. Feeds aren=E2=80=99t lists and = Lists aren=E2=80=99t feeds. The Atom spec says: This specification assigns no significance to the order of atom:entry elements within the feed. One could read that to mean that feeds are fundamentally unordered or tha= t Atom doesn't say what the order means. Other RSS formats are ordered, either implicitly or explicity (RSS 1.0). For interoperatility, lots of software is going to treat Atom as ordered. Otherwise, it is not possible to go from Atom to RSS 1.0. > What is a search engine or a matching engine supposed to return as a re= sul > if it find a match for a user query in an entry that comes from a list= -feed? Maybe the list feed should have a noindex flag. > Should it return the entire feed or should it return just the entry/ite= m > that contained the stuff in the users=E2=80=99 query? I'd return the entry. It is all about the entries. If the list position i= s semantically important to the entry, then include a link from the entry t= o the list. "This is movie 312 in wunder's queue." wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 30 17:54:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAE3r-00018l-Vc for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:54:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11607 for ; Tue, 30 Aug 2005 17:54:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULoW9L017434; Tue, 30 Aug 2005 14:50:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7ULoWvL017433; Tue, 30 Aug 2005 14:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7ULoV6a017418 for ; Tue, 30 Aug 2005 14:50:31 -0700 (PDT) (envelope-from stpeter@jabber.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 12B754478D9 for ; Tue, 30 Aug 2005 15:50:46 -0600 (MDT) Message-ID: <4314D4B5.9050204@jabber.org> Date: Tue, 30 Aug 2005 15:50:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. References: <20050830055003.290F672410D@mail.pubsub.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080608080307080100090700" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms080608080307080100090700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Walter Underwood wrote: > --On August 30, 2005 1:49:57 AM -0400 Bob Wyman wrote: > > >>I’m sorry, but I can’t go on without complaining. Microsoft has proposed >>extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are >>proposing much the same for Atom (i.e. stateful, incremental or partitioned >>feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds. > > > The Atom spec says: > > This specification assigns no significance to the order of atom:entry > elements within the feed. > > One could read that to mean that feeds are fundamentally unordered or that > Atom doesn't say what the order means. Is not logical order, if any, determined by the datetime of the published (or updated) element? > Other RSS formats are ordered, either implicitly or explicity (RSS 1.0). > For interoperatility, lots of software is going to treat Atom as ordered. > Otherwise, it is not possible to go from Atom to RSS 1.0. I assume you mean from RSS 1.0 to Atom. :-) Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------ms080608080307080100090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8jCC BPUwggLdoAMCAQICAwEjfTANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTA1 MTcxNzQ2MDBaFw0wNjA1MTcxNzQ2MDBaMEIxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC6QaezyuQyuya0zB98ew+fDDeO6dbkFE1Td2OrePzTOuSMNHH1 kvpAxpC7m9WtSeeQ874XC9qmPxBurEILQYZrA/IJNUR+kWvJzAJLJK/62xOCOuDuNjLXKv5F BJEeg/uDpiq6K7yfsLcwg5wkxmIGsajYR+maGDlqV7aJeMuTcRTeNHNIBliwToPlIRvQfJbP B3D4tCInHxWeg5BmyqXZgpEPdJ1hyoHB+YvA/0YKAb1Fq9Fq2n6ZC0O70ndkx++OXw65kkYi m6N/dHQ9xjtpOOk6cQu+SKoL2BfU8kBp9bSmIUymn+KqUdwTcge4vFieJ1lWmtMsKUTbLbgh 0P9ZAgMBAAGjgbwwgbkwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlv dXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNB Y2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNl cnQub3JnMB0GA1UdEQQWMBSBEnN0cGV0ZXJAamFiYmVyLm9yZzANBgkqhkiG9w0BAQQFAAOC AgEAk+5v9P2B9Zher5QMtmGRSqg+Dkmd2xMoBjPItsR2FFS6waXf3Hv82n4W//9HzM+zAuKv a0kzHY9IHCqcpRVBAqKpN6a6VHb6ZmtwKtj38wmLwMUIqnfvEx4AvP8QJHERLRVn8JL801QT 8Nt1y/6LaOKkFiQUZGvP5m6plXHx2DqL2gfAtZ/VSivSTzkJp3XyDnL04TdKFMY6vPvoT1Ub d48KW+ZA1NE1+h6gxr4jQVUExKeKB25RoxZMXyMqbawnzJZYl2fEkYgQVWVpPZO6NC9u45u4 kyOXNaLjiQwLpCvZj6x87YOQKn1YyiIWXSUFU4ArsaR/BvtVb53IKYE2LE8dPqq/fn1iMCb4 qLesxc+SQWAQB/xiDlVA00eJq+Ulyq4KTFnbARWHgXOqLUo9Uu+GsiK8L6WLf4vr2F8dhDwa tfw7oGjGmGJd0ZO/Yt3Wp7ytutsM+4I3ewlQyRWsXx6zcSHN43FUFZpCJxrfD1k1t9z/MJy/ d2zx7mjjbjcfTykIi8taC2UwdMBAbpNmH4gh+VnrEPgYHOONwBTqL/dfW0Px5pa0Fv/WU/VQ gYep9RLmdDYcwR2bn9XLdVDngMHHTr3Z9LNl1VfQnZg2wi2wvfIrrE0gOtJD7dMPl64Un2Tv L0bvyJrhkiKKdFACad+aOcw1pyWIiDixoYZPJi8wggT1MIIC3aADAgECAgMBI30wDQYJKoZI hvcNAQEEBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDUwNTE3MTc0NjAwWhcNMDYwNTE3MTc0NjAw WjBCMR0wGwYDVQQDExRKLiBQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3Rw ZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAukGns8rk MrsmtMwffHsPnww3junW5BRNU3djq3j80zrkjDRx9ZL6QMaQu5vVrUnnkPO+Fwvapj8QbqxC C0GGawPyCTVEfpFrycwCSySv+tsTgjrg7jYy1yr+RQSRHoP7g6Yquiu8n7C3MIOcJMZiBrGo 2Efpmhg5ale2iXjLk3EU3jRzSAZYsE6D5SEb0HyWzwdw+LQiJx8VnoOQZsql2YKRD3SdYcqB wfmLwP9GCgG9RavRatp+mQtDu9J3ZMfvjl8OuZJGIpujf3R0PcY7aTjpOnELvkiqC9gX1PJA afW0piFMpp/iqlHcE3IHuLxYnidZVprTLClE2y24IdD/WQIDAQABo4G8MIG5MAwGA1UdEwEB /wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3Ig RlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYw JDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAdBgNVHREEFjAUgRJzdHBl dGVyQGphYmJlci5vcmcwDQYJKoZIhvcNAQEEBQADggIBAJPub/T9gfWYXq+UDLZhkUqoPg5J ndsTKAYzyLbEdhRUusGl39x7/Np+Fv//R8zPswLir2tJMx2PSBwqnKUVQQKiqTemulR2+mZr cCrY9/MJi8DFCKp37xMeALz/ECRxES0VZ/CS/NNUE/Dbdcv+i2jipBYkFGRrz+ZuqZVx8dg6 i9oHwLWf1Uor0k85Cad18g5y9OE3ShTGOrz76E9VG3ePClvmQNTRNfoeoMa+I0FVBMSnigdu UaMWTF8jKm2sJ8yWWJdnxJGIEFVlaT2TujQvbuObuJMjlzWi44kMC6Qr2Y+sfO2DkCp9WMoi Fl0lBVOAK7Gkfwb7VW+dyCmBNixPHT6qv359YjAm+Ki3rMXPkkFgEAf8Yg5VQNNHiavlJcqu CkxZ2wEVh4Fzqi1KPVLvhrIivC+li3+L69hfHYQ8GrX8O6BoxphiXdGTv2Ld1qe8rbrbDPuC N3sJUMkVrF8es3EhzeNxVBWaQica3w9ZNbfc/zCcv3ds8e5o4243H08pCIvLWgtlMHTAQG6T Zh+IIflZ6xD4GBzjjcAU6i/3X1tD8eaWtBb/1lP1UIGHqfUS5nQ2HMEdm5/Vy3VQ54DBx069 2fSzZdVX0J2YNsItsL3yK6xNIDrSQ+3TD5euFJ9k7y9G78ia4ZIiinRQAmnfmjnMNacliIg4 saGGTyYvMYIDhzCCA4MCAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0 cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5 MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwEjfTAJBgUrDgMCGgUAoIIB 2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MzAyMTUw NDVaMCMGCSqGSIb3DQEJBDEWBBQHg6JDFhzT6xMZdhyFkz3MFqUmxzBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3Qg Q0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBT aWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB I30wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMBI30wDQYJKoZIhvcN AQEBBQAEggEAId/zB/NvaWcc43IWbhbvIh2gQPr4CCgAFopu8t/8q2m5VEmSf9G6yuyOunVO quDwryVz+y/WcUdYryYob2e/syErFJI9XuNcbZiY+inmTL0O9Ui5KTwlU/YL9308l4h8/m6D VE3CvrxuQndvaJ3kIqr5teFZOiT3U4+p318H5YUeznTJYuqPA0wFzDEMm6pXSFIRw8Z/8Hzh Uvwca0vawSwNgjIFsMzdOoDlw8Z/LN0/QDzHM2HlfFZnobgyCQzP07s0JS7S0IHkfQX4ZUNt 0aTZvA1xtJDXApaBhP40DMXBKONcF9DhcTcHFpb4NZBAebNdnLaGd2tCId4XY+LvTwAAAAAA AA== --------------ms080608080307080100090700-- From owner-atom-syntax@mail.imc.org Tue Aug 30 18:12:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAELY-00069M-7S for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:12:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12844 for ; Tue, 30 Aug 2005 18:12:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UM5h4F019252; Tue, 30 Aug 2005 15:05:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UM5hCn019251; Tue, 30 Aug 2005 15:05:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UM5hBH019239 for ; Tue, 30 Aug 2005 15:05:43 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id DE96551 for ; Tue, 30 Aug 2005 15:05:37 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7UM5akv001796 for ; Tue, 30 Aug 2005 15:05:37 -0700 (PDT) Date: Tue, 30 Aug 2005 15:05:47 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. Message-ID: <07EFDFC79A3015446E06A6D3@Wunders-Computer.local> In-Reply-To: <4314D4B5.9050204@jabber.org> References: <20050830055003.290F672410D@mail.pubsub.com> <4314D4B5.9050204@jabber.org> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 30, 2005 3:50:45 PM -0600 Peter Saint-Andre wrote: >> Otherwise, it is not possible to go from Atom to RSS 1.0. > > I assume you mean from RSS 1.0 to Atom. :-) No. You can go from a Bag to List by ignoring the order. RSS 1.0 is a List, so you would need to invent an order to put unordered items in it. wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 30 18:12:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAELb-00069W-Qv for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:12:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12854 for ; Tue, 30 Aug 2005 18:12:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UM8C5n019442; Tue, 30 Aug 2005 15:08:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UM8CoH019441; Tue, 30 Aug 2005 15:08:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UM8BEP019433 for ; Tue, 30 Aug 2005 15:08:11 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 553AA51; Tue, 30 Aug 2005 15:08:06 -0700 (PDT) Received: from localhost (spike.verity.com [192.168.4.22]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j7UM85kv001838; Tue, 30 Aug 2005 15:08:05 -0700 (PDT) Date: Tue, 30 Aug 2005 15:08:16 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. Message-ID: <62440C0E5DAB42C63AE1E1AE@Wunders-Computer.local> In-Reply-To: <4314D4B5.9050204@jabber.org> References: <20050830055003.290F672410D@mail.pubsub.com> <4314D4B5.9050204@jabber.org> X-Mailer: Mulberry/4.0.2 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On August 30, 2005 3:50:45 PM -0600 Peter Saint-Andre wrote: >> One could read that to mean that feeds are fundamentally unordered or that >> Atom doesn't say what the order means. > > Is not logical order, if any, determined by the datetime of the published > (or updated) element? That is one kind of order. Other kinds are relevance to a search term (A9 OpenSearch), editorial importance (BBC News feeds), or datetime of original publication (nearly all blog feeds, not the same as last update). wunder -- Walter Underwood Principal Software Architect, Verity From owner-atom-syntax@mail.imc.org Tue Aug 30 18:25:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEXU-0001YJ-Cy for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:25:08 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13752 for ; Tue, 30 Aug 2005 18:25:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMJd6p020515; Tue, 30 Aug 2005 15:19:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UMJdxt020514; Tue, 30 Aug 2005 15:19:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMJcrg020501 for ; Tue, 30 Aug 2005 15:19:38 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.163.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 81EE0A32E4; Tue, 30 Aug 2005 18:19:37 -0400 (EDT) In-Reply-To: References: <20050830055003.290F672410D@mail.pubsub.com> <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <483A72A4-1C41-4800-A749-22B6E907440C@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 15:19:34 -0700 To: Graham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd say an ordered list *can be* an entry that gets updated regularly. There's absolutely no reason that Netflix can't have one DVD-per-entry, and it's not a hack. On 30/08/2005, at 2:04 PM, Graham wrote: > But conceptually Bob is absolutely correct. An ordered list is just > an entry that gets updated regularly. There's absolutely no reason > for Netflix to create an individual entry for each DVD. It's a hack > that makes it look better in most aggregators. Nothing more. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Aug 30 18:52:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEyI-0000io-57 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:52:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15136 for ; Tue, 30 Aug 2005 18:52:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMmZuN023051; Tue, 30 Aug 2005 15:48:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UMmZa9023050; Tue, 30 Aug 2005 15:48:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMmY3f023044 for ; Tue, 30 Aug 2005 15:48:35 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j7UMmYTW027569 for ; Tue, 30 Aug 2005 16:48:34 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IM200FU64OY0X@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 30 Aug 2005 16:48:34 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IM200JZD4OXPY@mail.sun.net> for atom-syntax@imc.org; Tue, 30 Aug 2005 16:48:34 -0600 (MDT) Date: Tue, 30 Aug 2005 15:48:49 -0700 From: Tim Bray Subject: Re: "Top 10" and other lists should be entries, not feeds. In-reply-to: <62440C0E5DAB42C63AE1E1AE@Wunders-Computer.local> To: Walter Underwood Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.734) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050830055003.290F672410D@mail.pubsub.com> <4314D4B5.9050204@jabber.org> <62440C0E5DAB42C63AE1E1AE@Wunders-Computer.local> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Aug 30, 2005, at 3:08 PM, Walter Underwood wrote: > That is one kind of order. Other kinds are relevance to a search term > (A9 OpenSearch), editorial importance (BBC News feeds), or datetime of > original publication (nearly all blog feeds, not the same as last > update). Well put. It's obvious that there exist feeds that have ordering requirements that are orthogonal to atom:updated. It's plausible, but not obvious, that the first two kinds of order Walter enumerates are instances of a class which we might label "importance" or "priority". It's also plausible, but even less obvious, that there are going to be lots of places where non-updated order matters in a way that has to do with "importance", to the extent that a generally-implemented extension will be useful. It's also plausible, but not obvious, that there's no usefully- generalizable notion of "importance", that the semantics of this stuff are really application-specific, and that interested parties should go and do their own NetFlix or A9 or BBC extensions. Or just cram your Netflix queue in a single entry. Fortunately, the format spec, with its "assigns no significance" language, doesn't get in the way of people who want to work on this problem. I can see two generalized approaches; the first is a singleton attribute of child of that says "in this feed, order reflects importance". The second is such an attribute that says "in this feed, an ordering by the following namespaced-element child of reflects importance". I prefer the first. I haven't looked at the Microsoft proposal. Clearly, the WG lacks consensus, at least in the short term. -Tim From owner-atom-syntax@mail.imc.org Tue Aug 30 19:01:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAF6q-0003gv-UA for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 19:01:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16265 for ; Tue, 30 Aug 2005 19:01:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMrSDC023500; Tue, 30 Aug 2005 15:53:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UMrS2m023499; Tue, 30 Aug 2005 15:53:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UMrNPL023490 for ; Tue, 30 Aug 2005 15:53:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id j7UMrNqB017093; Tue, 30 Aug 2005 15:53:23 -0700 (PDT) Received: from [10.0.0.9] (host-83-146-12-185.bulldogdsl.com [83.146.12.185]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j7UMrK75008557 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 Aug 2005 15:53:22 -0700 (PDT) In-Reply-To: <483A72A4-1C41-4800-A749-22B6E907440C@mnot.net> References: <20050830055003.290F672410D@mail.pubsub.com> <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> <483A72A4-1C41-4800-A749-22B6E907440C@mnot.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <938EF526-60F2-410E-B35E-91470BE75189@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Tue, 30 Aug 2005 23:53:19 +0100 To: Mark Nottingham X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Aug 2005, at 11:19 pm, Mark Nottingham wrote: > I'd say an ordered list *can be* an entry that gets updated > regularly. There's absolutely no reason that Netflix can't have one > DVD-per-entry, and it's not a hack. Well it depends. The basic paradigm for a feed is as a newswire of recently posted or updated entries, which works pretty well. For the netflix queue to work, you have to take a step beyond that and view the feed file as a document and not just an envelope. It's not necessarily a hack, but it's a totally different paradigm. Graham From owner-atom-syntax@mail.imc.org Tue Aug 30 19:25:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFTz-0002Xf-Qn for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 19:25:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17291 for ; Tue, 30 Aug 2005 19:25:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7UNKqDh027217; Tue, 30 Aug 2005 16:20:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7UNKpO0027216; Tue, 30 Aug 2005 16:20:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j7UNKo9Y027198 for ; Tue, 30 Aug 2005 16:20:50 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 30 Aug 2005 23:20:44 -0000 Received: from xdsl-213-196-227-92.netcologne.de (EHLO klangraum) [213.196.227.92] by mail.gmx.net (mp014) with SMTP; 31 Aug 2005 01:20:44 +0200 X-Authenticated: #163624 Date: Wed, 31 Aug 2005 01:20:51 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. Message-ID: <20050830232051.GB31874@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050830055003.290F672410D@mail.pubsub.com> <4314D126.4060507@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4314D126.4060507@cegetel.net> 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: * Thomas Broyer [2005-08-30 23:40]: > Henry Story also proposed atom:id to be "order-related": Indeed, and together with an extension for expiring entries, the Netflix use case should be pretty well covered. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue Aug 30 20:22:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAGMh-0003Yt-Hs for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 20:22:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19673 for ; Tue, 30 Aug 2005 20:22:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V0HKLp031437; Tue, 30 Aug 2005 17:17:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V0HKeM031436; Tue, 30 Aug 2005 17:17:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V0HKKt031424 for ; Tue, 30 Aug 2005 17:17:20 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 48035 invoked by uid 17064); 31 Aug 2005 00:17:09 -0000 Received: from unknown (HELO [192.168.1.40]) ([213.3.58.210]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 31 Aug 2005 00:17:09 -0000 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <4314D126.4060507@cegetel.net> References: <20050830055003.290F672410D@mail.pubsub.com> <4314D126.4060507@cegetel.net> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3244E562-21CF-4CF7-AB7C-348B05AE6FFC@bblfish.net> From: Henry Story Subject: Re: "Top 10" and other lists should be entries, not feeds. Date: Wed, 31 Aug 2005 02:17:07 +0200 To: Thomas Broyer , Atom Syntax X-Mailer: Apple Mail (2.734) X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7V0HKKt031431 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 ietf.org id UAA19673 It's late here, but since I have been called... Clearly the order of the entries could not be deduced from the tags =20 themselves. One would need to have an extra tag in there such as this tag tag:first-in-list 1 The Graphes of Wrath 1 July 2005 ... ... to specify the order of the entry. I think at the time I was talking =20 in the context of that being proposed. Again it is late, but I think my idea of having a entry always stay =20 at the same position was that I was thinking that from one week to another one could just =20 change the content of the entry tag:first-in-list 1 Of Mice and Men 8 July 2005 ... So that one could still think of a feed as a sequence of changes to =20 resources. One would then, I thought, not need to republish the whole list of =20 entries, just those that changed from week to week. As a result there was I =20 thought, no need for a tag. But the problem with that suggestion was that it could not cope well =20 with mistaken feed updates. So that if I mistakenly entered "Of Mice and Men" but I =20 meant to enter "The Restaurant at the End of the Universe" then adding the =20 following entry tag:first-in-list 1 The Restaurant at the end of the Universe 8 July 2005 ... would tend to indicate that the change was insignificant, whereas a =20 change of date would tend to indicate that the there was a new entry in =20 first position. Some proposed that one should distinguish therefore between the =20 update time of the entry and the update time of the object of the entry... Henry On 30 Aug 2005, at 23:35, Thomas Broyer wrote: > Bob Wyman wrote: > >> >> I=92m sorry, but I can=92t go on without complaining. Microsoft has =20 >> proposed extensions which turn RSS V2.0 feeds into lists and we=92ve =20 >> got folk who are proposing much the same for Atom (i.e. stateful, =20 >> incremental or partitioned feeds)=85 I think they are wrong. Feeds =20 >> aren=92t lists and Lists aren=92t feeds. It seems to me that if you =20 >> want a =93Top 10=94 list, then you should simply create an entry that = =20 >> provides your Top 10. Then, insert that entry in your feed so that =20 >> the rest of us can read it. If you update the list, then just =20 >> replace the entry in your feed. If you create a new list (Top 34?) =20 >> then insert that in the feed along with the =93Top10=94 list. >> >> > Henry Story also proposed atom:id to be "order-related": > > ... > > tag:first-in-list > Some entry > ... > > > tag:second-in-list > Another entry > ... > > > > and a bit later: > > ... > > tag:first-in-list > Another entry > ... > > > tag:second-in-list > Yet another entry > ... > > > > Note how tag:first-in-list entry now represents "Another entry" =20 > while it were previously "Some entry", and tag:second-in-list now =20 > is "Yet another entry" while it were "Another entry". > > --=20 > Thomas Broyer > > From owner-atom-syntax@mail.imc.org Tue Aug 30 20:29:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAGTv-0004Sa-Vm for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 20:29:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19908 for ; Tue, 30 Aug 2005 20:29:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V0P2dO032253; Tue, 30 Aug 2005 17:25:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V0P26q032252; Tue, 30 Aug 2005 17:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V0P2Qr032238 for ; Tue, 30 Aug 2005 17:25:02 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so7276nzi for ; Tue, 30 Aug 2005 17:24:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=F71d8R7VmwVJezLsbRJAmnrSojt8WNJvKomTG68JLPIgneOeXBftEuKzw+5ibDUzYPTdOpY8etvrthwk1iZakWtj/RscpdbxaGMPY6xmpymTFzI1Bve/MTT6/dG74YNgSAGltq8CxwFXhM7QODd6tDB+1aknx2CHzjJunQFXQ/Y= Received: by 10.36.215.13 with SMTP id n13mr334283nzg; Tue, 30 Aug 2005 17:24:56 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 8sm82665nzn.2005.08.30.17.24.56; Tue, 30 Aug 2005 17:24:56 -0700 (PDT) Message-ID: <4314F8CF.3010809@gmail.com> Date: Tue, 30 Aug 2005 17:24:47 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Thomas Broyer , Atom Syntax Subject: Re: "Top 10" and other lists should be entries, not feeds. References: <20050830055003.290F672410D@mail.pubsub.com> <4314D126.4060507@cegetel.net> <3244E562-21CF-4CF7-AB7C-348B05AE6FFC@bblfish.net> In-Reply-To: <3244E562-21CF-4CF7-AB7C-348B05AE6FFC@bblfish.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Or.. perhaps 1 http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-01.txt - James Henry Story wrote: > > It's late here, but since I have been called... > > Clearly the order of the entries could not be deduced from the tags > themselves. > One would need to have an extra tag in there such as this tag > > > > tag:first-in-list > 1 > The Graphes of Wrath > 1 July 2005 > ... > > ... > > to specify the order of the entry. I think at the time I was talking > in the context > of that being proposed. > > Again it is late, but I think my idea of having a entry always stay > at the same position > was that I was thinking that from one week to another one could just > change the content > of the entry > > > > tag:first-in-list > 1 > Of Mice and Men > 8 July 2005 > ... > > > > So that one could still think of a feed as a sequence of changes to > resources. One > would then, I thought, not need to republish the whole list of > entries, just > those that changed from week to week. As a result there was I > thought, no need for > a tag. > > But the problem with that suggestion was that it could not cope well > with mistaken > feed updates. So that if I mistakenly entered "Of Mice and Men" but I > meant to > enter "The Restaurant at the End of the Universe" then adding the > following entry > > > > tag:first-in-list > 1 > The Restaurant at the end of the Universe > 8 July 2005 > ... > > > > > would tend to indicate that the change was insignificant, whereas a > change > of date would tend to indicate that the there was a new entry in > first position. > > Some proposed that one should distinguish therefore between the > update time of the > entry and the update time of the object of the entry... > > Henry > From owner-atom-syntax@mail.imc.org Tue Aug 30 23:38:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAJQx-00084y-A3 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 23:38:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27885 for ; Tue, 30 Aug 2005 23:38:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V3WgPZ049414; Tue, 30 Aug 2005 20:32:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V3Wgos049411; Tue, 30 Aug 2005 20:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V3Wbmm049389 for ; Tue, 30 Aug 2005 20:32:41 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 31 Aug 2005 13:32:54 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 31 Aug 2005 13:04:10 +1000 Subject: Re: "Top 10" and other lists should be entries, not feeds. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4314D4B5.9050204@jabber.org> 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: Content-Transfer-Encoding: 7bit On 31/8/05 7:50 AM, "Peter Saint-Andre" wrote: > Is not logical order, if any, determined by the datetime of the > published (or updated) element? No. I've seen a few things online where they publish chapter 3 first, followed by chapter 8, and then go back and fill in the blanks. And then update chapter 2. Sometimes there are good reasons for this, strangely enough. Leaving aside completely the idea of publishing a chunk, followed by more chunks, and *then* re-arranging them into some semblance of logical order once they know what content they have. e. From owner-atom-syntax@mail.imc.org Tue Aug 30 23:38:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAJQx-00084z-A2 for atompub-archive@megatron.ietf.org; Tue, 30 Aug 2005 23:38:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27884 for ; Tue, 30 Aug 2005 23:38:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V3WgtS049413; Tue, 30 Aug 2005 20:32:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V3WgFR049412; Tue, 30 Aug 2005 20:32:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V3WbQf049388 for ; Tue, 30 Aug 2005 20:32:41 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 31 Aug 2005 13:32:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 31 Aug 2005 12:59:07 +1000 Subject: Re: "Top 10" and other lists should be entries, not feeds. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 31/8/05 6:01 AM, "Mark Nottingham" wrote: > It sounds like you've got use cases for Atom that other use cases > (e.g., lists) make difficult to work with. Banning those other use > cases makes things easier for you, but I don't think it's good for > Atom overall. those other use cases are also a good example of some feeds which shouldn't be devoured by robots. e. From owner-atom-syntax@mail.imc.org Wed Aug 31 01:02:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKkR-00066w-Aj for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 01:02:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02036 for ; Wed, 31 Aug 2005 01:02:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V4sM9g057660; Tue, 30 Aug 2005 21:54:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V4sMhN057659; Tue, 30 Aug 2005 21:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V4sLXr057647 for ; Tue, 30 Aug 2005 21:54:22 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so811701wra for ; Tue, 30 Aug 2005 21:54:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hJ7iZkAUymRVtrt676DHw3AQjg+HxRsQYx9pvAUik7M1oaQCYofMKQZDUfzoYptT9cv4ZTqIgpuv76abShTBtfMiiiLAb21MmLLjcgrAaqOipOx6nrYchT6SjHVsfe+6DtUoYeyovYlY1Iw6YTYZt/CK1SD89QntHIeheWshd74= Received: by 10.54.52.63 with SMTP id z63mr33774wrz; Tue, 30 Aug 2005 21:54:16 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id 9sm6254220wrl.2005.08.30.21.54.15; Tue, 30 Aug 2005 21:54:16 -0700 (PDT) Message-ID: <431537EF.2010503@gmail.com> Date: Tue, 30 Aug 2005 21:54:07 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: draft-snell-atompub-feed-nofollow-00.txt [was: Re: Don't Aggregrate Me] References: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <7E57B3275505DE9018564AEA@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This HAS NOT yet been submitted. I'm offering it up for discussion first. http://www.snellspace.com/public/draft-snell-atompub-feed-nofollow-00.txt defines x:follow="yes|no" x:index="yes|no" and x:archive="yes|no" attributes - James From owner-atom-syntax@mail.imc.org Wed Aug 31 03:42:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EANF6-0005y4-U7 for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 03:42:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06061 for ; Wed, 31 Aug 2005 03:42:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V7ZTjK072745; Wed, 31 Aug 2005 00:35:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7V7ZSBk072743; Wed, 31 Aug 2005 00:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7V7ZSPq072735 for ; Wed, 31 Aug 2005 00:35:28 -0700 (PDT) (envelope-from danbri@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 78F504EEC5; Wed, 31 Aug 2005 03:35:26 -0400 (EDT) Message-ID: <43155DE1.7010104@w3.org> Date: Wed, 31 Aug 2005 08:36:01 +0100 From: Dan Brickley User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Saint-Andre Cc: atom-syntax@imc.org Subject: Re: "Top 10" and other lists should be entries, not feeds. References: <20050830055003.290F672410D@mail.pubsub.com> <4314D4B5.9050204@jabber.org> In-Reply-To: <4314D4B5.9050204@jabber.org> Content-Type: text/plain; charset=windows-1252; format=flowed 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 ietf.org id DAA06061 Peter Saint-Andre wrote: > Walter Underwood wrote: > >> --On August 30, 2005 1:49:57 AM -0400 Bob Wyman =20 >> wrote: >> >> >>> I=E2=80=99m sorry, but I can=E2=80=99t go on without complaining. Mic= rosoft has=20 >>> proposed >>> extensions which turn RSS V2.0 feeds into lists and we=E2=80=99ve got= folk=20 >>> who are >>> proposing much the same for Atom (i.e. stateful, incremental or=20 >>> partitioned >>> feeds)=E2=80=A6 I think they are wrong. Feeds aren=E2=80=99t lists an= d Lists=20 >>> aren=E2=80=99t feeds. >> >> >> >> The Atom spec says: >> >> This specification assigns no significance to the order of atom:entry >> elements within the feed. >> >> One could read that to mean that feeds are fundamentally unordered or=20 >> that >> Atom doesn't say what the order means. > > > Is not logical order, if any, determined by the datetime of the=20 > published (or updated) element? Often it makes sense for the order to come from properties of the things described by the items/entries, rather than publication dates. Examples: movie listings, job listings, photos by image creation rather than upload time, etc. Generally, feeds that aren't blog content but are views into s= ome database, ie. the same kinds of feed that are most likely to use=20 data-centric markup extensions. Atom allows such orderings to be exposed, without requiring that a machine-friendly justification be given. Seems about right to me. cheers, Dan From owner-atom-syntax@mail.imc.org Wed Aug 31 11:39:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUgc-0000Yj-AG for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:39:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27275 for ; Wed, 31 Aug 2005 11:39:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFV3YO019497; Wed, 31 Aug 2005 08:31:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VFV3QD019496; Wed, 31 Aug 2005 08:31:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFV2Aj019474 for ; Wed, 31 Aug 2005 08:31:03 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so84259nzi for ; Wed, 31 Aug 2005 08:30:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=leJM147HZyApzlftLQLvLv2BkpxQk+YOwMtV2zsG5T9R35vyQqayzt8SBiuPn/9FUaYN5ucGjVU+BNSkNa3A0V7dG60VLIT1L1olf0a9sOQJBRg1usNhPrp3ogb0OUInWLXjvegPydSd7cCUy2zRcYkB++0tqM6pbyo1CTD2JlU= Received: by 10.36.148.16 with SMTP id v16mr900042nzd; Wed, 31 Aug 2005 08:30:57 -0700 (PDT) Received: by 10.36.153.6 with HTTP; Wed, 31 Aug 2005 08:30:57 -0700 (PDT) Message-ID: <1f2ed5cd05083108303617c724@mail.gmail.com> Date: Wed, 31 Aug 2005 17:30:57 +0200 From: Danny Ayers To: bobwyman@pubsub.com Subject: Re: "Top 10" and other lists should be entries, not feeds. Cc: Mark Nottingham , atom-syntax@imc.org In-Reply-To: <20050830210957.2DB257244B5@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> <20050830210957.2DB257244B5@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7VFV3Aj019491 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/30/05, Bob Wyman wrote: > No. I'm saying that if Netflix switches over to Atom, what they > should do is insert the Queue information, as a list, into a single entry > within the feed. Correct me if I'm wrong, but doesn't Atom already support this, along with pretty much every other approach? Entries in an individual feed document are unordered. The client can derive a well-defined order from the dates (or have something considerably less controlled going per doc changes). That's for date order. But the client could sort entries according to some other derived order - e.g. alphabetically by title or content or by size. Or by value of the x:priority element on each entry, with perhaps a later entry flagged 2 replacing the current entry with an element with that value. Or by interpretation of something like: ... ... ( - is that the kind of thing you had in mind, Bob?) Another alternative would be: ... whatever ... ... i.e. having the list order provided in a single entry, but through extensions rather than in the content. There's a load of other alternatives to - adding "next" and "previous" URI links, labelled with whatever axis the sort order is over. I doubt there's much difference in terms of effort needed to support either the per-entry or in-entry approaches. Capabilities of the client might make a lot of difference though - expressing the order in XHTML might be more client-friendly than using something like RDF/XML or any other hard-to-view format. With the aggregator code I've been playing with recently the list approach might be marginally easier to support, as it could be XSLT'd across to an rdf:List. Sorting on an x:sortPosition kind of element could be trickier as that would need to be considered in combination with the date, but then again joins may be more flexible. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Aug 31 11:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUj1-0001J3-EB for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:42:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27355 for ; Wed, 31 Aug 2005 11:42:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFZ194019822; Wed, 31 Aug 2005 08:35:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VFZ13U019821; Wed, 31 Aug 2005 08:35:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFZ18T019811 for ; Wed, 31 Aug 2005 08:35:01 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id i28so84780nzi for ; Wed, 31 Aug 2005 08:34:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r7D78iCdtCMp5Sz5jJmSjs9d0O8JvhUyShgOGuGKE1Grxxz+My0eS4XcAwnRBegE2/ChpcMfte4WN+AQKx/1kmPEwGGFH5mEJsZaNl8bOwYlTBX2ikk6b4JWmXBFq8RYLZmqWAVSBNwi5vGvreOT0HNKhkuiBn8YUiaCGpnNr34= Received: by 10.36.17.7 with SMTP id 7mr901900nzq; Wed, 31 Aug 2005 08:34:10 -0700 (PDT) Received: by 10.36.153.6 with HTTP; Wed, 31 Aug 2005 08:34:54 -0700 (PDT) Message-ID: <1f2ed5cd05083108347eb58016@mail.gmail.com> Date: Wed, 31 Aug 2005 17:34:54 +0200 From: Danny Ayers To: bobwyman@pubsub.com Subject: Re: "Top 10" and other lists should be entries, not feeds. Cc: Mark Nottingham , atom-syntax@imc.org In-Reply-To: <1f2ed5cd05083108303617c724@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <851BC219-9E2E-4A84-B055-DB5C64E85950@mnot.net> <20050830210957.2DB257244B5@mail.pubsub.com> <1f2ed5cd05083108303617c724@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7VFZ18T019816 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 8/31/05, Danny Ayers wrote: Correction: > I doubt there's much difference in terms of effort needed to support > either the per-entry or in-entry approaches. Capabilities of the > client might make a lot of difference though => > I doubt there's much difference in terms of effort needed for a publisher to support > either the per-entry or in-entry approaches. Capabilities of the > client might make a lot of difference though Also what I didn't ask was - as these approaches are already supported by the Atom format, what's the point of dispute, the aim of this discussion? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Aug 31 11:55:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUvp-0004uk-2o for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:55:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27981 for ; Wed, 31 Aug 2005 11:55:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFmxgk020864; Wed, 31 Aug 2005 08:48:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VFmxw4020863; Wed, 31 Aug 2005 08:48:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com ([64.34.58.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VFmwNC020852 for ; Wed, 31 Aug 2005 08:48:58 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pubsub.com (Postfix) with ESMTP id 8B6B2725B7E; Wed, 31 Aug 2005 11:36:20 -0400 (EDT) Reply-To: From: "Bob Wyman" To: , "'Mark Nottingham'" Cc: Subject: The benefits of "Lists are Entries" rather than "Lists are Feeds" Date: Wed, 31 Aug 2005 11:36:18 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20050830210957.2DB257244B5@mail.pubsub.com> Thread-Index: AcWtnbDxg0ZH+ujKShuWH8M3SHD1QwACBQRAACbQSYA= Message-Id: <20050831153620.8B6B2725B7E@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Folks, I hate to be insistent, however, I think that in the mail below I offered some pretty compelling reasons why lists should be entries rather than turning feeds into lists. Could someone please comment on this? Is there some point that I'm completely missing? What is wrong with my suggestion that lists-are-entries is much more useful than the alternative? -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Bob Wyman Sent: Tuesday, August 30, 2005 5:10 PM To: 'Mark Nottingham' Cc: atom-syntax@imc.org Subject: RE: "Top 10" and other lists should be entries, not feeds. Mark Nottingham wrote: >Are you saying that when/if Netflix switches over to Atom, they > shouldn't use it for the Queue? No. I'm saying that if Netflix switches over to Atom, what they should do is insert the Queue information, as a list, into a single entry within the feed. This will not only preserve the nature of Atom feeds as "feeds" but also allow NetFlix a number of new and potentially interesting opportunities for providing data to customers. Most important among these will be the ability to include multiple lists in the feed (i.e. in addition to the Queue, they could also include their "Top 10" list as well as a set of "recommendations" based on user experience. They might even include a list of "10 most recent transactions on your account") Each list would be a distinct entry. To make life easier on aggregators, each entry "type" should probably use the same atom:id across "versions." This allows the aggregators to discard earlier, now out of date entries. NetFlix would also be able to intermix information such as the "Queue List" with non-list entries. For instance, they might have a "Message from NetFlix" that they want to include in the feed or, they might include a series of movie reviews that were carefully selected for the specific user. Basically, by using entries for lists instead of converting the entire feed into a list, NetFlix is able to offer a much richer and much more satisfying experience to their users. The ability of Atom to carry both lists and non-lists as entries means that Atom is able to offer a much more flexible and powerful mechanism to NetFlix than can be had from the less-capable RSS V2.0 solution. I think that if I were NetFlix, I would want to have the opportunity to experiment with and find ways to exploit this powerful capability. The richer the opportunity for communications between NetFlix and their customers, the greater the opportunity they have to generate revenues. The alternative to using entries rather than feeds would be creating multiple feeds per user. That strikes me as a solution which is ugly on its face and unquestionably increases the complexity of the system for both NetFlix and its customers. The "list-in-entry" solution is much more elegant and much more powerful. bob wyman From owner-atom-syntax@mail.imc.org Wed Aug 31 12:14:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVDu-0001QE-Ti for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 12:14:02 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28679 for ; Wed, 31 Aug 2005 12:13:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VG8p5X022968; Wed, 31 Aug 2005 09:08:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VG8pir022967; Wed, 31 Aug 2005 09:08:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VG8ocC022958 for ; Wed, 31 Aug 2005 09:08:50 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6C780A32D0; Wed, 31 Aug 2005 12:08:49 -0400 (EDT) In-Reply-To: <20050831153620.8B6B2725B7E@mail.pubsub.com> References: <20050831153620.8B6B2725B7E@mail.pubsub.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" Date: Wed, 31 Aug 2005 09:08:45 -0700 To: X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What would you like the working group to do? On 31/08/2005, at 8:36 AM, Bob Wyman wrote: > > Folks, I hate to be insistent, however, I think that in the mail > below I > offered some pretty compelling reasons why lists should be entries > rather > than turning feeds into lists. Could someone please comment on > this? Is > there some point that I'm completely missing? What is wrong with my > suggestion that lists-are-entries is much more useful than the > alternative? > > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] > On Behalf Of Bob Wyman > Sent: Tuesday, August 30, 2005 5:10 PM > To: 'Mark Nottingham' > Cc: atom-syntax@imc.org > Subject: RE: "Top 10" and other lists should be entries, not feeds. > > Mark Nottingham wrote: > >> Are you saying that when/if Netflix switches over to Atom, they >> shouldn't use it for the Queue? >> > No. I'm saying that if Netflix switches over to Atom, what they > should do is insert the Queue information, as a list, into a single > entry > within the feed. > This will not only preserve the nature of Atom feeds as "feeds" > but > also allow NetFlix a number of new and potentially interesting > opportunities > for providing data to customers. Most important among these will be > the > ability to include multiple lists in the feed (i.e. in addition to the > Queue, they could also include their "Top 10" list as well as a set of > "recommendations" based on user experience. They might even include > a list > of "10 most recent transactions on your account") Each list would be a > distinct entry. To make life easier on aggregators, each entry > "type" should > probably use the same atom:id across "versions." This allows the > aggregators > to discard earlier, now out of date entries. > NetFlix would also be able to intermix information such as the > "Queue List" with non-list entries. For instance, they might have a > "Message > from NetFlix" that they want to include in the feed or, they might > include a > series of movie reviews that were carefully selected for the > specific user. > Basically, by using entries for lists instead of converting the > entire feed into a list, NetFlix is able to offer a much richer and > much > more satisfying experience to their users. > The ability of Atom to carry both lists and non-lists as entries > means that Atom is able to offer a much more flexible and powerful > mechanism > to NetFlix than can be had from the less-capable RSS V2.0 solution. > I think > that if I were NetFlix, I would want to have the opportunity to > experiment > with and find ways to exploit this powerful capability. The richer the > opportunity for communications between NetFlix and their customers, > the > greater the opportunity they have to generate revenues. > The alternative to using entries rather than feeds would be > creating > multiple feeds per user. That strikes me as a solution which is > ugly on its > face and unquestionably increases the complexity of the system for > both > NetFlix and its customers. The "list-in-entry" solution is much > more elegant > and much more powerful. > > bob wyman > > > > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Aug 31 12:28:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAVRa-0006eC-AX for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 12:28:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29181 for ; Wed, 31 Aug 2005 12:28:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VGMjOc025471; Wed, 31 Aug 2005 09:22:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VGMjTf025470; Wed, 31 Aug 2005 09:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VGMjEP025464 for ; Wed, 31 Aug 2005 09:22:45 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1471337rnf for ; Wed, 31 Aug 2005 09:22:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=t0wkI5FYUvjW+pQeWlcCZHIWuV6yoPvR1PwvOyKgDs8gZf9XPuoER5YMGYw5miaxonamZgGVtU23SHEzxgWDWmkk5LmlYIG/DdS6J4NiLqaE83I9Qb0YjUbBWr1QmHr+wQAN3sgD3N9NyG16ImqKtTBo+TwEDVm/89D7VEGseZY= Received: by 10.38.75.15 with SMTP id x15mr161108rna; Wed, 31 Aug 2005 09:22:44 -0700 (PDT) Received: from ?192.168.1.100? ( [67.181.221.143]) by mx.gmail.com with ESMTP id k6sm5866509rnd.2005.08.31.09.22.44; Wed, 31 Aug 2005 09:22:44 -0700 (PDT) Message-ID: <4315D952.2090804@gmail.com> Date: Wed, 31 Aug 2005 09:22:42 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bobwyman@pubsub.com CC: "'Mark Nottingham'" , atom-syntax@imc.org Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" References: <20050831153620.8B6B2725B7E@mail.pubsub.com> In-Reply-To: <20050831153620.8B6B2725B7E@mail.pubsub.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: Content-Transfer-Encoding: 7bit It may very well be more useful, but we shouldn't mandate it in any way. Let people build whatever kind of applications they want with Atom. Bob Wyman wrote: >Folks, I hate to be insistent, however, I think that in the mail below I >offered some pretty compelling reasons why lists should be entries rather >than turning feeds into lists. Could someone please comment on this? Is >there some point that I'm completely missing? What is wrong with my >suggestion that lists-are-entries is much more useful than the alternative? > >-----Original Message----- >From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] >On Behalf Of Bob Wyman >Sent: Tuesday, August 30, 2005 5:10 PM >To: 'Mark Nottingham' >Cc: atom-syntax@imc.org >Subject: RE: "Top 10" and other lists should be entries, not feeds. > >Mark Nottingham wrote: > > >>Are you saying that when/if Netflix switches over to Atom, they >>shouldn't use it for the Queue? >> >> > No. I'm saying that if Netflix switches over to Atom, what they >should do is insert the Queue information, as a list, into a single entry >within the feed. > This will not only preserve the nature of Atom feeds as "feeds" but >also allow NetFlix a number of new and potentially interesting opportunities >for providing data to customers. Most important among these will be the >ability to include multiple lists in the feed (i.e. in addition to the >Queue, they could also include their "Top 10" list as well as a set of >"recommendations" based on user experience. They might even include a list >of "10 most recent transactions on your account") Each list would be a >distinct entry. To make life easier on aggregators, each entry "type" should >probably use the same atom:id across "versions." This allows the aggregators >to discard earlier, now out of date entries. > NetFlix would also be able to intermix information such as the >"Queue List" with non-list entries. For instance, they might have a "Message >from NetFlix" that they want to include in the feed or, they might include a >series of movie reviews that were carefully selected for the specific user. > Basically, by using entries for lists instead of converting the >entire feed into a list, NetFlix is able to offer a much richer and much >more satisfying experience to their users. > The ability of Atom to carry both lists and non-lists as entries >means that Atom is able to offer a much more flexible and powerful mechanism >to NetFlix than can be had from the less-capable RSS V2.0 solution. I think >that if I were NetFlix, I would want to have the opportunity to experiment >with and find ways to exploit this powerful capability. The richer the >opportunity for communications between NetFlix and their customers, the >greater the opportunity they have to generate revenues. > The alternative to using entries rather than feeds would be creating >multiple feeds per user. That strikes me as a solution which is ugly on its >face and unquestionably increases the complexity of the system for both >NetFlix and its customers. The "list-in-entry" solution is much more elegant >and much more powerful. > > bob wyman > > > > > > > From owner-atom-syntax@mail.imc.org Wed Aug 31 13:29:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWOe-0006wY-4C for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:29:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01613 for ; Wed, 31 Aug 2005 13:29:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VHMekY032770; Wed, 31 Aug 2005 10:22:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VHMerb032769; Wed, 31 Aug 2005 10:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VHMdee032756 for ; Wed, 31 Aug 2005 10:22:39 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by xproxy.gmail.com with SMTP id h27so200005wxd for ; Wed, 31 Aug 2005 10:22:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P/hrAua5VRdXSgabyZad97e8vBo4MWTOWQvmeYvz0QDPLkziNF5Qzx6txCyrKYjjZlPGkBrNVrALiuOaCSmmo8F4MFMfS3gT7NePa0ZRvcPNUqbE6oMa5r+wedAX80+vcSh0+LHwM/5oYFN2MSnN0s+HQoqj3680kfYLCOihddo= Received: by 10.70.44.14 with SMTP id r14mr37994wxr; Wed, 31 Aug 2005 10:22:34 -0700 (PDT) Received: by 10.70.48.3 with HTTP; Wed, 31 Aug 2005 10:22:34 -0700 (PDT) Message-ID: <540e373205083110224cd8c779@mail.gmail.com> Date: Wed, 31 Aug 2005 12:22:34 -0500 From: "Roger B." To: atom-syntax@imc.org Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" In-Reply-To: <20050831153620.8B6B2725B7E@mail.pubsub.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050830210957.2DB257244B5@mail.pubsub.com> <20050831153620.8B6B2725B7E@mail.pubsub.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j7VHMeee032763 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > What is wrong with my > suggestion that lists-are-entries is much more useful than the alternative? Bob: Well, off the top of my head... (1) If the lists are embedded as (X)HTML, then only aggregators that display markup will be able to do anything with them, and headline-only aggregators will be useless. (2) If the lists are embedded in a new extension of some sort, developers have to buy in to get even minimal functionality. Not so if the entries are list items... even a non-list-aware aggregator will be able to display *something*. (3) If the lists are embedded as (X)HTML, my options for re-sorting the list are somewhere between minimal and non-existent. In fact, the only benefit I can see (as a user) to lists-within-entries is the ability to easily archive the state of the list. But that's probably better left to aggregator developers to implement as a feature. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed Aug 31 14:42:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXXv-0005lP-VY for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 14:42:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05254 for ; Wed, 31 Aug 2005 14:42:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VITXAn039770; Wed, 31 Aug 2005 11:29:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VITXFQ039769; Wed, 31 Aug 2005 11:29:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VITXke039763 for ; Wed, 31 Aug 2005 11:29:33 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout01/MantshX 4.0) with ESMTP id j7VITWLe029634; Wed, 31 Aug 2005 11:29:32 -0700 (PDT) Received: from [10.0.0.9] (host-83-146-12-185.bulldogdsl.com [83.146.12.185]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j7VITTBL026260 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 Aug 2005 11:29:31 -0700 (PDT) In-Reply-To: <540e373205083110224cd8c779@mail.gmail.com> References: <20050830210957.2DB257244B5@mail.pubsub.com> <20050831153620.8B6B2725B7E@mail.pubsub.com> <540e373205083110224cd8c779@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" Date: Wed, 31 Aug 2005 19:29:27 +0100 To: "Roger B." X-Mailer: Apple Mail (2.734) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 31 Aug 2005, at 6:22 pm, Roger B. wrote: > (1) If the lists are embedded as (X)HTML, then only aggregators that > display markup will be able to do anything with them, and > headline-only aggregators will be useless. And damn those unthinking bloggers who embed their paragraphs as (X) HTML, because headline-only aggregators are useless for reading them. > (2) If the lists are embedded in a new extension of some sort, > developers have to buy in to get even minimal functionality. Not so if > the entries are list items... even a non-list-aware aggregator will be > able to display *something*. Who is advocating this? > (3) If the lists are embedded as (X)HTML, my options for re-sorting > the list are somewhere between minimal and non-existent. Fair point. > In fact, the only benefit I can see (as a user) to > lists-within-entries is the ability to easily archive the state of the > list. But that's probably better left to aggregator developers to > implement as a feature. Another feature is the list can be formatted properly XHTML, considerably improving legibly over a bunch of floating entries. Graham From owner-atom-syntax@mail.imc.org Wed Aug 31 17:01:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZiX-0002S9-ME for atompub-archive@megatron.ietf.org; Wed, 31 Aug 2005 17:01:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14763 for ; Wed, 31 Aug 2005 17:01:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VKuqat050239; Wed, 31 Aug 2005 13:56:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VKuq4v050238; Wed, 31 Aug 2005 13:56:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server1.livestoryboard.com (livestoryboard.com [209.61.132.12] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VKuptC050231 for ; Wed, 31 Aug 2005 13:56:51 -0700 (PDT) (envelope-from rob@koberg.com) Received: from [127.0.0.1] (livestoryboard.com [209.61.132.12] (may be forged)) (authenticated) by server1.livestoryboard.com (8.11.6/8.11.6) with ESMTP id j7VKw0g29164; Wed, 31 Aug 2005 15:58:01 -0500 Message-ID: <4316198F.2090700@koberg.com> Date: Wed, 31 Aug 2005 16:56:47 -0400 From: Robert Koberg User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "A. Pagaltzis" , Atom Syntax Subject: Re: The benefits of "Lists are Entries" rather than "Lists are Feeds" References: <20050830210957.2DB257244B5@mail.pubsub.com> <20050831153620.8B6B2725B7E@mail.pubsub.com> <540e373205083110224cd8c779@mail.gmail.com> <20050831203333.GA10254@klangraum> In-Reply-To: <20050831203333.GA10254@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed 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 ietf.org id RAA14763 Hi, A. Pagaltzis wrote: > * Graham [2005-08-31 20:40]: >=20 >>Another feature is the list can be formatted properly XHTML, >>considerably improving legibly over a bunch of floating >>entries. >=20 >=20 > Straw man. The onus for the legibility of an XHTML-formatted list > lies with the publisher; for the entries-as-items list, it lies > with the aggregator developer. I=E2=80=99m sorry if you aggregator > developer can=E2=80=99t make a bunch of floating entries very readable. What is a floating entry? I have tried a search in the specs (IETF and=20 .3) and google for: atom floating entry. No results or no relevent result= s. -Rob
  1. Number One
  2. Number Two
    3. ...