From owner-atom-syntax@mail.imc.org Sun May 1 07:22:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14820 for ; Sun, 1 May 2005 07:22: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 j41BEvIm044944; Sun, 1 May 2005 04: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 j41BEvs1044943; Sun, 1 May 2005 04:14:57 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41BEs8C044897 for ; Sun, 1 May 2005 04:14:56 -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); Sun, 1 May 2005 21:05:40 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 01 May 2005 21:14:45 +1000 Subject: Re: PaceExplainDuplicateIds From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050430133435a4e501@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 1/5/05 6:34 AM, "Robert Sayre" wrote: > Say someone writes a quick PHP script that doesn't keep any state and > loops through the entries to display them on a web page. They'll have > different results than a well-written desktop aggregator. a well written aggregator may well also mimic the behaviour of that PHP hack, opting to display all versions of the entry with the duplicate ID. This would be correct behaviour for a feed of wiki-page history, for example. e. From owner-atom-syntax@mail.imc.org Sun May 1 07:23:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14867 for ; Sun, 1 May 2005 07:23: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 j41BGLk3045560; Sun, 1 May 2005 04:16: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 j41BGLbX045559; Sun, 1 May 2005 04:16:21 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41BGKaN045535 for ; Sun, 1 May 2005 04:16:20 -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); Sun, 1 May 2005 21:07:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 01 May 2005 21:16:16 +1000 Subject: Re: PaceOptionalFeedLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050430120381bba2a@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 1/5/05 5:03 AM, "Robert Sayre" wrote: > "atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same > combination of type and hreflang attribute values." how do I then point to both my full content feed *and* my summary only feed (and just quietly, my titles only feed)? the above spec text would make this invalid: e. From owner-atom-syntax@mail.imc.org Sun May 1 10:05:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23712 for ; Sun, 1 May 2005 10:05: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 j41Dv1S1095015; Sun, 1 May 2005 06:57: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 j41Dv1qo095014; Sun, 1 May 2005 06:57:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41Dux9I094985 for ; Sun, 1 May 2005 06:57:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j41DtuMu024650; Sun, 1 May 2005 14:56:07 +0100 (BST) In-Reply-To: <68fba5c5050430133435a4e501@mail.gmail.com> References: <68fba5c505043013021b5ae924@mail.gmail.com> <68fba5c5050430133435a4e501@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7210BE24-61A7-4CBA-BE7E-9588B0E2347A@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceExplainDuplicateIds Date: Sun, 1 May 2005 14:55:55 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Apr 2005, at 9:34 pm, Robert Sayre wrote: > Say someone writes a quick PHP script that doesn't keep any state and > loops through the entries to display them on a web page. They'll have > different results than a well-written desktop aggregator. A well-written desktop RSS aggregator would consider it a mistake on the publisher's part and display all entries in the feed rather than throwing away data. The current Atom policy of banning duplicate ids backs up this policy. If you want to come up with a different policy, that's fine, but this Pace changes us from having one to having none. -1 Graham From owner-atom-syntax@mail.imc.org Sun May 1 10:12:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24407 for ; Sun, 1 May 2005 10:12: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 j41E4NEA096039; Sun, 1 May 2005 07:04: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 j41E4N0e096038; Sun, 1 May 2005 07:04:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41E4Lut096021 for ; Sun, 1 May 2005 07:04:22 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j41E3g7N026244; Sun, 1 May 2005 15:03:42 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalFeedLink Date: Sun, 1 May 2005 15:03:41 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 May 2005, at 12:16 pm, Eric Scheid wrote: > how do I then point to both my full content feed *and* my summary > only feed > (and just quietly, my titles only feed)? I hope that you don't. Unless we have a programmatic way of describing the differences between those links, the best policy is for the publisher to pick one. User intervention isn't always possible. The spec already contains the requirement: > atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same type > attribute value. atom:feed elements MAY contain additional > atom:link elements beyond those described above. (Which the pace doesn't remove, but also adds the text: > "atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same > combination of type and hreflang attribute values." So, if accepted, we'd have 2 conflicting rules. The Pace needs an edit) Graham From owner-atom-syntax@mail.imc.org Sun May 1 10:42:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26177 for ; Sun, 1 May 2005 10:42: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 j41EYsel099695; Sun, 1 May 2005 07:34: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 j41EYsVt099694; Sun, 1 May 2005 07:34: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41EYreH099676 for ; Sun, 1 May 2005 07:34:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2571345wra for ; Sun, 01 May 2005 07:34:48 -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=FsXr9uGOX0tMVbxKVh3skuIhb18CDMt3IcZXJAJmb72I/t5/RVsB/aUalmrBXlE2lnLfbqKTbLSlqGsgbv+brC+chQaTvLQyGWpqj3jC53oyjR3VJ9y1bRWY8d2GVRjyk0AZCx8H50ErXT8k74ZiGzRSw++OHIMLYI2QlXKvSSM= Received: by 10.54.33.32 with SMTP id g32mr159715wrg; Sun, 01 May 2005 07:34:48 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sun, 1 May 2005 07:34:48 -0700 (PDT) Message-ID: <68fba5c505050107346856e610@mail.gmail.com> Date: Sun, 1 May 2005 10:34:48 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceOptionalFeedLink Cc: Eric Scheid , atom-syntax 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 j41EYreH099688 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > So, if accepted, we'd have 2 conflicting rules. The Pace needs an edit) D'oh. You're right. I've edited the Pace, to just delete the MUST. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 1 11:56:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29517 for ; Sun, 1 May 2005 11:56: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 j41FmbOu012149; Sun, 1 May 2005 08: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 j41FmbTO012148; Sun, 1 May 2005 08:48: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j41FmZGw012123 for ; Sun, 1 May 2005 08:48:35 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 May 2005 15:48:28 -0000 Received: from xdsl-81-173-175-251.netcologne.de (EHLO klangraum) [81.173.175.251] by mail.gmx.net (mp003) with SMTP; 01 May 2005 17:48:28 +0200 X-Authenticated: #163624 Date: Sun, 1 May 2005 17:51:37 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: PaceExplainDuplicateIds Message-ID: <20050501155137.GA20127@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c505043013021b5ae924@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c505043013021b5ae924@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-04-30 22:15]: > Remove the bullet point that reads > > {{{ atom:feed elements MUST NOT contain atom:entry elements > with identical atom:id values. }}} > > Add a paragraph after the list that reads > > {{{ > Atom Processors use the atom:id element found in Atom entries > to identify distinct entries. It is RECOMMENDED that each entry > in an Atom Feed Document have a distinct atom:id value. > }}} -1 I would +1 allowing identical IDs if it was required that the entries sharing an ID had different sources. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 1 12:44:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01686 for ; Sun, 1 May 2005 12:44: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 j41GUUDp017258; Sun, 1 May 2005 09:30: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 j41GUUVb017257; Sun, 1 May 2005 09:30:30 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41GUSKn017240 for ; Sun, 1 May 2005 09:30:29 -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, 2 May 2005 02:17:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 02 May 2005 02:18:00 +1000 Subject: Re: PaceExplainDuplicateIds From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050501155137.GA20127@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 2/5/05 1:51 AM, "A. Pagaltzis" wrote: > I would +1 allowing identical IDs if it was required that the > entries sharing an ID had different sources. perhaps we need to explain the concept of 'entries' (as resources), as distinct from s (as representations), and explain that 'entries' must have unique IDs, and that the element of any ties it back to the 'entry' resource. It would then follow that multiple representations which happen to have the same value are just different representations of the source 'entry', and possibly even different instantiations in time. e. From owner-atom-syntax@mail.imc.org Sun May 1 14:22:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06482 for ; Sun, 1 May 2005 14:22: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 j41IBJcm031293; Sun, 1 May 2005 11:11: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 j41IBJHM031292; Sun, 1 May 2005 11:11:19 -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 j41IBHeW031275 for ; Sun, 1 May 2005 11:11:18 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 01 May 2005 18:11:08 -0000 Received: from xdsl-81-173-175-251.netcologne.de (EHLO klangraum) [81.173.175.251] by mail.gmx.net (mp027) with SMTP; 01 May 2005 20:11:08 +0200 X-Authenticated: #163624 Date: Sun, 1 May 2005 20:14:17 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: PaceExplainDuplicateIds Message-ID: <20050501181417.GA20611@klangraum> Mail-Followup-To: Atom Syntax References: <20050501155137.GA20127@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-05-01 18:45]: > perhaps we need to explain the concept of 'entries' (as > resources), as distinct from s (as representations), and > explain that 'entries' must have unique IDs, and that the > element of any ties it back to the > 'entry' resource. That definitely sounds like a plan. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 1 14:51:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08309 for ; Sun, 1 May 2005 14:51: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 j41Ihwx5035695; Sun, 1 May 2005 11: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 j41Ihwdx035694; Sun, 1 May 2005 11:43:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41IhvA0035676 for ; Sun, 1 May 2005 11:43:57 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j41IhVZ09399 for ; Sun, 1 May 2005 11:43:47 -0700 (PDT) Received: from [10.169.186.6] ([10.169.186.6]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IFTQOJ01.R06; Sun, 1 May 2005 11:43:31 -0700 Message-ID: <42752356.3060302@aol.net> Date: Sun, 01 May 2005 11:43:34 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceExplainDuplicateIds References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050403080601070100030803" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------050403080601070100030803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 2/5/05 1:51 AM, "A. Pagaltzis" wrote: > > > >>I would +1 allowing identical IDs if it was required that the >>entries sharing an ID had different sources. >> >> > >perhaps we need to explain the concept of 'entries' (as resources), as >distinct from s (as representations), and explain that 'entries' must >have unique IDs, and that the element of any ties it >back to the 'entry' resource. It would then follow that multiple >representations which happen to have the same value are just >different representations of the source 'entry', and possibly even different >instantiations in time. > >e. > > > +1. --------------050403080601070100030803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Scheid wrote: 
On 2/5/05 1:51 AM, "A. Pagaltzis" <pagaltzis@gmx.de> wrote:

  
I would +1 allowing identical IDs if it was required that the
entries sharing an ID had different sources.
    

perhaps we need to explain the concept of 'entries' (as resources), as
distinct from <entry>s (as representations), and explain that 'entries' must
have unique IDs, and that the <atom:id> element of any <atom:entry> ties it
back to the 'entry' resource. It would then follow that multiple <entry>
representations which happen to have the same <atom:id> value are just
different representations of the source 'entry', and possibly even different
instantiations in time.

e.
+1.

--------------050403080601070100030803-- From owner-atom-syntax@mail.imc.org Sun May 1 15:16:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11083 for ; Sun, 1 May 2005 15:16: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 j41JA3OS040053; Sun, 1 May 2005 12:10: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 j41JA3rh040052; Sun, 1 May 2005 12:10:03 -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 j41JA1K9040035 for ; Sun, 1 May 2005 12:10:02 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 01 May 2005 19:09:55 -0000 Received: from p508FD364.dip.t-dialin.net (EHLO [192.168.0.4]) [80.143.211.100] by mail.gmx.net (mp023) with SMTP; 01 May 2005 21:09:55 +0200 X-Authenticated: #1915285 Message-ID: <42752976.70509@gmx.de> Date: Sun, 01 May 2005 21:09:42 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: PaceOptionalFeedLink References: <68fba5c5050430120381bba2a@mail.gmail.com> In-Reply-To: <68fba5c5050430120381bba2a@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 +1 for nor requiring the link element. Best regards, Julian From owner-atom-syntax@mail.imc.org Sun May 1 15:20:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11915 for ; Sun, 1 May 2005 15:20: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 j41JEZ2A040843; Sun, 1 May 2005 12:14: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 j41JEZbo040842; Sun, 1 May 2005 12:14:35 -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 j41JEXIB040826 for ; Sun, 1 May 2005 12:14:34 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 01 May 2005 19:14:27 -0000 Received: from p508FD364.dip.t-dialin.net (EHLO [192.168.0.4]) [80.143.211.100] by mail.gmx.net (mp026) with SMTP; 01 May 2005 21:14:27 +0200 X-Authenticated: #1915285 Message-ID: <42752A88.9010103@gmx.de> Date: Sun, 01 May 2005 21:14:16 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: atom-syntax@imc.org Subject: Re: PaceXhtmlDivSuggestedOnly References: <42739975.20003@cegetel.net> In-Reply-To: <42739975.20003@cegetel.net> Content-Type: text/plain; charset=UTF-8; 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 For the record...: +1 on not requiring wrapper elements +1 on properly distinguishing between block-level and in-line +1 on using the same recommendations for type="html" as well Best regards, Julian From owner-atom-syntax@mail.imc.org Sun May 1 15:35:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12520 for ; Sun, 1 May 2005 15:35: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 j41JQam2042481; Sun, 1 May 2005 12:26: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 j41JQaDP042480; Sun, 1 May 2005 12:26:36 -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 j41JQavZ042473 for ; Sun, 1 May 2005 12:26:36 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 3080 invoked by uid 17064); 1 May 2005 19:26:35 -0000 Received: from unknown (HELO [192.168.0.7]) ([83.112.239.129]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 May 2005 19:26:35 -0000 To: atom-syntax Syntax Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <253AA809-7269-46EF-AC82-2B3A8146AA22@bblfish.net> Cc: Eric Scheid Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceExplainDuplicateIds Date: Sun, 1 May 2005 20:10:17 +0200 X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 May 2005, at 18:18, Eric Scheid wrote: > On 2/5/05 1:51 AM, "A. Pagaltzis" wrote: > >> I would +1 allowing identical IDs if it was required that the >> entries sharing an ID had different sources. >> >> > > perhaps we need to explain the concept of 'entries' (as resources), as > distinct from s (as representations), and explain that > 'entries' must > have unique IDs, and that the element of any > ties it > back to the 'entry' resource. It would then follow that multiple > > representations which happen to have the same value are just > different representations of the source 'entry', and possibly even > different > instantiations in time. > Exactly. I think this will help dissolve the issue very easily. The way I am currently thinking of this is as follows. The .... xml we find in a atom feed is a time stamped representation of a resource. It is the state of a resource at a particular time. Or perhaps better: it is metadata about the state of a resource at a particular time. If we then think of the entry id as a resource, then we may think of all of these xml representations as representations of that id, where the representations each specify the date and time of their validity. Because the representations contain the date and time of their validity they can be placed in a collection without ambiguity. So there is a little distinction we need to be careful of: an "..." representation is a representation *of* the id resource, but these representations are *about* the state of some other resources at a particular time (most notably the link "alternate" resource). Henry Story http://bblfish.net/blog/ > e. > > From owner-atom-syntax@mail.imc.org Sun May 1 18:19:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21103 for ; Sun, 1 May 2005 18:19: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 j41MBLYm061332; Sun, 1 May 2005 15:11: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 j41MBLDi061331; Sun, 1 May 2005 15:11:21 -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 j41MBJPD061323 for ; Sun, 1 May 2005 15:11:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (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 j41KFhor031715; Sun, 1 May 2005 16:15:44 -0400 Message-ID: <42755401.9040701@intertwingly.net> Date: Sun, 01 May 2005 18:11:13 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Panzer CC: Eric Scheid , Atom Syntax Subject: Re: PaceExplainDuplicateIds References: <42752356.3060302@aol.net> In-Reply-To: <42752356.3060302@aol.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 John Panzer wrote: > Eric Scheid wrote: > >>On 2/5/05 1:51 AM, "A. Pagaltzis" wrote: >> >>>I would +1 allowing identical IDs if it was required that the >>>entries sharing an ID had different sources. >> >>perhaps we need to explain the concept of 'entries' (as resources), as >>distinct from s (as representations), and explain that 'entries' must >>have unique IDs, and that the element of any ties it >>back to the 'entry' resource. It would then follow that multiple >>representations which happen to have the same value are just >>different representations of the source 'entry', and possibly even different >>instantiations in time. >> >>e. >> > +1. To me, this sounds very much like the following Pace: http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument If the current proposal is different, how so? If not, have people reviewed the discussion that occurred when that particular proposal was brought before the working group? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 2 00:47:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10715 for ; Mon, 2 May 2005 00:47: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 j424chdA015019; Sun, 1 May 2005 21:38: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 j424ch3K015018; Sun, 1 May 2005 21:38:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from S1.cableone.net (smtp1.cableone.net [24.116.0.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j424cgua015001 for ; Sun, 1 May 2005 21:38:43 -0700 (PDT) (envelope-from Kevin@Electricdiary.com) Received: from icarus (unverified [24.119.170.182]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 18407813 for ; Sun, 01 May 2005 21:38:59 -0700 From: "Kevin Mesiab" To: "'atom-syntax'" Subject: RE: PaceOptionalFeedLink Date: Sun, 1 May 2005 22:38:36 -0600 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: AcVOW2hfa5bBtQjJT9imevwm3ldrTwAdQanw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <68fba5c505050107346856e610@mail.gmail.com> Message-ID: <1115008739_84337@S1.cableone.net> X-IP-stats: Incoming Last 0, First 11, in=12, out=0, spam=0 X-External-IP: 24.119.170.182 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In regards to atom:source construct: This, to me, seems like adding verbosity to the feed that does not necessarily need to be there. The attributes specified in the source construct are the 'meta' elements of any feed. Why not make the source element a URI to the resources feed and implementers who want the info can deference the link. -Kevin Mesiab Founder, Electric Diary Publishing 208-863-4235 -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Robert Sayre Sent: Sunday, May 01, 2005 8:35 AM To: Graham Cc: Eric Scheid; atom-syntax Subject: Re: PaceOptionalFeedLink > > So, if accepted, we'd have 2 conflicting rules. The Pace needs an edit) D'oh. You're right. I've edited the Pace, to just delete the MUST. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 2 02:53:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08658 for ; Mon, 2 May 2005 02:53: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 j426jX5V069726; Sun, 1 May 2005 23:45: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 j426jXhD069725; Sun, 1 May 2005 23:45:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j426jWkJ069709 for ; Sun, 1 May 2005 23:45:32 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j426jVWj005459 for ; Mon, 2 May 2005 02:45:31 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBK13118; Mon, 2 May 2005 02:45:30 -0400 (EDT) Message-Id: <200505020645.DBK13118@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! Date: Mon, 2 May 2005 02:45: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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVO4oYzkyxOc9FbSX6fwkdhXlMBJg== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit For yet another reason why aggregators deliver up duplicate entries, See: http://bobwyman.pubsub.com/main/2005/05/rss_ads_done_th.html Hopefully, Atom V1.0 will make it easier for us to isolate our users from the impact of poorly designed advertising programs... bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 03:41:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11217 for ; Mon, 2 May 2005 03: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 j427YMCh090794; Mon, 2 May 2005 00:34: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 j427YMZA090793; Mon, 2 May 2005 00:34: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j427YJrP090744 for ; Mon, 2 May 2005 00:34:21 -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, 2 May 2005 17:23:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 02 May 2005 17:32:22 +1000 Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200505020645.DBK13118@ms8.netsolmail.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 2/5/05 4:45 PM, "Bob Wyman" wrote: > > For yet another reason why aggregators deliver up duplicate entries, > > See: http://bobwyman.pubsub.com/main/2005/05/rss_ads_done_th.html > > Hopefully, Atom V1.0 will make it easier for us to isolate our users from > the impact of poorly designed advertising programs... look closer at the 'ord' value... http://ad.doubleclick.net/jump/idg.us.idg.net.standard.rsstower/;pos=skyscra per;tile=2;sz=160x600;ord=20050428170456 my, that does look like this: 2005/04/28 17:04:56 They are inserting a timestamp. They don't really care that much about tracking the 'ord' value. They *do* care about getting accurate counts of 'impressions'. Counting impressions is essential to their trade, and you'll find that it is industry standard practice. Sadly. e. From owner-atom-syntax@mail.imc.org Mon May 2 06:50:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00632 for ; Mon, 2 May 2005 06:50: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 j42AhUrf068328; Mon, 2 May 2005 03:43: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 j42AhU8O068327; Mon, 2 May 2005 03:43:30 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42AhTAc068310 for ; Mon, 2 May 2005 03:43:30 -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 1DSYOe-000149-00; Mon, 02 May 2005 11:43:28 +0100 Date: Mon, 2 May 2005 11:43:28 +0100 From: James Aylett To: Atom Syntax Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! Message-ID: <20050502104328.GA2772@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <200505020645.DBK13118@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 02, 2005 at 05:32:22PM +1000, Eric Scheid wrote: > look closer at the 'ord' value... > > http://ad.doubleclick.net/jump/idg.us.idg.net.standard.rsstower/;pos=skyscra > per;tile=2;sz=160x600;ord=20050428170456 > > my, that does look like this: > > 2005/04/28 17:04:56 > > They are inserting a timestamp. They don't really care that much about > tracking the 'ord' value. They *do* care about getting accurate counts of > 'impressions'. Indeed, ord= is a random number (usually calculated as a timestamp, for convenience). Note that DCLK has a mechanism for when a dynamic ord value cannot be calculated, which I imagine gets slightly different processing at there end. (It's used for static embedded tags.) ord=1, from memory. > Counting impressions is essential to their trade, and you'll find > that it is industry standard practice. A couple of things I'd say about this: (1) this is broadly true :-) (2) but it's not that uncommon for people to need to track static instances - consider, for instance emails; HTTP level cache control is being used as well. There's no reason RSS feeds can't be considered in this way. (3) that's a clickthrough URL (/jump/); the actual thing that will change in content is the /ad/ call, right after. The ord value in both will change, and will always match. So yes, Eric is right that they don't care about the ord value. Note however that it's also possible to track other things through DCLK (and other ad industry) tags, and the tag might be generated on the fly based on all sorts of things that they sometimes do want to track. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 2 08:33:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10243 for ; Mon, 2 May 2005 08: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 j42CPY6a012222; Mon, 2 May 2005 05:25: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 j42CPYv6012221; Mon, 2 May 2005 05:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42CPWmS012163 for ; Mon, 2 May 2005 05:25:33 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 7854 invoked from network); 2 May 2005 14:25:23 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 14:25:23 +0200 Message-ID: <42761C3C.6080507@wp.pl> Date: Mon, 02 May 2005 14:25:32 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: suggestion: add new value to type attribute Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.939116) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that you should add new value to type attribute (3.1.1) - xml type="xml" This value will allow embed not only text, HTML and XHTML but also others XML applications like SVG, SMIL etc. Like in XSLT 2.0 draft in method attribute. Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 08:50:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13017 for ; Mon, 2 May 2005 08:50: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 j42Chk3c020646; Mon, 2 May 2005 05:43: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 j42Chkis020645; Mon, 2 May 2005 05:43:46 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42Chj66020611 for ; Mon, 2 May 2005 05:43:46 -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, 2 May 2005 22:34:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 02 May 2005 22:43:39 +1000 Subject: Re: suggestion: add new value to type attribute From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42761C3C.6080507@wp.pl> 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/5/05 10:25 PM, "Domel" wrote: > I think that you should add new value to type attribute (3.1.1) - xml > type="xml" > This value will allow embed not only text, HTML and XHTML but also > others XML applications like SVG, SMIL etc. > Like in XSLT 2.0 draft in method attribute. > the way it's done is that you put the mime-type of the xml into the type attribute. That way you can not only have xml content, but you also clearly communicate just what kind of xml it is. e. From owner-atom-syntax@mail.imc.org Mon May 2 09:11:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15063 for ; Mon, 2 May 2005 09:11: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 j42D43QB028469; Mon, 2 May 2005 06:04: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 j42D43lN028468; Mon, 2 May 2005 06:04:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42D41Rd028450 for ; Mon, 2 May 2005 06:04:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j42D33gK010346; Mon, 2 May 2005 14:03:09 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33217AF6-78CF-488C-9FCB-B77D3A60533D@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: suggestion: add new value to type attribute Date: Mon, 2 May 2005 14:03:00 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 May 2005, at 1:43 pm, Eric Scheid wrote: > On 2/5/05 10:25 PM, "Domel" wrote: > >> I think that you should add new value to type attribute (3.1.1) - xml >> type="xml" >> This value will allow embed not only text, HTML and XHTML but also >> others XML applications like SVG, SMIL etc. >> Like in XSLT 2.0 draft in method attribute. > the way it's done is that you put the mime-type of the xml into the > type > attribute. That way you can not only have xml content, but you also > clearly > communicate just what kind of xml it is. Actual 3.1.1 is the section on Text Constructs (atom:title, atom:summary, etc), which do not allow arbitrary XML, or MIME types in the type attribute. In answer to the original suggestion, you may embed arbitrary XML in the atom:content element (as Eric described), but not in the title or summary, which are designed to be universally readable by any client, and thus have a limited feature set. Graham From owner-atom-syntax@mail.imc.org Mon May 2 09:12:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15175 for ; Mon, 2 May 2005 09:12: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 j42D6CFL028725; Mon, 2 May 2005 06:06: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 j42D6CNG028724; Mon, 2 May 2005 06:06:12 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42D6BYA028713 for ; Mon, 2 May 2005 06:06:11 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id 441A422C196; Mon, 2 May 2005 15:06:04 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Mon, 2 May 2005 15:06:05 +0200 (CEST) Message-ID: <1345.82.127.77.43.1115039165.squirrel@ssl-webmail.sitadelle.com> Date: Mon, 2 May 2005 15:06:05 +0200 (CEST) Subject: Re: suggestion: add new value to type attribute From: "Thomas Broyer" To: In-Reply-To: References: <42761C3C.6080507@wp.pl> 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 Eric Scheid wrote: > > On 2/5/05 10:25 PM, "Domel" wrote: > >> I think that you should add new value to type attribute (3.1.1) - xml >> type="xml" >> This value will allow embed not only text, HTML and XHTML but also >> others XML applications like SVG, SMIL etc. >> Like in XSLT 2.0 draft in method attribute. >> > > the way it's done is that you put the mime-type of the xml into the type > attribute. That way you can not only have xml content, but you also > clearly communicate just what kind of xml it is. Note that this is only applicable to atom:content, not to Text Constructs, as these are really meant to be textual content: title, subtitle, summary and copyright. As we're about it, it might be good to have some text about possible future values and how Atom 1.0 compliant processors are supposed to handle those values. For example, assume Atom 2.0 adds the new value "docbook". How would Atom 1.0 processors treat a text construct with type="docbook"? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 2 09:40:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17130 for ; Mon, 2 May 2005 09:40: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 j42DWwdw032801; Mon, 2 May 2005 06:32: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 j42DWwFl032800; Mon, 2 May 2005 06:32:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42DWvIY032784 for ; Mon, 2 May 2005 06:32:58 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 6455 invoked from network); 2 May 2005 15:32:49 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 15:32:49 +0200 Message-ID: <42762C0E.1010905@wp.pl> Date: Mon, 02 May 2005 15:33:02 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: suggestion: mention about xml:id Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.560838) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that you should mention about xml:id attribute (just like you did with xml:base attribute). xml:id is very useful attribute. It can be used in XPath, XPointer, CSS, DOM (maybe in JS) etc. http://www.w3.org/TR/xml-id/ (now in CR) Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 09:46:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17667 for ; Mon, 2 May 2005 09:46: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 j42DfEP9034000; Mon, 2 May 2005 06:41: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 j42DfEDQ033999; Mon, 2 May 2005 06:41:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42DfDLL033982 for ; Mon, 2 May 2005 06:41:13 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 15008 invoked by uid 10); 2 May 2005 13:41:06 -0000 Received: (vexira-qq 14995-728028A5 invoked from network) 02 May 2005 15:41:05 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2005 13:41:05 -0000 Message-ID: <42762DF0.90804@annevankesteren.nl> Date: Mon, 02 May 2005 15:41:04 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Domel CC: atom-syntax@imc.org Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> In-Reply-To: <42762C0E.1010905@wp.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Domel wrote: > I think that you should mention about xml:id attribute (just like you > did with xml:base attribute). > xml:id is very useful attribute. It can be used in XPath, XPointer, CSS, > DOM (maybe in JS) etc. > > http://www.w3.org/TR/xml-id/ (now in CR) What is the use case? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 2 10:10:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19720 for ; Mon, 2 May 2005 10:10: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 j42E35gS036706; Mon, 2 May 2005 07:03: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 j42E35lQ036705; Mon, 2 May 2005 07:03:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42E33Lu036680 for ; Mon, 2 May 2005 07:03:04 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 14406 invoked by uid 10); 2 May 2005 14:02:57 -0000 Received: (vexira-qq 14391-4BD8999F invoked from network) 02 May 2005 16:02:57 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2005 14:02:57 -0000 Message-ID: <42763310.2060708@annevankesteren.nl> Date: Mon, 02 May 2005 16:02:56 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Domel , Atom Syntax Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> In-Reply-To: <4276323F.1050808@wp.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Domel wrote: > Many case. Two examples: > 1. Selectros in CSS. Now selectors can only be element like * , E, E F, > E > F and pseudo-class/pseudo-elements like: E:first-child. But we can't > matche any E element ID. Atom 0.8 support xml:lang so support also > E:lang(c) but there aren't any id attributes to CSS 's E#myid Perhaps I should have been more specific. What is the use case of styling Atom? > 2. XPointers - point some parto of document in URI/IRI for example: > http://example.org/atom.xml#myid Also, what is the use case for this. What should it actually when given to a feed reader. Note also that you can safely add the xml:id attribute to any element without causing any harm. It might be that the feed validator dislikes it, but that should't be a problem. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 2 10:31:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21735 for ; Mon, 2 May 2005 10: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 j42EPV44039679; Mon, 2 May 2005 07:25: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 j42EPVca039678; Mon, 2 May 2005 07:25:31 -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 j42EPUPr039649 for ; Mon, 2 May 2005 07:25:30 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j42ERw24029453; Mon, 2 May 2005 07:27:59 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j42ERWd4007977; Mon, 2 May 2005 09:27:32 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j42EPRVp016659; Mon, 2 May 2005 09:25:27 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFV00I219EDB3@ims1.labs.mot.com>; Mon, 02 May 2005 09:25:25 -0500 (CDT) Date: Mon, 02 May 2005 09:25:25 -0500 From: Brett Lindsley Subject: Re: suggestion: add new value to type attribute To: Graham Cc: Eric Scheid , atom-syntax Message-id: <42763855.4090007@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <33217AF6-78CF-488C-9FCB-B77D3A60533D@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT One thought I had to make the TextConstruct and Content more similar is to have a type attribute in the TextConstruct; however, the TextConstruct could be limited to types of text/plain, text/html and text/xhtml. It would also eliminate the need for special types of TEXT, HTML and XHTML. Brett Lindsley, Motorola Labs Graham wrote: > > > On 2 May 2005, at 1:43 pm, Eric Scheid wrote: > >> On 2/5/05 10:25 PM, "Domel" wrote: >> >>> I think that you should add new value to type attribute (3.1.1) - xml >>> type="xml" >>> This value will allow embed not only text, HTML and XHTML but also >>> others XML applications like SVG, SMIL etc. >>> Like in XSLT 2.0 draft in method attribute. >> > >> the way it's done is that you put the mime-type of the xml into the >> type >> attribute. That way you can not only have xml content, but you also >> clearly >> communicate just what kind of xml it is. > > > Actual 3.1.1 is the section on Text Constructs (atom:title, > atom:summary, etc), which do not allow arbitrary XML, or MIME types > in the type attribute. > > In answer to the original suggestion, you may embed arbitrary XML in > the atom:content element (as Eric described), but not in the title or > summary, which are designed to be universally readable by any client, > and thus have a limited feature set. > > Graham > From owner-atom-syntax@mail.imc.org Mon May 2 10:41:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22541 for ; Mon, 2 May 2005 10:41: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 j42EWjXJ040550; Mon, 2 May 2005 07:32: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 j42EWjI6040549; Mon, 2 May 2005 07:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EWi9O040532 for ; Mon, 2 May 2005 07:32:45 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j42EWapc009655 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 2 May 2005 10:32:37 -0400 (EDT) Message-ID: <42763AF6.1050800@atrus.org> Date: Mon, 02 May 2005 10:36:38 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> <42763310.2060708@annevankesteren.nl> In-Reply-To: <42763310.2060708@annevankesteren.nl> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Domel wrote: > >> Many case. Two examples: >> 1. Selectros in CSS. Now selectors can only be element like * , E, E >> F, E > F and pseudo-class/pseudo-elements like: E:first-child. But we >> can't matche any E element ID. Atom 0.8 support xml:lang so support >> also E:lang(c) but there aren't any id attributes to CSS 's E#myid > > > Perhaps I should have been more specific. What is the use case of > styling Atom? > > >> 2. XPointers - point some parto of document in URI/IRI for example: >> http://example.org/atom.xml#myid > > > Also, what is the use case for this. What should it actually when > given to a feed reader. > > Note also that you can safely add the xml:id attribute to any element > without causing any harm. It might be that the feed validator dislikes > it, but that should't be a problem. I concur. XML has many useful features. The Atom spec should only cover ones that are: 1) likely to be useful in a significant portion of cases (the use cases) 2) require clarification in the context of Atom If you look at section 2, where xml:lang and xml:base are mentioned, you can see that they require some clarification (base MUSt be used to resolve relative URLs, lang has some context and inheritence issues). -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Mon May 2 10:46:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22964 for ; Mon, 2 May 2005 10:46: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 j42Egdc1042120; Mon, 2 May 2005 07: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 j42Egd2I042119; Mon, 2 May 2005 07:42:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EgcFn042101 for ; Mon, 2 May 2005 07:42:39 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 15493 invoked from network); 2 May 2005 16:42:22 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 16:42:22 +0200 Message-ID: <42763C83.50505@wp.pl> Date: Mon, 02 May 2005 16:43:15 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> <42763310.2060708@annevankesteren.nl> In-Reply-To: <42763310.2060708@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.972407) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > Perhaps I should have been more specific. What is the use case of > styling Atom? Some people styling feeds. OK, I don't think everybody must styling Atom but when somebody want why not? > Also, what is the use case for this. What should it actually when > given to a feed reader. I don't agree. XPointers give a lot of advantages to feed reader (framework to navigation and other "going" to some part, it allow display field which will be define). It has also advantages to linking to Atom. OK, another example: 3. DOM tree - getElementByID Atom is a XML application and majority of XML application define id attribute. XML also refer to ID attribute. xml:id is like predefined atributtes should support it. http://www.w3.org/2001/xml.xsd Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 10:46:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22984 for ; Mon, 2 May 2005 10: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 j42EfhRC041990; Mon, 2 May 2005 07:41: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 j42EfhmG041988; Mon, 2 May 2005 07:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EfgOs041971 for ; Mon, 2 May 2005 07:41:42 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 22614 invoked from network); 2 May 2005 16:41:36 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 16:41:36 +0200 Message-ID: <42763C50.9010600@wp.pl> Date: Mon, 02 May 2005 16:42:24 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.690656) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Example of my type="xml" Support SVG Hello, out there Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 10:50:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23141 for ; Mon, 2 May 2005 10:49: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 j42EelpX041701; Mon, 2 May 2005 07:40: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 j42EelVU041699; Mon, 2 May 2005 07:40:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EejTr041634 for ; Mon, 2 May 2005 07:40:46 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 16090 invoked by uid 10); 2 May 2005 14:40:38 -0000 Received: (vexira-qq 16083-F7C3EA9E invoked from network) 02 May 2005 16:40:38 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2005 14:40:38 -0000 Message-ID: <42763BE5.8070606@annevankesteren.nl> Date: Mon, 02 May 2005 16:40:37 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Domel , Atom Syntax Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> <42763310.2060708@annevankesteren.nl> <427639A9.90101@wp.pl> In-Reply-To: <427639A9.90101@wp.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Domel wrote: >> Perhaps I should have been more specific. What is the use case of >> styling Atom? > > Some people styling feeds. OK, I don't think everybody must styling Atom > but when somebody want why not? Yeah why not? That does not have anything to do with Atom mentioning the xml:id attribute though. Authors can include it themselves if desired. xml:base and xml:lang solve specific Atom problems, xml:id doesn't do that. (Atom uses something else to uniquely identify each entry. It also couldn't reuse xml:id for this by the way.) >> Also, what is the use case for this. What should it actually when >> given to a feed reader. I meant: "What should it actually [do] when given to a feed reader". > I don't agree. I'm not sure how you can't agree when I didn't even make a statement. > XPointers give a lot of advantages to feed reader > (framework to navigation and other "going" to some part, it allow > display field which will be define). It has also advantages to linking > to Atom. So are you saying XPointer should be part of the Atom specification as well..? > OK, another example: > 3. DOM tree - getElementByID Again, what is the use case for Atom? > Atom is a XML application and majority of XML application define id > attribute. Because they need an ID attribute, Atom doesn't. > XML also refer to ID attribute. xml:id is like predefined > atributtes should support it. http://www.w3.org/2001/xml.xsd That does not mean Atom has to include a reference to it in the specification and depend on xml:id to become a rec. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 2 10:50:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23168 for ; Mon, 2 May 2005 10:50: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 j42EgE2i042071; Mon, 2 May 2005 07:42: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 j42EgEbE042070; Mon, 2 May 2005 07:42:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42EgBl5042045 for ; Mon, 2 May 2005 07:42:13 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 854 invoked from network); 2 May 2005 16:42:05 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 16:42:05 +0200 Message-ID: <42763C73.7020507@wp.pl> Date: Mon, 02 May 2005 16:42:59 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> In-Reply-To: <42762DF0.90804@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.506569) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > What is the use case? Many case. Two examples: 1. Selectros in CSS. Now selectors can only be element like * , E, E F, E > F and pseudo-class/pseudo-elements like: E:first-child. But we can't matche any E element ID. Atom 0.8 support xml:lang so support also E:lang(c) but there aren't any id attributes to CSS 's E#myid 2. XPointers - point some parto of document in URI/IRI for example: http://example.org/atom.xml#myid Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 11:13:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24876 for ; Mon, 2 May 2005 11:13: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 j42F3qwk045058; Mon, 2 May 2005 08:03: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 j42F3qag045057; Mon, 2 May 2005 08:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42F3ocW045028 for ; Mon, 2 May 2005 08:03:50 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 11214 invoked from network); 2 May 2005 17:03:44 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 17:03:44 +0200 Message-ID: <4276418E.3020706@wp.pl> Date: Mon, 02 May 2005 17:04:46 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: Anne van Kesteren , atom-syntax@imc.org Subject: Re: [SPAM] Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> <42763310.2060708@annevankesteren.nl> <427639A9.90101@wp.pl> <42763BE5.8070606@annevankesteren.nl> In-Reply-To: <42763BE5.8070606@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1 Fuz2=1) AS2=NO(0.875871) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Yeah why not? That does not have anything to do with Atom mentioning > the xml:id attribute though. Authors can include it themselves if > desired. xml:base and xml:lang solve specific Atom problems, xml:id > doesn't do that. (Atom uses something else to uniquely identify each > entry. It also couldn't reuse xml:id for this by the way.) I don't see difference between xml:lang and xml:id in this context, xml:lang MAY be used in Atom and in my proposition xml:id MAY be used. > > So are you saying XPointer should be part of the Atom specification as > well..? No, I say that xml:id should be part of Atom specyfication and when it will be then we can use XPointers in Atom (and other extensions) (analogy: Atom not need namespaces, XML rec don't defined xmlns attribute, but Atom has xmlns attribute, because it provide many features) > > Again, what is the use case for Atom? Grand of features to webdeveloper. Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 11:14:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24958 for ; Mon, 2 May 2005 11:14: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 j42F7iZA045509; Mon, 2 May 2005 08:07: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 j42F7ixF045508; Mon, 2 May 2005 08:07:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42F7huP045484 for ; Mon, 2 May 2005 08:07:43 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 1323 invoked from network); 2 May 2005 17:07:37 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 17:07:37 +0200 Message-ID: <42764278.4050409@wp.pl> Date: Mon, 02 May 2005 17:08:40 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org, Brett Lindsley Subject: Re: suggestion: add new value to type attribute References: <33217AF6-78CF-488C-9FCB-B77D3A60533D@mac.com> <42763855.4090007@labs.mot.com> In-Reply-To: <42763855.4090007@labs.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=NO(Body=1 Fuz1=1) AS2=NO(0.535980) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Brett Lindsley wrote: > text/xhtml application/xhtml+xml - RFC3236 ;-) Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 11:39:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26754 for ; Mon, 2 May 2005 11:39: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 j42FXDrr048891; Mon, 2 May 2005 08:33: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 j42FXDjb048890; Mon, 2 May 2005 08:33:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42FXC3g048883 for ; Mon, 2 May 2005 08:33:12 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j42FcXrB023951 for ; Mon, 2 May 2005 08:38:38 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j42FZmYW001642 for ; Mon, 2 May 2005 10:35:48 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j42FX1Vp018062; Mon, 2 May 2005 10:33:01 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFV00ITQCJ0B3@ims1.labs.mot.com>; Mon, 02 May 2005 10:33:00 -0500 (CDT) Date: Mon, 02 May 2005 10:33:00 -0500 From: Brett Lindsley Subject: Re: suggestion: add new value to type attribute To: Domel Cc: atom-syntax@imc.org, Brett Lindsley Message-id: <4276482C.5030407@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <33217AF6-78CF-488C-9FCB-B77D3A60533D@mac.com> <42763855.4090007@labs.mot.com> <42764278.4050409@wp.pl> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Nice catch. This does imply that processing embeded XML documents is different than processing embedded text. Of course, we've been talking about div, containers, namespaces, etc. My thought on this was to treat an embedded XML document as a block of escaped text and let a processor other than the Atom processor handle it. Thus, text/plain, text/html and application/xhtml+xml ;-) would all be processed consistently (as a block of escaped text). Special case handling (XML docs) would be done outside of the Atom parser without a need to worry about the Atom context. Brett Lindsley, Motorola Labs Domel wrote: > Brett Lindsley wrote: > >> text/xhtml > > > application/xhtml+xml - RFC3236 ;-) > > Dominik Tomaszuk > > > From owner-atom-syntax@mail.imc.org Mon May 2 11:46:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27421 for ; Mon, 2 May 2005 11:46: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 j42FdvSR049681; Mon, 2 May 2005 08:39: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 j42Fdvcx049680; Mon, 2 May 2005 08:39:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42FdtCe049646 for ; Mon, 2 May 2005 08:39:56 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 13628 invoked by uid 10); 2 May 2005 15:39:50 -0000 Received: (vexira-qq 13609-981E2A58 invoked from network) 02 May 2005 17:39:50 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2005 15:39:50 -0000 Message-ID: <427649C5.7020100@annevankesteren.nl> Date: Mon, 02 May 2005 17:39:49 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Lindsley CC: Domel , atom-syntax@imc.org, Brett Lindsley Subject: Re: suggestion: add new value to type attribute References: <33217AF6-78CF-488C-9FCB-B77D3A60533D@mac.com> <42763855.4090007@labs.mot.com> <42764278.4050409@wp.pl> <4276482C.5030407@labs.mot.com> In-Reply-To: <4276482C.5030407@labs.mot.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Brett Lindsley wrote: > My thought on this was to treat an embedded XML document as a block > of escaped text and let a processor other than the Atom processor handle > it. Thus, text/plain, text/html and application/xhtml+xml ;-) would all be > processed consistently (as a block of escaped text). Special case handling > (XML docs) would be done outside of the Atom parser without a need > to worry about the Atom context. XHTML is not escaped text and should not be treated as such imho. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 2 11:55:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27978 for ; Mon, 2 May 2005 11: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 j42FlWM4050619; Mon, 2 May 2005 08:47: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 j42FlWRc050618; Mon, 2 May 2005 08:47:32 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42FlWdi050610 for ; Mon, 2 May 2005 08:47:32 -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 1DSd8t-0001YX-00; Mon, 02 May 2005 16:47:31 +0100 Date: Mon, 2 May 2005 16:47:31 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute Message-ID: <20050502154731.GM2772@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <42763C50.9010600@wp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42763C50.9010600@wp.pl> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 02, 2005 at 04:42:24PM +0200, Domel wrote: > Example of my type="xml" > Support SVG > > > Hello, out there > > Hello, out there ? (4.1.3.3.4.) (Assuming is an acceptable root element for SVG.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 2 11:57:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28172 for ; Mon, 2 May 2005 11:57: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 j42FlxZ3050675; Mon, 2 May 2005 08:47: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 j42FlxVn050674; Mon, 2 May 2005 08:47: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 j42Flwdn050654 for ; Mon, 2 May 2005 08:47:59 -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 9E7399B for ; Mon, 2 May 2005 08:47:53 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j42Flpng029589 for ; Mon, 2 May 2005 08:47:53 -0700 (PDT) Date: Mon, 02 May 2005 08:48:12 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! Message-ID: <46E9D765EBB40232DBD9EE28@adsl-64-166-133-243.dsl.snfc21.pacbell.net> X-Mailer: Mulberry/4.0.0b1 (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 May 2, 2005 5:32:22 PM +1000 Eric Scheid wrote: > > Counting impressions is essential to their trade, and you'll find that it is > industry standard practice. Make that "was essential", and "should be a dying practice." Ads have moved to results-based billing, paying for clickthrough and conversion. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon May 2 12:30:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01637 for ; Mon, 2 May 2005 12:30: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 j42GNGVV055926; Mon, 2 May 2005 09:23: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 j42GNFBO055925; Mon, 2 May 2005 09:23:16 -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 j42GNFSe055909 for ; Mon, 2 May 2005 09:23:15 -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 <2005050216230801200dcgg8e>; Mon, 2 May 2005 16:23:09 +0000 Date: Mon, 2 May 2005 10:23:07 -0600 Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! 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: <46E9D765EBB40232DBD9EE28@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Message-Id: <77ACE0FC-BB26-11D9-9FF1-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, May 2, 2005, at 09:48 AM, Walter Underwood wrote: >> Counting impressions is essential to their trade, and you'll find >> that it is >> industry standard practice. > > Make that "was essential", and "should be a dying practice." Ads have > moved to > results-based billing, paying for clickthrough and conversion. > ...except that calculating clickthrough percentage is still important, and that requires counting impressions. From owner-atom-syntax@mail.imc.org Mon May 2 12:43:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02649 for ; Mon, 2 May 2005 12:43: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 j42GYpio057477; Mon, 2 May 2005 09:34: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 j42GYoqW057476; Mon, 2 May 2005 09:34:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42GYnKu057457 for ; Mon, 2 May 2005 09:34:50 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 3979 invoked by uid 10); 2 May 2005 16:34:44 -0000 Received: (vexira-qq 03968-726180D9 invoked from network) 02 May 2005 18:34:43 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2005 16:34:43 -0000 Message-ID: <427656A4.5040603@annevankesteren.nl> Date: Mon, 02 May 2005 18:34:44 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Aylett CC: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute References: <42763C50.9010600@wp.pl> <20050502154731.GM2772@tartarus.org> In-Reply-To: <20050502154731.GM2772@tartarus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Aylett wrote: > (Assuming is an acceptable root element for SVG.) It isn't. application/xml is probably more appropriate. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 2 13:49:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08670 for ; Mon, 2 May 2005 13:49: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 j42HU9Rj065437; Mon, 2 May 2005 10:30: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 j42HU9s3065436; Mon, 2 May 2005 10:30: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42HU7oJ065400 for ; Mon, 2 May 2005 10:30:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3056338wra for ; Mon, 02 May 2005 10:30:02 -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=MybcE3hlA+H32Wgzetwga7sztHBWZCbyyq084HvP+qnudPeF0rLEdfXj774NscTYiFCDrdzMCZPeEx5doIzY3nwopFqD1TtuqqK6cw0qFW0zWpfASs6P1VigvwlgMGLX/l9PLIzEGj1jIb/NILxIPu/vg8Q83uOJhrEpJSlQ15Q= Received: by 10.54.122.12 with SMTP id u12mr13178wrc; Mon, 02 May 2005 10:30:02 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 2 May 2005 10:30:01 -0700 (PDT) Message-ID: <68fba5c505050210301d2ad37c@mail.gmail.com> Date: Mon, 2 May 2005 13:30:01 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Cc: "atom-syntax Syntax'" In-Reply-To: <200504271548.DAO13916@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200504271548.DAO13916@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j42HU8oJ065429 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Bob Wyman wrote: > Alternatively, if you have a better > method then that proposed by Graham for defending against the attack, please > describe it. Otherwise, Graham's compromise should be accepted and the > specification revised. Is there a proposal on the table outlining the compromise? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 2 14:38:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16869 for ; Mon, 2 May 2005 14:38: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 j42IMr0V072548; Mon, 2 May 2005 11:22: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 j42IMrPB072547; Mon, 2 May 2005 11:22:53 -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 j42IMqOP072541 for ; Mon, 2 May 2005 11:22:52 -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 j42IMqjO014436 for ; Mon, 2 May 2005 12:22:52 -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 <0IFV005GGKE3PD@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 02 May 2005 12:22:52 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFV0008PKD58A@mail.sun.net> for atom-syntax@imc.org; Mon, 02 May 2005 12:22:51 -0600 (MDT) Date: Mon, 02 May 2005 11:23:53 -0700 From: Tim Bray Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint In-reply-to: <68fba5c505050210301d2ad37c@mail.gmail.com> To: Robert Sayre Cc: bob@wyman.us, "atom-syntax Syntax'" Message-id: <80f7524c61885c7be6b77e626e46bdcd@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200504271548.DAO13916@ms8.netsolmail.com> <68fba5c505050210301d2ad37c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 2, 2005, at 10:30 AM, Robert Sayre wrote: >> Alternatively, if you have a better >> method then that proposed by Graham for defending against the attack, >> please >> describe it. Otherwise, Graham's compromise should be accepted and the >> specification revised. > > Is there a proposal on the table outlining the compromise? I just asked Graham to write a Pace. -Tim From owner-atom-syntax@mail.imc.org Mon May 2 14:42:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17126 for ; Mon, 2 May 2005 14: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 j42IbhEP074885; Mon, 2 May 2005 11:37: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 j42Ibh9B074884; Mon, 2 May 2005 11:37:43 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IbgQY074853 for ; Mon, 2 May 2005 11:37:42 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.61.144]) by smtp.cegetel.net (Postfix) with ESMTP id 5966A22C19C; Mon, 2 May 2005 20:37:36 +0200 (CEST) Message-ID: <4276738C.4090007@cegetel.net> Date: Mon, 02 May 2005 20:38:04 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Domel Cc: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute References: <42763C50.9010600@wp.pl> In-Reply-To: <42763C50.9010600@wp.pl> 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 Domel wrote: > > Example of my type="xml" > Support SVG > > > Hello, out there > > SVG doesn't define embedding in other languages apart from providing a whole SVG document as defined by the SVG spec, e.g. in an "svg" element. Actually, you must provide an SVG viewport, which is done with the "svg" element, and a viewport can be a self-contained SVG document. Hello, out there -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 2 14:49:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17847 for ; Mon, 2 May 2005 14:49: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 j42IgtRl075608; Mon, 2 May 2005 11:42: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 j42IgtQB075607; Mon, 2 May 2005 11:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42Igshx075591 for ; Mon, 2 May 2005 11:42:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j42IfjT6006727 for ; Mon, 2 May 2005 19:41:45 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <2876AE2C-9873-43CD-9BCB-B436A91B7EF0@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: PaceDuplicateIDWithSource Date: Mon, 2 May 2005 19:41:47 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource Graham === Abstract Allow multiple version of an entry within a feed where the source id is different. Status Proposed Rationale The current spec does not allow multiple versions of the same entry within a feed. In normal usage, this is OK, but when merging two feeds into a single feed, it requires duplicate detection and the discarding of data. Note it does not make legal having an entry without a source and a entry with a source, both of which have the same entry id, since the feed without a source may come from the same feed as the one with. Proposal In relation to atompub-format-08: In section 4.1.1, replace: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values With: atom:feed elements MUST NOT contain an atom:entry element that has the same atom:id value as any other atom:entry element, unless both atom:entry elements each contain an atom:source element, and the two atom:id values in each atom:source element are different. Impacts Allows duplicate ids within feeds, so atom:source must also be examined when looking for duplicates. From owner-atom-syntax@mail.imc.org Mon May 2 14:57:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18480 for ; Mon, 2 May 2005 14: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 j42Inwc9076760; Mon, 2 May 2005 11:49: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 j42Inw33076759; Mon, 2 May 2005 11:49:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42InvD7076739 for ; Mon, 2 May 2005 11:49:57 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j42InLfH008325 for ; Mon, 2 May 2005 19:49:21 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <8478296E-3759-4483-8226-8019C4FA0B30@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: Last minute editorial suggestions Date: Mon, 2 May 2005 19:49:23 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit - In section 4.2.4 there's an obsolete reference to atom:head - In section 3.1.1.3, the text "The XHTML div element itself MUST NOT be considered part of the content" is inadequate. Replace with (or add): "The intended value of the content is contained within the XHTML div, and the div itself MUST be discarded." (I sort of suggested this before) - In section 4.2.7.1 "Comparing atom:id", the two lists give the impression of "these ones are different" and "but, these ones are the same" when reading quickly. I'd suggest either merging the lists and discussing the implications at the bottom, or moving the discussion to the top of each list: "For example, these are four distinct identifiers, despite their differences in case: http://www.example.org/thing http://www.example.org/Thing http://www.EXAMPLE.org/thing HTTP://www.example.org/thing Likewise, these are three distinct identifiers, because IRI %- escaping is significant for the purposes of comparison: http://www.example.com/~bob http://www.example.com/%7ebob http://www.example.com/%7Ebob" Graham From owner-atom-syntax@mail.imc.org Mon May 2 15:00:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18855 for ; Mon, 2 May 2005 15:00: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 j42IsnP6077417; Mon, 2 May 2005 11:54: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 j42IsnI2077416; Mon, 2 May 2005 11:54:49 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IsmuK077410 for ; Mon, 2 May 2005 11:54:48 -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 1DSg47-0006GR-00; Mon, 02 May 2005 19:54:47 +0100 Date: Mon, 2 May 2005 19:54:47 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute Message-ID: <20050502185447.GN2772@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <42763C50.9010600@wp.pl> <20050502154731.GM2772@tartarus.org> <427656A4.5040603@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427656A4.5040603@annevankesteren.nl> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 02, 2005 at 06:34:44PM +0200, Anne van Kesteren wrote: > James Aylett wrote: > >(Assuming is an acceptable root element for SVG.) > > It isn't. application/xml is probably more appropriate. It would be, if SVG explained how to embed fragments in other XML dialects. As I understand, it doesn't, in which case embedding the entire document seems preferable. (Note that we've had to invent our own way of embedding XHTML fragments in Atom - this isn't an uncommon problem ...) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 2 15:05:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20059 for ; Mon, 2 May 2005 15:05: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 j42IwYQh077929; Mon, 2 May 2005 11:58: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 j42IwYFn077928; Mon, 2 May 2005 11:58:34 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IwXaE077914 for ; Mon, 2 May 2005 11:58:33 -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 1DSg7k-0006Hy-00; Mon, 02 May 2005 19:58:32 +0100 Date: Mon, 2 May 2005 19:58:32 +0100 From: James Aylett To: Atom Syntax Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! Message-ID: <20050502185832.GO2772@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <46E9D765EBB40232DBD9EE28@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E9D765EBB40232DBD9EE28@adsl-64-166-133-243.dsl.snfc21.pacbell.net> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 02, 2005 at 08:48:12AM -0700, Walter Underwood wrote: > > Counting impressions is essential to their trade, and you'll find > > that it is industry standard practice. > > Make that "was essential", and "should be a dying practice." Ads > have moved to results-based billing, paying for clickthrough and > conversion. That's an awfully broad statement, which isn't borne out in practice. Clickthrough isn't a terribly good metric for success, so it isn't going to maintain its image as a good basis for billing. Conversion is more interesting, but is a much higher risk for publishers to book against, especially on smaller brands. I strongly suspect that per-media booking (for instance, booking by the thousand impressions) will be with us in some form or another for some time to come. Besides, as has been pointed out, even if you do book against raw click volumes, your only way of figuring out whether this was the best value you could have made out of your property is to calculate the clickthrough rate, which requires some measure of per-media recording. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 2 15:08:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20628 for ; Mon, 2 May 2005 15:08: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 j42J0iMq078348; Mon, 2 May 2005 12:00: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 j42J0iKh078347; Mon, 2 May 2005 12:00:44 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42J0h1h078341 for ; Mon, 2 May 2005 12:00:43 -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 1DSg9q-0006M8-00; Mon, 02 May 2005 20:00:42 +0100 Date: Mon, 2 May 2005 20:00:42 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Editorial: missing "a" Message-ID: <20050502190042.GP2772@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Not sure if anyone's pointed this out. Section 4.2.9.2 (the "rel" Attribute), second paragraph: > The value of "rel" MUST be string ... which should probably be "... MUST be a string ...". James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 2 15:39:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24324 for ; Mon, 2 May 2005 15:39: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 j42JKUGe081550; Mon, 2 May 2005 12:20: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 j42JKUoj081549; Mon, 2 May 2005 12:20:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.wp.pl (smtp.wp.pl [212.77.101.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42JKT2U081533 for ; Mon, 2 May 2005 12:20:29 -0700 (PDT) (envelope-from ddooss@wp.pl) Received: (wp-smtpd smtp.wp.pl 12680 invoked from network); 2 May 2005 21:19:47 +0200 Received: from 50-host.net.bialystok.pl (HELO [127.0.0.1]) (ddooss@[81.15.254.50]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 2 May 2005 21:19:47 +0200 Message-ID: <4276450E.9030906@wp.pl> Date: Mon, 02 May 2005 17:19:42 +0200 From: Domel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7) Gecko/20040616 X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org, Anne van Kesteren Subject: Re: suggestion: mention about xml:id References: <42762C0E.1010905@wp.pl> <42762DF0.90804@annevankesteren.nl> <4276323F.1050808@wp.pl> <42763310.2060708@annevankesteren.nl> <427639A9.90101@wp.pl> <42763BE5.8070606@annevankesteren.nl> In-Reply-To: <42763BE5.8070606@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO AS1=Unknown AS2=NO(0.875871) AS3=NO AS4=NO Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Yeah why not? That does not have anything to do with Atom mentioning > the xml:id attribute though. Authors can include it themselves if > desired. xml:base and xml:lang solve specific Atom problems, xml:id > doesn't do that. (Atom uses something else to uniquely identify each > entry. It also couldn't reuse xml:id for this by the way.) I don't see difference between xml:lang and xml:id in this context, xml:lang MAY be used in Atom and in my proposition xml:id MAY be used. > > So are you saying XPointer should be part of the Atom specification as > well..? No, I say that xml:id should be part of Atom specyfication and when it will be then we can use XPointers in Atom (and other extensions) (analogy: Atom not need namespaces, XML rec don't defined xmlns attribute, but Atom has xmlns attribute, because it provide many features) > > Again, what is the use case for Atom? Grand of features to webdeveloper. Dominik Tomaszuk From owner-atom-syntax@mail.imc.org Mon May 2 15:57:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28592 for ; Mon, 2 May 2005 15: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 j42JeF1E084357; Mon, 2 May 2005 12: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 j42JeFhY084356; Mon, 2 May 2005 12:40:15 -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 j42JeESc084335 for ; Mon, 2 May 2005 12:40:14 -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 <2005050219400701200ddo4de>; Mon, 2 May 2005 19:40:07 +0000 Date: Mon, 2 May 2005 13:40:06 -0600 Subject: Re: PaceDuplicateIDWithSource 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: <2876AE2C-9873-43CD-9BCB-B436A91B7EF0@mac.com> 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, May 2, 2005, at 12:41 PM, Graham wrote: > http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource > > Graham > > === > Abstract > > Allow multiple version of an entry within a feed where the source id > is different. > > Status > > Proposed > > Rationale > > The current spec does not allow multiple versions of the same entry > within a feed. In normal usage, this is OK, but when merging two feeds > into a single feed, it requires duplicate detection and the discarding > of data. The abstract and rationale made me think this was proposing something entirely different from what it is--that multiple representations of the same entry resource could appear in a feed document as long as they were aggregated into the feed by different routes. What the actual proposed text allows is not multiple versions of the same entry, but multiple entries with the same id as long as they're from different feeds. When merging two feeds, duplicate detection will still have to be done, because both feeds could contain the same entry, with the same atom:source/atom:id. > Note it does not make legal having an entry without a source and a > entry with a source, both of which have the same entry id, since the > feed without a source may come from the same feed as the one with. I don't see any reason to disallow this--the one without an atom:source would look to the current feed for its id. I don't see how this makes it any more likely that they'd come from the same feed. We could require that the feed have an atom:id in such a case if we want to, so that the IDs can be compared (ie. existing atom:id != missing atom:id is not good enough). > Proposal > > In relation to atompub-format-08: > > In section 4.1.1, replace: > > atom:feed elements MUST NOT contain atom:entry elements with identical > atom:id values > With: > > atom:feed elements MUST NOT contain an atom:entry element that has the > same atom:id value as any other atom:entry element, unless both > atom:entry elements each contain an atom:source element, and the two > atom:id values in each atom:source element are different. > Impacts > > Allows duplicate ids within feeds, so atom:source must also be > examined when looking for duplicates. > > > From owner-atom-syntax@mail.imc.org Mon May 2 16:01:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00302 for ; Mon, 2 May 2005 16:01: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 j42Js3Cm086354; Mon, 2 May 2005 12:54: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 j42Js3TS086353; Mon, 2 May 2005 12:54: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 j42Js3X0086337 for ; Mon, 2 May 2005 12:54: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 0E793CC for ; Mon, 2 May 2005 12:53:58 -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 j42Jrvng002870 for ; Mon, 2 May 2005 12:53:57 -0700 (PDT) Date: Mon, 02 May 2005 13:03:23 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way! Message-ID: <3F4B54F04E00BEAF7E1C8612@diva.verity.com> In-Reply-To: <20050502185832.GO2772@tartarus.org> References: <46E9D765EBB40232DBD9EE28@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <20050502185832.GO2772@tartarus.org> 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 How to make money from ads is off-topic, sorry for starting in that direction. I don't quite get this, though. What about e-mails and RSS is being compared? --On Monday, May 02, 2005 11:43:28 AM +0100 James Aylett wrote: > > (2) but it's not that uncommon for people to need to track > static instances - consider, for instance emails; HTTP level > cache control is being used as well. There's no reason > RSS feeds can't be considered in this way. The business of ads in feeds is pretty confused. How does a feed relate to an impression, when it might be viewed later or not at all? I would hope that advertisers figure out that impression-based approaches don't really mesh with feeds, but in the meantime, we are probably stuck with hacks like Bob Wyman describes. We punted explicit support for ads, so they will continue to show up in content and cause more work for Bob. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon May 2 16:42:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13417 for ; Mon, 2 May 2005 16:42: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 j42KZplg091976; Mon, 2 May 2005 13:35: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 j42KZpjV091975; Mon, 2 May 2005 13:35:51 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42KZoRC091968 for ; Mon, 2 May 2005 13:35:50 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.61.144]) by smtp.cegetel.net (Postfix) with ESMTP id A4B1422C1D0; Mon, 2 May 2005 22:35:44 +0200 (CEST) Message-ID: <42768F43.6000209@cegetel.net> Date: Mon, 02 May 2005 22:36:19 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: James Aylett Cc: atom-syntax@imc.org Subject: Re: suggestion: add new value to type attribute References: <42763C50.9010600@wp.pl> <20050502154731.GM2772@tartarus.org> <427656A4.5040603@annevankesteren.nl> <20050502185447.GN2772@tartarus.org> In-Reply-To: <20050502185447.GN2772@tartarus.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 James Aylett wrote: > On Mon, May 02, 2005 at 06:34:44PM +0200, Anne van Kesteren wrote: > > >>James Aylett wrote: >> >>>(Assuming is an acceptable root element for SVG.) >> >>It isn't. application/xml is probably more appropriate. > > > It would be, if SVG explained how to embed fragments in other XML > dialects. As I understand, it doesn't, in which case embedding the > entire document seems preferable. (Note that we've had to invent our > own way of embedding XHTML fragments in Atom - this isn't an uncommon > problem ...) So what is XHTMLMOD for? We don't need XHTML metadata, as they are provided by the feed. We just need block or inline content models, which are generalized in the div and span containers, so we use their content model. I don't think the WG have /invented/ an Atom way of embedding XHTML, they just *used* (maybe without knowing it) the XHTML modularization framework. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 2 17:11:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15618 for ; Mon, 2 May 2005 17:11: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 j42L3bNh093432; Mon, 2 May 2005 14:03: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 j42L3bc9093431; Mon, 2 May 2005 14:03:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42L3b6u093424 for ; Mon, 2 May 2005 14:03:37 -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 (rwcrmhc11) with SMTP id <2005050221032701300f803ge>; Mon, 2 May 2005 21:03:28 +0000 Date: Mon, 2 May 2005 15:03:26 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceDuplicateIDWithSource2 From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit 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 http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 This is what I thought had been suggested. Hopefully I didn't err in putting two changes into one proposal, but the first seemed a little odd without the acknowledgment provided by the second. Coming up with wording for the first change that makes the point without getting horrendously verbose and convoluted isn't as easy as I thought! Antone == Abstract == Allow multiple entries with the same ID in a feed document if their source feeds are demonstrably different. Adjust the wording regarding the uniquess of atom:id values to reflect the recognition that publishers might duplicate each others' atom:ids, even if accidentally. == Status == Proposed. == Rationale == The current spec does not allow multiple entries in a feed document with the same ID. This can cause problems if, whether accidentally or maliciously, different feeds use the same IDs for their entries. This proposal alleviates this problem by allowing a feed document to contain multiple entries with the same ID as long as their source feed's ID is different, enabling consumers to determine that they are not duplicates of the same entry. The current spec requires atom:id values to be minted in a way that "assures uniqueness". This is impossible, since no one can prevent others from, whether accidentally or maliciously, duplicating one's ids. This proposal rewords that requirement to reflect recognition of this fact. == Proposal == In relation to atompub-format-08: In section 4.1.1, replace: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values With: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless the values of the atom:id elements for each of their source feeds is different. If the value of atom:id for the source feed cannot be determined by one of the two following rules, then the value of atom:id for the atom:entry MUST be unique within its enclosing atom:feed element. * If an atom:entry element contains an atom:source element, and that element contains an atom:id element, use its value. * If an atom:entry does not contain an atom:source element, and the atom:entry element's parent atom:feed element contains an atom:id element, use its value. In 4.2.7, replace: The content of an atom:id element MUST be created in a way that assures uniqueness. With: The content of an atom:id element MUST be created in a way that, as nearly as possible, assures uniqueness. An atom:id value that has been used with one entry in a particular feed MUST NOT ever be used with a different entry in the same feed, and SHOULD NOT ever be used with an entry in another feed. == Impacts == Allows duplication ids within feeds, so atom:source/atom:id or atom:feed/atom:id must be examined when looking for duplicates. From owner-atom-syntax@mail.imc.org Mon May 2 17:18:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16033 for ; Mon, 2 May 2005 17:18: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 j42LDUnf094588; Mon, 2 May 2005 14:13: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 j42LDUZu094587; Mon, 2 May 2005 14:13:30 -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 j42LDTrL094578 for ; Mon, 2 May 2005 14:13: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 (sccrmhc14) with SMTP id <20050502211308014009s8lie>; Mon, 2 May 2005 21:13:23 +0000 Date: Mon, 2 May 2005 15:13:06 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Getting atom:source right From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit 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 > 4.2.11 The "atom:source" Element > > If an atom:entry is copied from one feed into another feed, then the > source atom:feed's metadata (all child elements of atom:feed other > than the atom:entry elements) MAY be preserved within the copied > entry by adding an atom:source child element, if it is not already > present in the entry, and including some or all of the source feed's > metadata elements as the atom:source element's children. Such > metadata SHOULD be preserved if the source atom:feed contains any of > the child elements atom:author, atom:contributor, atom:copyright, or > atom:category and those child elements are not present in the source > atom:entry. Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of the atom:source element MUST NOT be replaced with metadata from the containing atom:feed. That's implied by "if it is not already present in the entry", but it may be best to be more explicit. From owner-atom-syntax@mail.imc.org Mon May 2 17:33:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17783 for ; Mon, 2 May 2005 17:33: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 j42LQY8B095528; Mon, 2 May 2005 14:26: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 j42LQYO4095527; Mon, 2 May 2005 14:26:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LQXc5095521 for ; Mon, 2 May 2005 14:26:34 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j42LQLTn019450; Mon, 2 May 2005 17:26:33 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBN58164 (AUTH bob@wyman.us); Mon, 2 May 2005 17:26:20 -0400 (EDT) Message-Id: <200505022126.DBN58164@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Walter Underwood'" , "'Atom Syntax'" Subject: Dynamic Content Flagging (was: RE: FYI: More on duplicates in feeds: DoubleClick does ads the WRONG way!) Date: Mon, 2 May 2005 17:26:18 -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 In-Reply-To: <3F4B54F04E00BEAF7E1C8612@diva.verity.com> Thread-Index: AcVPU5YnlbsrtgAqReuSnO/CKRYopQABc1Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > We punted explicit support for ads, so they will continue to show up > in content and cause more work for Bob. Uhh... It isn't just me. This work needs to be done by just about anyone who builds an aggregator if they implement duplicate detection based on analysis of item contents. Hopefully, that will be much less necessary with Atom feeds in the future; however, as long as we've got RSS we'll still need to do text-based comparisons to detect "updates." The problem with explicit "ad" support was, of course, that people would be highly likely to use the "ad" tag as a license to delete content and strip the ads. I've been thinking that there might be a more general solution in allowing people to tag certain elements, spans or divs as dynamic content which could be masked during canonicalization prior to change detection. Such a generic method of tagging would eliminate the major "damage" done by ads while providing support for other kinds of dynamic content that doesn't involve ads. For instance, we've got Slashdot and now Spaces that change a "comment count" in posts whenever someone creates a new comment. That wrecks havoc on change detection code... Also, at PubSub, we'd love to insert data like the current LinkRank or LinkCount, and various other dynamic bits that should be ignored when comparing two items. If we could create an attribute like "dynamic" (much like the nofollow attribute) that could be put in elements, then comparison code would know what bits to ignore -- whether or not they were ad related. The time of day is: 5:25pm EST. bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 17:36:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18133 for ; Mon, 2 May 2005 17: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 j42LQlam095547; Mon, 2 May 2005 14:26: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 j42LQlZH095546; Mon, 2 May 2005 14:26:47 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LQkJ2095533 for ; Mon, 2 May 2005 14:26:46 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.61.144]) by smtp.cegetel.net (Postfix) with ESMTP id 42F3D22C15D; Mon, 2 May 2005 23:26:40 +0200 (CEST) Message-ID: <42769B33.8000605@cegetel.net> Date: Mon, 02 May 2005 23:27:15 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: PaceXhtmlDivSuggestedOnly X-Priority: 3) 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 Antone Roundy wrote: > I'd support forbidding any attributes other than (a) namespace > declaration(s) on container elements...in fact, I'm going to add that > to PaceXmlContentWrapper. Won't that complicate validation a lot? >> If the spec is changed to forbid any attribute (other than the XHTML >> namespace declaration), then the XHTML div is not really an XHTML div, >> it becomes (and actually it already is, as it is not part of the >> content) a dummy container belonging to the XHTML namespace, whichever >> its name (though it's better if it looks like an existing XHTML >> element). > > I disagree with this characterization. We may have profiled the XHTML > div element for this particular use, but that doesn't stop it from > being an XHTML div. Honestly, is there a great difference between these two if the attributes that are allowed on the container are defined by Atom and no more XHTML, apart from "div" looking like an existing XHTML element.
Some content here.
Some content here. If you're "profiling" the DIV, you make it different from the XHTML div, e.g. a new element with the same name and the same content model. If you were writing a DTD for Atom (assuming it wouldn't use interleaved content models), you'd have to declare your own xhtml:div that would shadow the one declared in the XHTMLMOD DTD(s). It would then be obvious that *your* xhtml:div is not XHTML xhtml:div but a distinct element with the name. And as you probably don't "control" the XHTML namespace, it wouldn't be a good design to define a new element in a namespace that is not /yours/ . IMO, embedding XHTML should be done by defining an XHTML content model (%Block or %Flow) on a "local" element, such as atom:content, and I believe XHTML modularization has been thought and designed this way. > If the author adds a div or span, that's fine. But if the software ads > it, it's altering the author's content, and should have a way to so > indicate so that the change can be undone. There are two kinds of Atom document producers: - people who create them by hands or code their own application/script to build them from their content: these are in the first category: "the author adds a div or span". - software that is used by authors but is not coded by them. I don't think much of these will produce prefix-free Atom documents (although it shouldn't be taken in account in the Atom design). Software authors will most likely declare the XHTML namespace once (particularly if they treat the XHTML as a "black box"), or try to declare it on the content elements (if there are paragraphs, on each

, if there is only a few children in mixed content, on each of these children, etc.). Such software shouldn't alter the content in any way. People using such software (that they have not coded) will most likely won't care of how their XHTML (if only they know they are using XHTML!) is embedded within their Atom feeds, as long as these feeds are "just working". If they do care, well, they'll either find some software that adds such a container (so the author is aware that his content will be modified) or provide their own container with a namespace declaration and find some software that won't try to move this declaration on another element. Finally, people using template-engines, such as MovableType, will choose between two kinds of templates (assuming they're using XHTML and MT knows how to make an excerpt, essentially closing every opened tag): ... <$MTEntryExcerpt$> ... and ...

<$MTEntryExcerpt$>
... Either they use the second one and it's the responsibility of the software author/deliverer to inform the end-user that it will wrap his content so somehow alter it; or they *choose* between both so it's *their* responsibility if their content is altered; or they use the first and there's no problem. I assumed that people who cares about using prefixed-names or default-namespaces-only has some minimum technical skill and hence is able to either: * write their own feeds (or app/template to produce them) the way they want; or * choose the appropriate application/template that meets their needs -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 2 17:42:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18545 for ; Mon, 2 May 2005 17:42: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 j42LbETU096063; Mon, 2 May 2005 14:37: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 j42LbEJR096062; Mon, 2 May 2005 14:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LbDUF096056 for ; Mon, 2 May 2005 14:37:13 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j42LbCvR002377; Mon, 2 May 2005 17:37:12 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBN62050 (AUTH bob@wyman.us); Mon, 2 May 2005 17:37:02 -0400 (EDT) Message-Id: <200505022137.DBN62050@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceDuplicateIDWithSource Date: Mon, 2 May 2005 17:37:01 -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 In-Reply-To: Thread-Index: AcVPUzPO+yTGY3/ESBelV3He73bukwACsXdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > multiple representations of the same entry resource could appear > in a feed document as long as they were aggregated into the feed > by different routes. Two rules: 1. You should only write a source element into an entry if it does not already have one. 2. If you copy an entry that doesn't have a source element, then you SHOULD insert one that indicates source from which you copied the entry. (Note: I wish that SHOULD was a MUST...) The effect of these two rules is that the path from the original source to the final destination is irrelevant. An entry may have been copied 100's of times between many feeds; however, it should always carry identification of its *original* source. Remember, we explicitly decided not to deal with the issue of paths when these discussions and those on the more general issue of "provenance" were going on. bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 17:48:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19134 for ; Mon, 2 May 2005 17:48: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 j42LgkVq096354; Mon, 2 May 2005 14:42: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 j42LgkJM096353; Mon, 2 May 2005 14:42:46 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LgjbK096332 for ; Mon, 2 May 2005 14:42:46 -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 <20050502214240016002rdgpe>; Mon, 2 May 2005 21:42:40 +0000 Date: Mon, 2 May 2005 15:42:37 -0600 Subject: Re: PaceXhtmlDivSuggestedOnly 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: <42769B33.8000605@cegetel.net> Message-Id: <1A222BA2-BB53-11D9-9FF1-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, May 2, 2005, at 03:27 PM, Thomas Broyer wrote: > Antone Roundy wrote: >> I'd support forbidding any attributes other than (a) namespace >> declaration(s) on container elements...in fact, I'm going to add that >> to PaceXmlContentWrapper. > > Won't that complicate validation a lot? Not being a validator author, I don't know. An equally acceptable alternative, would be to state that consumers MAY ignore attributes other than namespace declarations on contain elements. >> If the author adds a div or span, that's fine. But if the software >> ads it, it's altering the author's content, and should have a way to >> so indicate so that the change can be undone. > > There are two kinds of Atom document producers: > - people who create them by hands or code their own > application/script to build them from their content: these are in the > first category: "the author adds a div or span". > - software that is used by authors but is not coded by them. I don't > think much of these will produce prefix-free Atom documents Blogger could always change, but right now, they do. Since it doesn't require fiddling with the content as much (the XHTML would still need to be validated or at least checked for well-formedness in a robust app), I don't think it will be as rare as you're suggesting. From owner-atom-syntax@mail.imc.org Mon May 2 17:52:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19504 for ; Mon, 2 May 2005 17:52: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 j42Llkhp096603; Mon, 2 May 2005 14:47: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 j42Llkh2096602; Mon, 2 May 2005 14:47:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42Llku1096596 for ; Mon, 2 May 2005 14:47:46 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j42LljeB016594; Mon, 2 May 2005 17:47:45 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBN65377 (AUTH bob@wyman.us); Mon, 2 May 2005 17:47:43 -0400 (EDT) Message-Id: <200505022147.DBN65377@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'atom-syntax'" Subject: RE: PaceDuplicateIDWithSource Date: Mon, 2 May 2005 17:47:42 -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 In-Reply-To: <2876AE2C-9873-43CD-9BCB-B436A91B7EF0@mac.com> Thread-Index: AcVPSUWrVUtAIq0PSIKq5RWTD8AzewAFdUQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > atom:feed elements MUST NOT contain an atom:entry element that has > the same atom:id value as any other atom:entry element, unless both > atom:entry elements each contain an atom:source element, and the two > atom:id values in each atom:source element are different. -.5 Graham's text would make the *real* entry id the concatenation of the atom:id of the feed and the atom:id of the entry. This means that we need to make sure that atom:id is a required element of feed. The problem here is that it is very easy to "fake" the atom:id of a feed. It is harder to fake the URI from which a feed is actually read. I would much prefer if the *real* entry id was built from the concatenation of the URI of the source feed, as identified in a link element (with rel="self") and the atom:id of the entry. bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 18:06:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20792 for ; Mon, 2 May 2005 18:06: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 j42Lx8RH097073; Mon, 2 May 2005 14:59: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 j42Lx8FN097072; Mon, 2 May 2005 14:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42Lx8eT097060 for ; Mon, 2 May 2005 14:59:08 -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 (rwcrmhc13) with SMTP id <20050502215856015004jc29e>; Mon, 2 May 2005 21:59:01 +0000 Date: Mon, 2 May 2005 15:58:55 -0600 Subject: Re: PaceDuplicateIDWithSource 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: <200505022137.DBN62050@ms8.netsolmail.com> Message-Id: <608B61C2-BB55-11D9-9FF1-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, May 2, 2005, at 03:37 PM, Bob Wyman wrote: > Antone Roundy wrote: >> multiple representations of the same entry resource could appear >> in a feed document as long as they were aggregated into the feed >> by different routes. > Two rules: > 1. You should only write a source element into an entry if it does > not already have one. > 2. If you copy an entry that doesn't have a source element, then you > SHOULD insert one that indicates source from which you copied the > entry. > (Note: I wish that SHOULD was a MUST...) > > The effect of these two rules is that the path from the original > source to the final destination is irrelevant. Yes, I agree...including, absent some convincing argument to the contrary, that it were a MUST. What I was saying is that the abstract and rationale of the Pace led me to think that it was trying to enable what I wrote above. From owner-atom-syntax@mail.imc.org Mon May 2 19:18:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29084 for ; Mon, 2 May 2005 19:18: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 j42NBhtt001843; Mon, 2 May 2005 16:11: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 j42NBhc8001841; Mon, 2 May 2005 16:11:43 -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 j42NBgAP001834 for ; Mon, 2 May 2005 16:11: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 j42NBgi7004702 for ; Mon, 2 May 2005 17:11:42 -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 <0IFV00MO3XRHYS@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 02 May 2005 17:11:42 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFV00AHUXRGOI@mail.sun.net> for atom-syntax@imc.org; Mon, 02 May 2005 17:11:41 -0600 (MDT) Date: Mon, 02 May 2005 16:12:42 -0700 From: Tim Bray Subject: Re: PaceDuplicateIDWithSource In-reply-to: <200505022137.DBN62050@ms8.netsolmail.com> To: bob@wyman.us Cc: atom-syntax@imc.org, "'Antone Roundy'" Message-id: <4e9365609305b9d2459434eddc90dbb4@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200505022137.DBN62050@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 2, 2005, at 2:37 PM, Bob Wyman wrote: >> multiple representations of the same entry resource could appear >> in a feed document as long as they were aggregated into the feed >> by different routes. > Two rules: Bob, we need spec language. Right now, we have Paces from Graham and Roundy. Can you please make sure which of these meets your application needs, and if neither do, either fix one of them or construct a new one? You're our canary in the coal mine on this issue. -Tim From owner-atom-syntax@mail.imc.org Mon May 2 19:35:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00412 for ; Mon, 2 May 2005 19:35: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 j42NO32E002619; Mon, 2 May 2005 16:24: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 j42NO346002618; Mon, 2 May 2005 16:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42NO2Wi002610 for ; Mon, 2 May 2005 16:24:02 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j42NNMns006450; Tue, 3 May 2005 00:23:28 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceDuplicateIDWithSource2 Date: Tue, 3 May 2005 00:23:24 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 May 2005, at 10:03 pm, Antone Roundy wrote: > The content of an atom:id element MUST be created in a way that, > as nearly as possible, assures uniqueness. An atom:id value that > has been used with one entry in a particular feed MUST NOT ever be > used with a different entry in the same feed, and SHOULD NOT ever > be used with an entry in another feed. That last part: Are you against category feeds? Are you against aggregated feeds? Are you against search results feeds? Graham From owner-atom-syntax@mail.imc.org Mon May 2 19:40:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01066 for ; Mon, 2 May 2005 19:40: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 j42NY3Jp003017; Mon, 2 May 2005 16: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 j42NY3xR003016; Mon, 2 May 2005 16:34:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42NY2wU003001 for ; Mon, 2 May 2005 16:34:02 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j42NXpA2008482; Tue, 3 May 2005 00:33:52 +0100 (BST) In-Reply-To: <200505022147.DBN65377@ms8.netsolmail.com> References: <200505022147.DBN65377@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <044DC9B8-D2F3-4057-8F71-F9BB7A682CB5@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceDuplicateIDWithSource Date: Tue, 3 May 2005 00:33:54 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit These two statements conflict: > It is harder to fake the URI from which a feed is actually read. > as identified in a link element (with rel="self") and the atom:id > of the entry. rel=self doesn't contain where the feed came from, it contains where the feed claims it came from, and since it has no constraints on uniqueness or persistence, but is just as easy to spoof as id, it's an even worse choice. A better thing to do would be to add a missing feature to the source element: Where the feed actually came from. I'd suggest it being a uri/href/src attribute on the source element itself, since it describes the sourcing of the feed. Adding an element within would imply the new element was part of the original feed. Then we need a new Pace that uses the original URI. (I'm also starting to think that feed ids are a bit of a waste of space, but anyway...) Graham From owner-atom-syntax@mail.imc.org Mon May 2 19:45:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01417 for ; Mon, 2 May 2005 19:45: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 j42NctlF003148; Mon, 2 May 2005 16:38: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 j42NctO2003147; Mon, 2 May 2005 16:38:55 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42NcpqH003122 for ; Mon, 2 May 2005 16:38:55 -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 <20050502233830016002t0voe>; Mon, 2 May 2005 23:38:30 +0000 Date: Mon, 2 May 2005 17:38:28 -0600 Subject: Re: PaceDuplicateIDWithSource2 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: <493A35CC-BB63-11D9-9FF1-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, May 2, 2005, at 05:23 PM, Graham wrote: > On 2 May 2005, at 10:03 pm, Antone Roundy wrote: >> The content of an atom:id element MUST be created in a way that, as >> nearly as possible, assures uniqueness. An atom:id value that has >> been used with one entry in a particular feed MUST NOT ever be used >> with a different entry in the same feed, and SHOULD NOT ever be used >> with an entry in another feed. > > That last part: Are you against category feeds? Are you against > aggregated feeds? Are you against search results feeds? > No, my wording is just imperfect. It should not be use with an entry originating in a different feed. Category feeds: that's something we haven't dealt with well yet. Should they, or feeds that combine category feeds present the entries like aggregated feeds? Should we add an "authoritative" link type, as recently discussed, and change this wording to work with that? Search results feeds: more difficult. If the search criteria don't change, then it's the same feed, so the prior sentence applies. If the search criteria do change...is it the same "entry"? I'd imagine that in some cases it might be, but in some I'd think it isn't. Perhaps that's exception to the SHOULD NOT. But it does sound like a good argument for fixing this sentence. It's time for dinner, so I'll have to wording to express the idea that an ID should correspond to exactly one "entry resource". Feel free to beat me to it. From owner-atom-syntax@mail.imc.org Mon May 2 19:55:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02232 for ; Mon, 2 May 2005 19:55: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 j42Nnbhf003747; Mon, 2 May 2005 16:49: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 j42NnbFk003746; Mon, 2 May 2005 16:49:37 -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 j42Nna6E003729 for ; Mon, 2 May 2005 16:49:37 -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 <20050502234931014009ts8te>; Mon, 2 May 2005 23:49:31 +0000 Date: Mon, 2 May 2005 17:49:29 -0600 Subject: Re: PaceDuplicateIDWithSource 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: <044DC9B8-D2F3-4057-8F71-F9BB7A682CB5@mac.com> 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, May 2, 2005, at 05:33 PM, Graham wrote: > These two statements conflict: > >> It is harder to fake the URI from which a feed is actually read. > >> as identified in a link element (with rel="self") and the atom:id of >> the entry. > > rel=self doesn't contain where the feed came from, it contains where > the feed claims it came from, and since it has no constraints on > uniqueness or persistence, but is just as easy to spoof as id, it's an > even worse choice. Huh? I thought it contained a URI from which the feed could be accessed, and that if one were to get the feed from a different URI, the preferred action would be to fetch it from the "self" URI in the future. If an aggregator is subscribed to the "self" URI, then it knows what entries have been there, and can't be deceived by a feed claiming to have an entry from there. You're correct that there's no persistence, but I'd think most feeds are going to have fairly stable addresses. As for uniqueness, how are you going to get multiple feeds from the same URI? Different feeds may CLAIM the same "self" URI, but only one can actually come from there, so spoofs can be easily detected. > (I'm also starting to think that feed ids are a bit of a waste of > space, but anyway...) I agree completely, except for cases recently named where a feed doesn't have a URI (delivered by email, etc). From owner-atom-syntax@mail.imc.org Mon May 2 21:10:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08812 for ; Mon, 2 May 2005 21: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 j430q4rD008514; Mon, 2 May 2005 17:52: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 j430q4ni008513; Mon, 2 May 2005 17:52:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j430q37Y008500 for ; Mon, 2 May 2005 17:52:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j430pfda024000; Tue, 3 May 2005 01:51:47 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A8D2A37-64E9-48B4-9F28-E9E44B13B1AB@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceDuplicateIDWithSource Date: Tue, 3 May 2005 01:51:40 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 May 2005, at 12:49 am, Antone Roundy wrote: > Huh? I thought it contained a URI from which the feed could be > accessed, and that if one were to get the feed from a different > URI, the preferred action would be to fetch it from the "self" URI > in the future. No. The spec says simply this: "The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element" If an aggregator is reading the feed from the "wrong" URI, the web server can easily be set up to provide HTTP redirects on that address. > If an aggregator is subscribed to the "self" URI, then it knows > what entries have been there, and can't be deceived by a feed > claiming to have an entry from there. You're correct that there's > no persistence, but I'd think most feeds are going to have fairly > stable addresses. As for uniqueness, how are you going to get > multiple feeds from the same URI? Different feeds may CLAIM the > same "self" URI, but only one can actually come from there, so > spoofs can be easily detected. It's the claiming that's the problem. If the real URI must always match the rel="self", then every Atom feed must be discarded when the two don't match, and the request attempted again. That seems like hazardous behaviour and mixing of layers to me. It also means a feed document is only valid when accessed from its original location. Graham From owner-atom-syntax@mail.imc.org Mon May 2 21:13:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09043 for ; Mon, 2 May 2005 21:13: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 j4317mYI009444; Mon, 2 May 2005 18:07: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 j4317mBC009443; Mon, 2 May 2005 18:07:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4317l5X009437 for ; Mon, 2 May 2005 18:07:47 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4317kqp010477; Mon, 2 May 2005 21:07:46 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBO23847; Mon, 2 May 2005 21:07:44 -0400 (EDT) Message-Id: <200505030107.DBO23847@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: Getting atom:source right Date: Mon, 2 May 2005 21:07:42 -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.2180 Thread-Index: AcVPXSTtzR9s+uknQYu8VPWedcdKFAAHxxtA In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Should we add something like this [to 4.2.11]? > If an atom:entry element already containing an atom:source element > is copied to another feed, the contents of the atom:source element > MUST NOT be replaced with metadata from the containing atom:feed. +1. As Antone suggests, we're probably best off being as explicit as possible with this stuff. bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 21:32:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10695 for ; Mon, 2 May 2005 21:32: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 j431ML38010504; Mon, 2 May 2005 18: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 j431MLDt010503; Mon, 2 May 2005 18:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j431MLCL010497 for ; Mon, 2 May 2005 18:22:21 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j431MJTj023544; Mon, 2 May 2005 21:22:20 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBO27120; Mon, 2 May 2005 21:22:18 -0400 (EDT) Message-Id: <200505030122.DBO27120@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceDuplicateIDWithSource2 Date: Mon, 2 May 2005 21:22:16 -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.2180 Thread-Index: AcVPcYYeN7vXb60IQ5uRXnGshQ+nigAC3Zlg In-Reply-To: <493A35CC-BB63-11D9-9FF1-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy asked: > Category feeds: ... Should they, or feeds that combine category > feeds present the entries like aggregated feeds? Yes, at least normally. An entry should have only one "source." On a site that has a "master" feed and also provides copies of entries in a variety of category feeds, I feel that the "master" feed should be the source and things in the category feeds should be copies which contain atom:source elements pointing to the master. Of course, you could reasonably do it the other way around, however, for a variety of reasons I think that would be less then optimal. One thing you should not do with category feeds is "tag" things simply by putting them in one feed or another. If you have a feed for things that are in category "foobar" then each entry which is in the "foobar" feed should also have an atom:category element with the value "foobar." The entry should standalone and be associated with the same category or categories no matter which feed it is found in. > Should we add an "authoritative" link type, as recently discussed, > and change this wording to work with that? It would be great if we could permit one feed to subordinate itself to another, however, I don't that would really change the fact that there really should be only one source for an entry. > Search results feeds: more difficult. If the search criteria don't > change, then it's the same feed, so the prior sentence applies. I'm not sure what you're getting at here. However, it seems to me that a search results feed is almost always going to be an aggregate feed and thus should be filled with entries that have source elements identifying other feeds. But, I suspect that I haven't understood properly what you were trying to say. Please try rephrasing. bob wyman From owner-atom-syntax@mail.imc.org Mon May 2 22:47:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16263 for ; Mon, 2 May 2005 22:47: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 j432ZdJK016006; Mon, 2 May 2005 19:35: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 j432ZdHc016005; Mon, 2 May 2005 19:35:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j432Za2C015974 for ; Mon, 2 May 2005 19:35:39 -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 <2005050302353101400fp0gme>; Tue, 3 May 2005 02:35:31 +0000 Date: Mon, 2 May 2005 20:35:29 -0600 Subject: Re: PaceDuplicateIDWithSource2 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: <200505030122.DBO27120@ms8.netsolmail.com> Message-Id: <039C908C-BB7C-11D9-9FF1-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, May 2, 2005, at 07:22 PM, Bob Wyman wrote: > Antone Roundy asked: >> Category feeds: ... Should they, or feeds that combine category >> feeds present the entries like aggregated feeds? > Yes, at least normally. An entry should have only one "source." > On a site that has a "master" feed and also provides copies of > entries in a variety of category feeds, I feel that the "master" feed > should > be the source and things in the category feeds should be copies which > contain atom:source elements pointing to the master. Of course, you > could > reasonably do it the other way around, however, for a variety of > reasons I > think that would be less then optimal. I agree with all of the above in thoery, but getting people to do this could be hampered by the fact that category feeds would have to duplicate the master feed's metadata in every entry...or at least should...since the WG decided against creating a method of doing it only once in aggregate feeds. That duplication makes me hesitant to embrace this idea wholeheartedly. But I don't know of another solution that the WG hasn't already rejected. >> Should we add an "authoritative" link type, as recently discussed, >> and change this wording to work with that? > It would be great if we could permit one feed to subordinate itself > to another, however, I don't that would really change the fact that > there > really should be only one source for an entry. Agreed on both points. >> Search results feeds: more difficult. If the search criteria don't >> change, then it's the same feed, so the prior sentence applies. > I'm not sure what you're getting at here. However, it seems to me > that a search results feed is almost always going to be an aggregate > feed > and thus should be filled with entries that have source elements > identifying > other feeds. > But, I suspect that I haven't understood properly what you were > trying to say. Please try rephrasing. Oops, my mistake--I was thinking of searches of non-entry resources (such as web page searches) being published as a feed. Defining a method for generating ids for such things is a little too far outside of the core of what we're doing to both with. You're right, of course. Anyway, I've added "originating" three times in that last sentence, making it "An atom:id value that has been used with one entry originating in a particular feed MUST NOT ever be used with a different entry originating in the same feed, and SHOULD NOT ever be used with an entry originating in another feed." Does that address the question sufficiently (within the scope of the Pace at least)? From owner-atom-syntax@mail.imc.org Tue May 3 04:34:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13810 for ; Tue, 3 May 2005 04:34: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 j438RRLs007008; Tue, 3 May 2005 01:27: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 j438RRsi007007; Tue, 3 May 2005 01:27: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 j438RQs9006964 for ; Tue, 3 May 2005 01:27:26 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j438RKm11937; Tue, 3 May 2005 17:27:20 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 3e346336_bbad_11d9_9799_0030482533a1_18947; Tue, 03 May 2005 17:27:53 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO004E02; 3 May 05 17:29:31 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 3 May 05 17:29:12 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG004DFB; 3 May 05 17:29:04 +0900 Message-Id: <6.0.0.20.2.20050503171556.08254cf0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 May 2005 17:21:13 +0900 To: Antone Roundy , atom-syntax@imc.org From: Martin Duerst Subject: Re: PaceDuplicateIDWithSource2 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 I'm not really happy with this. Conceptually, it seems to replace an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs (remember what they expand to), that doesn't make sense. What guarantee do we have that two feeds will be different? (yes, these days, we get feeds over http, but there are other ways to get feeds, where things may not be that easy). If we don't have a solution for the malicious case, and we think we need one, we should work on some security stuff. If we think that accidential ID duplication is a problem, then let's look at how we can improve the explanation. After that, there may still be an occasional accident, but the spec should be worded to catch that, not to provide a loophole. If we have to allow duplicate IDs, I'd rather prefer we do it without all this feed/source/... stuff: I.e. if you are an aggregator and can't manage to do duplicate elimination, you can just delegate the problem to the next place in the feeding chain. Regards, Martin. At 06:03 05/05/03, Antone Roundy wrote: > >http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 > >This is what I thought had been suggested. Hopefully I didn't err in putting two changes into one proposal, but the first seemed a little odd without the acknowledgment provided by the second. > >Coming up with wording for the first change that makes the point without getting horrendously verbose and convoluted isn't as easy as I thought! > >Antone > >== Abstract == > >Allow multiple entries with the same ID in a feed document if their source feeds are demonstrably different. Adjust the wording regarding the uniquess of atom:id values to reflect the recognition that publishers might duplicate each others' atom:ids, even if accidentally. > >== Status == > >Proposed. > >== Rationale == > >The current spec does not allow multiple entries in a feed document with the same ID. This can cause problems if, whether accidentally or maliciously, different feeds use the same IDs for their entries. This proposal alleviates this problem by allowing a feed document to contain multiple entries with the same ID as long as their source feed's ID is different, enabling consumers to determine that they are not duplicates of the same entry. > >The current spec requires atom:id values to be minted in a way that "assures uniqueness". This is impossible, since no one can prevent others from, whether accidentally or maliciously, duplicating one's ids. This proposal rewords that requirement to reflect recognition of this fact. > >== Proposal == > >In relation to atompub-format-08: > >In section 4.1.1, replace: > > atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values > >With: > > atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless the values of the atom:id elements for each of their source feeds is different. If the value of atom:id for the source feed cannot be determined by one of the two following rules, then the value of atom:id for the atom:entry MUST be unique within its enclosing atom:feed element. > > * If an atom:entry element contains an atom:source element, and that element contains an atom:id element, use its value. > * If an atom:entry does not contain an atom:source element, and the atom:entry element's parent atom:feed element contains an atom:id element, use its value. > >In 4.2.7, replace: > > The content of an atom:id element MUST be created in a way that assures uniqueness. > >With: > > The content of an atom:id element MUST be created in a way that, as nearly as possible, assures uniqueness. An atom:id value that has been used with one entry in a particular feed MUST NOT ever be used with a different entry in the same feed, and SHOULD NOT ever be used with an entry in another feed. > >== Impacts == > >Allows duplication ids within feeds, so atom:source/atom:id or atom:feed/atom:id must be examined when looking for duplicates. > From owner-atom-syntax@mail.imc.org Tue May 3 04:52:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15142 for ; Tue, 3 May 2005 04:52: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 j438hGwF012174; Tue, 3 May 2005 01:43: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 j438hGA6012173; Tue, 3 May 2005 01:43:16 -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 j438hF1x012134 for ; Tue, 3 May 2005 01:43:15 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j438h9m12939; Tue, 3 May 2005 17:43:09 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id a3453f2c_bbb0_11d9_866b_0030482532aa_12871; Tue, 03 May 2005 17:52:11 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO004E13; 3 May 05 17:45:20 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 3 May 05 17:45:11 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG004E12; 3 May 05 17:45:01 +0900 Message-Id: <6.0.0.20.2.20050503173520.0825bb00@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 03 May 2005 17:36:14 +0900 To: Julian Reschke , Thomas Broyer From: Martin Duerst Subject: Re: PaceXhtmlDivSuggestedOnly Cc: atom-syntax@imc.org In-Reply-To: <42752A88.9010103@gmx.de> References: <42739975.20003@cegetel.net> <42752A88.9010103@gmx.de> 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 04:14 05/05/02, Julian Reschke wrote: > >For the record...: > >+1 on not requiring wrapper elements +1 here, too. >+1 on properly distinguishing between block-level and in-line +0.5 here, the CSS display property can change things easily. Regards, Martin. >+1 on using the same recommendations for type="html" as well > >Best regards, Julian > From owner-atom-syntax@mail.imc.org Tue May 3 06:45:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29341 for ; Tue, 3 May 2005 06: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 j43Aaa2G050416; Tue, 3 May 2005 03:36: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 j43AaaJ5050415; Tue, 3 May 2005 03:36:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43AaYDA050400 for ; Tue, 3 May 2005 03:36:35 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-5199.l4.c3.dsl.pol.co.uk ([81.79.116.79] helo=[192.168.0.2]) by cmailg1.svr.pol.co.uk with esmtp (Exim 4.41) id 1DSulV-0004fv-Di for atom-syntax@imc.org; Tue, 03 May 2005 11:36:33 +0100 Message-ID: <4277543C.1000907@isofarro.uklinux.net> Date: Tue, 03 May 2005 11:36:44 +0100 From: Isofarro 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: editorial suggestion (draft 08): "date-time" 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 In section 3.3 titled "Date Constructs" 3.3 Date Constructs A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset. RFC3339 is offered as a description of the date format. I originally missed the nuance of "date-time", and immediately mistakenly thought all the "date formats" of section 5.6 in RFC3339 (including just the year alone) were allowed. (I was quickly scanning for an example of a date format - it was a silly series of mistakes on my part). Suggest that you list an example or two of the date formats allowable. Saves readers hunting down an example and missing the explicit mention of which format. So adding the following might alleviate confusion (the second uses the optional fraction of a second), and a time offset other than GMT (Z): 2003-12-13T18:30:02Z 2003-12-13T18:30:02.25Z 2003-12-13T18:30:02+01:00 2003-12-13T18:30:02.25+01:00 Thanks, Mike From owner-atom-syntax@mail.imc.org Tue May 3 07:23:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04786 for ; Tue, 3 May 2005 07:23: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 j43BBwuY062915; Tue, 3 May 2005 04:11: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 j43BBwBj062913; Tue, 3 May 2005 04:11:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43BBuZh062861 for ; Tue, 3 May 2005 04:11:57 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 3557 invoked by uid 10); 3 May 2005 11:11:50 -0000 Received: (vexira-qq 03546-2FCD5947 invoked from network) 03 May 2005 13:11:50 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 May 2005 11:11:50 -0000 Message-ID: <42775C77.8000009@annevankesteren.nl> Date: Tue, 03 May 2005 13:11:51 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: hreflang attribute should be allowed to be empty as well Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. [1] -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue May 3 10:39:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24943 for ; Tue, 3 May 2005 10:39: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 j43EUGr8018778; Tue, 3 May 2005 07:30: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 j43EUG20018777; Tue, 3 May 2005 07:30:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wvmler2.mail.xerox.com (wvmler2.mail.xerox.com [13.8.138.217]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43EUEYE018759 for ; Tue, 3 May 2005 07:30:15 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from wvmlir1.mail.xerox.com (wvmlir1.mail.xerox.com [13.147.8.221]) by wvmler2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43EU88n001114; Tue, 3 May 2005 07:30:14 -0700 Received: from wvmlir1.mail.xerox.com (localhost [127.0.0.1]) by wvmlir1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43ETUOl005866; Tue, 3 May 2005 07:29:30 -0700 Received: from usa7061gw04.na.xerox.net (usa7061gw04.na.xerox.net [13.151.32.6]) by wvmlir1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43ETUcF005859; Tue, 3 May 2005 07:29:30 -0700 Received: from usa7061ms01.na.xerox.net ([13.151.34.2]) by usa7061gw04.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 07:29:30 -0700 Received: from mail pickup service by usa7061ms01.na.xerox.net with Microsoft SMTPSVC; Tue, 3 May 2005 07:29:30 -0700 Received: from usa7061bh01.na.xerox.net ([13.151.33.5]) by usa7061ms01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 15:55:43 -0700 Received: from usa0300bh01.na.xerox.net ([13.129.0.48]) by usa7061bh01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 06:26:10 -0700 Received: from usa0300gw01.na.xerox.net ([13.129.0.40]) by usa0300bh01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 09:26:09 -0400 Received: from wbmlir2.mail.xerox.com ([13.131.8.222]) by usa0300gw01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 09:26:09 -0400 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmlir2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42DP2gT032539 for ; Mon, 2 May 2005 09:25:06 -0400 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmler1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42DNBkJ006413 for ; Mon, 2 May 2005 09:23:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by wbmler1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42DN8hh006370 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 2 May 2005 09:23:09 -0400 X-Xerox-Source-Ip: 208.184.76.39 X-Xerox-Source-Name: above.proper.com X-Xerox-Reported-Name: above.proper.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42D6CFL028725; Mon, 2 May 2005 06:06: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 j42D6CNG028724; Mon, 2 May 2005 06:06:12 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42D6BYA028713 for ; Mon, 2 May 2005 06:06:11 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id 441A422C196; Mon, 2 May 2005 15:06:04 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Mon, 2 May 2005 15:06:05 +0200 (CEST) Message-ID: <1345.82.127.77.43.1115039165.squirrel@ssl-webmail.sitadelle.com> Date: Mon, 2 May 2005 15:06:05 +0200 (CEST) Subject: Re: suggestion: add new value to type attribute From: "Thomas Broyer" To: In-Reply-To: References: <42761C3C.6080507@wp.pl> 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 List-Archive: List-Unsubscribe: List-ID: X-Brightmail-Flag: NO X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on wbmler1.mail.xerox.com X-Spam-Report: This mail has been scanned in order to control spam. The results are given below in the "Content Analysis" line. If the number of points is greater than required, then this mail is very probably spam. ---------------- Content Analysis: (0.0 points, 5.0 required) ---------------- X-Spam-Status: No, hits=0.0 required=5.0 tests=none X-Envelope-Trace: wbmler1.j42DNBkJ006413 X-Envelope-From: X-OriginalArrivalTime: 02 May 2005 13:26:09.0598 (UTC) FILETIME=[80A52DE0:01C54F1A] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Eric Scheid wrote: > > On 2/5/05 10:25 PM, "Domel" wrote: > >> I think that you should add new value to type attribute (3.1.1) - xml >> type="xml" >> This value will allow embed not only text, HTML and XHTML but also >> others XML applications like SVG, SMIL etc. >> Like in XSLT 2.0 draft in method attribute. >> > > the way it's done is that you put the mime-type of the xml into the type > attribute. That way you can not only have xml content, but you also > clearly communicate just what kind of xml it is. Note that this is only applicable to atom:content, not to Text Constructs, as these are really meant to be textual content: title, subtitle, summary and copyright. As we're about it, it might be good to have some text about possible future values and how Atom 1.0 compliant processors are supposed to handle those values. For example, assume Atom 2.0 adds the new value "docbook". How would Atom 1.0 processors treat a text construct with type="docbook"? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 3 10:40:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24974 for ; Tue, 3 May 2005 10:40: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 j43EVHfa018932; Tue, 3 May 2005 07:31: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 j43EVHoU018931; Tue, 3 May 2005 07:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wvmler1.mail.xerox.com (wvmler1.mail.xerox.com [13.8.138.216]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43EVGQt018924 for ; Tue, 3 May 2005 07:31:17 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from wvmlir2.mail.xerox.com (wvmlir2.mail.xerox.com [13.147.8.222]) by wvmler1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43EV21i032216 for ; Tue, 3 May 2005 07:31:16 -0700 Received: from wvmlir2.mail.xerox.com (localhost [127.0.0.1]) by wvmlir2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43EUtiM012953 for ; Tue, 3 May 2005 07:30:55 -0700 Received: from usa7061gw04.na.xerox.net (usa7061gw04.na.xerox.net [13.151.32.6]) by wvmlir2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43EUluZ012798 for ; Tue, 3 May 2005 07:30:55 -0700 Received: from usa7061ms01.na.xerox.net ([13.151.34.2]) by usa7061gw04.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 07:30:48 -0700 Received: from mail pickup service by usa7061ms01.na.xerox.net with Microsoft SMTPSVC; Tue, 3 May 2005 07:30:45 -0700 Received: from usa7061bh01.na.xerox.net ([13.151.33.5]) by usa7061ms01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 15:56:07 -0700 Received: from usa0300bh02.na.xerox.net ([13.129.0.50]) by usa7061bh01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 May 2005 04:30:03 -0700 Received: from usa0300gw02.na.xerox.net ([13.129.0.42]) by usa0300bh02.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 May 2005 07:30:01 -0400 Received: from wbmlir3.mail.xerox.com ([13.131.8.223]) by usa0300gw02.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 May 2005 07:30:00 -0400 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmlir3.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j41BT1uR006059 for ; Sun, 1 May 2005 07:29:02 -0400 Received: from wbmler1.mail.xerox.com (localhost [127.0.0.1]) by wbmler1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j41BRbpF023417 for ; Sun, 1 May 2005 07:27:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by wbmler1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j41BRbJf023413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 1 May 2005 07:27:37 -0400 X-Xerox-Source-Ip: 208.184.76.39 X-Xerox-Source-Name: above.proper.com X-Xerox-Reported-Name: above.proper.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41BGLk3045560; Sun, 1 May 2005 04:16: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 j41BGLbX045559; Sun, 1 May 2005 04:16:21 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j41BGKaN045535 for ; Sun, 1 May 2005 04:16:20 -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); Sun, 1 May 2005 21:07:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 01 May 2005 21:16:16 +1000 Subject: Re: PaceOptionalFeedLink From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050430120381bba2a@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit List-Archive: List-Unsubscribe: List-ID: X-Brightmail-Flag: NO X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on wbmler1.mail.xerox.com X-Spam-Report: This mail has been scanned in order to control spam. The results are given below in the "Content Analysis" line. If the number of points is greater than required, then this mail is very probably spam. ---------------- Content Analysis: (1.0 points, 5.0 required) ---------------- 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML 0.2 HTML_MESSAGE BODY: HTML included in message X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_30_40,HTML_MESSAGE X-Envelope-Trace: wbmler1.j41BRbpF023417 X-Envelope-From: X-OriginalArrivalTime: 01 May 2005 11:30:00.0856 (UTC) FILETIME=[1C89C980:01C54E41] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/5/05 5:03 AM, "Robert Sayre" wrote: > "atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same > combination of type and hreflang attribute values." how do I then point to both my full content feed *and* my summary only feed (and just quietly, my titles only feed)? the above spec text would make this invalid: e. From owner-atom-syntax@mail.imc.org Tue May 3 10:44:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25404 for ; Tue, 3 May 2005 10: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 j43EbH2c019802; Tue, 3 May 2005 07: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 j43EbHMa019801; Tue, 3 May 2005 07:37:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wvmler4.mail.xerox.com (wvmler4.mail.xerox.com [13.8.138.219]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43EbGJN019795 for ; Tue, 3 May 2005 07:37:16 -0700 (PDT) (envelope-from bob@wyman.us) Received: from wvmlir2.mail.xerox.com (wvmlir2.mail.xerox.com [13.147.8.222]) by wvmler4.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43Eb7Pf005155; Tue, 3 May 2005 07:37:16 -0700 Received: from wvmlir2.mail.xerox.com (localhost [127.0.0.1]) by wvmlir2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43Ea9h6015478; Tue, 3 May 2005 07:36:09 -0700 Received: from usa7061gw04.na.xerox.net (usa7061gw04.na.xerox.net [13.151.32.6]) by wvmlir2.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j43Ea8DR015448; Tue, 3 May 2005 07:36:09 -0700 Received: from usa7061ms01.na.xerox.net ([13.151.34.2]) by usa7061gw04.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 07:36:02 -0700 Received: from mail pickup service by usa7061ms01.na.xerox.net with Microsoft SMTPSVC; Tue, 3 May 2005 07:35:58 -0700 Received: from usa7061bh02.na.xerox.net ([13.151.33.6]) by usa7061ms01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 15:56:49 -0700 Received: from usa0300bh01.na.xerox.net ([13.129.0.48]) by usa7061bh02.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 14:53:07 -0700 Received: from usa0300gw02.na.xerox.net ([13.129.0.42]) by usa0300bh01.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 17:53:05 -0400 Received: from wbmlir1.mail.xerox.com ([13.131.8.221]) by usa0300gw02.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 May 2005 17:53:04 -0400 Received: from wbmler3.mail.xerox.com (localhost [127.0.0.1]) by wbmlir1.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42Lq2t2023001 for ; Mon, 2 May 2005 17:52:04 -0400 Received: from wbmler3.mail.xerox.com (localhost [127.0.0.1]) by wbmler3.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42LoLGs013826 for ; Mon, 2 May 2005 17:50:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by wbmler3.mail.xerox.com (8.13.4/8.13.1) with ESMTP id j42LoKkU013819 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 2 May 2005 17:50:21 -0400 X-Xerox-Source-Ip: 208.184.76.39 X-Xerox-Source-Name: above.proper.com X-Xerox-Reported-Name: above.proper.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LbETU096063; Mon, 2 May 2005 14:37: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 j42LbEJR096062; Mon, 2 May 2005 14:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42LbDUF096056 for ; Mon, 2 May 2005 14:37:13 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j42LbCvR002377; Mon, 2 May 2005 17:37:12 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBN62050 (AUTH bob@wyman.us); Mon, 2 May 2005 17:37:02 -0400 (EDT) Message-Id: <200505022137.DBN62050@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceDuplicateIDWithSource Date: Mon, 2 May 2005 17:37:01 -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 In-Reply-To: Thread-Index: AcVPUzPO+yTGY3/ESBelV3He73bukwACsXdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 List-Archive: List-Unsubscribe: List-ID: X-Brightmail-Flag: NO X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on wbmler3.mail.xerox.com X-Spam-Report: This mail has been scanned in order to control spam. The results are given below in the "Content Analysis" line. If the number of points is greater than required, then this mail is very probably spam. ---------------- Content Analysis: (0.0 points, 5.0 required) ---------------- X-Spam-Status: No, hits=0.0 required=5.0 tests=none X-Envelope-Trace: wbmler3.j42LoLGs013826 X-Envelope-From: X-OriginalArrivalTime: 02 May 2005 21:53:04.0821 (UTC) FILETIME=[5187E650:01C54F61] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > multiple representations of the same entry resource could appear > in a feed document as long as they were aggregated into the feed > by different routes. Two rules: 1. You should only write a source element into an entry if it does not already have one. 2. If you copy an entry that doesn't have a source element, then you SHOULD insert one that indicates source from which you copied the entry. (Note: I wish that SHOULD was a MUST...) The effect of these two rules is that the path from the original source to the final destination is irrelevant. An entry may have been copied 100's of times between many feeds; however, it should always carry identification of its *original* source. Remember, we explicitly decided not to deal with the issue of paths when these discussions and those on the more general issue of "provenance" were going on. bob wyman From owner-atom-syntax@mail.imc.org Tue May 3 11:05:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27669 for ; Tue, 3 May 2005 11:05: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 j43EwCrN022920; Tue, 3 May 2005 07:58: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 j43EwCxU022919; Tue, 3 May 2005 07:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43EwB6F022908 for ; Tue, 3 May 2005 07:58:12 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX00AM45B6AS10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 03 May 2005 16:52:18 +0200 (CEST) Received: from quark ([84.48.117.46]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX001855M83G50@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 03 May 2005 16:58:57 +0200 (CEST) Date: Tue, 03 May 2005 17:01:33 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: hreflang attribute should be allowed to be empty as well In-reply-to: <42775C77.8000009@annevankesteren.nl> To: Anne van Kesteren , Atom Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42775C77.8000009@annevankesteren.nl> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Tue, 03 May 2005 13:11:51 +0200, Anne van Kesteren wrote: > I think that the HREFLANG attribute[1] should be allowed to be empty as > well, just like xml:lang is allowed to be empty. I'm +1 to this. It makes sense. -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 3 11:06:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27851 for ; Tue, 3 May 2005 11: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 j43F0lK9023042; Tue, 3 May 2005 08:00: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 j43F0lkg023041; Tue, 3 May 2005 08:00:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43F0kgv023031 for ; Tue, 3 May 2005 08:00:47 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX00AO05FIAW10@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 03 May 2005 16:54:54 +0200 (CEST) Received: from quark ([84.48.117.46]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX001I95QL3G50@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 03 May 2005 17:01:33 +0200 (CEST) Date: Tue, 03 May 2005 17:04:10 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Getting atom:source right In-reply-to: To: Antone Roundy , atom-syntax@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy wrote: > Should we add something like this? > > If an atom:entry element already containing an atom:source element > is copied to another feed, the contents of the atom:source element > MUST NOT be replaced with metadata from the containing atom:feed. I think I understand what you want, but I'm having difficulties reading the paragraph. If I misunderstand (or don't undersand it at all ;-) it, perhaps readers and implementors of the Atom spec. will as well? > That's implied by "if it is not already present in the entry", but it > may be best to be more explicit. I agree. But I'm not sure the intended message is communicated clearly enough. But that might just be me. :-\ -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 3 11:15:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29042 for ; Tue, 3 May 2005 11:15: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 j43F9ali023941; Tue, 3 May 2005 08:09: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 j43F9a0V023940; Tue, 3 May 2005 08:09: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43F9ZAK023933 for ; Tue, 3 May 2005 08:09:36 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3555823wra for ; Tue, 03 May 2005 08:09:30 -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=aWjsb6KsKFHZvD+Sn1PlyQP1zOqSmgSLTsUFwrs/hWLU/MfLqkDi5gBuhpJeUaqZHcRwmyVK9OjEBQ+tLZtzE8V3qyzg/U96aOhZkDgY7V7AH2tvg/mujaI+WCyDIZiV4OtPLKAlN8ROKvFmeekMTYLp86fYXnJ4qM2fkBZglJM= Received: by 10.54.99.11 with SMTP id w11mr1135844wrb; Tue, 03 May 2005 08:09:30 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 3 May 2005 08:09:30 -0700 (PDT) Message-ID: <68fba5c505050308093478fde@mail.gmail.com> Date: Tue, 3 May 2005 11:09:30 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: hreflang attribute should be allowed to be empty as well Cc: Atom Syntax In-Reply-To: <42775C77.8000009@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42775C77.8000009@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43F9aAK023935 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/3/05, Anne van Kesteren wrote: > > I think that the HREFLANG attribute[1] should be allowed to be empty as > well, just like xml:lang is allowed to be empty. Why would we want that? xml:lang uses the empty string to halt inheritance, if necessary. hreflang doesn't have that problem. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 11:24:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00034 for ; Tue, 3 May 2005 11:24: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 j43FEeg3024667; Tue, 3 May 2005 08:14: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 j43FEeFP024666; Tue, 3 May 2005 08:14: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43FEdao024648 for ; Tue, 3 May 2005 08:14:39 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3559147wra for ; Tue, 03 May 2005 08:14:34 -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=QeY/UTiYtu1WraePczCibFD3Us5mcZS6C+P123XjFWoUS9IpEN2cpE/C0dFBb4H9ZU4t+a26mAUOfNkFBKeQMn2LE44gXrvx9A8icCyRpz0nM359O/qM1yPgOH2vUvq+81DqCJpcKzghIPFPQiwn+DljtZUNnK2S3Ti/l4HCE7c= Received: by 10.54.99.11 with SMTP id w11mr1138706wrb; Tue, 03 May 2005 08:14:34 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 3 May 2005 08:14:34 -0700 (PDT) Message-ID: <68fba5c505050308144c217d2c@mail.gmail.com> Date: Tue, 3 May 2005 11:14:34 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Last minute editorial suggestions Cc: atom-syntax In-Reply-To: <8478296E-3759-4483-8226-8019C4FA0B30@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <8478296E-3759-4483-8226-8019C4FA0B30@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43FEeao024661 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/2/05, Graham wrote: > > - In section 4.2.4 there's an obsolete reference to atom:head > > - In section 3.1.1.3, the text "The XHTML div element itself MUST NOT > be considered part of the content" is inadequate. Replace with (or > add): "The intended value of the content is contained within the > XHTML div, and the div itself MUST be discarded." (I sort of > suggested this before) Why is it inadequate? I don't think the suggested text is any clearer, since "MUST be discarded" isn't very meaningful or accurate. If it refers to what happens when an implementation takes the HTML and puts it somewhere else, we're definitely not going to be specifying that. It's better to describe what the markup means whenever possible. > > - In section 4.2.7.1 "Comparing atom:id", the two lists give the > impression of "these ones are different" and "but, these ones are the > same" when reading quickly. I'd suggest either merging the lists and > discussing the implications at the bottom, or moving the discussion > to the top of each list: Looks good. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 11:26:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00162 for ; Tue, 3 May 2005 11:26: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 j43FHauI025206; Tue, 3 May 2005 08:17: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 j43FHaSr025205; Tue, 3 May 2005 08:17: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43FHZkW025175 for ; Tue, 3 May 2005 08:17:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3561260wra for ; Tue, 03 May 2005 08:17:30 -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=FGASFsSqK80ewLLPO1hu9bFHqmj0/cDs0yAQf/nak13o5t31gbKfZMz0ID8CMCkt83PuWu7/zN58D30WPPVaCGpKPlRZhOCG92KgbnvwnCfTIghzwS98vPIt/kd2biOMbvqhUGtdfJw0EysPPAHbcmtkUiXFwJjrRBB6yj93Y3c= Received: by 10.54.122.17 with SMTP id u17mr1141788wrc; Tue, 03 May 2005 08:17:30 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 3 May 2005 08:17:30 -0700 (PDT) Message-ID: <68fba5c505050308172deb85f2@mail.gmail.com> Date: Tue, 3 May 2005 11:17:30 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Isofarro Subject: Re: editorial suggestion (draft 08): "date-time" format Cc: atom-syntax@imc.org In-Reply-To: <4277543C.1000907@isofarro.uklinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4277543C.1000907@isofarro.uklinux.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43FHZkW025197 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/3/05, Isofarro wrote: > > Suggest that you list an example or two of the date formats allowable. > Saves readers hunting down an example and missing the explicit mention > of which format. Agree. Will do. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 11:26:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00240 for ; Tue, 3 May 2005 11:26: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 j43FM6VZ025939; Tue, 3 May 2005 08:22: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 j43FM6l9025938; Tue, 3 May 2005 08:22:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [64.134.126.251] (dhcp64-134-126-251.sjcc.sjc.wayport.net [64.134.126.251]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43FM5lR025920 for ; Tue, 3 May 2005 08:22:06 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 3 May 2005 08:21:59 -0700 To: Atom WG From: Paul Hoffman Subject: ADMINISTRIVIA: another mail loop Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Expect to see at least a couple of more duplicates of recent messages on the list. This one comes courtesy of Xerox. The offending user has been removed from the mailing list and been told of the problem. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 3 11:45:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02207 for ; Tue, 3 May 2005 11:45: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 j43FXj55027734; Tue, 3 May 2005 08:33: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 j43FXi1v027733; Tue, 3 May 2005 08:33:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43FXiXb027716 for ; Tue, 3 May 2005 08:33:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j43FV320024804; Tue, 3 May 2005 16:31:13 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57D233D0-D16F-40CB-909D-9E15149C8222@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Getting atom:source right Date: Tue, 3 May 2005 16:31:59 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 May 2005, at 10:13 pm, Antone Roundy wrote: > Should we add something like this? > > If an atom:entry element already containing an atom:source > element > is copied to another feed, the contents of the atom:source > element > MUST NOT be replaced with metadata from the containing atom:feed. > > That's implied by "if it is not already present in the entry", but > it may be best to be more explicit. Yes, but I agree about the lack of clarity with this particular wording. Graham From owner-atom-syntax@mail.imc.org Tue May 3 11:46:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02304 for ; Tue, 3 May 2005 11:46: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 j43FVGSx027395; Tue, 3 May 2005 08: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 j43FVGdL027394; Tue, 3 May 2005 08:31:16 -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 j43FVFga027376 for ; Tue, 3 May 2005 08:31:15 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3569984wra for ; Tue, 03 May 2005 08:31: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=VLXNHflBfe/p6ZB11bA6BgXbcsXxsDntN/zc8SnrwLSkiDMebDuxUu8Ozu517JUPy8a9d8tudnvim+1BPbXQyau5m+bMSxQE94KLDOH+Ipg7k8KbXQ1wgFZavROU01N72zmd+iBnbKl3LCnn3XmvyNCwQKjqzzQ8T4GdBpN6RSA= Received: by 10.54.114.11 with SMTP id m11mr1150216wrc; Tue, 03 May 2005 08:31:09 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 3 May 2005 08:31:09 -0700 (PDT) Message-ID: <68fba5c5050503083159842561@mail.gmail.com> Date: Tue, 3 May 2005 11:31:09 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: Alexey Melnikov , Mark Nottingham , Robert Sayre , iesg@ietf.org, atom-syntax@imc.org In-Reply-To: <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43FVFga027389 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/29/05, Martin Duerst wrote: > At 03:33 05/04/29, Alexey Melnikov wrote: > > > >Ok, maybe it is just me, but what does it mean to "collapse white-space"? > Does this mean to replace FWS (in RFC 2822 sense) with a single space? > > Making this more precise is definitely desirable. But there is also > an i18n issue: This works fine for languages that use spaces between > words. It doesn't work for languages that don't have spaces between > words (Chinese, Japanese, Thai,...). If Text elements are only used > for short things such as names or titles, that's not a big issue, > the text in question can just be put on a single line. However, > when the texts in question are long, it's a serious issue, and > should be fixed. I believe the intent of this text was to match HTML's text treatment, so that implementations can avoid preprocessing whitespace. http://www.w3.org/TR/html4/struct/text.html#h-9.1 Suggestions for less vague text is welcome, but I want to make sure the text remains comprehensible to non-experts. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 12:00:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03368 for ; Tue, 3 May 2005 12: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 j43Fr2fQ030553; Tue, 3 May 2005 08:53: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 j43Fr2Pj030552; Tue, 3 May 2005 08:53:02 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43Fr0D5030527 for ; Tue, 3 May 2005 08:53:01 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-103.dti.cegetel.net [217.19.192.103]) by smtp.cegetel.net (Postfix) with SMTP id D08743185BE; Tue, 3 May 2005 17:52:50 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 3 May 2005 17:52:55 +0200 (CEST) Message-ID: <2151.82.127.77.43.1115135575.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 3 May 2005 17:52:55 +0200 (CEST) Subject: Re: PaceXhtmlDivSuggestedOnly From: "Thomas Broyer" To: In-Reply-To: <6.0.0.20.2.20050503173520.0825bb00@itmail.it.aoyama.ac.jp> References: <42739975.20003@cegetel.net> <42752A88.9010103@gmx.de> <6.0.0.20.2.20050503173520.0825bb00@itmail.it.aoyama.ac.jp> 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 Martin Duerst wrote: > > At 04:14 05/05/02, Julian Reschke wrote: > >+1 on properly distinguishing between block-level and in-line > > +0.5 here, the CSS display property can change things easily. So this is OK for you?
  • This
  • is
  • a
  • title

...with block-level content.

 -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 3 13:01:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10371 for ; Tue, 3 May 2005 13:01: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 j43Gpw8D038791; Tue, 3 May 2005 09:51: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 j43Gpw6r038790; Tue, 3 May 2005 09:51:58 -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 j43GpvqX038773 for ; Tue, 3 May 2005 09:51:58 -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 j43GpvjO008966 for ; Tue, 3 May 2005 10:51:57 -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 <0IFX0000TAUL1D@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 May 2005 10:51:57 -0600 (MDT) Received: from [192.168.1.20] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFX000SJAUK8A@mail.sun.net> for atom-syntax@imc.org; Tue, 03 May 2005 10:51:57 -0600 (MDT) Date: Tue, 03 May 2005 09:52:59 -0700 From: Tim Bray Subject: Autodiscovery To: "atom-syntax Syntax'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG draft, and has done so, see: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml Although Mark's not subscribed, I've agreed to relay any changes that have WG consensus back to him for update; although if they're minor, I guess one of us could just rejigger the XML ourselves. I scanned them and nothing objectionable leapt out at me, but please, could a few more people also have a look? Assuming no errors, or rather that any errors we turn up are fixed, are there any objections to us submitting this I-D as a product of the Atompub WG? -Tim From owner-atom-syntax@mail.imc.org Tue May 3 13:14:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11554 for ; Tue, 3 May 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 j43H9K3j041297; Tue, 3 May 2005 10:09: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 j43H9Kwt041296; Tue, 3 May 2005 10:09: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 j43H9J6f041279 for ; Tue, 3 May 2005 10:09:19 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 03 May 2005 17:09:12 -0000 Received: from p508FA37C.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.163.124] by mail.gmx.net (mp014) with SMTP; 03 May 2005 19:09:12 +0200 X-Authenticated: #1915285 Message-ID: <4277B035.8030105@gmx.de> Date: Tue, 03 May 2005 19:09:09 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: "atom-syntax Syntax'" Subject: Re: Autodiscovery References: In-Reply-To: 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 Tim Bray wrote: > > Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG > draft, and has done so, see: > > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml > > Although Mark's not subscribed, I've agreed to relay any changes that > have WG consensus back to him for update; although if they're minor, I > guess one of us could just rejigger the XML ourselves. > > I scanned them and nothing objectionable leapt out at me, but please, > could a few more people also have a look? > > Assuming no errors, or rather that any errors we turn up are fixed, are > there any objections to us submitting this I-D as a product of the > Atompub WG? -Tim One thing that immediately comes to mind that the references need to be checked, for instance for URI (not RFC2396 anymore) and for XML 1.0 (now at 3rd edition). Best regards, Julian From owner-atom-syntax@mail.imc.org Tue May 3 13:15:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11580 for ; Tue, 3 May 2005 13:15: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 j43H7513040885; Tue, 3 May 2005 10:07: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 j43H75GX040884; Tue, 3 May 2005 10:07:05 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43H736P040866 for ; Tue, 3 May 2005 10:07:04 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.38.156]) by smtp.cegetel.net (Postfix) with ESMTP id 7F5731A41F3; Tue, 3 May 2005 19:06:57 +0200 (CEST) Message-ID: <4277AFC3.1030500@cegetel.net> Date: Tue, 03 May 2005 19:07:15 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Anne van Kesteren Cc: Atom Syntax Subject: Re: hreflang attribute should be allowed to be empty as well References: <42775C77.8000009@annevankesteren.nl> In-Reply-To: <42775C77.8000009@annevankesteren.nl> 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 Anne van Kesteren wrote: > > I think that the HREFLANG attribute[1] should be allowed to be empty as > well, just like xml:lang is allowed to be empty. xml:lang is allowed to be empty to override a previous, inherited, xml:lang declaration without specifying a new language. As xml:lang doesn't apply to the content of the linked resource, hreflang does not need to allow an empty value. If you don't want to or can't specify the language of the linked resource, just omit the hreflang attribute. We might want to distinguish those two cases: not providing a language hint vs. explicitly telling the linked resource can't be "language qualified" but I'm not sure why this would be needed and what would be the difference (interop, accessibility, etc.) However, we may need to make clearer that an xml:lang doesn't apply to the linked resource. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 3 13:23:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12255 for ; Tue, 3 May 2005 13:23: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 j43HFPRS042363; Tue, 3 May 2005 10:15: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 j43HFPV2042362; Tue, 3 May 2005 10:15: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43HFOPO042343 for ; Tue, 3 May 2005 10:15:24 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3637028wra for ; Tue, 03 May 2005 10:15:18 -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=ANHssEYU7CVsdUeMzSeiixXipY4vWPYUtXvG/2sqtsAUZWRF3jJK6855Z+VNONX2VjjBiWhp0ZMhfZ+uX6CwaEVWwhxJAdtilA4yc7Qj4d3+lrWzYRnyipc5kvsS244zzpiGfLckdUKHg5hJIHEuL3YXwPZEgLtsIMB2qKEuovc= Received: by 10.54.114.11 with SMTP id m11mr1209521wrc; Tue, 03 May 2005 10:15:18 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 3 May 2005 10:15:18 -0700 (PDT) Message-ID: <68fba5c505050310153619b251@mail.gmail.com> Date: Tue, 3 May 2005 13:15:18 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Re: Autodiscovery In-Reply-To: <68fba5c505050310146ade3af6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505050310146ade3af6@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43HFOPO042356 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/3/05, Tim Bray wrote: > I scanned them and nothing objectionable leapt out at me, but please, > could a few more people also have a look? I've never liked the rules in section 6. For example, when presenting a single option from multiple link elements, UAs should be permitted to present an alternate in the user's preferred language. I'm pretty sure this issue was the subject of my first post to atom-syntax. What a rathole that turned out to be... Also, the references need updating in some cases, unless they are supposed to match what's in the HTML drafts. RFC2045 might need to be updated to the Freed/Klensin draft that the format references. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 13:24:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12380 for ; Tue, 3 May 2005 13:24: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 j43HIGhg042810; Tue, 3 May 2005 10:18: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 j43HIGru042809; Tue, 3 May 2005 10:18:16 -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 j43HIFQc042789 for ; Tue, 3 May 2005 10:18:15 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 72501 messnum 7061897 invoked from network[83.70.217.193/unknown]); 3 May 2005 17:18:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail01.svc.cra.dublin.eircom.net (qp 72501) with SMTP; 3 May 2005 17:18:08 -0000 Message-ID: <4277B24D.5010707@dehora.net> Date: Tue, 03 May 2005 18:18:05 +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 Syntax'" Subject: Re: Autodiscovery 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 Tim Bray wrote: > Assuming no errors, or rather that any errors we turn up are fixed, are > there any objections to us submitting this I-D as a product of the > Atompub WG? -Tim How do we manage a WG product produced and edited by a non-WG member? This isn't an objection, btw, I'm just curious about the pragmatics of editorship and decision making when the editor isn't here. I remember Mark P said something on this list once about showing up, it stuck with me because he'd nailed it. cheers Bill From owner-atom-syntax@mail.imc.org Tue May 3 13:25:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12524 for ; Tue, 3 May 2005 13: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 j43HIWNp042874; Tue, 3 May 2005 10:18: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 j43HIWgp042873; Tue, 3 May 2005 10:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43HIVW7042844 for ; Tue, 3 May 2005 10:18:31 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j43HGsmA018875; Tue, 3 May 2005 18:16:59 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F8743D8-F2C5-4165-B796-821BFCEEA874@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Autodiscovery Date: Tue, 3 May 2005 18:17:06 +0100 To: Tim Bray X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 May 2005, at 5:52 pm, Tim Bray wrote: > I scanned them and nothing objectionable leapt out at me, but > please, could a few more people also have a look? The only thing I noticed was the href attribute definition: "The value MAY be a relative URI, and if so, clients MUST resolve it to a full URI (section 5 of [RFC2396]) using the document's base URI (section 12.4 of HTML 4 [W3C.REC-html401-19991224])" I'd be happier with "the document's base URI" being replaced with "the prevailing base URI", since the current wording could easily be misinterpreted as meaning only the URI it was loaded from. (Yes, I'm aware an HTML or XHTML document only has a single base URI for the whole thing, and that the section 12.4 referenced is the element definition, but it took me a while to look that up) From owner-atom-syntax@mail.imc.org Tue May 3 13:33:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13185 for ; Tue, 3 May 2005 13:33: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 j43HQwaD043946; Tue, 3 May 2005 10:26: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 j43HQwIT043945; Tue, 3 May 2005 10:26:58 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43HQvkj043906 for ; Tue, 3 May 2005 10:26:57 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.38.156]) by smtp.cegetel.net (Postfix) with ESMTP id 42CB43187C7; Tue, 3 May 2005 19:26:51 +0200 (CEST) Message-ID: <4277B471.7030100@cegetel.net> Date: Tue, 03 May 2005 19:27:13 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Martin Duerst Cc: Alexey Melnikov , Mark Nottingham , Robert Sayre , iesg@ietf.org, atom-syntax@imc.org Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> In-Reply-To: <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> 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 Martin Duerst wrote: > > At 03:33 05/04/29, Alexey Melnikov wrote: > > > If the value is "text", the content of the Text construct MUST NOT > > > contain child elements. Such text is intended to be presented to > > > humans in a readable fashion. Thus, Atom Processors MAY collapse > > > white-space (including line-breaks), > > > >Ok, maybe it is just me, but what does it mean to "collapse > >white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a > >single space? > > Making this more precise is definitely desirable. But there is also > an i18n issue: This works fine for languages that use spaces between > words. It doesn't work for languages that don't have spaces between > words (Chinese, Japanese, Thai,...). If Text elements are only used > for short things such as names or titles, that's not a big issue, > the text in question can just be put on a single line. However, > when the texts in question are long, it's a serious issue, and > should be fixed. My understanding of type="text" is that this is "just text" without any "formatting". Hence, it is not meant to be "preformatted text" such as text/plain or inside an (X)HTML "pre". This means type="text" content is a single paragraph of text. If you need paragraphs, lists or any other "structural formatting", you have to use type="html" or type="xhtml" with the appropriate content. I was about to writing a Pace about white-space handling in type="text" (either using xml:space or an attribute that would have mimic'd the "white-space" CSS property) when I understood/recalled that Text Constructs have accessibility in mind (hence their limitation to textual contents) and preformatted text is not accessible enough. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 3 13:40:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13769 for ; Tue, 3 May 2005 13:40: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 j43HXP00044787; Tue, 3 May 2005 10:33: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 j43HXPpE044786; Tue, 3 May 2005 10:33:25 -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 j43HXOh8044759 for ; Tue, 3 May 2005 10:33:25 -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; Tue, 03 May 2005 13:33:19 -0400 id 002F00E2.4277B5DF.00005109 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" , "'atom-syntax Syntax''" Subject: RE: Autodiscovery Date: Tue, 3 May 2005 13:33:22 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749CA9F@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4277B24D.5010707@dehora.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43HXPh8044781 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Bill de hra [mailto:bill@dehora.net] > Sent: Tuesday, May 03, 2005 1:18 PM > To: atom-syntax Syntax' > Subject: Re: Autodiscovery > > > > Tim Bray wrote: > > > Assuming no errors, or rather that any errors we turn up > are fixed, are > > there any objections to us submitting this I-D as a product of the > > Atompub WG? -Tim > > How do we manage a WG product produced and edited by a non-WG member? I've privately asked Tim and Paul the same question. Though section 6.3 of RFC 2418 doesn't specifically say that a document editor MUST be a member of the working group, the situation appears so obvious that it shouldn't need to be stated. -Scott- From owner-atom-syntax@mail.imc.org Tue May 3 13:50:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14691 for ; Tue, 3 May 2005 13:50: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 j43HiV46046565; Tue, 3 May 2005 10:44: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 j43HiVS9046564; Tue, 3 May 2005 10:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43HiVUF046549 for ; Tue, 3 May 2005 10:44:31 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from wintermute (ti132110a080-1210.bb.online.no [85.165.132.186]) by faceman.dreamhost.com (Postfix) with ESMTP id C1CA5111DA7; Tue, 3 May 2005 10:44:29 -0700 (PDT) Date: Tue, 03 May 2005 19:42:55 +0200 To: Atom-syntax Subject: Re: Autodiscovery References: Cc: "Tim Bray" From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (Win32, build 7587) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 03 May 2005 18:52:59 +0200, Tim Bray wrote: > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html > http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml > > Although Mark's not subscribed, I've agreed to relay any changes that > have WG consensus back to him for update; although if they're minor, I > guess one of us could just rejigger the XML ourselves. First, I am not too fond of making an autodiscovery protocol "Atom-only" - we will have to live with other feed formats for a few years still, so I think we should embrace legacy feed formats. These are my suggestions 1) Change the attribute value for the rel from "alternate" to "feed", or some similar wording. A feed is not always an alternate of the HTML document in which it occurs. Suggested replacement text: # 4.1 rel attribute # The rel attribute MUST be present in an Atom autodiscovery element. As defined # in section 6.12 of HTML 4 [W3C.REC-html401-19991224], the value of the rel # attribute is a space-separated list of keywords. The list of keywords MUST # include the keyword "feed" in uppercase, lowercase, or mixed case. 2) I am not too fond of requiring a type attribute, since feeds may be served in multiple formats from a single URL. I have previously performed a survey about how aggregators handle content negotiation, , and with sensible q-values set, aggregators currently in development may be served feeds in a format they're able to understand. In line with this, I suggeest that section 4.2 is removed, and that a new section 5.1 is added: # 5.1 type attribute # The type attribute MAY be present in an Atom autodiscovery element. As defined # in section 12.3 of HTML 4 [W3C.REC-html401-19991224], the value of the type # attribute of any link element MUST be a registered Internet media type [RFC2045]. -- Arve Bersvendsen From owner-atom-syntax@mail.imc.org Tue May 3 15:42:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26566 for ; Tue, 3 May 2005 15:42: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 j43JWSpt064466; Tue, 3 May 2005 12:32: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 j43JWSms064465; Tue, 3 May 2005 12:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43JWREF064444 for ; Tue, 3 May 2005 12:32:27 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j43JVmUd004951; Tue, 3 May 2005 20:31:53 +0100 (BST) In-Reply-To: <42712C6D.4030905@isode.com> References: <42712C6D.4030905@isode.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05BDB9EA-9D4A-41AD-8A6E-D1B998A922AA@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 3 May 2005 20:32:04 +0100 To: Alexey Melnikov X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 28 Apr 2005, at 7:33 pm, Alexey Melnikov wrote: > Ok, maybe it is just me, but what does it mean to "collapse white- > space"? Does this mean to replace FWS (in RFC 2822 sense) with a > single space? Since the statement is a MAY, I don't think any exact meaning is necessary. It's simply a hint to publishers that whitespace may not be preserved. On 29 Apr 2005, at 10:17 am, Martin Duerst wrote: > Making this more precise is definitely desirable. But there is also > an i18n issue: This works fine for languages that use spaces between > words. It doesn't work for languages that don't have spaces between > words (Chinese, Japanese, Thai,...). If Text elements are only used > for short things such as names or titles, that's not a big issue, > the text in question can just be put on a single line. However, > when the texts in question are long, it's a serious issue, and > should be fixed. A consumer may do anything that can reasonably be described as "collapsing whitespace", but are not required to. How does this cause problems in Asian languages? Graham From owner-atom-syntax@mail.imc.org Tue May 3 17:18:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13147 for ; Tue, 3 May 2005 17:18: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 j43L9qGo079726; Tue, 3 May 2005 14:09: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 j43L9qrK079724; Tue, 3 May 2005 14:09:52 -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 j43L9p29079718 for ; Tue, 3 May 2005 14:09:51 -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 j43L9pi7023484 for ; Tue, 3 May 2005 15:09:51 -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 <0IFX001O7MSEKV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 03 May 2005 15:09:51 -0600 (MDT) Received: from [192.168.1.19] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFX00ASTMS8OI@mail.sun.net> for atom-syntax@imc.org; Tue, 03 May 2005 15:09:50 -0600 (MDT) Date: Tue, 03 May 2005 14:10:46 -0700 From: Tim Bray Subject: Re: Autodiscovery In-reply-to: <046F43A8D79C794FA4733814869CDF0749CA9F@dul1wnexmb01.vcorp.ad.vrsn.com> To: "'atom-syntax Syntax''" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <046F43A8D79C794FA4733814869CDF0749CA9F@dul1wnexmb01.vcorp.ad.vrsn.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 3, 2005, at 10:33 AM, Scott Hollenbeck wrote: > I've privately asked Tim and Paul the same question. Though section > 6.3 of > RFC 2418 doesn't specifically say that a document editor MUST be a > member of > the working group, the situation appears so obvious that it shouldn't > need > to be stated. OK, that's an issue, plus it turns out that there are people who actually want to make changes. So I guess we'll need a new co-editor and to do some actual WG process. I'll talkk to Paul about it. -Tim From owner-atom-syntax@mail.imc.org Tue May 3 18:45:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20022 for ; Tue, 3 May 2005 18:45: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 j43FrGME030585; Tue, 3 May 2005 08:53: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 j43FrGYT030584; Tue, 3 May 2005 08:53:16 -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 j43FrFrb030565 for ; Tue, 3 May 2005 08:53:16 -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 <2005050315530801100mratje>; Tue, 3 May 2005 15:53:09 +0000 Date: Tue, 3 May 2005 09:53:07 -0600 Subject: Re: Getting atom:source right Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: Message-Id: <714BED86-BBEB-11D9-8A80-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j43FrGrb030579 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, May 3, 2005, at 09:04 AM, Asbjrn Ulsberg wrote: > On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy > wrote: >> Should we add something like this? >> >> If an atom:entry element already containing an atom:source >> element >> is copied to another feed, the contents of the atom:source >> element >> MUST NOT be replaced with metadata from the containing >> atom:feed. > > I think I understand what you want, but I'm having difficulties > reading the paragraph. If I misunderstand (or don't undersand it at > all ;-) it, perhaps readers and implementors of the Atom spec. will as > well? > The point is that atom:summary is to contain the metadata from the feed in which the entry originated. When an entry is copied form the originating feed, the feeds metadata is put into atom:summary inside the entry. When the same entry is copied from the second feed to a third feed, it already has atom:summary, so the metadata from the second feed MUST NOT be copied into atom:summary, which would replace the metadata from the originating feed. Which part of this is unclear from the text above? Would this be better? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of the atom:source element MUST NOT be replaced. This simplifies the sentence, and contains all the critical information. I personally don't like it as much, because it feels a little incomplete, and it doesn't call out the metadata that people would be most likely to erroneously replace it with. But I wouldn't complain if we went with this. From owner-atom-syntax@mail.imc.org Tue May 3 18:50:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20475 for ; Tue, 3 May 2005 18:50: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 j43MfB8J094352; Tue, 3 May 2005 15:41: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 j43MfBFi094351; Tue, 3 May 2005 15:41:11 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43Mf8tX094330 for ; Tue, 3 May 2005 15:41:09 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.38.156]) by smtp.cegetel.net (Postfix) with ESMTP id 0CEE41A4496; Wed, 4 May 2005 00:41:02 +0200 (CEST) Message-ID: <4277FE13.9010401@cegetel.net> Date: Wed, 04 May 2005 00:41:23 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Martin Duerst Cc: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceDuplicateIDWithSource2 References: <6.0.0.20.2.20050503171556.08254cf0@itmail.it.aoyama.ac.jp> In-Reply-To: <6.0.0.20.2.20050503171556.08254cf0@itmail.it.aoyama.ac.jp> 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 Martin Duerst wrote: > > I'm not really happy with this. Conceptually, it seems to replace > an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs > (remember what they expand to), that doesn't make sense. > What guarantee do we have that two feeds will be different? > (yes, these days, we get feeds over http, but there are other > ways to get feeds, where things may not be that easy). > > If we don't have a solution for the malicious case, and we > think we need one, we should work on some security stuff. > > If we think that accidential ID duplication is a problem, > then let's look at how we can improve the explanation. > After that, there may still be an occasional accident, > but the spec should be worded to catch that, not to > provide a loophole. > > If we have to allow duplicate IDs, I'd rather prefer we > do it without all this feed/source/... stuff: I.e. if > you are an aggregator and can't manage to do duplicate > elimination, you can just delegate the problem to the > next place in the feeding chain. OK, so, something like this (conceptually). First, start with the "originating publisher": 1. *You* MUST NOT use an atom:id for different entries (entries as resource, not as representations) in any of *your* feeds. 2. *You* MUST NOT include the same entry (resource, not representation) more than once in a feed. -> atom:id should be reworded to clarify that they identify an "entry resource", not each of its representations. Next, what about aggregation? First thoughts: As atom:id are not guaranteed to be "globally unique", aggregated feeds might contain different entries (entry resources) with the same atom:id. As they are aggregated entries, they should (I'd also wish it were a MUST) have an atom:source. So we can say that a feed is allowed to include different entries sharing the same atom:id as long as at most one of them doesn't have an atom:source). This is also a way to enforce the second item of the above list in the "publishers' camp". -> please, change the SHOULD on atom:source to a MUST One step further: aggregation of aggregated feeds. We didn't handled the case where a single entry can appear more than once in an aggregated feed because of different aggregation routes. There, we need to identify and distinguish feeds from each other, so yes we're moving to an identifier pair (feed+entry). So we have to look at the atom:source and its content. However, we didn't solve the problem as, IMO, we shouldn't require an entry to have a single source feed. Publishers should be allowed to publish an entry in several feeds (main + category) without the atom:source hassle. atom:id is also not a required metadata of a feed. Suggestion: "delegate the problem to the next place in the feeding chain". This will push delegation 'til the end-user's aggregator where he might have settings on how to treat entries with the same atom:id but different feed's atom:id. Finally, what about atom:id at the feed level? IMO, different feed "flavors" (full-content, summary-only, title-only) should use the same atom:id as a mean to say "I guaranty that these are the same (e.g. they are updated simultaneously and one is not a subset/superset of another), with different levels of richness". It should be the same for last-10-entries vs. last-50-entries feeds, as long as their [insert lesser denominator here, e.g. 10] most recent entries (based on their atom:updated) are the same (based on their atom:id), it'd then be a mean to say "I guaranty that these are the same (e.g. they are updated simultaneously), with different history lengths". Oh, and last but not least: these considerations on "entry identification" should IMO appear in an informative appendix. The normative part of the spec would just say a feed SHOULD NOT include more than one entry with a given atom:id and then point to the appendix for more about some ways of identifying entry duplicates. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 3 20:04:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24833 for ; Tue, 3 May 2005 20: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 j43NuloI003519; Tue, 3 May 2005 16:56: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 j43Nul7F003518; Tue, 3 May 2005 16:56:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j43Nuk1H003512 for ; Tue, 3 May 2005 16:56:46 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id 7CCA316EE0; Tue, 3 May 2005 18:56:48 -0500 (CDT) Date: Tue, 3 May 2005 18:56:48 -0500 From: David Nesting To: Arve Bersvendsen Cc: atom-syntax@imc.org Subject: Re: Autodiscovery Message-ID: <20050503235648.GC2161@home.fastolfe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 03, 2005 at 07:42:55PM +0200, Arve Bersvendsen wrote: > > 1) Change the attribute value for the rel from "alternate" to "feed", or > some similar wording. A feed is not always an alternate of the HTML > document in which it occurs. Suggested replacement text: I'm all for avoiding pigeonholing like that. But what about the case when a feed IS an alternate version? HTML says to use "alternate", this says to use "feed". Which takes precedence? Plus, "feed" is kind of application-specific. What about "related"? Consider also that HTML allows alternate stylesheets to be identified with the relationships "alternate" and "stylesheet". HTML overrides the semantics of "alternate" in this case (since the stylesheet isn't an alternate version of the page, it's just an alternate stylesheet). Who's to say we can't overload it a little for this case? So I might suggest, in order of preference: 1. "alternate" for feeds that can be considered alternate versions of the current document, and "related" for feeds that can be discovered via this page, but aren't actually an alternate form of the content on that page; or 2. "feed" for all feeds, and "alternate feeds" for feeds that can be considered alternate versions of the current document. (This would use "alternate" with its stand-alone meaning, not the meaning given to it in the "alternate stylesheet" case.) > 2) I am not too fond of requiring a type attribute, since feeds may be > served in multiple formats from a single URL. I have previously performed Omitting the type is only practical when you have a link relationship dedicated to this specific application. If we continue to use generic relationships like "alternate" and/or "related", it becomes a little inefficient since you have to hit the link targets pretty much indiscriminately looking for one that responds with a media type you're looking for. I expect that many of my implementations will utilize content negotiation (using the same URL as an HTML representation, where needed), so I expect that I'll have some links like: Or even As crazy as that looks, is there a better way of saying "this URL is also available in these media types"? David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Tue May 3 20:30:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26497 for ; Tue, 3 May 2005 20:30: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 j440KwSn005215; Tue, 3 May 2005 17:20: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 j440KwWx005214; Tue, 3 May 2005 17:20:58 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j440KuLt005205 for ; Tue, 3 May 2005 17:20:57 -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, 4 May 2005 10:11:46 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 04 May 2005 10:20:46 +1000 Subject: Re: Autodiscovery 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 4/5/05 3:42 AM, "Arve Bersvendsen" wrote: > 1) Change the attribute value for the rel from "alternate" to "feed", or ... > 2) I am not too fond of requiring a type attribute I suspect the requirement for @type was because of the choice of 'alternate' as the trigger, and thus if (1) passes then (2) can be relaxed. e. From owner-atom-syntax@mail.imc.org Tue May 3 21:00:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28359 for ; Tue, 3 May 2005 21: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 j440r97X007120; Tue, 3 May 2005 17:53: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 j440r9LV007119; Tue, 3 May 2005 17:53:09 -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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j440r7PK007111 for ; Tue, 3 May 2005 17:53:07 -0700 (PDT) (envelope-from randymorin@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so123884rne for ; Tue, 03 May 2005 17:53:07 -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=CsCyU3gw8IaMyIJJ2udJmiLyROa97v3naMI1LqF9jT4glmekb+/T08v6eocB3cYfJYZf2T2NKUBV5a+4PYB8kQZ1YApz6z4u0BRd9gMwgkcHij8Hl/x/JH7KW6FNlOIJVNkc03iVAESlCzP4LFO6H2gF6KRDyTnYKVmVRH+V5Wk= Received: by 10.38.6.75 with SMTP id 75mr529874rnf; Tue, 03 May 2005 17:53:03 -0700 (PDT) Received: by 10.38.76.24 with HTTP; Tue, 3 May 2005 17:53:02 -0700 (PDT) Message-ID: Date: Tue, 3 May 2005 20:53:02 -0400 From: Randy Charles Morin Reply-To: randy@kbcafe.com To: Atomlist Subject: Re: AutoDiscovery 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 j440r8PK007114 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit +1 to adding lang as an attribute to link thanks Robert ; Tue, 3 May 2005 21: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 j4416ZuN008700; Tue, 3 May 2005 18:06: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 j4416ZGC008699; Tue, 3 May 2005 18:06:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4416YwY008683 for ; Tue, 3 May 2005 18:06:34 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44150e5019068 for ; Wed, 4 May 2005 02:05:22 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <167BF1D2-CC5F-41B7-92D5-9EA9B344674D@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Atom Syntax From: Graham Subject: pie/ecto/atom/rss Date: Wed, 4 May 2005 02:05:56 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've noticed the new version of Safari never mentions "Atom" in its UI, always referring to it as "RSS". A friend of a friend has a website that labels its Atom and RSS feeds "RSS feed" and "RSS feed (Non-Atom)" respsectively. Is the working group concerned about this usage? Graham From owner-atom-syntax@mail.imc.org Tue May 3 23:58:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11426 for ; Tue, 3 May 2005 23:58: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 j443oxFh028893; Tue, 3 May 2005 20:50: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 j443oxmg028892; Tue, 3 May 2005 20:50:59 -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 j443owh6028870 for ; Tue, 3 May 2005 20:50:58 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 49so165773wri for ; Tue, 03 May 2005 20:50: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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KnlaGd0j5B9/5rW6Bbs4Brx0vpYk03M9iuuwSvPNH4yG1byHAyvQhAqWQvCMNvzYV1wpQAm+lXoVfHCmqM3cdJaDLJ44vG/7Ao59Tq8sCf1A0OlrW0ZYPnNww3+11WPbDdtVxqvLkOcZ/g761b9NrNwOQCamdzkotaGtv0Noh+4= Received: by 10.54.20.37 with SMTP id 37mr524320wrt; Tue, 03 May 2005 20:50:53 -0700 (PDT) Received: from ?12.45.57.167? ([12.45.57.167]) by mx.gmail.com with ESMTP id 39sm812373wrl.2005.05.03.20.50.50; Tue, 03 May 2005 20:50:53 -0700 (PDT) Message-ID: <42784696.1060409@gmail.com> Date: Tue, 03 May 2005 20:50:46 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arve Bersvendsen CC: Atom-syntax Subject: Re: Autodiscovery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; 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 Arve Bersvendsen wrote: > First, I am not too fond of making an autodiscovery protocol "Atom-only" It's only Atom-only in that it doesn't attempt to dictate things outside the WG's charter: as it's written now, it's just a well-specified exact equivalent of the existing RSS autodiscovery spec-blog-post. Anyone who has existing code for RSS autodiscovery can simply check for one of two values of @type, rather than just one, and be done with it (well, actually, anyone with existing code for RSS autodiscovery has already long since done so). > 1) Change the attribute value for the rel from "alternate" to "feed", Don't forget, since you would be doing that primarily for people who think too much, that you'll also need to include a profile [1] URI and make a guess at what dereferencing that URI ought to return, and probably take a stab at explaining how to deal with multiple profiles, since the HTML spec punted on that. Popularizing "feed" would have one benefit outside Atom's scope, though: there's currently no useful way for an RSS 1.0 feed to do autodiscovery with type="application/rdf+xml" since it could be any alternate RDF, not just RSS: if Atom breaks the ice with "feed" then RSS 1.0 wins. > 2) I am not too fond of requiring a type attribute, since feeds may be > served in multiple formats from a single URL. If you've changed to rel="feed" you've lost all backward compatibility, so you might as well just say type="application/atom+xml" and still do content negotiation for anything that actually prefers RSS: nothing that only knows RSS will recognize you (and what thing that knows Atom would prefer RSS?). But if you do rel="feed" with no type, then since the namespacing aspect of @profile wasn't ever actually made workable, you are completely claiming the use of that @rel for Atom/RSS: no other past or future things could use it without being willing to take the pounding of a million aggregators. Phil Ringnalda [1] http://www.w3.org/TR/REC-html40/struct/global.html#profiles From owner-atom-syntax@mail.imc.org Tue May 3 23:59:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11469 for ; Tue, 3 May 2005 23:59: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 j443qHMa029056; Tue, 3 May 2005 20:52: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 j443qHFw029055; Tue, 3 May 2005 20:52: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j443qGAO029037 for ; Tue, 3 May 2005 20:52:16 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so96056wra for ; Tue, 03 May 2005 20:52: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=okxCVfcs/NdVwGPVNTZwJV685IuV7zmiqSHkSumEC7SkGYHNCZpAN1xuQiaUxgPQNuudLp2+f/1Sl99xRrpUJLWlcm/4ZScmEbWh0Rm5H5amZJwccdSlBsKaNKh653IvOAkzMz4WM5TLEgegpGvJYW8wWlaRnPCLjcjrtRYeeSw= Received: by 10.54.122.7 with SMTP id u7mr58556wrc; Tue, 03 May 2005 20:52:09 -0700 (PDT) Received: from ?12.45.57.167? ([12.45.57.167]) by mx.gmail.com with ESMTP id 16sm895428wrl.2005.05.03.20.51.51; Tue, 03 May 2005 20:51:53 -0700 (PDT) Message-ID: <427846D3.9070600@gmail.com> Date: Tue, 03 May 2005 20:51:47 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: randy@kbcafe.com CC: Atomlist Subject: Re: AutoDiscovery 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 Randy Charles Morin wrote: > +1 to not Atom specific > thanks Arve > ; Wed, 4 May 2005 01: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 j445Uq3j054271; Tue, 3 May 2005 22:30: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 j445Uqct054270; Tue, 3 May 2005 22:30:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j445UpP1054253 for ; Tue, 3 May 2005 22:30:51 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-2.princeton.edu ([128.112.34.157]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTCT9-0000il-3I; Wed, 04 May 2005 01:30:47 -0400 Message-ID: <42785DBF.7060104@inkedblade.net> Date: Wed, 04 May 2005 01:29:35 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , Tim.Bray@Sun.COM, pilgrim@gmail.com Subject: Re: Autodiscovery References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arve Bersvendsen wrote: > > On Tue, 03 May 2005 18:52:59 +0200, Tim Bray wrote: > >> http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt > > 1) Change the attribute value for the rel from "alternate" to "feed", > or some similar wording. A feed is not always an alternate of the > HTML document in which it occurs. As I mentioned last November [1] I agree with not requiring the 'alternate' rel value for the reasons stated in http://fantasai.inkedblade.net/weblog/2004/linking-feeds/ Briefly, it is an abuse of its semantics because many feed links are not links to alternate representations of the current page. [1] http://www.imc.org/atom-syntax/mail-archive/msg11705.html ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 01:48:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18662 for ; Wed, 4 May 2005 01:47: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 j445gfuC061199; Tue, 3 May 2005 22:42: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 j445gfXn061198; Tue, 3 May 2005 22:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j445ge4s061183 for ; Tue, 3 May 2005 22:42:41 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-2.princeton.edu ([128.112.34.157]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTCea-0001Nj-BF for atom-syntax@imc.org; Wed, 04 May 2005 01:42:36 -0400 Message-ID: <4278608D.7060504@inkedblade.net> Date: Wed, 04 May 2005 01:41:33 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <20050503235648.GC2161@home.fastolfe.net> In-Reply-To: <20050503235648.GC2161@home.fastolfe.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Nesting wrote: > I expect that many of my implementations will utilize content negotiation > (using the same URL as an HTML representation, where needed), so I expect > that I'll have some links like: > > > > > Or even > > > That won't work, because content negotiation will continue to return the same thing it returned just now. You must somehow tell the server to return a specific other version of the current document, and you do that typically by sending a GET request with a different URL -- one that specifies a particular version of the resource. > As crazy as that looks, is there a better way of saying "this URL is > also available in these media types"? File extensions that encode file format in the URL are harmful when the goal is to "return the content in an appropriate format", which may change over time or with UA. If you're asking for a document in a *specific* format, then that a specifier for that format should be part of the URL. ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 02:03:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23055 for ; Wed, 4 May 2005 02:03: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 j445r9sm066649; Tue, 3 May 2005 22:53: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 j445r9Ll066648; Tue, 3 May 2005 22:53:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j445r8Mn066633 for ; Tue, 3 May 2005 22:53:08 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-2.princeton.edu ([128.112.34.157]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTCoi-0001mg-5L; Wed, 04 May 2005 01:53:04 -0400 Message-ID: <42786301.3060603@inkedblade.net> Date: Wed, 04 May 2005 01:52:01 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , whatwg@whatwg.org Subject: Re: Autodiscovery References: <42784696.1060409@gmail.com> In-Reply-To: <42784696.1060409@gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Phil Ringnalda wrote: > > Arve Bersvendsen wrote: > >> On Tue, 03 May 2005 18:52:59 +0200, Tim Bray wrote: >> >>> http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt > >> 1) Change the attribute value for the rel from "alternate" to "feed", > > Don't forget, since you would be doing that primarily for people who > think too much, that you'll also need to include a profile [1] URI and > make a guess at what dereferencing that URI ought to return, and > probably take a stab at explaining how to deal with multiple profiles, > since the HTML spec punted on that. This would not be necessary if 'feed' were added to the HTML standard directly. > Popularizing "feed" would have one benefit outside Atom's scope, though: > there's currently no useful way for an RSS 1.0 feed to do autodiscovery > with type="application/rdf+xml" since it could be any alternate RDF, not > just RSS: if Atom breaks the ice with "feed" then RSS 1.0 wins. 'feed' is not really defining a /relation/, it's defining a sort of meta-content-type... But I would much prefer that to forcing 'alternate' on non-'alternate' links. ~fantasai (Copying to WHATWG mailing list: http://www.whatwg.org/ ) From owner-atom-syntax@mail.imc.org Wed May 4 02:10:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29824 for ; Wed, 4 May 2005 02:10: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 j4464RsA072077; Tue, 3 May 2005 23: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 j4464RuD072076; Tue, 3 May 2005 23:04:27 -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 j4464QML072051 for ; Tue, 3 May 2005 23:04:26 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54279 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228905AbVEDGEY (ORCPT ); Wed, 4 May 2005 09:04:24 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <20050503235648.GC2161@home.fastolfe.net> References: <20050503235648.GC2161@home.fastolfe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Autodiscovery Date: Wed, 4 May 2005 09:04:16 +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 May 4, 2005, at 02:56, David Nesting wrote: > Plus, "feed" is kind of application-specific. What about "related"? It's a spec for discovering *feeds*. It is proper to have an app-specific rel value to avoid feed-specific apps downloading non-feed related documents. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 02:14:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04370 for ; Wed, 4 May 2005 02:14: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 j4469PJs074328; Tue, 3 May 2005 23:09: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 j4469PrF074326; Tue, 3 May 2005 23:09:25 -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 j4469Oti074315 for ; Tue, 3 May 2005 23:09:24 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54288 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228885AbVEDGJW (ORCPT ); Wed, 4 May 2005 09:09:22 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42784696.1060409@gmail.com> References: <42784696.1060409@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Autodiscovery Date: Wed, 4 May 2005 09:09:19 +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 May 4, 2005, at 06:50, Phil Ringnalda wrote: >> 1) Change the attribute value for the rel from "alternate" to "feed", > > Don't forget, since you would be doing that primarily for people who > think too much, that you'll also need to include a profile [1] URI No you don't. rel='license' and rel='nofollow' have been deployable without a profile. You just release running code that hard-codes rel='feed' and, boom, no profile needed. > But if you do rel="feed" with no type, then since the namespacing > aspect of @profile wasn't ever actually made workable, you are > completely claiming the use of that @rel for Atom/RSS: no other past > or future things could use it without being willing to take the > pounding of a million aggregators. I don't see that as a problem but as a practical deterrent that lowers the already low probability of (rather theoretical) name clashes. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 02:24:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16858 for ; Wed, 4 May 2005 02: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 j446GQFK077439; Tue, 3 May 2005 23:16: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 j446GQDO077438; Tue, 3 May 2005 23:16: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j446GPxw077397 for ; Tue, 3 May 2005 23:16:25 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so19949wri for ; Tue, 03 May 2005 23:16:20 -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=j9cLfR7Mqtnf5yjrB1/bsesHLdRjcJe19MyyMep6yl9mBvzbY5S7LnNC819oOd/QTZ40Px5kFTRs3DQ/s+x0clPYCZlWdmMkRY9xhw/ubkPA42s5l62a2v5YfaJJcUHvRi6rXsTBh65yMX66Wgh5NJY7LO07MAG5/O1o3xLHkLg= Received: by 10.54.54.4 with SMTP id c4mr240965wra; Tue, 03 May 2005 23:16:20 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Tue, 3 May 2005 23:16:20 -0700 (PDT) Message-ID: <14be96d305050323162633186b@mail.gmail.com> Date: Wed, 4 May 2005 01:16:20 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom-syntax Subject: Re: Autodiscovery In-Reply-To: <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j446GQxw077432 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Henri Sivonen wrote > No you don't. rel='license' and rel='nofollow' have been deployable > without a profile. You just release running code that hard-codes > rel='feed' and, boom, no profile needed. Then I'm confused as to why you can't just release running code that hard-codes rel="alternate". You know, like people have already done. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed May 4 02:27:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19871 for ; Wed, 4 May 2005 02:26: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 j446LEvJ079570; Tue, 3 May 2005 23:21: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 j446LEdd079569; Tue, 3 May 2005 23:21:14 -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 j446LDEO079553 for ; Tue, 3 May 2005 23:21:13 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54296 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228902AbVEDGVM (ORCPT ); Wed, 4 May 2005 09:21:12 +0300 In-Reply-To: <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <308521f95b08913abf1b51937523c9e6@iki.fi> Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, atom-syntax@imc.org, Mark Nottingham , Robert Sayre , Alexey Melnikov From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Wed, 4 May 2005 09:20:48 +0300 To: Martin Duerst 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 Apr 29, 2005, at 12:17, Martin Duerst wrote: > Making this more precise is definitely desirable. But there is also > an i18n issue: This works fine for languages that use spaces between > words. It doesn't work for languages that don't have spaces between > words (Chinese, Japanese, Thai,...). If Text elements are only used > for short things such as names or titles, that's not a big issue, > the text in question can just be put on a single line. However, > when the texts in question are long, it's a serious issue, and > should be fixed. You seem to be assuming that the length of a "line" is restricted in XML source. Why? As far as I can tell, it should be permissible to produce Atom documents that contain no LF or CR characters. Can't languages without spaces use long source "lines" and apply soft wrapping in a source view if necessary? Why is this a wire format problem? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 02:29:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18210 for ; Wed, 4 May 2005 01:40: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 j445ZXSi056576; Tue, 3 May 2005 22: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 j445ZXEL056575; Tue, 3 May 2005 22:35:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j445ZX5Y056565 for ; Tue, 3 May 2005 22:35:33 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-2.princeton.edu ([128.112.34.157]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTCXh-00010E-49 for atom-syntax@imc.org; Wed, 04 May 2005 01:35:29 -0400 Message-ID: <42785EE2.5080207@inkedblade.net> Date: Wed, 04 May 2005 01:34:26 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <20050503235648.GC2161@home.fastolfe.net> In-Reply-To: <20050503235648.GC2161@home.fastolfe.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Nesting wrote: > On Tue, May 03, 2005 at 07:42:55PM +0200, Arve Bersvendsen wrote: > >>1) Change the attribute value for the rel from "alternate" to "feed", or >>some similar wording. A feed is not always an alternate of the HTML >>document in which it occurs. Suggested replacement text: > > I'm all for avoiding pigeonholing like that. But what about the case > when a feed IS an alternate version? HTML says to use "alternate", > this says to use "feed". Which takes precedence? Neither. You can put both. > Plus, "feed" is kind of application-specific. What about "related"? A link, by its very existence, is indicating that the two documents are related. rel="related" is redundant. > Consider also that HTML allows alternate stylesheets to be identified > with the relationships "alternate" and "stylesheet". HTML overrides > the semantics of "alternate" in this case (since the stylesheet isn't > an alternate version of the page, it's just an alternate stylesheet). This is recognized as a mistake on the part of the HTML 4.01 spec authors. The 'rel' attribute takes a space-separated *list* of rel values: this exception aside, one value does not modify the other. > Who's to say we can't overload it a little for this case? You are not writing the HTML 4.01 spec, you're writing an autodiscovery spec that takes advantage of the syntax *and semantics* given in HTML 4. Your specification should be consistent with HTML 4, not contradictory to it. ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 03:51:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02106 for ; Wed, 4 May 2005 03:51: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 j447hmS6018672; Wed, 4 May 2005 00:43: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 j447hm8w018671; Wed, 4 May 2005 00:43:48 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j447hjNu018623 for ; Wed, 4 May 2005 00:43:48 -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, 4 May 2005 17:43:42 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 04 May 2005 17:43:38 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42786301.3060603@inkedblade.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 4/5/05 3:52 PM, "fantasai" wrote: > 'feed' is not really defining a /relation/, it's defining a sort of > meta-content-type... But I would much prefer that to forcing 'alternate' > on non-'alternate' links. instead of "feed", consider "updates", which gets closer to the gist of the sense e. From owner-atom-syntax@mail.imc.org Wed May 4 04:08:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03532 for ; Wed, 4 May 2005 04:08: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 j4481aKV026287; Wed, 4 May 2005 01:01: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 j4481a8H026286; Wed, 4 May 2005 01:01:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4481Y70026231 for ; Wed, 4 May 2005 01:01:35 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 14999 invoked by uid 10); 4 May 2005 08:01:28 -0000 Received: (vexira-qq 14967-8E917A88 invoked from network) 04 May 2005 10:01:27 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 May 2005 08:01:27 -0000 Message-ID: <4278815B.1000601@annevankesteren.nl> Date: Wed, 04 May 2005 10:01:31 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Atom-syntax Subject: Re: Autodiscovery References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> In-Reply-To: <14be96d305050323162633186b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Pilgrim wrote: >> No you don't. rel='license' and rel='nofollow' have been deployable >> without a profile. You just release running code that hard-codes >> rel='feed' and, boom, no profile needed. > > Then I'm confused as to why you can't just release running code that > hard-codes rel="alternate". You know, like people have already done. rel="alternate" is already used for other purposes. (But obviously, you know that too.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Wed May 4 04:09:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03594 for ; Wed, 4 May 2005 04:09: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 j4483e6B027168; Wed, 4 May 2005 01:03: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 j4483eti027167; Wed, 4 May 2005 01:03:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4483dZ2027111 for ; Wed, 4 May 2005 01:03:39 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 10859 invoked by uid 10); 4 May 2005 08:03:33 -0000 Received: (vexira-qq 10851-6D08E1DF invoked from network) 04 May 2005 10:03:33 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 May 2005 08:03:33 -0000 Message-ID: <427881D9.1060901@annevankesteren.nl> Date: Wed, 04 May 2005 10:03:37 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: randy@kbcafe.com CC: Atomlist Subject: Re: AutoDiscovery References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Randy Charles Morin wrote: > +1 to adding lang as an attribute to link > thanks Robert > From owner-atom-syntax@mail.imc.org Wed May 4 04:11:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03755 for ; Wed, 4 May 2005 04: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 j4486bE5028403; Wed, 4 May 2005 01: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 j4486bXt028401; Wed, 4 May 2005 01:06:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4486aiS028387 for ; Wed, 4 May 2005 01:06:36 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from wintermute (ti132110a080-1210.bb.online.no [85.165.132.186]) by faceman.dreamhost.com (Postfix) with ESMTP id 265B6111D9C; Wed, 4 May 2005 01:06:35 -0700 (PDT) Date: Wed, 04 May 2005 10:04:57 +0200 To: Atom-syntax Subject: Re: Autodiscovery Cc: "Eric Scheid" References: From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (Win32, build 7587) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid wrote: > instead of "feed", consider "updates", which gets closer to the gist of > the sense No. To me 'Updates' signifies that something is 'updated'. Even posting new content falls outside of that definition. -- Arve Bersvendsen From owner-atom-syntax@mail.imc.org Wed May 4 04:16:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04375 for ; Wed, 4 May 2005 04:16: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 j448Ah49029966; Wed, 4 May 2005 01:10: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 j448AhM0029965; Wed, 4 May 2005 01:10:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j448AgnO029910 for ; Wed, 4 May 2005 01:10:42 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050504081036.UHOK1168.mta05-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Wed, 4 May 2005 09:10:36 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> for ; Wed, 4 May 2005 09:10:36 +0100 From: "Andy Henderson" To: Subject: Atom feed refresh rates Date: Wed, 4 May 2005 09:10:35 +0100 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: AcVQgL+Wx/4yHz6pRneCSpqN7Nosow== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If I'm asking this in the wrong place, sorry; please redirect me if you can. I am the author of an Aggregator and I'm looking for advice on refresh rates. There was some discussion in this group back in June about a possible 'Refresh rate' element. That seems to have been dismissed in favour of bandwidth throttling techniques, notably etag, last-modified and compression. I already support all these plus some additional ones. I am uncomfortable, though, with the implication that refresh rates don't matter and should be left to the end-user to decide. I am adding Atom support to my Agg. For RSS feeds, I have used the ttl and sy:updatePeriod / sy:updateFrequency elements to allow feed providers to limit refresh rates. I have, in any case, imposed a minimum refresh rate of one hour - because that seemed the decent thing to do. However, I'm coming under pressure to reduce that minimum limit for feeds that are clearly designed for shorter refresh periods - such as the Gmail Atom feeds. I'm reluctant to implement a free-for-all so I'm looking for guidance on how I should tackle this issue. Andy Henderson Constructive IT Advice From owner-atom-syntax@mail.imc.org Wed May 4 04:59:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07738 for ; Wed, 4 May 2005 04:59: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 j448pmMu047462; Wed, 4 May 2005 01:51: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 j448pmvZ047461; Wed, 4 May 2005 01:51:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j448pk2M047414 for ; Wed, 4 May 2005 01:51:47 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 2628 invoked by uid 10); 4 May 2005 08:51:41 -0000 Received: (vexira-qq 02613-111DFE2C invoked from network) 04 May 2005 10:51:41 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 May 2005 08:51:41 -0000 Message-ID: <42788D21.2090106@annevankesteren.nl> Date: Wed, 04 May 2005 10:51:45 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: hreflang attribute should be allowed to be empty as well References: <42775C77.8000009@annevankesteren.nl> <68fba5c505050308093478fde@mail.gmail.com> In-Reply-To: <68fba5c505050308093478fde@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 5/3/05, Anne van Kesteren wrote: > >>I think that the HREFLANG attribute[1] should be allowed to be empty as >>well, just like xml:lang is allowed to be empty. > > Why would we want that? xml:lang uses the empty string to halt > inheritance, if necessary. hreflang doesn't have that problem. You are right. Ignore the suggestion. (Having it might make some things easier for publishers, but not that much.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Wed May 4 06:52:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18357 for ; Wed, 4 May 2005 06:52: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 j44AcWiA086836; Wed, 4 May 2005 03:38: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 j44AcWkV086835; Wed, 4 May 2005 03:38:32 -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 j44AcVKe086820 for ; Wed, 4 May 2005 03:38:32 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 2E5B34F54F; Wed, 4 May 2005 06:38:31 -0400 (EDT) Date: Wed, 4 May 2005 06:38:31 -0400 From: Dan Brickley To: Henri Sivonen Cc: Atom Syntax Subject: Re: Autodiscovery Message-ID: <20050504103831.GA8363@homer.w3.org> References: <20050503235648.GC2161@home.fastolfe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Henri Sivonen [2005-05-04 09:04+0300] > > On May 4, 2005, at 02:56, David Nesting wrote: > > >Plus, "feed" is kind of application-specific. What about "related"? > > It's a spec for discovering *feeds*. It is proper to have an > app-specific rel value to avoid feed-specific apps downloading non-feed > related documents. What's a feed? 1/2 ;) FWIW in the FOAF spec we currently say: (although we shouldn't really be taking over the title attribute...) (we don't really say what a FOAF file is either; pointing to an RSS1 doc that had some use of the FOAF namespace in it too could be reasonable...). Dan From owner-atom-syntax@mail.imc.org Wed May 4 06:52:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18381 for ; Wed, 4 May 2005 06:52: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 j44AiL9r089315; Wed, 4 May 2005 03:44: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 j44AiLwN089314; Wed, 4 May 2005 03:44:21 -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 j44AiK3l089305 for ; Wed, 4 May 2005 03:44:20 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j44AkoqW023149; Wed, 4 May 2005 03:46:50 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j44AlM26002130; Wed, 4 May 2005 05:47:22 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j44AiJVp017311; Wed, 4 May 2005 05:44:19 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFY003SROHU2E@ims1.labs.mot.com>; Wed, 04 May 2005 05:44:19 -0500 (CDT) Date: Wed, 04 May 2005 05:44:18 -0500 From: Brett Lindsley Subject: Re: Atom feed refresh rates To: Andy Henderson Cc: atom-syntax@imc.org Message-id: <4278A782.7010105@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Andy, I recall bringing up the same issue with respect to portable devices. My angle was that firing up the transmitter, making a network connection and connecting to the server is still an expensive operation in time and power (for a portable device) - even if the server returns nothing . There is no reason to check feeds that are not being updated, but then, there currently is no way to know this. I recall there was a proposal on cache control. That seemed like a good direction, but I don't recall it being discussed. As you indicated, if the feed had some element that indicated it won't be updated (for example) for another day (e.g. a "daily news summary"), then the end client would need to only check once a day. Brett Lindsley, Motorola Labs Andy Henderson wrote: >If I'm asking this in the wrong place, sorry; please redirect me if you can. > >I am the author of an Aggregator and I'm looking for advice on refresh >rates. There was some discussion in this group back in June about a >possible 'Refresh rate' element. That seems to have been dismissed in >favour of bandwidth throttling techniques, notably etag, last-modified and >compression. I already support all these plus some additional ones. I am >uncomfortable, though, with the implication that refresh rates don't matter >and should be left to the end-user to decide. > >I am adding Atom support to my Agg. For RSS feeds, I have used the ttl and >sy:updatePeriod / sy:updateFrequency elements to allow feed providers to >limit refresh rates. I have, in any case, imposed a minimum refresh rate of >one hour - because that seemed the decent thing to do. However, I'm coming >under pressure to reduce that minimum limit for feeds that are clearly >designed for shorter refresh periods - such as the Gmail Atom feeds. I'm >reluctant to implement a free-for-all so I'm looking for guidance on how I >should tackle this issue. > >Andy Henderson >Constructive IT Advice > > > From owner-atom-syntax@mail.imc.org Wed May 4 06:58:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18809 for ; Wed, 4 May 2005 06:58: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 j44An9Tp091733; Wed, 4 May 2005 03:49: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 j44An9hT091732; Wed, 4 May 2005 03:49:09 -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 j44An7tp091696 for ; Wed, 4 May 2005 03:49:07 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54480 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228975AbVEDKtF (ORCPT ); Wed, 4 May 2005 13:49:05 +0300 In-Reply-To: <42789046.6010900@zurich.ibm.com> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <308521f95b08913abf1b51937523c9e6@iki.fi> <42789046.6010900@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <29588a3b01551ec6feced0562f138c5d@iki.fi> Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, atom-syntax@imc.org, Robert Sayre , Martin Duerst , Mark Nottingham , Alexey Melnikov From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Wed, 4 May 2005 13:48:38 +0300 To: Brian E Carpenter 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 May 4, 2005, at 12:05, Brian E Carpenter wrote: > Henri Sivonen wrote: >> On Apr 29, 2005, at 12:17, Martin Duerst wrote: >>> Making this more precise is definitely desirable. But there is also >>> an i18n issue: This works fine for languages that use spaces between >>> words. It doesn't work for languages that don't have spaces between >>> words (Chinese, Japanese, Thai,...). If Text elements are only used >>> for short things such as names or titles, that's not a big issue, >>> the text in question can just be put on a single line. However, >>> when the texts in question are long, it's a serious issue, and >>> should be fixed. >> You seem to be assuming that the length of a "line" is restricted in >> XML source. Why? As far as I can tell, it should be permissible to >> produce Atom documents that contain no LF or CR characters. >> Can't languages without spaces use long source "lines" and apply soft >> wrapping in a source view if necessary? Why is this a wire format >> problem? > > Are you suggesting that a canonical format without CRLF should be > mandatory? No, not mandatory, although I expect to produce such feeds myself (even in English or Finnish). I am suggesting that pretty-printing line breaks should not be introduced in places where normalizing them to a space would be inappropriate. So if you have a long string of Chinese, Japanese or Thai and you don't want spaces in that string, just don't put white space there. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 07:03:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19403 for ; Wed, 4 May 2005 07:03: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 j44Avswm095490; Wed, 4 May 2005 03:57: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 j44AvsbO095489; Wed, 4 May 2005 03:57:54 -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 j44AvrVA095478 for ; Wed, 4 May 2005 03:57:53 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54483 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228704AbVEDK5w (ORCPT ); Wed, 4 May 2005 13:57:52 +0300 In-Reply-To: <14be96d305050323162633186b@mail.gmail.com> References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0ddadc99a41ce83550ede71051ea02ae@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom-syntax From: Henri Sivonen Subject: Re: Autodiscovery Date: Wed, 4 May 2005 13:57:51 +0300 To: Mark Pilgrim 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 May 4, 2005, at 09:16, Mark Pilgrim wrote: > On 5/4/05, Henri Sivonen wrote >> No you don't. rel='license' and rel='nofollow' have been deployable >> without a profile. You just release running code that hard-codes >> rel='feed' and, boom, no profile needed. > > Then I'm confused as to why you can't just release running code that > hard-codes rel="alternate". You know, like people have already done. Sure you can. ("Can" in the sense that it is possible.) However, when other things are equal, I think misusing an existing relation (feed usually is not a proper alternate representation) is worse than specifying a new one without all the profile fluff. Still, I am well aware that the other things are not equal in this case (ie. there is deployed code), which is why I was not arguing in favor of rel='feed' per se, but pointing out that the particular reasoning against it did not hold water, IMO. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 07:08:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19934 for ; Wed, 4 May 2005 07:08: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 j44B1H2A096685; Wed, 4 May 2005 04:01: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 j44B1HMo096684; Wed, 4 May 2005 04:01:17 -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 j44AvrVC095478 for ; Wed, 4 May 2005 04:01:15 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:54488 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228905AbVEDLBP (ORCPT ); Wed, 4 May 2005 14:01:15 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71d6929301bd6bb62905b0d382810053@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Autodiscovery Date: Wed, 4 May 2005 14:01:12 +0300 To: Eric Scheid 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 May 4, 2005, at 10:43, Eric Scheid wrote: > On 4/5/05 3:52 PM, "fantasai" wrote: > >> 'feed' is not really defining a /relation/, it's defining a sort of >> meta-content-type... But I would much prefer that to forcing >> 'alternate' >> on non-'alternate' links. > > instead of "feed", consider "updates", which gets closer to the gist > of the > sense We all call them feeds and in the end it comes down to picking a string that software uses for comparison. Why all the over-generalization? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 4 07:38:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22967 for ; Wed, 4 May 2005 07:38: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 j44BTNDJ008709; Wed, 4 May 2005 04: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 j44BTN96008708; Wed, 4 May 2005 04:29: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j44BTLBR008636 for ; Wed, 4 May 2005 04:29:22 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 May 2005 11:29:14 -0000 Received: from p508F8C10.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.140.16] by mail.gmx.net (mp006) with SMTP; 04 May 2005 13:29:14 +0200 X-Authenticated: #1915285 Message-ID: <4278B208.2060701@gmx.de> Date: Wed, 04 May 2005 13:29:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Lindsley CC: Andy Henderson , atom-syntax@imc.org Subject: Re: Atom feed refresh rates References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> In-Reply-To: <4278A782.7010105@labs.mot.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 Brett Lindsley wrote: > > > Andy, I recall bringing up the same issue with respect to portable > devices. My angle > was that firing up the transmitter, making a network connection and > connecting to > the server is still an expensive operation in time and power (for a > portable > device) - even if the server returns nothing . There is no reason to > check feeds > that are not being updated, but then, there currently is no way to know > this. > > I recall there was a proposal on cache control. That seemed like a good > direction, > but I don't recall it being discussed. As you indicated, if the feed had > some > element that indicated it won't be updated (for example) for another day > (e.g. > a "daily news summary"), then the end client would need to only check once > a day. > > Brett Lindsley, Motorola Labs Isn't this what the HTTP "Expires" header is for ()? Best regards, Julian From owner-atom-syntax@mail.imc.org Wed May 4 07:56:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24867 for ; Wed, 4 May 2005 07:56: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 j44Bnsi5017769; Wed, 4 May 2005 04:49: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 j44BnsTj017768; Wed, 4 May 2005 04:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate6.mot.com (motgate6.mot.com [144.189.100.106]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BnsQx017757 for ; Wed, 4 May 2005 04:49:54 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j44BnkJI011593; Wed, 4 May 2005 04:49:46 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j44BqbaY000086; Wed, 4 May 2005 06:52:37 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j44BnjVp017968; Wed, 4 May 2005 06:49:45 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFY0038JRIW2E@ims1.labs.mot.com>; Wed, 04 May 2005 06:49:44 -0500 (CDT) Date: Wed, 04 May 2005 06:49:44 -0500 From: Brett Lindsley Subject: Re: Atom feed refresh rates To: Julian Reschke Cc: Brett Lindsley , Andy Henderson , atom-syntax@imc.org Message-id: <4278B6D8.9080703@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <4278B208.2060701@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT In reviewing the protocol spec (and the basic protocol spec), there is no mention of recommended HTTP headers. There are examples in the basic protocol spec that shows ETag and Last-Modified but not Expires. Maybe there should be a section in the protocol spec showing "recommended headers" (a SHOULD) for use with Atom feeds. This would encourage the use of these three headers. Brett Lindsley, Motorola Labs. Julian Reschke wrote: > > Brett Lindsley wrote: > >> >> >> Andy, I recall bringing up the same issue with respect to portable >> devices. My angle >> was that firing up the transmitter, making a network connection and >> connecting to >> the server is still an expensive operation in time and power (for a >> portable >> device) - even if the server returns nothing . There is no reason to >> check feeds >> that are not being updated, but then, there currently is no way to >> know this. >> >> I recall there was a proposal on cache control. That seemed like a >> good direction, >> but I don't recall it being discussed. As you indicated, if the feed >> had some >> element that indicated it won't be updated (for example) for another >> day (e.g. >> a "daily news summary"), then the end client would need to only check >> once >> a day. >> >> Brett Lindsley, Motorola Labs > > > Isn't this what the HTTP "Expires" header is for > ()? > > Best regards, Julian > From owner-atom-syntax@mail.imc.org Wed May 4 08:05:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25894 for ; Wed, 4 May 2005 08:05: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 j44BvQNT021465; Wed, 4 May 2005 04:57: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 j44BvQET021464; Wed, 4 May 2005 04:57:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44BvPWj021413 for ; Wed, 4 May 2005 04:57:25 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050504115719.CUNN8086.mta13-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Wed, 4 May 2005 12:57:19 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050504115719.OLII1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3>; Wed, 4 May 2005 12:57:19 +0100 From: "Andy Henderson" To: "'Julian Reschke'" Cc: , "'Brett Lindsley'" Subject: RE: Atom feed refresh rates Date: Wed, 4 May 2005 12:57:18 +0100 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: <4278B208.2060701@gmx.de> Thread-Index: AcVQnINsxv68VXbFRaqff8mODt37dwAA27Eg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050504115719.OLII1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>Isn't this what the HTTP "Expires" header is for ()?<<< I don't think this helps a lot with my original issue because in many cases a feed's updater will either not know when they will next update the feed, or will be updating the feed frequently throughout the day. Andy From owner-atom-syntax@mail.imc.org Wed May 4 08:14:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27000 for ; Wed, 4 May 2005 08:14: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 j44C8JQ1025336; Wed, 4 May 2005 05:08: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 j44C8Jbs025335; Wed, 4 May 2005 05:08:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44C8Ivv025303 for ; Wed, 4 May 2005 05:08:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44C4Vkg013703; Wed, 4 May 2005 13:05:15 +0100 (BST) In-Reply-To: <4278B208.2060701@gmx.de> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <4278B208.2060701@gmx.de> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F38A1C0-292C-40F9-B620-1202E3341F46@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 13:06:12 +0100 To: Julian Reschke X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 12:29 pm, Julian Reschke wrote: > Isn't this what the HTTP "Expires" header is for ( greenbytes.de/tech/webdav/rfc2616.html#header.expires>)? +1 Graham From owner-atom-syntax@mail.imc.org Wed May 4 08:19:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27541 for ; Wed, 4 May 2005 08:19: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 j44CE4oD027524; Wed, 4 May 2005 05:14: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 j44CE4nn027523; Wed, 4 May 2005 05:14:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44CE3Td027478 for ; Wed, 4 May 2005 05:14:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44CCiWR017693; Wed, 4 May 2005 13:12:44 +0100 (BST) In-Reply-To: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0659A553-E426-4503-93E9-4C6F7DDF7D6B@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 13:13:41 +0100 To: Andy Henderson X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 9:10 am, Andy Henderson wrote: > I am adding Atom support to my Agg. For RSS feeds, I have used the > ttl and > sy:updatePeriod / sy:updateFrequency elements to allow feed > providers to > limit refresh rates. Why? > I have, in any case, imposed a minimum refresh rate of one hour - > because that seemed the decent thing to do. This is a myth perpetuated by cheapskate bloggers. There's no technical reason for it beyond "I bought a lousy hosting package". > However, I'm coming under pressure to reduce that minimum limit for > feeds that are clearly > designed for shorter refresh periods - such as the Gmail Atom > feeds. I'm reluctant to implement a free-for-all so I'm looking > for guidance on how I should tackle this issue. Keep the global setting for all feeds limited to 60 (or 30) minutes, but allow the setting for individual feeds to be set lower. Graham From owner-atom-syntax@mail.imc.org Wed May 4 08:20:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27573 for ; Wed, 4 May 2005 08:20: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 j44CAxHL026327; Wed, 4 May 2005 05:10: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 j44CAxkw026326; Wed, 4 May 2005 05:10:59 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44CAvg0026295 for ; Wed, 4 May 2005 05:10:58 -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, 4 May 2005 22:10:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 04 May 2005 22:10:48 +1000 Subject: Re: Atom feed refresh rates From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4278A782.7010105@labs.mot.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 4/5/05 8:44 PM, "Brett Lindsley" wrote: > As you indicated, if the feed had some element that indicated it won't be > updated (for example) for another day (e.g. a "daily news summary"), then the > end client would need to only check once a day. aggregators could also take note of the suggested refresh time at the time of subscription, setting the refresh rate as appropriate as a default. for the common case of an auto-discovery feed subscription, this would be quite handy. if users want to override that default then they can. e. From owner-atom-syntax@mail.imc.org Wed May 4 08:20:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27602 for ; Wed, 4 May 2005 08:20: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 j44CDr5w027445; Wed, 4 May 2005 05:13: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 j44CDr8Y027443; Wed, 4 May 2005 05:13: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 j44CDqxk027383 for ; Wed, 4 May 2005 05:13:52 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 May 2005 12:13:46 -0000 Received: from p508F8C10.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.140.16] by mail.gmx.net (mp018) with SMTP; 04 May 2005 14:13:46 +0200 X-Authenticated: #1915285 Message-ID: <4278BC78.3050503@gmx.de> Date: Wed, 04 May 2005 14:13:44 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Henderson CC: atom-syntax@imc.org, "'Brett Lindsley'" Subject: Re: Atom feed refresh rates References: <20050504115719.OLII1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3> In-Reply-To: <20050504115719.OLII1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3> 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 Andy Henderson wrote: >>>>Isn't this what the HTTP "Expires" header is for > > ()?<<< > > I don't think this helps a lot with my original issue because in many cases > a feed's updater will either not know when they will next update the feed, > or will be updating the feed frequently throughout the day. If they don't know that, how can the previous response you got help you in determining when to poll next? Best regards, Julian From owner-atom-syntax@mail.imc.org Wed May 4 08:24:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29329 for ; Wed, 4 May 2005 08:24: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 j44C8LBd025351; Wed, 4 May 2005 05:08: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 j44C8L5I025350; Wed, 4 May 2005 05:08:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44C8Ivx025303 for ; Wed, 4 May 2005 05:08:20 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44C4Vkf013703; Wed, 4 May 2005 13:04:37 +0100 (BST) In-Reply-To: <4278A782.7010105@labs.mot.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44C0A995-70C0-4C40-8562-94C7AA53B59F@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 13:05:27 +0100 To: Brett Lindsley X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 11:44 am, Brett Lindsley wrote: > There is no reason to check feeds that are not being updated, but > then, there currently is no way to know this. plug plug: http://www.fondantfancies.com/apps/shrook/distfaq.php > As you indicated, if the feed had some > element that indicated it won't be updated (for example) for > another day (e.g. > a "daily news summary"), then the end client would need to only > check once > a day. Please don't confuse bandwidth (number of posts per day) with latency (checking rate). They're largely unrelated. You could only check once per day if the daily summary appeared at an exact, known time, was never late, and was never updated later. Graham From owner-atom-syntax@mail.imc.org Wed May 4 09:00:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03187 for ; Wed, 4 May 2005 09:00: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 j44CtpMm048352; Wed, 4 May 2005 05:55: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 j44CtpBW048351; Wed, 4 May 2005 05:55:51 -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 j44Ctoam048307 for ; Wed, 4 May 2005 05:55:50 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so169619wri for ; Wed, 04 May 2005 05:55:45 -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=CDddu9OjLJwSSY2X4HGbRzXckLJCjNk4hNlBWM3qMIquhDeDNsl4dpkStJ91VtUmEcPSPiWSEi5cvdhr69WuIVQHeJ292Q2uJUSQIXgTIXL241Bu6jYB4OqRLivNQw2SBjfRGokrBtNzMpdRkADPc2sPGX3LJhdhZrXrKbCrUsQ= Received: by 10.54.147.2 with SMTP id u2mr233713wrd; Wed, 04 May 2005 05:55:45 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Wed, 4 May 2005 05:55:45 -0700 (PDT) Message-ID: <14be96d3050504055510608950@mail.gmail.com> Date: Wed, 4 May 2005 07:55:45 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom Syntax Subject: Re: Atom feed refresh rates In-Reply-To: <6F38A1C0-292C-40F9-B620-1202E3341F46@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <4278B208.2060701@gmx.de> <6F38A1C0-292C-40F9-B620-1202E3341F46@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44Ctpam048343 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Graham wrote: > On 4 May 2005, at 12:29 pm, Julian Reschke wrote: > > Isn't this what the HTTP "Expires" header is for > +1 +1 Also, that belongs in an implementation guide, not a format spec. Like this one: http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html I am soliciting co-editors. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed May 4 09:11:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04215 for ; Wed, 4 May 2005 09: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 j44CxriJ049953; Wed, 4 May 2005 05:59: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 j44Cxr6Q049952; Wed, 4 May 2005 05:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44CxpN0049935 for ; Wed, 4 May 2005 05:59:51 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44CvqwT012958; Wed, 4 May 2005 13:57:52 +0100 (BST) In-Reply-To: <20050504125148.TPGP1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3> References: <20050504125148.TPGP1279.aamta03-winn.mailhost.ntl.com@AndyHenderson3> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3648C1C7-FE70-4EA7-9050-FBCFE852B32F@mac.com> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 13:58:50 +0100 To: Andy Henderson X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 1:51 pm, Andy Henderson wrote: >>>> This is a myth perpetuated by cheapskate bloggers. There's no >>>> technical >>>> > reason for it beyond "I bought a lousy hosting package".<<< > > I don't think so. Slashdot is just one example of a feed that has > introduced bandwidth throttling in response to aggregators polling too > frequently. But it's the only example I know of, of a large scale site that's complained. Note they've never (as far as I know) said that it was costing them money or causing them other problems, they've just arbitrarily complained about "poorly written" programs and decreed how often people may check their feed. There's no evidence of a technical problem here, just a bunch of uptight twunts telling other people how to write their software. Graham From owner-atom-syntax@mail.imc.org Wed May 4 09:11:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04242 for ; Wed, 4 May 2005 09:11: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 j44D4K8I050461; Wed, 4 May 2005 06:04: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 j44D4Kag050459; Wed, 4 May 2005 06:04: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 j44D4Jaf050453 for ; Wed, 4 May 2005 06:04:19 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 80589 invoked by uid 17064); 4 May 2005 13:04:19 -0000 Received: from unknown (HELO [192.168.0.7]) ([83.112.129.167]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 May 2005 13:04:19 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <14be96d3050504055510608950@mail.gmail.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <4278B208.2060701@gmx.de> <6F38A1C0-292C-40F9-B620-1202E3341F46@mac.com> <14be96d3050504055510608950@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <491CDFC4-71B3-4A28-BEC0-C90D0D040696@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 15:04:15 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 14:55, Mark Pilgrim wrote: > > On 5/4/05, Graham wrote: > >> On 4 May 2005, at 12:29 pm, Julian Reschke wrote: >> >>> Isn't this what the HTTP "Expires" header is for >>> >> +1 >> > > +1 +1 > Also, that belongs in an implementation guide, not a format spec. > Like this one: > > http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html > > I am soliciting co-editors. > > -- > Cheers, > -Mark > From owner-atom-syntax@mail.imc.org Wed May 4 09:18:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05486 for ; Wed, 4 May 2005 09:18: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 j44DCWc8052009; Wed, 4 May 2005 06:12: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 j44DCWt5052008; Wed, 4 May 2005 06:12:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44DCWlY051992 for ; Wed, 4 May 2005 06:12:32 -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 (rwcrmhc11) with SMTP id <2005050413122601300f5o80e>; Wed, 4 May 2005 13:12:26 +0000 Date: Wed, 4 May 2005 07:12:24 -0600 Subject: Re: Autodiscovery 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: <4278608D.7060504@inkedblade.net> Message-Id: <27F82537-BC9E-11D9-BA79-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 Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote: > David Nesting wrote: >> I expect that many of my implementations will utilize content >> negotiation >> (using the same URL as an HTML representation, where needed), so I >> expect >> that I'll have some links like: >> >> >> Or even >> >> > > That won't work, because content negotiation will continue to return > the same thing it returned just now. You must somehow tell the server > to return a specific other version of the current document, and you > do that typically by sending a GET request with a different URL -- > one that specifies a particular version of the resource. > See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14 GET /path-to-the-feed HTTP/1.1 Accept: application/atom+xml ... You don't have to change the URL--just list only the format you want in the Accept header. If the autodiscovery link was lying/mistaken and that format really isn't available at that URL, you should get a 406 (not acceptable) response. From owner-atom-syntax@mail.imc.org Wed May 4 09:19:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05696 for ; Wed, 4 May 2005 09:19: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 j44DBVMc051862; Wed, 4 May 2005 06:11: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 j44DBVCo051861; Wed, 4 May 2005 06:11: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44DBUu5051837 for ; Wed, 4 May 2005 06:11:30 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so269736wra for ; Wed, 04 May 2005 06:11:25 -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=VGUMFt1tHd7gGL1GHpLUy7DlUDAo1CXLmQxMJ8cM/42dFxtPC7IGp5Leo0+szPRZRAm+jo2LC/xHiax36eFHsuEJnSz1Bu6ODp2U62QPIeUdim4wOlNGiD5qJ05kaTbI5un9qyilbvOQq+RuVNuSKAJDX/AATTqbQ2vlpj/RBRA= Received: by 10.54.153.19 with SMTP id a19mr59688wre; Wed, 04 May 2005 06:11:24 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 06:11:24 -0700 (PDT) Message-ID: <68fba5c5050504061177627f8f@mail.gmail.com> Date: Wed, 4 May 2005 09:11:24 -0400 From: Robert Sayre Reply-To: Robert Sayre To: fantasai Subject: Re: Autodiscovery Cc: Atom Syntax In-Reply-To: <42785EE2.5080207@inkedblade.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44DBUu5051856 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, fantasai wrote: > > > Who's to say we can't overload it a little for this case? > > You are not writing the HTML 4.01 spec, you're writing an autodiscovery > spec that takes advantage of the syntax *and semantics* given in HTML 4. > Your specification should be consistent with HTML 4, not contradictory > to it. The autodiscovery spec is a reasonable interpretation of the *one line* definition of the 'alternate' relation. It is not contradictory. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 4 10:16:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12741 for ; Wed, 4 May 2005 10:16: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 j44E9vqo061833; Wed, 4 May 2005 07:09: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 j44E9vgB061832; Wed, 4 May 2005 07:09:57 -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 j44E9uq2061798 for ; Wed, 4 May 2005 07:09: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 8E6E4B9 for ; Wed, 4 May 2005 07:09:49 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j44E9hng002729 for ; Wed, 4 May 2005 07:09:49 -0700 (PDT) Date: Wed, 04 May 2005 07:10:04 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates Message-ID: <8BACAD774F3314A7C0CF557E@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <4278A782.7010105@labs.mot.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> X-Mailer: Mulberry/4.0.0b1 (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 PaceCaching uses the HTTP model for Atom, whether Atom is used over HTTP or some other protocol. PaceCaching was rejected by the editors because it was too late (two months ago) and non-core. I think that: a) it is never too late to get it right, and b) scalability is core. The PACE describes why refresh rates do not solve the problem adequately. wunder --On May 4, 2005 5:44:18 AM -0500 Brett Lindsley wrote: > > > Andy, I recall bringing up the same issue with respect to portable devices. My angle > was that firing up the transmitter, making a network connection and connecting to > the server is still an expensive operation in time and power (for a portable > device) - even if the server returns nothing . There is no reason to check feeds > that are not being updated, but then, there currently is no way to know this. > > I recall there was a proposal on cache control. That seemed like a good direction, > but I don't recall it being discussed. As you indicated, if the feed had some > element that indicated it won't be updated (for example) for another day (e.g. > a "daily news summary"), then the end client would need to only check once > a day. > > Brett Lindsley, Motorola Labs > > Andy Henderson wrote: > >> If I'm asking this in the wrong place, sorry; please redirect me if you can. >> >> I am the author of an Aggregator and I'm looking for advice on refresh >> rates. There was some discussion in this group back in June about a >> possible 'Refresh rate' element. That seems to have been dismissed in >> favour of bandwidth throttling techniques, notably etag, last-modified and >> compression. I already support all these plus some additional ones. I am >> uncomfortable, though, with the implication that refresh rates don't matter >> and should be left to the end-user to decide. >> >> I am adding Atom support to my Agg. For RSS feeds, I have used the ttl and >> sy:updatePeriod / sy:updateFrequency elements to allow feed providers to >> limit refresh rates. I have, in any case, imposed a minimum refresh rate of >> one hour - because that seemed the decent thing to do. However, I'm coming >> under pressure to reduce that minimum limit for feeds that are clearly >> designed for shorter refresh periods - such as the Gmail Atom feeds. I'm >> reluctant to implement a free-for-all so I'm looking for guidance on how I >> should tackle this issue. >> >> Andy Henderson >> Constructive IT Advice >> >> >> > > > -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Wed May 4 10:53:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17598 for ; Wed, 4 May 2005 10: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 j44EjfWE067139; Wed, 4 May 2005 07: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 j44EjfgU067138; Wed, 4 May 2005 07:45:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EjemL067117 for ; Wed, 4 May 2005 07:45:41 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44EhAC5021293; Wed, 4 May 2005 15:43:15 +0100 (BST) In-Reply-To: <20050504131130.SYPX5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> References: <20050504131130.SYPX5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 15:44:08 +0100 To: Andy Henderson X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 2:11 pm, Andy Henderson wrote: >> But it's the only example I know of, of a large scale site that's >> complained. Note they've never (as far as I know) said that it was >> costing >> them money or causing them other problems, they've just arbitrarily >> complained about "poorly written" programs and decreed how often >> people may >> check their feed. There's no evidence of a technical problem here, >> just a >> bunch of uptight twunts telling other people how to write their >> software.<<< > > I'm no expert on the provider side, but I believe it to be a wider > issue. > There was some discussion at http://regsched.bookinfo.info/ and some > attempts to implement bandwidth throttling but it petered out > because, it > seemed to me, the problem was very difficult to solve from the > provider's > end. A quick look at that site turned up only one other site actually complaining, MSDN, and they changed their minds: Scoble's post was widely debated by bloggers before being corrected by Microsoft's Sara Williams. "In a nutshell, our RSS traffic is neglible compared to all the traffic generated by Windows Update, MSN, downloads, and the rest of microsoft.com," wrote Williams. "We were motivated to reduce the size of the blogs.msdn.com home page primarily for operational efficiency's sake." According to that site, Boing Boing's RSS feed (one of the most subscribed to) uses 3GB a day, or about $1.20 at current prices. Bandwidth is only going to get cheaper, and designing a system that might save a few gigs is going to be about as relevant in the future as the LOWSRC IMG tag. I think the forward looking thing to do would be for Atom to ignore this issue. Graham From owner-atom-syntax@mail.imc.org Wed May 4 11:02:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18348 for ; Wed, 4 May 2005 11:02: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 j44ErBcR068338; Wed, 4 May 2005 07:53: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 j44ErBsj068337; Wed, 4 May 2005 07:53:11 -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 j44ErAw3068319 for ; Wed, 4 May 2005 07:53:10 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so326755wra for ; Wed, 04 May 2005 07:53:02 -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=l15nllukxmYH6CN9SnSmdm6gDDByKJV2j3w4sT26ZiSkQiPLtE2unyFLBvlTjMgLq10pN8nPMoBmHDZZErSpMgkhRE68EPlSpOJmDQBoLOQ6+T7ifH6rZF4WAWZV0iMRJ7ZARBSgDT8azleNfrZPxBflsgJ7mBzroPlpvOyBPRo= Received: by 10.54.114.5 with SMTP id m5mr340260wrc; Wed, 04 May 2005 07:53:01 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 07:53:00 -0700 (PDT) Message-ID: <68fba5c5050504075350c0ca4c@mail.gmail.com> Date: Wed, 4 May 2005 10:53:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Walter Underwood Subject: Re: Atom feed refresh rates Cc: atom-syntax@imc.org In-Reply-To: <8BACAD774F3314A7C0CF557E@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <8BACAD774F3314A7C0CF557E@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44ErAw3068324 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Walter Underwood wrote: > > PaceCaching uses the HTTP model for Atom, whether Atom is used over HTTP > or some other protocol. > > PaceCaching was rejected by the editors because it was too late (two months > ago) and non-core. In this WG, the editors don't reject proposals or schedule issues. Those tasks fall to the chairs and secretary, respectively. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 4 11:23:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20982 for ; Wed, 4 May 2005 11:23: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 j44FFTg3070537; Wed, 4 May 2005 08:15: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 j44FFTEf070536; Wed, 4 May 2005 08:15:29 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44FFROi070524 for ; Wed, 4 May 2005 08:15:29 -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, 5 May 2005 01:15:23 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 01:15:19 +1000 Subject: Re: Atom feed refresh rates 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/5/05 12:44 AM, "Graham" wrote: > uses 3GB a day, or about $1.20 at current prices. only in some parts of the world. over here I'm paying 13.2 cents per K and reading from a recent bill 2,982.61 Kbytes cost me $393.79 AUD. e. From owner-atom-syntax@mail.imc.org Wed May 4 12:25:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26415 for ; Wed, 4 May 2005 12:25: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 j44GGJaQ079947; Wed, 4 May 2005 09:16: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 j44GGJEq079946; Wed, 4 May 2005 09:16:19 -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 j44GGHGO079925 for ; Wed, 4 May 2005 09:16:18 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so356742nzn for ; Wed, 04 May 2005 09:16: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=CFmI2XKg3SFlSRMjqaNk5pk1SxDugE2g2PvtNSHBpBv3jQvt3APGtb3C2FR52j1BohIK2eP7SaXxIC9BmPND7gjJLUoreNK28VKccBVeUjDHKjoYw/34AU+CW3mKFSVcMdbdm1JmTMjZGenfslGvtUSbMmCLlEkfuGThqzT3ItU= Received: by 10.36.59.14 with SMTP id h14mr162789nza; Wed, 04 May 2005 09:16:12 -0700 (PDT) Received: by 10.36.65.13 with HTTP; Wed, 4 May 2005 09:16:11 -0700 (PDT) Message-ID: <3f1451f505050409165df788d2@mail.gmail.com> Date: Wed, 4 May 2005 12:16:11 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: Autodiscovery Cc: fantasai , Atom Syntax In-Reply-To: <68fba5c5050504061177627f8f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> <68fba5c5050504061177627f8f@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44GGIGO079940 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Robert Sayre wrote: > > On 5/4/05, fantasai wrote: > > > > > Who's to say we can't overload it a little for this case? > > > > You are not writing the HTML 4.01 spec, you're writing an autodiscovery > > spec that takes advantage of the syntax *and semantics* given in HTML 4. > > Your specification should be consistent with HTML 4, not contradictory > > to it. > > The autodiscovery spec is a reasonable interpretation of the *one > line* definition of the 'alternate' relation. It is not contradictory. +1 -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed May 4 12:47:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28142 for ; Wed, 4 May 2005 12:47: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 j44GYHoB082757; Wed, 4 May 2005 09:34: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 j44GYHqC082756; Wed, 4 May 2005 09:34: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 j44GYGvw082750 for ; Wed, 4 May 2005 09:34: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 j44GYGjO006185 for ; Wed, 4 May 2005 10:34:16 -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 <0IFZ002M14P356@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 May 2005 10:34:15 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFZ00HZ64P2JS@mail.sun.net> for atom-syntax@imc.org; Wed, 04 May 2005 10:34:15 -0600 (MDT) Date: Wed, 04 May 2005 09:35:16 -0700 From: Tim Bray Subject: Re: Atom feed refresh rates In-reply-to: To: Graham Cc: Andy Henderson , Atom Syntax Message-id: <542b5aa53d6d24bc092e8f92d7e12069@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050504131130.SYPX5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 4, 2005, at 7:44 AM, Graham wrote: > A quick look at that site turned up only one other site actually > complaining, MSDN, and they changed their minds: Actually, as I recall, last time this came up (proposed by Walter Underwood), someone pointed out accurately that RSS2 has had this functionality for a long time and that nobody ever really implemented it; thus there was a strong vote from experience against such a feature. -Tim From owner-atom-syntax@mail.imc.org Wed May 4 12:48:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28353 for ; Wed, 4 May 2005 12: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 j44GWjld082522; Wed, 4 May 2005 09:32: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 j44GWjKA082521; Wed, 4 May 2005 09:32: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44GWgk3082500 for ; Wed, 4 May 2005 09:32:44 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so134710wri for ; Wed, 04 May 2005 09:32:36 -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=hbqu8VF6P5kRLYwnLCPnlwFQ/Q/wU+mOvw1t0UWv6xEIRPJwKW0EqiCBpd4VZI4eCA9zbIdj4bop5FPAErR6IKBxH1EZ+zNGyxkDvZxh1j9KrCDbPxkNrMy8oHZznC5DuvuWddWh43BJqc6TsHMZFYy6BgMIjV8vHPsqkbEgFkI= Received: by 10.54.79.15 with SMTP id c15mr195798wrb; Wed, 04 May 2005 09:32:36 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Wed, 4 May 2005 09:32:36 -0700 (PDT) Message-ID: <540e373205050409321f1624b3@mail.gmail.com> Date: Wed, 4 May 2005 11:32:36 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Atom feed refresh rates In-Reply-To: <0659A553-E426-4503-93E9-4C6F7DDF7D6B@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <0659A553-E426-4503-93E9-4C6F7DDF7D6B@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44GWik3082516 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > This is a myth perpetuated by cheapskate bloggers. There's no > technical reason for it beyond "I bought a lousy hosting package". Graham: I disagree. In a time where referrer and trackback spam agents are hammering servers everywhere, it's quite reasonable for aggregator developers to exhibit restraint and not add to the burden that the blogosphere has unintentionally created. That's not to say that there's something necessarily wrong with an aggregator that allows users to pull feeds every five minutes. If you're building something for people who are going to be subscribing to Gmail feeds or referrer logs (I'm subscribed to both in Newzcrawler), then you have to cater to those needs. The most anyone can ask is that you provide reasonable defaults and leave it at that. But I've got my own code set to limit refreshes to an hour or more, and don't forsee changing it. It's the right thing for *me* to do. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed May 4 13:13:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01522 for ; Wed, 4 May 2005 13:13: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 j44H5Pi0087489; Wed, 4 May 2005 10:05: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 j44H5PS4087488; Wed, 4 May 2005 10:05:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44H5OD3087481 for ; Wed, 4 May 2005 10:05:24 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from eetemad.student.princeton.edu ([140.180.146.72]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTNJJ-0004Jp-HN for atom-syntax@imc.org; Wed, 04 May 2005 13:05:21 -0400 Message-ID: <4279008B.5030108@inkedblade.net> Date: Wed, 04 May 2005 13:04:11 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arve Bersvendsen wrote: > > On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid > wrote: > >> instead of "feed", consider "updates", which gets closer to the gist >> of the sense > > No. To me 'Updates' signifies that something is 'updated'. Even posting > new content falls outside of that definition. That would signify "updates" to my document. If I'm linking to the CNN news feed, or my-favorite-blog, that wouldn't be appropriate. For this purpose, the syntax needs to signify that this is a feed, that it needs to be handled as such.. and that there is no other significant relationship between the document and the feed it links to (unless otherwise specified). ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 13:14:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01622 for ; Wed, 4 May 2005 13:14: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 j44H968v087794; Wed, 4 May 2005 10: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 j44H966M087793; Wed, 4 May 2005 10:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44H959g087787 for ; Wed, 4 May 2005 10:09:06 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from eetemad.student.princeton.edu ([140.180.146.72]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTNMt-0004Sp-8x for atom-syntax@imc.org; Wed, 04 May 2005 13:09:03 -0400 Message-ID: <4279016B.80606@inkedblade.net> Date: Wed, 04 May 2005 13:07:55 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> <68fba5c5050504061177627f8f@mail.gmail.com> In-Reply-To: <68fba5c5050504061177627f8f@mail.gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 5/4/05, fantasai wrote: > >>>Who's to say we can't overload it a little for this case? >> >>You are not writing the HTML 4.01 spec, you're writing an autodiscovery >>spec that takes advantage of the syntax *and semantics* given in HTML 4. >>Your specification should be consistent with HTML 4, not contradictory >>to it. > > The autodiscovery spec is a reasonable interpretation of the *one > line* definition of the 'alternate' relation. It is not contradictory. The definition of 'alternate' is not one line long on my screen, but here's the first sentence of it: # Alternate # Designates substitute versions for the document in which the link occurs. -- http://www.w3.org/TR/REC-html40/types.html#h-6.12 How is a link from the top of my homepage to my friend's weblog feed designating a "substitute version for the document in which the link occurs"? Note that we are not arguing the semantics of the element in an Atom document, but the semantics of the element in an HTML document. ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 13:39:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04743 for ; Wed, 4 May 2005 13:39: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 j44HNS6P089767; Wed, 4 May 2005 10: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 j44HNSBU089766; Wed, 4 May 2005 10:23: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44HNRGp089755 for ; Wed, 4 May 2005 10:23:27 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so412665wra for ; Wed, 04 May 2005 10:23: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=XsOsdqh0yedyWhigd1DEiAyXL5Y+LOZg6zzdhYEkQdprWL8dq3Og6C8mes95j8kGhNml7nUPHsnfCPHxJWzHeQ5v9r2FGW9oZggE3XnUT8E5GDROb/Zi1gyWbl6ieZXsYlizB29KKO9MdH5BiYw/aDRimsDauhEUamvJZv4mBgI= Received: by 10.54.122.14 with SMTP id u14mr403259wrc; Wed, 04 May 2005 10:23:21 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 10:23:21 -0700 (PDT) Message-ID: <68fba5c505050410235f4f1cea@mail.gmail.com> Date: Wed, 4 May 2005 13:23:21 -0400 From: Robert Sayre Reply-To: Robert Sayre To: fantasai Subject: Re: Autodiscovery Cc: Atom Syntax In-Reply-To: <4279016B.80606@inkedblade.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> <68fba5c5050504061177627f8f@mail.gmail.com> <4279016B.80606@inkedblade.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44HNRGp089760 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, fantasai wrote: > The definition of 'alternate' is not one line long on my screen, but > here's the first sentence of it: > > # Alternate > # Designates substitute versions for the document in which the link occurs. > > -- http://www.w3.org/TR/REC-html40/types.html#h-6.12 > > How is a link from the top of my homepage to my friend's weblog feed > designating a "substitute version for the document in which the link > occurs"? I don't know, but I'm not sure why you think that's what the autodiscovery spec endorses. Is there some part of the spec that endorses that? The autodiscovery spec is for use by UAs like Mozilla and Safari that present little icons alerting the user to a feed version of a page. Often, I never visit the page again, once I've subscribed to the feed. The feed is a substitute. > Note that we are not arguing the semantics of the element in > an Atom document, but the semantics of the element in an HTML > document. Yes, I caught that. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 4 13:52:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07439 for ; Wed, 4 May 2005 13:52: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 j44HfaN0091642; Wed, 4 May 2005 10: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 j44Hfa2g091641; Wed, 4 May 2005 10: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44HfYoO091627 for ; Wed, 4 May 2005 10: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); Thu, 5 May 2005 02:35:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 02:35:30 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050504061177627f8f@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 4/5/05 11:11 PM, "Robert Sayre" wrote: > The autodiscovery spec is a reasonable interpretation of the *one > line* definition of the 'alternate' relation. how is a feed of recent entries a "substitute version for the document in which the link occurs" when that document is some blog post long since dropped out of the feed? > Alternate > Designates substitute versions for the document in which the link occurs. When > used together with the lang attribute, it implies a translated version of the > document. When used together with the media attribute, it implies a version > designed for a different medium (or media). From owner-atom-syntax@mail.imc.org Wed May 4 14:11:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09204 for ; Wed, 4 May 2005 14:11: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 j44I2G57093163; Wed, 4 May 2005 11:02: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 j44I2GK8093162; Wed, 4 May 2005 11:02:16 -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 j44I2ERf093152 for ; Wed, 4 May 2005 11:02:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so434070wra for ; Wed, 04 May 2005 11:02: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=EYn/8wHUXcpGXvTm0hP9Wd3kwUkCUmkYROzQ7Fu/OHZSu7tyKu7gws7H+CrDzWv4HWD+eHxUEUGewVmkIz7KRNbP16xL+91G8KLrcljq+1VpltHsw3F4ZoAUPMSdTcn2WYmnwsXzr+ncI1pa1eU/HXoN+8MZShsT3PArkN0SfcM= Received: by 10.54.33.53 with SMTP id g53mr351802wrg; Wed, 04 May 2005 11:02:09 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 11:02:09 -0700 (PDT) Message-ID: <68fba5c505050411022559e7e3@mail.gmail.com> Date: Wed, 4 May 2005 14:02:09 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: Autodiscovery Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050504061177627f8f@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44I2ERf093155 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Eric Scheid wrote: > > On 4/5/05 11:11 PM, "Robert Sayre" wrote: > > > The autodiscovery spec is a reasonable interpretation of the *one > > line* definition of the 'alternate' relation. > > how is a feed of recent entries a "substitute version for the document in > which the link occurs" when that document is some blog post long since > dropped out of the feed? I don't know. Time is a funny thing. I think it would be a mistake to see this as an opportunity to invent a supremely capable and expressive autodiscovery spec. I've seen mozilla, safari, NNW do autodiscovery. I'm sure bots from PubSub, Technorati, Yahoo, etc do it as well. We should document what they do, and settle on one arbitrary choice where they differ for no good reason. Mark's draft does an excellent job of documenting that reality. I tried to rewrite it once, only to later realize what gross errors I'd made as I tried to clarify or add features to it. I can assure you that everything is there for a real-world reason. I suggested a few changes to section 6, which seems like overspecification to me, but that's the only thing I suggest we touch. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 4 14:11:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09307 for ; Wed, 4 May 2005 14:11: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 j44I2tOi093237; Wed, 4 May 2005 11:02: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 j44I2tCE093236; Wed, 4 May 2005 11:02:55 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44I2rV3093222 for ; Wed, 4 May 2005 11:02:54 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.53.119]) by smtp.cegetel.net (Postfix) with ESMTP id 81A0B318456; Wed, 4 May 2005 20:02:47 +0200 (CEST) Message-ID: <42790E46.5090800@cegetel.net> Date: Wed, 04 May 2005 20:02:46 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Robert Sayre Cc: fantasai , Atom Syntax Subject: Re: Autodiscovery References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> <68fba5c5050504061177627f8f@mail.gmail.com> In-Reply-To: <68fba5c5050504061177627f8f@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: > The autodiscovery spec is a reasonable interpretation of the *one > line* definition of the 'alternate' relation. It is not contradictory. But a feed is not a "substitute version" of an "archive page" as most archived entries are not in the feed anymore. That said, I'm totally in favor of using rel="alternate" to link to a feed from the _alternate_ HTML version. From an archive page, you should rather use rel="start". Actually, here's my view of those things: In the "latest news" page (generally the homepage for a weblog): In a "category" page: In a "single-entry archive" page: However, is this enough for the autodiscovery purpose? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed May 4 14:11:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09330 for ; Wed, 4 May 2005 14:11: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 j44I6pE7093763; Wed, 4 May 2005 11:06: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 j44I6puK093762; Wed, 4 May 2005 11:06:51 -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 j44I6pO5093748 for ; Wed, 4 May 2005 11:06:51 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so194214wri for ; Wed, 04 May 2005 11:06:45 -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=JshSFolC5Gwg4ioupf3uVlaK0AztfkUo6yTi/XfPIVbVneM0HCKFmoqF7kcw2iPNi7yxqXqBdJ4RzM9qtuJDRs2Neo50nL4qtFU8pr5XFTCzczEkynz8JaamlKfeLrc9qZfsXT3Ds49TlCGJ/X/AoWPTd7OiB3UsO+lIVZxq+Y0= Received: by 10.54.146.19 with SMTP id t19mr562345wrd; Wed, 04 May 2005 11:06:45 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Wed, 4 May 2005 11:06:44 -0700 (PDT) Message-ID: <540e373205050411062747063f@mail.gmail.com> Date: Wed, 4 May 2005 13:06:44 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Autodiscovery In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050504061177627f8f@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44I6pO5093757 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > how is a feed of recent entries a "substitute version for the document in > which the link occurs" when that document is some blog post long since > dropped out of the feed? Eric: A devil's advocacy moment... if I change the published date for the document to today's date, it will suddenly spring forward into my feed of recent entries. And at some point in the past, it was already in that feed. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed May 4 14:17:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10101 for ; Wed, 4 May 2005 14:17: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 j44IB8m8094090; Wed, 4 May 2005 11:11: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 j44IB8Bj094089; Wed, 4 May 2005 11:11:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leftfield.org (kelphw.sv.meer.net [205.217.155.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44IB8pp094078 for ; Wed, 4 May 2005 11:11:08 -0700 (PDT) (envelope-from chris@desalvo.org) Received: from [10.0.1.28] (wall.danger.com [216.220.212.140]) by leftfield.org (Postfix) with ESMTP id 5E5BF3D0D for ; Wed, 4 May 2005 11:11:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <4278A782.7010105@labs.mot.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> From: Chris DeSalvo Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 11:11:05 -0700 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44IB8pp094084 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 4, 2005, at 3:44 AM, Brett Lindsley wrote: > Andy, I recall bringing up the same issue with respect to portable > devices. My angle > was that firing up the transmitter, making a network connection and > connecting to > the server is still an expensive operation in time and power (for a > portable > device) - even if the server returns nothing . There is no reason to > check feeds > that are not being updated, but then, there currently is no way to > know this. As the author of an aggregator app for a portable wireless device I can tell you that this is a serious problem for this class of products. In my app I've implemented every trick in the book to try and reduce the amount of data that I have to pull through the radio and parse. I use If-None-Match and If-Changed-Since headers in my requests, I support compression, I respect caching hints from the servers. It doesn't help in all cases. I have 112 loaded up in my aggregator and only 74 of the servers hosting those feeds ever return a 304. The rest give me a 200 and gladly hand me everything regardless of whether it has changed or not. 17 of the servers don't bother supplying an ETag header. My feed list amounts to about 20 MB of data per day when polling once per hour. That is a lot of air time for a small radio, and a lot time spent grinding in an XML parser for a small CPU. This is especially upsetting because by my measurements only about 2 MB of data is fresh for any given day. The main hit is in battery life the above stats can trivially knock HOURS off of the life of a small battery. I've written extensively about this problem here: with a real-world example studied here: So, I guess I'd like to see an optional update-frequency hint element. Thanks, Chris From owner-atom-syntax@mail.imc.org Wed May 4 14:24:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10967 for ; Wed, 4 May 2005 14:24: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 j44IHS6m094435; Wed, 4 May 2005 11:17: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 j44IHSGC094434; Wed, 4 May 2005 11:17: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 j44IHRBd094428 for ; Wed, 4 May 2005 11:17:27 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id F0DAC4EFE4; Wed, 4 May 2005 14:17:26 -0400 (EDT) Date: Wed, 4 May 2005 14:17:26 -0400 From: Dan Brickley To: Eric Scheid Cc: Atom Syntax Subject: Re: Autodiscovery Message-ID: <20050504181726.GC32428@homer.w3.org> References: <68fba5c5050504061177627f8f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Eric Scheid [2005-05-05 02:35+1000] > > On 4/5/05 11:11 PM, "Robert Sayre" wrote: > > > The autodiscovery spec is a reasonable interpretation of the *one > > line* definition of the 'alternate' relation. > > how is a feed of recent entries a "substitute version for the document in > which the link occurs" when that document is some blog post long since > dropped out of the feed? Because the HTML definition is close to meaningless. I can substitute any document for another, and the 2nd is a substitution not through any intrinsic characteristics, but because it was substituted. Many of the HTML link type definitions don't bear up under detailed scrutiny... Dan From owner-atom-syntax@mail.imc.org Wed May 4 14:47:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13445 for ; Wed, 4 May 2005 14:47: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 j44Ib5Hd096797; Wed, 4 May 2005 11:37: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 j44Ib5FF096796; Wed, 4 May 2005 11:37:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Ib4XM096785 for ; Wed, 4 May 2005 11:37:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44IZi4A010249; Wed, 4 May 2005 19:35:49 +0100 (BST) In-Reply-To: <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9CBF28BE-7099-41D4-9F89-7B4C5A44AF37@mac.com> Cc: atom-syntax From: Graham Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 19:35:44 +0100 To: Chris DeSalvo X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44Ib5XM096791 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4 May 2005, at 7:11 pm, Chris DeSalvo wrote: > My feed list amounts to about 20 MB of data per day when polling > once per hour. That is a lot of air time for a small radio, and a > lot time spent grinding in an XML parser for a small CPU. This is > especially upsetting because by my measurements only about 2 MB of > data is fresh for any given day. The main hit is in battery life > the above stats can trivially knock HOURS off of the life of a > small battery. So you're saying the first smartphone aggregator that uses a gateway server to move the heavy lifting off of the device is going to clean up the market. What's this got to do with Atom? > So, I guess I'd like to see an optional update-frequency hint element. Why? Graham From owner-atom-syntax@mail.imc.org Wed May 4 15:13:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17010 for ; Wed, 4 May 2005 15: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 j44J0qvX098447; Wed, 4 May 2005 12:00: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 j44J0qFq098446; Wed, 4 May 2005 12:00:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44J0pPG098439 for ; Wed, 4 May 2005 12:00:52 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-17.princeton.edu ([128.112.34.172]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTP72-0001np-A4 for atom-syntax@imc.org; Wed, 04 May 2005 15:00:48 -0400 Message-ID: <42791B9A.2060509@inkedblade.net> Date: Wed, 04 May 2005 14:59:38 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <68fba5c5050504061177627f8f@mail.gmail.com> <20050504181726.GC32428@homer.w3.org> In-Reply-To: <20050504181726.GC32428@homer.w3.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dan Brickley wrote: > * Eric Scheid [2005-05-05 02:35+1000] > >>On 4/5/05 11:11 PM, "Robert Sayre" wrote: >> >> >>>The autodiscovery spec is a reasonable interpretation of the *one >>>line* definition of the 'alternate' relation. >> >>how is a feed of recent entries a "substitute version for the document in >>which the link occurs" when that document is some blog post long since >>dropped out of the feed? > > Because the HTML definition is close to meaningless. I can substitute > any document for another, and the 2nd is a substitution not through any > intrinsic characteristics, but because it was substituted. Many of the > HTML link type definitions don't bear up under detailed scrutiny... I think you're taking your anarchic interpretation a little too far there. Especially there: if you read the *spec*, you might notice that the definition of 'alternate' continues: # When used together with the media attribute, it implies a version # designed for a different medium (or media). From section 12.2.4, we also have # The rel attribute specifies the relationship of the linked document # with the current document. So, according to HTML 4.01 -- which is the definitive spec as far as HTML is concerned -- the following link designates a link to a version of the linking document that is application/atom+xml. Again, my friend's blog feed is not an Atom version of /my/ web page; linking to it as "alternate" would be wrong. ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 15:24:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18645 for ; Wed, 4 May 2005 15:24: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 j44JHjap099596; Wed, 4 May 2005 12:17: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 j44JHj2M099595; Wed, 4 May 2005 12:17:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leftfield.org (kelphw.sv.meer.net [205.217.155.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JHie3099588 for ; Wed, 4 May 2005 12:17:44 -0700 (PDT) (envelope-from chris@desalvo.org) Received: from [10.0.1.28] (wall.danger.com [216.220.212.140]) by leftfield.org (Postfix) with ESMTP id 613DF3D1F; Wed, 4 May 2005 12:17:41 -0700 (PDT) In-Reply-To: <9CBF28BE-7099-41D4-9F89-7B4C5A44AF37@mac.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> <9CBF28BE-7099-41D4-9F89-7B4C5A44AF37@mac.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <5ed608e236b316e89c2d652e92cb33a0@desalvo.org> Cc: dtcd@mac.com From: Chris DeSalvo Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 12:17:40 -0700 To: atom-syntax X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44JHie3099590 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 4, 2005, at 11:35 AM, Graham wrote: > On 4 May 2005, at 7:11 pm, Chris DeSalvo wrote: > >> My feed list amounts to about 20 MB of data per day when polling once >> per hour. That is a lot of air time for a small radio, and a lot >> time spent grinding in an XML parser for a small CPU. This is >> especially upsetting because by my measurements only about 2 MB of >> data is fresh for any given day. The main hit is in battery life >> the above stats can trivially knock HOURS off of the life of a small >> battery. > > So you're saying the first smartphone aggregator that uses a gateway > server to move the heavy lifting off of the device is going to clean > up the market. What's this got to do with Atom? > >> So, I guess I'd like to see an optional update-frequency hint element. > > Why? If the feed provided a hint for a reasonable polling frequency, it would be a plus for limited-resource devices. I hate to suggest that the format be changed as a prophylactic measure against bad-citizen servers, but that is the problem that I have to solve for my platform and applications. In case anyone cares, this is for the T-Mobile Sidekick. I work at Danger, Inc, the developer of the OS and hardware. I work on the OS and applications. -chris p.s. And yes, someone providing a good gateway, with a snazzy push protocol would make my life a lot easier. From owner-atom-syntax@mail.imc.org Wed May 4 15:25:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18889 for ; Wed, 4 May 2005 15:25: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 j44JKKXG099752; Wed, 4 May 2005 12:20: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 j44JKKaP099751; Wed, 4 May 2005 12:20:20 -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 j44JKK5C099733 for ; Wed, 4 May 2005 12:20:20 -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 <2005050419201401400a1ao3e>; Wed, 4 May 2005 19:20:14 +0000 Date: Wed, 4 May 2005 13:20:07 -0600 Subject: Re: Autodiscovery 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: <42791B9A.2060509@inkedblade.net> Message-Id: <86BDA322-BCD1-11D9-BA79-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, May 4, 2005, at 12:59 PM, fantasai wrote: > Again, my friend's blog feed is not an Atom version of /my/ web page; > linking to it as "alternate" would be wrong. To me, this raises a red flag, suggesting that using an autodiscovery link from your web page to your friend's feed is not what autodiscovery is intended for. From owner-atom-syntax@mail.imc.org Wed May 4 15:26:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18932 for ; Wed, 4 May 2005 15:26: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 j44JKMtO099760; Wed, 4 May 2005 12:20: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 j44JKMs1099759; Wed, 4 May 2005 12:20:22 -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 j44JKK9M099750 for ; Wed, 4 May 2005 12:20:20 -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 j44JKKjO011949 for ; Wed, 4 May 2005 13:20:20 -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 <0IFZ00BU7CDVIA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 May 2005 13:20:20 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFZ00APTCDUO6@mail.sun.net> for atom-syntax@imc.org; Wed, 04 May 2005 13:20:19 -0600 (MDT) Date: Wed, 04 May 2005 12:21:22 -0700 From: Tim Bray Subject: Re: Autodiscovery In-reply-to: <68fba5c505050411022559e7e3@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax , Eric Scheid Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050504061177627f8f@mail.gmail.com> <68fba5c505050411022559e7e3@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 4, 2005, at 11:02 AM, Robert Sayre wrote: > I think it would be a mistake to see this as an opportunity to invent > a supremely capable and expressive autodiscovery spec. I've seen > mozilla, safari, NNW do autodiscovery. I'm sure bots from PubSub, > Technorati, Yahoo, etc do it as well. We should document what they do, > and settle on one arbitrary choice where they differ for no good > reason. > > Mark's draft does an excellent job of documenting that reality. +1. It's Good Enough. -Tim From owner-atom-syntax@mail.imc.org Wed May 4 15:27:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19039 for ; Wed, 4 May 2005 15:27: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 j44JGAql099395; Wed, 4 May 2005 12:16: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 j44JGAFC099394; Wed, 4 May 2005 12:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JGADW099388 for ; Wed, 4 May 2005 12:16:10 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-17.princeton.edu ([128.112.34.172]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTPLr-0002RF-3Y for atom-syntax@imc.org; Wed, 04 May 2005 15:16:07 -0400 Message-ID: <42791F2F.1000705@inkedblade.net> Date: Wed, 04 May 2005 15:14:55 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <27F82537-BC9E-11D9-BA79-003065EA6144@geckotribe.com> In-Reply-To: <27F82537-BC9E-11D9-BA79-003065EA6144@geckotribe.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Tuesday, May 3, 2005, at 11:41 PM, fantasai wrote: > >> David Nesting wrote: >> >>> I expect that many of my implementations will utilize content >>> negotiation >>> (using the same URL as an HTML representation, where needed), so I >>> expect >>> that I'll have some links like: >>> >>> >>> Or even >>> >>> >> >> That won't work, because content negotiation will continue to return >> the same thing it returned just now. You must somehow tell the server >> to return a specific other version of the current document, and you >> do that typically by sending a GET request with a different URL -- >> one that specifies a particular version of the resource. >> > See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14 > > GET /path-to-the-feed HTTP/1.1 > Accept: application/atom+xml > ... > > You don't have to change the URL--just list only the format you want in > the Accept header. If the autodiscovery link was lying/mistaken and > that format really isn't available at that URL, you should get a 406 > (not acceptable) response. Where does it say that including a 'type' attribute on a link forces the UA to send a restricted Accept header? ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 15:40:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20438 for ; Wed, 4 May 2005 15:40: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 j44JXXGP000878; Wed, 4 May 2005 12:33: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 j44JXXI5000877; Wed, 4 May 2005 12:33: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j44JXV0m000863 for ; Wed, 4 May 2005 12:33:32 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 May 2005 19:33:25 -0000 Received: from p508FE082.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.224.130] by mail.gmx.net (mp013) with SMTP; 04 May 2005 21:33:25 +0200 X-Authenticated: #1915285 Message-ID: <4279237F.4060001@gmx.de> Date: Wed, 04 May 2005 21:33:19 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Autodiscovery References: <86BDA322-BCD1-11D9-BA79-003065EA6144@geckotribe.com> In-Reply-To: <86BDA322-BCD1-11D9-BA79-003065EA6144@geckotribe.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 Antone Roundy wrote: > > On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: > >> Again, my friend's blog feed is not an Atom version of /my/ web page; >> linking to it as "alternate" would be wrong. > > > To me, this raises a red flag, suggesting that using an autodiscovery > link from your web page to your friend's feed is not what autodiscovery > is intended for. +1 Julian From owner-atom-syntax@mail.imc.org Wed May 4 15:45:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20954 for ; Wed, 4 May 2005 15:45: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 j44JcGL4001310; Wed, 4 May 2005 12:38: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 j44JcGpa001309; Wed, 4 May 2005 12:38:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JcFVV001303 for ; Wed, 4 May 2005 12:38:16 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-17.princeton.edu ([128.112.34.172]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTPhE-0003Xb-53; Wed, 04 May 2005 15:38:12 -0400 Message-ID: <4279245B.4020907@inkedblade.net> Date: Wed, 04 May 2005 15:36:59 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax CC: whatwg@whatwg.org, pilgrim@gmail.com, Tim.Bray@Sun.COM Subject: Re: Autodiscovery References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> In-Reply-To: <0ddadc99a41ce83550ede71051ea02ae@iki.fi> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > On May 4, 2005, at 09:16, Mark Pilgrim wrote: > >> Then I'm confused as to why you can't just release running code that >> hard-codes rel="alternate". You know, like people have already done. > > Sure you can. ("Can" in the sense that it is possible.) > > However, when other things are equal, I think misusing an existing > relation (feed usually is not a proper alternate representation) is > worse than specifying a new one without all the profile fluff. > > Still, I am well aware that the other things are not equal in this case > (ie. there is deployed code), which is why I was not arguing in favor of > rel='feed' per se, but pointing out that the particular reasoning > against it did not hold water, IMO. It is the case that many, if not most, autodiscovery links *are* linking to valid alternates of the current page. Taking into account the wide use of the rel="alternate" type="application/atom+xml" combination, the spec could be written to - specify that any link with rel="feed" and type="application/atom+xml" indicates an autodiscoverable Atom feed - specify that UAs MAY also recognize the rel="alternate" and type="application/atom+xml" combination as an autodiscoverable Atom feed even if 'feed' is not among the rel values, - but specify that authors SHOULD NOT (or MUST NOT) leave out the 'feed' value - recommend that links that do indicate a feed version of the current HTML page SHOULD link to that feed with both link types Blogging software is a fast-moving industry. If the draft editor makes this change and notifies the community, I suspect it will not be long before most software supports both syntaxes. ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 15:48:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21695 for ; Wed, 4 May 2005 15:48: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 j44JfAdI001489; Wed, 4 May 2005 12: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 j44JfALw001488; Wed, 4 May 2005 12:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Jf9Bt001481 for ; Wed, 4 May 2005 12:41:09 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-c-17.princeton.edu ([128.112.34.172]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTPk2-0003fa-Nn for atom-syntax@imc.org; Wed, 04 May 2005 15:41:06 -0400 Message-ID: <4279250C.6010908@inkedblade.net> Date: Wed, 04 May 2005 15:39:56 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <86BDA322-BCD1-11D9-BA79-003065EA6144@geckotribe.com> In-Reply-To: <86BDA322-BCD1-11D9-BA79-003065EA6144@geckotribe.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: > >> Again, my friend's blog feed is not an Atom version of /my/ web page; >> linking to it as "alternate" would be wrong. > > To me, this raises a red flag, suggesting that using an autodiscovery > link from your web page to your friend's feed is not what autodiscovery > is intended for. Probably not. But the same argument applies if I have an autodiscovery link from a single entry in my blog to the main blog feed (which is a valid alternate version of my weblog's front page, but not of that single entry). ~fantasai From owner-atom-syntax@mail.imc.org Wed May 4 15:54:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23456 for ; Wed, 4 May 2005 15:54: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 j44Jn9ik002079; Wed, 4 May 2005 12:49: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 j44Jn9ae002078; Wed, 4 May 2005 12:49:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Jn8WO002071 for ; Wed, 4 May 2005 12:49:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j44JmRGt001625; Wed, 4 May 2005 20:48:32 +0100 (BST) In-Reply-To: <68fba5c505050411022559e7e3@mail.gmail.com> References: <68fba5c5050504061177627f8f@mail.gmail.com> <68fba5c505050411022559e7e3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51E499A2-EAFE-49A2-BD45-2728E3E22AF6@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Autodiscovery Date: Wed, 4 May 2005 20:48:26 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 May 2005, at 7:02 pm, Robert Sayre wrote: > settle on one arbitrary choice +1 Graham From owner-atom-syntax@mail.imc.org Wed May 4 15:56:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23763 for ; Wed, 4 May 2005 15:56: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 j44JpIBb002268; Wed, 4 May 2005 12:51: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 j44JpIQu002267; Wed, 4 May 2005 12:51: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JpGF2002257 for ; Wed, 4 May 2005 12:51:17 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so434057nzn for ; Wed, 04 May 2005 12:51:11 -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=hzfBFsbX6GsnUH/9TF1Uh+F3Gon0QgyffTQfdJ6b0KruWfveGHmxasn7kIJk2xEcxSFv6bRQW3yjNwYsSAziWRuPaLoyROvpkUeFaT5BzBNfLdrZUqIYp4fjU1A+3hRg9chHDu9IEfSL1Z8KQdV6yasNCiEnAnLkFHDr7A9BUnc= Received: by 10.36.23.5 with SMTP id 5mr192740nzw; Wed, 04 May 2005 12:51:11 -0700 (PDT) Received: by 10.36.65.13 with HTTP; Wed, 4 May 2005 12:51:11 -0700 (PDT) Message-ID: <3f1451f505050412517465d5c6@mail.gmail.com> Date: Wed, 4 May 2005 15:51:11 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: Autodiscovery Cc: Eric Scheid , Atom Syntax In-Reply-To: <68fba5c505050411022559e7e3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050504061177627f8f@mail.gmail.com> <68fba5c505050411022559e7e3@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44JpHF2002261 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Robert Sayre wrote: > Mark's draft does an excellent job of documenting that reality. +1 -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed May 4 16:52:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04081 for ; Wed, 4 May 2005 16:52: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 j44Kcq1r006064; Wed, 4 May 2005 13:38: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 j44Kcqs0006063; Wed, 4 May 2005 13:38:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from leftfield.org (kelphw.sv.meer.net [205.217.155.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Kcq5O006057 for ; Wed, 4 May 2005 13:38:52 -0700 (PDT) (envelope-from chris@desalvo.org) Received: from [10.0.1.28] (wall.danger.com [216.220.212.140]) by leftfield.org (Postfix) with ESMTP id 3A0E53D1F; Wed, 4 May 2005 13:38:51 -0700 (PDT) In-Reply-To: <68fba5c50505041252cd2d73@mail.gmail.com> References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> <9CBF28BE-7099-41D4-9F89-7B4C5A44AF37@mac.com> <5ed608e236b316e89c2d652e92cb33a0@desalvo.org> <68fba5c50505041252cd2d73@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <887c450e9e49203eff0d7a62996bdc40@desalvo.org> Content-Transfer-Encoding: 7bit Cc: Robert Sayre From: Chris DeSalvo Subject: Re: Atom feed refresh rates Date: Wed, 4 May 2005 13:38:48 -0700 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 I do not disagree. I just wanted to get my $0.02 in for completeness. I'm happy as a clam with atom as it is now. -chris On May 4, 2005, at 12:52 PM, Robert Sayre wrote: > No one is denying the existence of the problem you're describing. > However, this WG has consistently decided is that an optional XML > element of the kind you're describing wouldn't solve the problem. > Essentially, we'd be trading one evangelism problem for another. From owner-atom-syntax@mail.imc.org Wed May 4 18:53:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21046 for ; Wed, 4 May 2005 18:53: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 j44MjNkI022359; Wed, 4 May 2005 15:45: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 j44MjN5R022358; Wed, 4 May 2005 15:45:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44MjMkx022334 for ; Wed, 4 May 2005 15:45:23 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j44MjBpc016538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 May 2005 18:45:16 -0400 (EDT) Message-ID: <42795178.1080401@atrus.org> Date: Wed, 04 May 2005 18:49:28 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: Autodiscovery References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> In-Reply-To: <4279245B.4020907@inkedblade.net> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit fantasai wrote: > > Henri Sivonen wrote: > >> >> On May 4, 2005, at 09:16, Mark Pilgrim wrote: >> >>> Then I'm confused as to why you can't just release running code that >>> hard-codes rel="alternate". You know, like people have already done. >> >> >> Sure you can. ("Can" in the sense that it is possible.) >> >> However, when other things are equal, I think misusing an existing >> relation (feed usually is not a proper alternate representation) is >> worse than specifying a new one without all the profile fluff. >> >> Still, I am well aware that the other things are not equal in this >> case (ie. there is deployed code), which is why I was not arguing in >> favor of rel='feed' per se, but pointing out that the particular >> reasoning against it did not hold water, IMO. > > > It is the case that many, if not most, autodiscovery links *are* linking > to valid alternates of the current page. Taking into account the wide > use of the rel="alternate" type="application/atom+xml" combination, the > spec could be written to > > - specify that any link with rel="feed" and type="application/atom+xml" > indicates an autodiscoverable Atom feed > - specify that UAs MAY also recognize the rel="alternate" and > type="application/atom+xml" combination as an autodiscoverable Atom > feed even if 'feed' is not among the rel values, > - but specify that authors SHOULD NOT (or MUST NOT) leave out the > 'feed' value > - recommend that links that do indicate a feed version of the current > HTML page SHOULD link to that feed with both link types > > Blogging software is a fast-moving industry. If the draft editor makes > this change and notifies the community, I suspect it will not be long > before most software supports both syntaxes. > > ~fantasai I think you've missed how things are working at the moment. Most programs implemented what's in the spec before it's written. Mark is trying to negotiate a common standard when implementations already exist. A lot of experimentation has already occurred. One of the key points seems to be that autodiscovery is not meant to find all feeds linked to on a page, just the ones that serve as alternates to the current one. If people wanted this functionality, they would have done it by now. I think you have three separate cases of autodiscovery: * the feed for *this* page - handled by this autodiscovery proposal * other feeds the author reads or recommends - usually done by linking to a separate file. Some quick searching reveals one suggestion to use rel="blogroll" for this * any other feeds linked to for any reason at all - seems to be little interest in I don't think combining these three into one case will do any good. In fact, I think it's confusing and unusable. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed May 4 18:54:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21095 for ; Wed, 4 May 2005 18:54: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 j44MjE8D022332; Wed, 4 May 2005 15:45: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 j44MjEYJ022331; Wed, 4 May 2005 15:45:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44MjDih022310 for ; Wed, 4 May 2005 15:45:14 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j44Mj7pc016534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 May 2005 18:45:07 -0400 (EDT) Message-ID: <42795174.20700@atrus.org> Date: Wed, 04 May 2005 18:49:24 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: Autodiscovery References: <4279008B.5030108@inkedblade.net> In-Reply-To: <4279008B.5030108@inkedblade.net> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit fantasai wrote: > > Arve Bersvendsen wrote: > >> >> On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid >> wrote: >> >>> instead of "feed", consider "updates", which gets closer to the gist >>> of the sense >> >> >> No. To me 'Updates' signifies that something is 'updated'. Even >> posting new content falls outside of that definition. > > > That would signify "updates" to my document. If I'm linking to the > CNN news feed, or my-favorite-blog, that wouldn't be appropriate. > For this purpose, the syntax needs to signify that this is a feed, > that it needs to be handled as such.. and that there is no other > significant relationship between the document and the feed it links > to (unless otherwise specified). > > ~fantasai > These are both valid interpretations of "updates." From Princeton's WordNet: update - n - news that updates your information - v - 1: modernize or bring up to date; "We updated the kitchen in the old house" 2: bring up to date; supply with recent information 3: bring to the latest state of technology As this definition suggests, most people think of "updates" as modifications of items that already exists first and completely new items second. In the land of feeds, the frequency is reversed (most "updates" in feeds are new items, not modifications to existing ones). -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed May 4 18:54:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21136 for ; Wed, 4 May 2005 18:54: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 j44MjeXE022402; Wed, 4 May 2005 15:45: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 j44Mjesu022401; Wed, 4 May 2005 15:45:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Mjekn022388 for ; Wed, 4 May 2005 15:45:40 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j44MjXpc016541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 May 2005 18:45:33 -0400 (EDT) Message-ID: <4279518E.9070404@atrus.org> Date: Wed, 04 May 2005 18:49:50 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: Autodiscovery References: <4279008B.5030108@inkedblade.net> In-Reply-To: <4279008B.5030108@inkedblade.net> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit fantasai wrote: > > Arve Bersvendsen wrote: > >> >> On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid >> wrote: >> >>> instead of "feed", consider "updates", which gets closer to the gist >>> of the sense >> >> >> No. To me 'Updates' signifies that something is 'updated'. Even >> posting new content falls outside of that definition. > > > That would signify "updates" to my document. If I'm linking to the > CNN news feed, or my-favorite-blog, that wouldn't be appropriate. > For this purpose, the syntax needs to signify that this is a feed, > that it needs to be handled as such.. and that there is no other > significant relationship between the document and the feed it links > to (unless otherwise specified). > > ~fantasai > These are both valid interpretations of "updates." From Princeton's WordNet: update - n - news that updates your information - v - 1: modernize or bring up to date; "We updated the kitchen in the old house" 2: bring up to date; supply with recent information 3: bring to the latest state of technology As this definition suggests, most people think of "updates" as modifications of items that already exists first and completely new items second. In the land of feeds, the frequency is reversed (most "updates" in feeds are new items, not modifications to existing ones). -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed May 4 18:56:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21256 for ; Wed, 4 May 2005 18:56: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 j44MjDSW022320; Wed, 4 May 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 j44MjDAe022319; Wed, 4 May 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 mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44MjCkI022304 for ; Wed, 4 May 2005 15:45:12 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j44Mj3pc016531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 May 2005 18:45:06 -0400 (EDT) Message-ID: <42795171.6070209@atrus.org> Date: Wed, 04 May 2005 18:49:21 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: Autodiscovery 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 4/5/05 11:11 PM, "Robert Sayre" wrote: > > > >>The autodiscovery spec is a reasonable interpretation of the *one >>line* definition of the 'alternate' relation. >> >> > >how is a feed of recent entries a "substitute version for the document in >which the link occurs" when that document is some blog post long since >dropped out of the feed? > I'd suggest placing the link element only on the front page of your blog if this is a concern. The feed usually is a "substitute version for the document in which the link occurs" for that, at least. There's nothing in the spec that even suggests you to place the autodiscovery information in archive pages. In practice, people probably will, but I'm not sure it's worth worrying about. Do you have some example that's more generally applicable? -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed May 4 19:17:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25387 for ; Wed, 4 May 2005 19:17: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 j44N6nfp025237; Wed, 4 May 2005 16:06: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 j44N6nQv025236; Wed, 4 May 2005 16:06:49 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44N6mK3025202 for ; Wed, 4 May 2005 16:06: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 <2005050423063901600e0le5e>; Wed, 4 May 2005 23:06:40 +0000 Date: Wed, 4 May 2005 17:06:38 -0600 Subject: Re: Autodiscovery 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: <42795171.6070209@atrus.org> Message-Id: <2B58A4BF-BCF1-11D9-BA79-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, May 4, 2005, at 04:49 PM, Nikolas 'Atrus' Coukouma wrote: > Eric Scheid wrote: >> On 4/5/05 11:11 PM, "Robert Sayre" wrote: >>> The autodiscovery spec is a reasonable interpretation of the *one >>> line* definition of the 'alternate' relation. >> how is a feed of recent entries a "substitute version for the >> document in >> which the link occurs" when that document is some blog post long since >> dropped out of the feed? > I'd suggest placing the link element only on the front page of your > blog > if this is a concern. The feed usually is a "substitute version for the > document in which the link occurs" for that, at least. There's nothing > in the spec that even suggests you to place the autodiscovery > information in archive pages. In practice, people probably will, but > I'm > not sure it's worth worrying about. There is a good reason for putting the link in the individual entry pages: if people get to your blog via some location other than your blog homepage, you don't want them to have to go to your homepage to subscribe to your blog's feed. In such a case, sure, "alternate" wouldn't be descriptive of the feed's relationship to the isolated page, but the way that such links will be processed by browsers will match the intent for publishing the link -> "if you find this entry interesting enough to want to subscribe to my feed, here's where to do it". I personally don't care whether it's "alternative" or something like "feed". "Alternative" is a more generally applicable term, but yeah, it doesn't sound quite right on individual entry pages. From owner-atom-syntax@mail.imc.org Wed May 4 19:33:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26453 for ; Wed, 4 May 2005 19:33: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 j44NQXPF028144; Wed, 4 May 2005 16:26: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 j44NQXKO028143; Wed, 4 May 2005 16:26: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44NQWCe028125 for ; Wed, 4 May 2005 16:26: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); Thu, 5 May 2005 09:26:27 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 09:26:27 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42790E46.5090800@cegetel.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 5/5/05 4:02 AM, "Thomas Broyer" wrote: > Robert Sayre wrote: >> The autodiscovery spec is a reasonable interpretation of the *one >> line* definition of the 'alternate' relation. It is not contradictory. > > But a feed is not a "substitute version" of an "archive page" as most > archived entries are not in the feed anymore. > > That said, I'm totally in favor of using rel="alternate" to link to a > feed from the _alternate_ HTML version. > > From an archive page, you should rather use rel="start". The problem is, an automaton wouldn't know which to use as it wouldn't know if the page it is looking at is an entry archive page or a recent entries page, which rather defeats the purpose of "auto-discovery". Also, it would be entirely reasonable to use @rel='alternate' to point to an @type='application/atom+xml' Atom Entry Document from an archive page. Furthermore, from a recent entries page it would also be entirely reasonable to use @rel='start' to point to the first archive entry page. Thus, the meanings of 'alternate' and 'start' would be *reversed* depending on what kind of page you were looking at. This is not conducive to hands-free "auto" discovery. Using @rel='feed' from both kinds of pages fixes that problem. e. From owner-atom-syntax@mail.imc.org Wed May 4 19:34:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26524 for ; Wed, 4 May 2005 19:34: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 j44JqAIY002328; Wed, 4 May 2005 12:52: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 j44JqAp8002327; Wed, 4 May 2005 12:52: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Jq85x002314 for ; Wed, 4 May 2005 12:52:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so492287wra for ; Wed, 04 May 2005 12:52:00 -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=HhsL/L7sLiEV+E8uQt5/x9jApNs1Ke9sDyUezomyRFyb5vnh0A7cXHaJCSV7Tf83Va44S7jQ07GRWTFhhljSu7Secf2Q4j36aQ7UCW1k4oi2pefVcobOt9LMWVkQeP8zLpWPC/fEQG66BdemhNR76opEocmg3vKf/8DetrcNGrc= Received: by 10.54.153.19 with SMTP id a19mr286192wre; Wed, 04 May 2005 12:52:00 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 12:52:00 -0700 (PDT) Message-ID: <68fba5c50505041252cd2d73@mail.gmail.com> Date: Wed, 4 May 2005 15:52:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Chris DeSalvo Subject: Re: Atom feed refresh rates Cc: atom-syntax , dtcd@mac.com In-Reply-To: <5ed608e236b316e89c2d652e92cb33a0@desalvo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <4278A782.7010105@labs.mot.com> <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> <9CBF28BE-7099-41D4-9F89-7B4C5A44AF37@mac.com> <5ed608e236b316e89c2d652e92cb33a0@desalvo.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44JqA5x002322 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Chris DeSalvo wrote: > > If the feed provided a hint for a reasonable polling frequency, it > would be a plus for limited-resource devices. I hate to suggest that > the format be changed as a prophylactic measure against bad-citizen > servers, but that is the problem that I have to solve for my platform > and applications. No one is denying the existence of the problem you're describing. However, this WG has consistently decided is that an optional XML element of the kind you're describing wouldn't solve the problem. Essentially, we'd be trading one evangelism problem for another. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 4 19:34:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26526 for ; Wed, 4 May 2005 19:34: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 j44Go9Hp085826; Wed, 4 May 2005 09:50: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 j44Go9W7085825; Wed, 4 May 2005 09:50: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Go6YZ085807 for ; Wed, 4 May 2005 09:50:08 -0700 (PDT) (envelope-from lavandowska@gmail.com) Received: by wproxy.gmail.com with SMTP id 49so247775wri for ; Wed, 04 May 2005 09:49:55 -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=dEQT/xEQNtt7EFsdzm3ol5/UZD4jcqg+KUext7Rpn+NRsrBkmq7G5SWYbMv7lzDmSD8PIob9CucReZPP3IgyGPuML7saOeDV1iFi3c+yRtGJw2Ya4vn09P8HInLm2kTiz12NZemgw8UjCunMKMe7jgKde+JP+9IleD+9t4aCsTs= Received: by 10.54.55.23 with SMTP id d23mr812164wra; Wed, 04 May 2005 09:49:55 -0700 (PDT) Received: by 10.54.59.13 with HTTP; Wed, 4 May 2005 09:49:54 -0700 (PDT) Message-ID: <96d7d77c05050409495e337377@mail.gmail.com> Date: Wed, 4 May 2005 11:49:54 -0500 From: Lance Lavandowska Reply-To: Lance Lavandowska To: Atom Syntax Subject: Re: Atom feed refresh rates In-Reply-To: <540e373205050409321f1624b3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <0659A553-E426-4503-93E9-4C6F7DDF7D6B@mac.com> <540e373205050409321f1624b3@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j44Go8YZ085819 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/4/05, Roger B. wrote: > > That's not to say that there's something necessarily wrong with an > aggregator that allows users to pull feeds every five minutes. If In the toy aggregator I wrote I played with a scheduler that tried to throttle itself based on the feeds response. That is to say it started polling every ten minutes. If the feed returned a 302 (or the corresponding Etag "i haven't changed") then it extended that to every 20. Then 30... The problem I had was deciding what the maximum should be (1 hour? 2? 24?). Upon getting a 'fresh' feed it reset the interval to 10 minutes and started over again. I'm certain I got this idea from someone else, but don't recall who originated the idea. Lance Lavandowska From owner-atom-syntax@mail.imc.org Wed May 4 19:41:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26986 for ; Wed, 4 May 2005 19:41: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 j44NZbFM029718; Wed, 4 May 2005 16:35: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 j44NZbC1029717; Wed, 4 May 2005 16:35:37 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44NZaIK029710 for ; Wed, 4 May 2005 16:35:37 -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, 5 May 2005 09:35:35 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 09:35:35 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050504181726.GC32428@homer.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 5/5/05 4:17 AM, "Dan Brickley" wrote: >>> The autodiscovery spec is a reasonable interpretation of the *one >>> line* definition of the 'alternate' relation. >> >> how is a feed of recent entries a "substitute version for the document in >> which the link occurs" when that document is some blog post long since >> dropped out of the feed? > > Because the HTML definition is close to meaningless. I can substitute > any document for another, and the 2nd is a substitution not through any > intrinsic characteristics, but because it was substituted. Many of the > HTML link type definitions don't bear up under detailed scrutiny... Only if you take the most broadest sense of the word 'substitute'. This is like saying that not only is olive oil a substitute for butter in cooking, but so is engine oil, concrete, a 400 pound gorilla, and the square root of the gross national product of madagascar. No, I suspect they used the word 'substitute' in it's more narrow sense, and they used the word 'substitute' because they didn't want to write "alternate: Designates an alternate version for the document in which the link occurs" which would be circular. e. From owner-atom-syntax@mail.imc.org Wed May 4 19:47:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27509 for ; Wed, 4 May 2005 19:47: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 j44NcUN4030076; Wed, 4 May 2005 16:38: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 j44NcUkP030075; Wed, 4 May 2005 16:38:30 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44NcSXx030068 for ; Wed, 4 May 2005 16:38:29 -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, 5 May 2005 09:38:27 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 09:38:27 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <86BDA322-BCD1-11D9-BA79-003065EA6144@geckotribe.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/5/05 5:20 AM, "Antone Roundy" wrote: > On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote: >> Again, my friend's blog feed is not an Atom version of /my/ web page; >> linking to it as "alternate" would be wrong. > > To me, this raises a red flag, suggesting that using an autodiscovery > link from your web page to your friend's feed is not what autodiscovery > is intended for. I agree. However, using a link from an archive page is common practice (very!), but is one that would confound the use of Atom Entry Documents as @rel='alternate'. e. From owner-atom-syntax@mail.imc.org Wed May 4 20:02:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28406 for ; Wed, 4 May 2005 20:02: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 j44NttC8032633; Wed, 4 May 2005 16: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 j44Ntthh032632; Wed, 4 May 2005 16:55:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44NtqmR032609 for ; Wed, 4 May 2005 16:55:55 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j44Ntjpc017138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 4 May 2005 19:55:45 -0400 (EDT) Message-ID: <42796203.9000205@atrus.org> Date: Wed, 04 May 2005 20:00:03 -0400 From: "Nikolas 'Atrus' Coukouma" 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: Re: Autodiscovery 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 5/5/05 4:38 AM, "Nikolas 'Atrus' Coukouma" wrote: > > >>Do you have some example that's more generally applicable? >> >> > >in practice, people will put a link to the feed from which this page, and >others like it, are likely to be found, into entry only pages. > >otherwise auto-discovery doesn't work unless you first navigate to the front >page of someone's blog. > >people want to be able to say "here's a link to my feed" from entry pages. > >e. > As I said "I'm not sure it's worth worrying about." My current opinion is that it's just not worth making this change at this point, if this is in fact the only concern. It applies to a large number of pages with a small number of views and those are done for usability. Even if pages only had the link on the main page, I think it would allow 95% of users to find it. Maybe this is more of a concern for blogs where the archives are a major entry point. Perhaps this is even the usual case and I'm just used to people coming in the front door. What are the chances of someone subscribing to your feed if they never even look at the front page? -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed May 4 20:39:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02189 for ; Wed, 4 May 2005 20: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 j450SWsv036767; Wed, 4 May 2005 17:28: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 j450SWrC036766; Wed, 4 May 2005 17:28:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j450SVmc036759 for ; Wed, 4 May 2005 17:28:31 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from [68.164.89.32] (helo=[10.0.1.3]) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DTUEA-0007rc-VS; Wed, 04 May 2005 20:28:31 -0400 In-Reply-To: <14be96d305050323162633186b@mail.gmail.com> References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> 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: Kevin Marks Subject: Re: rel profiles [was Autodiscovery Date: Wed, 4 May 2005 17:28:19 -0700 To: Mark Pilgrim X-Mailer: Apple Mail (2.622) X-ELNK-Trace: b7e272d7a574036deb604bd72476f039239a348a220c26090505f63dd25d5ded520c7ebf82b2a2432601a10902912494350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.32 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit We have published profiles for both license and nofollow: http://developers.technorati.com/wiki/RelLicense http://developers.technorati.com/wiki/RelNoFollow feel free to use them... On May 3, 2005, at 11:16 PM, Mark Pilgrim wrote: > > On 5/4/05, Henri Sivonen wrote >> No you don't. rel='license' and rel='nofollow' have been deployable >> without a profile. You just release running code that hard-codes >> rel='feed' and, boom, no profile needed. > > Then I'm confused as to why you can't just release running code that > hard-codes rel="alternate". You know, like people have already done. > > -- > Cheers, > -Mark > From owner-atom-syntax@mail.imc.org Wed May 4 20:42:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02434 for ; Wed, 4 May 2005 20: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 j450ap70038211; Wed, 4 May 2005 17:36: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 j450apSs038210; Wed, 4 May 2005 17:36:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j450aoMo038196 for ; Wed, 4 May 2005 17:36:50 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from [68.164.89.32] (helo=[10.0.1.3]) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DTUMD-0004h9-LC; Wed, 04 May 2005 20:36:49 -0400 In-Reply-To: <42785DBF.7060104@inkedblade.net> References: <42785DBF.7060104@inkedblade.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: pilgrim@gmail.com, Atom Syntax , Tim.Bray@Sun.COM From: Kevin Marks Subject: Re: Autodiscovery and alternate Date: Wed, 4 May 2005 17:36:48 -0700 To: fantasai X-Mailer: Apple Mail (2.622) X-ELNK-Trace: b7e272d7a574036deb604bd72476f039239a348a220c260979b966d34b3fe7d78232800ef60256cea8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.32 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit How about "alternate" be recommended for only true substitutes; a feed for comments or pictures should not be labelled "alternate", as it is not a substitute. "feed" is appealing, but does fly in the face of practice. There are existing rel values that could apply to qualify other kinds of feeds, or we could suggest new ones. eg, if it is an titles-only feed, rel="contents" would apply If you had both full-content and summary feeds available, this could be indicated in a machine readable way (I appreciate that Atom handles this properly within the format, unlike RSS, but offering both versions is something I see many sites doing). I am amazed that there was no rel="summary" defined by the w3c; this would be a useful extension to consider. http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links On May 3, 2005, at 10:29 PM, fantasai wrote: > > Arve Bersvendsen wrote: >> On Tue, 03 May 2005 18:52:59 +0200, Tim Bray wrote: >>> http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt >> >> 1) Change the attribute value for the rel from "alternate" to "feed", >> or some similar wording. A feed is not always an alternate of the >> HTML document in which it occurs. > > As I mentioned last November [1] I agree with not requiring the > 'alternate' rel value for the reasons stated in > http://fantasai.inkedblade.net/weblog/2004/linking-feeds/ > Briefly, it is an abuse of its semantics because many feed links > are not links to alternate representations of the current page. > > [1] http://www.imc.org/atom-syntax/mail-archive/msg11705.html > > ~fantasai > From owner-atom-syntax@mail.imc.org Wed May 4 20:42:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02480 for ; Wed, 4 May 2005 20:42: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 j450W0ev037243; Wed, 4 May 2005 17:32: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 j450W0iu037241; Wed, 4 May 2005 17:32: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j450VxaE037222 for ; Wed, 4 May 2005 17:31:59 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so610637wra for ; Wed, 04 May 2005 17:31:53 -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=BUpBC41U95EqAWJ9c7sUmnwz2iO0MSOSA3w38gEA6u2QCWVva7poKZIK3s5Ppmv1IlyejHHDV4LfRfwsgBq0TD0bUZ3cGAh53mjSLcuFCRI7zSGH6uA62qQ1gyq0NTv1lCyqMuEkNRSIHS/tDSU90QzSj6B4cpkyb/tWarGsWgQ= Received: by 10.54.33.57 with SMTP id g57mr653345wrg; Wed, 04 May 2005 17:31:53 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 4 May 2005 17:31:53 -0700 (PDT) Message-ID: <68fba5c5050504173154652d13@mail.gmail.com> Date: Wed, 4 May 2005 20:31:53 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Martin Duerst Subject: PaceOriginalAttribute (was: PaceDuplicateIDWithSource2) Cc: Antone Roundy , atom-syntax@imc.org, bob@wyman.us, Graham In-Reply-To: <6.0.0.20.2.20050503171556.08254cf0@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.20050503171556.08254cf0@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j450VxaE037236 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit http://www.intertwingly.net/wiki/pie/PaceOriginalAttribute On 5/3/05, Martin Duerst wrote: > > I'm not really happy with this. I found Martin's comments (copied in full below) to be accurate. So, I thought I would try another approach. Comments, suggestions, and alterations are welcome. Robert Sayre == Abstract == Preserve the original ID elsewhere, and require republishers to mint new IDs for *their entries*. == Status == Open == Rationale == Duplicate entry ids in feeds are too easy to create unintentionally, and the legitimate uses can't be verified as updates unless they come from the originating feed. == Proposal == Add an 'original' attribute to atom:source and reword as follows: {{{ If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. 4.2.11.1 The 'original' Attribute Atom entries can be republished and altered by intermediaries, but Atom feeds MUST NOT contain duplicate atom:id values. The 'original' attribute contains the entry's initial atom:id value. atom:source elements MUST have an 'original' attribute. }}} == Impacts == == Notes == ---- CategoryProposals On 5/3/05, Martin Duerst wrote: > > I'm not really happy with this. Conceptually, it seems to replace > an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs > (remember what they expand to), that doesn't make sense. > What guarantee do we have that two feeds will be different? > (yes, these days, we get feeds over http, but there are other > ways to get feeds, where things may not be that easy). > > If we don't have a solution for the malicious case, and we > think we need one, we should work on some security stuff. > > If we think that accidential ID duplication is a problem, > then let's look at how we can improve the explanation. > After that, there may still be an occasional accident, > but the spec should be worded to catch that, not to > provide a loophole. > > If we have to allow duplicate IDs, I'd rather prefer we > do it without all this feed/source/... stuff: I.e. if > you are an aggregator and can't manage to do duplicate > elimination, you can just delegate the problem to the > next place in the feeding chain. > > Regards, Martin. From owner-atom-syntax@mail.imc.org Wed May 4 20:55:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03176 for ; Wed, 4 May 2005 20:55: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 j450nL6e039869; Wed, 4 May 2005 17:49: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 j450nLIY039868; Wed, 4 May 2005 17:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j450nKGX039862 for ; Wed, 4 May 2005 17:49:20 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j450nIeB008995; Wed, 4 May 2005 20:49:18 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCC93621; Wed, 4 May 2005 20:49:17 -0400 (EDT) Message-Id: <200505050049.DCC93621@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Chris DeSalvo'" , Subject: Atom on portable wireless device (was: RE: Atom feed refresh rates) Date: Wed, 4 May 2005 20:49:14 -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.2180 Thread-Index: AcVQ2hLk5AsSlkSJRfewcgq36GL2FQAMBFyw In-Reply-To: <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Chris DeSalvo wrote: > As the author of an aggregator app for a portable wireless device I > can tell you that this is a serious problem for this class of products. You didn't list support for RFC3229+feed[1,2] as one of the things you are doing. This would help you drastically reduce the bandwidth needed when you find a feed that actually has new content. If you use RFC3229+feed to pull a feed, then you will only get the new entries in the feed -- not ones that you've copied over before. It's one step beyond If-None-Match, etc. But, the real problem with your approach is that you have apparently coded the device so that it goes out and polls large numbers of feeds. This doesn't make sense. For a portable wireless device with limited bandwidth and limited connectivity, you should be accessing feeds via an intermediary "proxy" that gathers up all your updates into a *single* feed. That feed should be served using RFC3229+feed to ensure that you only copy from it the updated entries since you last pulled from it. Of course, it would also make sense to support compression on the results. There is no more efficient mechanism for polling for feeds from the kind of device you describe. You say that you're reading about 20MB per day but you're only able to harvest 2MB of "fresh" data from it? This 1/10 harvesting yield is actually pretty normal when polling RSS/Atom feeds served without RFC3229+feed. If you used RFC3229+feed, you would find that your yield would start to approach 100% rather then the 10% you are at now. Additionally, given the efficiencies here, you would be able to increase your polling frequency almost arbitrarily without significantly increasing the bandwidth consumption of your system. Thus, you could cut latency below the average of 30 minutes which is implied by a polling frequency of 1 hour. You've written on your blog that you want to see more "304" responses. Well, I would suggest that what you *really* should want is more "226" responses -- 226 is the success code for an RFC3229+feed GET operation. bob wyman [1] http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html [2] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html ==== Original Message ====== In my app I've implemented every trick in the book to try and reduce the amount of data that I have to pull through the radio and parse. I use If-None-Match and If-Changed-Since headers in my requests, I support compression, I respect caching hints from the servers. It doesn't help in all cases. I have 112 loaded up in my aggregator and only 74 of the servers hosting those feeds ever return a 304. The rest give me a 200 and gladly hand me everything regardless of whether it has changed or not. 17 of the servers don't bother supplying an ETag header. My feed list amounts to about 20 MB of data per day when polling once per hour. That is a lot of air time for a small radio, and a lot time spent grinding in an XML parser for a small CPU. This is especially upsetting because by my measurements only about 2 MB of data is fresh for any given day. The main hit is in battery life - the above stats can trivially knock HOURS off of the life of a small battery. I've written extensively about this problem here: with a real-world example studied here: So, I guess I'd like to see an optional update-frequency hint element. Thanks, Chris From owner-atom-syntax@mail.imc.org Wed May 4 21:32:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06492 for ; Wed, 4 May 2005 21:32: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 j451KmrI045301; Wed, 4 May 2005 18:20: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 j451KmV6045300; Wed, 4 May 2005 18:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j451KlWQ045292 for ; Wed, 4 May 2005 18:20:47 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j451KkeD021015 for ; Wed, 4 May 2005 21:20:46 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCD00084; Wed, 4 May 2005 21:20:45 -0400 (EDT) Message-Id: <200505050120.DCD00084@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs Date: Wed, 4 May 2005 21:20:43 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0266_01C550EF.21554790" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVREKfIiFAO/pX7QJGj/JixxHjTeA== 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_0266_01C550EF.21554790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 with a comment: If this Pace is accepted (and I hope it will be) the issue of Duplicate IDs should probably be dealt with in Mark's Implementation Guide.[1] Atom supports the publishing of "newer versions" of an entry which use the same atom:id as earlier versions of the same entry. It is not required that atom:updated be modified when a newer version is written. If the PaceAllowDuplicateIDs is accepted, it will be permitted to have multiple entries with the same atom:id in a single feed. However, the Pace language says processors "SHOULD" regard as feed generation errors any entries which duplicate both the atom:id and atom:updated of another entry in the same feed. Thus, feed authors who wish to publish feeds with duplicate atom:ids should ensure that any entry which duplicates an entry already in the feed has a different value for atom:updated. This constraint is not a requirement of the language, but it is a clear derivative of it. Basically, you don't have to update atom:updated unless you think it makes sense OR you are publishing to a feed that already has an entry with the same atom:id as the atom:id of the entry you are currently publishing. bob wyman [1] http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html ------=_NextPart_000_0266_01C550EF.21554790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 with a comment:

 

If this Pace is accepted (and I hope it will be) the issue of Duplicate IDs = should probably be dealt with in Mark’s Implementation Guide.[1] =

 

Atom supports the publishing of "newer versions" of an entry which = use the same atom:id as earlier versions of the same entry. It is not required = that atom:updated be modified when a newer version is written. =

If the PaceAllowDuplicateIDs is accepted, it will be permitted to have multiple entries with the same atom:id in a single feed. However, the Pace = language says processors “SHOULD” regard as feed generation errors any = entries which duplicate both the atom:id and atom:updated of another entry in = the same feed. Thus, feed authors who wish to publish feeds with duplicate = atom:ids should ensure that any entry which duplicates an entry already in the = feed has a different value for atom:updated. This constraint is not a requirement = of the language, but it is a clear derivative of = it.

Basically, you don’t have to update atom:updated unless you think it makes = sense OR you are publishing to a feed that already has an entry with the same = atom:id as the atom:id of the entry you are currently = publishing.

 

      bob = wyman

 

[1] http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html

 

------=_NextPart_000_0266_01C550EF.21554790-- From owner-atom-syntax@mail.imc.org Wed May 4 22:52:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13739 for ; Wed, 4 May 2005 22:52: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 j452hbOL058329; Wed, 4 May 2005 19:43: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 j452hbLZ058328; Wed, 4 May 2005 19:43:37 -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 j452hapx058322 for ; Wed, 4 May 2005 19:43:36 -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 j452hajO022799 for ; Wed, 4 May 2005 20:43:36 -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 <0IFZ00BHQWWN3B@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 May 2005 20:43:36 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFZ0005SWWH87@mail.sun.net> for atom-syntax@imc.org; Wed, 04 May 2005 20:43:35 -0600 (MDT) Date: Wed, 04 May 2005 19:44:32 -0700 From: Tim Bray Subject: Re: http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs In-reply-to: <200505050120.DCD00084@ms8.netsolmail.com> To: bob@wyman.us Cc: atom-syntax@imc.org Message-id: <1e0c695aabe61a324e07e230dbf77616@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=WINDOWS-1252; format=flowed References: <200505050120.DCD00084@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j452hbpx058323 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 4, 2005, at 6:20 PM, Bob Wyman wrote: > +1 with a comment: > > If this Pace is accepted (and I hope it will be) the issue of > Duplicate IDs should probably be dealt with in Marks Implementation > Guide.[1] Er, I had planned to refine this a bit and then announce it to the group with some explanations and some other background research I did; so how about I promise to do that later this evening; and please consider waiting for that before you all pile in, pro or contra. -Tim From owner-atom-syntax@mail.imc.org Wed May 4 23:03:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14719 for ; Wed, 4 May 2005 23:03: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 j44NerIa030375; Wed, 4 May 2005 16:40: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 j44NersQ030374; Wed, 4 May 2005 16:40:53 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Neq9Q030368 for ; Wed, 4 May 2005 16:40:52 -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, 5 May 2005 09:40:51 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 09:40:51 +1000 Subject: Re: Autodiscovery From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4279245B.4020907@inkedblade.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 5/5/05 5:36 AM, "fantasai" wrote: > - specify that UAs MAY also recognize the rel="alternate" and > type="application/atom+xml" combination as an autodiscoverable Atom > feed even if 'feed' is not among the rel values, and that UA should check that the representation returned when requesting that resource is an Atom Feed Document, and not an Atom Entry Document. e. From owner-atom-syntax@mail.imc.org Thu May 5 00:10:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21232 for ; Thu, 5 May 2005 00:10: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 j4541nqT070472; Wed, 4 May 2005 21:01: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 j4541nTm070471; Wed, 4 May 2005 21:01: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-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 j4541mbu070462 for ; Wed, 4 May 2005 21:01:48 -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 j4541mjO004028 for ; Wed, 4 May 2005 22:01:48 -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 <0IG000JQR0IZWE@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 May 2005 22:01:48 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG00006P0IZ8A@mail.sun.net> for atom-syntax@imc.org; Wed, 04 May 2005 22:01:47 -0600 (MDT) Date: Wed, 04 May 2005 21:02:50 -0700 From: Tim Bray Subject: PaceAllowDuplicateIDs To: Atom Syntax Message-id: <73eb986f1cca36c77bfae6708e448e52@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs This Pace was motivated by a talk I had with Bob Wyman today about the problems the synthofeed-generator community has. Summary: 1. There are multiple plausible use-cases for feeds with duplicate IDs 2. Pro and Contra 3. Alternate Paces 4. Details about this Pace 1. Use-Cases Here's a stream of stock-market quotes. My Portfolio .... MSFT 2005-05-03T10:00:00-05:00 Bid: 25.20 Ask: 25.50 Last: 25.20 MSFT 2005-05-03T11:00:00-05:00 Bid: 25.15 Ask: 25.25 Last: 25.20 MSFT 2005-05-03T12:00:00-05:00 Bid: 25.10 Ask: 25.15 Last: 25.10 You could also imagine a stream of weather readings. Bob's actual here-and-now today use-case from PubSub is earthquakes, an entry describes an earthquake and they keep re-issuing it as new info about strength/location comes in. Some people only care about the most recent version of the entry, others might want to see all of them. Basically, each atom:entry element describes the same Entry, only at a different point in time. You could argue that in some cases, these are representations of the Web resources identified by the atom:id URI, but I don't think we need to say that explicitly. Yes, you could think of alternate ways of representing stock quotes or any of the other use-cases but this is simple and direct and idiomatic. 2. Pro and Contra Given that I issued the consensus call rejecting the last attempt to do this, which was PaceRepeatIdInDocument, I felt nervous about revisiting the issue. So I went and reviewed the discussion around that one, which I extracted and placed at http://www.tbray.org/tmp/RepeatID.txt for the WG's convenience. Reviewing that discussion, I'm actually not impressed. There were a few -1's but very few actual technical arguments about why this shouldn't be done. The most common was "Software will screw this up". On reflection, I don't believe that. You have a bunch of Entries, some of them have the same ID and are distinguished by datestamp. Some software will show the latest, some will show all of them, the good software will allow switching back and forth. Doesn't seem like rocket science to me. So here's how I see it: there are plausible use cases for doing this, and one of the leading really large-scale implementors in the space (PubSub) wants to do this right now. Bob's been making strong claims about not being able to use Atom if this restriction remains in place. I believe strongly that if there's something that implementors want to do, standards shouldn't get in the way unless there's real interoperability damage. I'm certainly prepared to believe that this could cause interoperability damage, but to date I haven't seen any convincing arguments that it will. I think that if we nonetheless forbid it, people who want to do this will (a) use RSS instead of Atom, (b) cook up horrible kludges, or (c) ignore us and just do it. So my best estimate is that the cost of allowing dupes is probably much lower than the cost of forbidding them. Finally, our charter does say that we're also supposed to specify how you'd go about archiving feeds, and AllowDuplicateIDs makes this trivial. I looked around and failed to find how we claimed we were going to do that while still forbidding duplicates, but it's possible I missed that. 3. Alternate Paces I didn't want to just revive PaceRepeatIdInDocument, because it used the word "version" in what I thought was kind of a sloppy way, and because it wasn't current against format-08. I don't like either PaceDuplicateIDWithSource or ...WithSource2, they are complicated and don't really meet PubSub's needs anyhow. So I'm strongly -1 on both of those. Yes, that means that if this Pace fails, we'll allow no duplicates at all. I prefer either "dupes OK" or "no dupes" to "dupes OK in the following circumstances"; cleaner. 4. Details Section 4.1.2 of format-08 says that atom:entry "represents an individual entry". The Pace says that if you have dupes, they "represent the same entry", which I think is consistent with both the letter and spirit of 4.1.2. The Pace discourages duplicate timestamps without resorting to MUST language, because accidents can happen; this allows software to throw such entries on the floor while positively encouraging noisy complaining. On the other hand, if the WG wanted either to insist on a MUST here or remove the discouragement altogether I could live with that. Finally, it makes it clear that if there are entries with duplicate atom:id, software is free to display all or a subset, and calls out the likely common case where you discard all but the most recent. If I were Brent Simmons or equivalent, I'd be coding up a button where you can arrange to show them all or just one. From owner-atom-syntax@mail.imc.org Thu May 5 01:18:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26469 for ; Thu, 5 May 2005 01:18: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 j4554ALZ082015; Wed, 4 May 2005 22: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 j4554AQE082014; Wed, 4 May 2005 22:04:10 -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 j45549hk082005 for ; Wed, 4 May 2005 22:04:09 -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 j45549jO008119 for ; Wed, 4 May 2005 23:04:09 -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 <0IG000BOL3EWIA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 04 May 2005 23:04:09 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG0000C63EW8A@mail.sun.net> for atom-syntax@imc.org; Wed, 04 May 2005 23:04:08 -0600 (MDT) Date: Wed, 04 May 2005 22:05:10 -0700 From: Tim Bray Subject: Re: PaceAllowDuplicateIDs In-reply-to: <73eb986f1cca36c77bfae6708e448e52@sun.com> To: Tim Bray Cc: Atom Syntax Message-id: <7c85515f06bb74f69ef454d1ab869ebd@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 4, 2005, at 9:02 PM, Tim Bray wrote: > Here's a stream of stock-market quotes. [snicker] I left the ID's out of the entries in the example. Imagine that each one has urn:uuid:1335c695-cfb8-4ebb-aaaa-80da344efa6a -Tim From owner-atom-syntax@mail.imc.org Thu May 5 03:12:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26753 for ; Thu, 5 May 2005 03: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 j4571rVa041186; Thu, 5 May 2005 00:01: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 j4571rBr041185; Thu, 5 May 2005 00:01: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 j4571qRh041166 for ; Thu, 5 May 2005 00:01:52 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 45823 invoked by uid 17064); 5 May 2005 07:01:52 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 07:01:52 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <73eb986f1cca36c77bfae6708e448e52@sun.com> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D52F3DC-3935-4759-9E6E-28A5C982CF8E@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 09:01:48 +0200 To: Tim Bray , Atom Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tonight something incredible happened to me. You won't believe it. I was walking back from the pubs when I got snapped by a passing space ships full of hyper advanced aliens. They did various experiments on me, and cloned me 1000 times. It is terrible. I just don't know what to do. I suppose that I means am +1000 on this now. :-) That's consensus, I am sure. Henry http://bblfish.net/blog/ On 5 May 2005, at 06:02, Tim Bray wrote: > > > http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs > > This Pace was motivated by a talk I had with Bob Wyman today about > the problems the synthofeed-generator community has. > > Summary: > 1. There are multiple plausible use-cases for feeds with duplicate IDs > 2. Pro and Contra > 3. Alternate Paces > 4. Details about this Pace > > 1. Use-Cases > > Here's a stream of stock-market quotes. > > My Portfolio > .... > MSFT > 2005-05-03T10:00:00-05:00 > Bid: 25.20 Ask: 25.50 Last: 25.20 > > MSFT > 2005-05-03T11:00:00-05:00 > Bid: 25.15 Ask: 25.25 Last: 25.20 > > MSFT > 2005-05-03T12:00:00-05:00 > Bid: 25.10 Ask: 25.15 Last: 25.10 > > > > You could also imagine a stream of weather readings. Bob's actual > here-and-now today use-case from PubSub is earthquakes, an entry > describes an earthquake and they keep re-issuing it as new info > about strength/location comes in. > > Some people only care about the most recent version of the entry, > others might want to see all of them. Basically, each atom:entry > element describes the same Entry, only at a different point in time. > > You could argue that in some cases, these are representations of > the Web resources identified by the atom:id URI, but I don't think > we need to say that explicitly. > > Yes, you could think of alternate ways of representing stock quotes > or any of the other use-cases but this is simple and direct and > idiomatic. > > 2. Pro and Contra > > Given that I issued the consensus call rejecting the last attempt > to do this, which was PaceRepeatIdInDocument, I felt nervous about > revisiting the issue. So I went and reviewed the discussion around > that one, which I extracted and placed at http://www.tbray.org/tmp/ > RepeatID.txt for the WG's convenience. > > Reviewing that discussion, I'm actually not impressed. There were > a few -1's but very few actual technical arguments about why this > shouldn't be done. The most common was "Software will screw this > up". On reflection, I don't believe that. You have a bunch of > Entries, some of them have the same ID and are distinguished by > datestamp. Some software will show the latest, some will show all > of them, the good software will allow switching back and forth. > Doesn't seem like rocket science to me. > > So here's how I see it: there are plausible use cases for doing > this, and one of the leading really large-scale implementors in the > space (PubSub) wants to do this right now. Bob's been making > strong claims about not being able to use Atom if this restriction > remains in place. > > I believe strongly that if there's something that implementors want > to do, standards shouldn't get in the way unless there's real > interoperability damage. I'm certainly prepared to believe that > this could cause interoperability damage, but to date I haven't > seen any convincing arguments that it will. I think that if we > nonetheless forbid it, people who want to do this will (a) use RSS > instead of Atom, (b) cook up horrible kludges, or (c) ignore us and > just do it. > > So my best estimate is that the cost of allowing dupes is probably > much lower than the cost of forbidding them. > > Finally, our charter does say that we're also supposed to specify > how you'd go about archiving feeds, and AllowDuplicateIDs makes > this trivial. I looked around and failed to find how we claimed we > were going to do that while still forbidding duplicates, but it's > possible I missed that. > > 3. Alternate Paces > > I didn't want to just revive PaceRepeatIdInDocument, because it > used the word "version" in what I thought was kind of a sloppy way, > and because it wasn't current against format-08. I don't like > either PaceDuplicateIDWithSource or ...WithSource2, they are > complicated and don't really meet PubSub's needs anyhow. So I'm > strongly -1 on both of those. Yes, that means that if this Pace > fails, we'll allow no duplicates at all. I prefer either "dupes > OK" or "no dupes" to "dupes OK in the following circumstances"; > cleaner. > > 4. Details > > Section 4.1.2 of format-08 says that atom:entry "represents an > individual entry". The Pace says that if you have dupes, they > "represent the same entry", which I think is consistent with both > the letter and spirit of 4.1.2. > > The Pace discourages duplicate timestamps without resorting to MUST > language, because accidents can happen; this allows software to > throw such entries on the floor while positively encouraging noisy > complaining. On the other hand, if the WG wanted either to insist > on a MUST here or remove the discouragement altogether I could live > with that. > > Finally, it makes it clear that if there are entries with duplicate > atom:id, software is free to display all or a subset, and calls out > the likely common case where you discard all but the most recent. > If I were Brent Simmons or equivalent, I'd be coding up a button > where you can arrange to show them all or just one. > > > From owner-atom-syntax@mail.imc.org Thu May 5 03:14:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26873 for ; Thu, 5 May 2005 03:14: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 j4577tsH044013; Thu, 5 May 2005 00:07: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 j4577tfD044012; Thu, 5 May 2005 00:07:55 -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 j4577sQN043997 for ; Thu, 5 May 2005 00:07:54 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:56949 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228802AbVEEHHw (ORCPT ); Thu, 5 May 2005 10:07:52 +0300 In-Reply-To: References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <861f046bc09da6da20b887638461a8b5@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom-syntax , Mark Pilgrim From: Henri Sivonen Subject: Re: rel profiles [was Autodiscovery Date: Thu, 5 May 2005 10:06:59 +0300 To: Kevin Marks 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 May 5, 2005, at 03:28, Kevin Marks wrote: > We have published profiles for both license and nofollow: > http://developers.technorati.com/wiki/RelLicense > http://developers.technorati.com/wiki/RelNoFollow > > feel free to use them... What value do they add compared to profileless usage? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Thu May 5 03:26:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27951 for ; Thu, 5 May 2005 03:26: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 j457FJYh047311; Thu, 5 May 2005 00:15: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 j457FJ0e047309; Thu, 5 May 2005 00:15:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457FIsi047263 for ; Thu, 5 May 2005 00:15:18 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050505071512.EUFD2412.mta09-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com> for ; Thu, 5 May 2005 08:15:12 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050505071512.FDXG1844.aamta08-winn.mailhost.ntl.com@AndyHenderson3> for ; Thu, 5 May 2005 08:15:12 +0100 From: "Andy Henderson" To: "'Atom Syntax'" Subject: RE: Atom feed refresh rates Date: Thu, 5 May 2005 08:15:10 +0100 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: <542b5aa53d6d24bc092e8f92d7e12069@sun.com> Thread-Index: AcVQyfR2m0ubU2nFTNSNFFqWBoiCDAAeBAqA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050505071512.FDXG1844.aamta08-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>Actually, as I recall, last time this came up (proposed by Walter >>>Underwood), someone pointed out accurately that RSS2 has had this >>>functionality for a long time and that nobody ever really implemented >>>it; thus there was a strong vote from experience against such a >>>feature. -Tim<<< There is no RSS2 feature I can see that allows feed providers to tell aggregators the minimum refresh period. There's the ttl tag. That was, I believe, introduced for a different purpose and determines the Maximum time a feed should be cached in a certain situation. The tag's usage has morphed over time and, if more than 60 minutes, I assume it's a Minimum time; but it's not surprising if feed providers are wary of using the tag in this way. What has yet to be tried is a specific tag in the core feed standard that promotes and determines good behaviour for aggregators refreshing their feeds. Even if it were to prove only a limited benefit, it would still be a benefit. Andy From owner-atom-syntax@mail.imc.org Thu May 5 03:33:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28342 for ; Thu, 5 May 2005 03:33: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 j457PH1k051707; Thu, 5 May 2005 00:25: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 j457PHr7051706; Thu, 5 May 2005 00:25:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457PGHw051654 for ; Thu, 5 May 2005 00:25:16 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050505072510.PSYC21532.mta08-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com> for ; Thu, 5 May 2005 08:25:10 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050505072510.OQCP1289.aamta02-winn.mailhost.ntl.com@AndyHenderson3> for ; Thu, 5 May 2005 08:25:10 +0100 From: "Andy Henderson" To: Subject: RE: Atom feed refresh rates Date: Thu, 5 May 2005 08:25:09 +0100 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: <4278BC78.3050503@gmx.de> Thread-Index: AcVQ4/SDs9XSRZ05TdqROqVAgHobJwAX2VwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050505072510.OQCP1289.aamta02-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>You can do that with the "Expires" response header. Everytime the resource is requestef, serve it with a value of "now + minimumrefreshinterval".<<< Ah. I see what you mean. Thank you. The problem is that when you say "You can do that now with the "Expires" response header" - I can't. It's a theoretical capability I have, but not a practical one. I am directly responsible for three feeds. One is a feed associated with my aggregator. It's a simple xml file stored on a shared server along with the rest of my web site. I have no access to any HTML headers. When aggregators access my feed, no code of mine runs - the transaction is handled by the server alone. The other two are feeds generated on the fly from a back-end database; again they are running on a shared server and, again, my development tool (IBM's Domino) gives me no access to set the Expires header. I just used Microsoft's Fiddler tool to check all the feeds I subscribe to (not a scientific sample, I admit, but it's a pretty broad mix and includes blog sites and blogging tools) and just two provide Expires headers. One is the BBC, the other is Wired. Both set Expires to expire immediately. I'm guessing they have good reason to do that. I re-subscribed to Slashdot (which has implemented draconian bandwidth throttling measures) and it doesn't use Expires headers. So, Expires is a measure that I could use in theory but is not available to me either directly or, apparently, via third party blogging sites/tools. When I look at best practice, I find Expires is either not used or is used in a different way. Both from a provider viewpoint and from an aggregator viewpoint, Expires does not seem a practical option. Andy From owner-atom-syntax@mail.imc.org Thu May 5 03:34:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28468 for ; Thu, 5 May 2005 03:34: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 j457RXoQ052849; Thu, 5 May 2005 00:27: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 j457RXiZ052848; Thu, 5 May 2005 00:27:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457RWAA052836 for ; Thu, 5 May 2005 00:27:32 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from eetemad.student.princeton.edu ([140.180.146.72]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTala-0001IE-GY; Thu, 05 May 2005 03:27:26 -0400 Message-ID: <4279CAD8.5030301@inkedblade.net> Date: Thu, 05 May 2005 03:27:20 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , pilgrim@gmail.com, Tim.Bray@Sun.COM Subject: Re: Autodiscovery, real-world examples References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> <42795178.1080401@atrus.org> In-Reply-To: <42795178.1080401@atrus.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas 'Atrus' Coukouma wrote: > fantasai wrote: > > I think you've missed how things are working at the moment. Most > programs implemented what's in the spec before it's written. Mark is > trying to negotiate a common standard when implementations already > exist. A lot of experimentation has already occurred. I'm not suggesting that the spec invalidate such well-entrenched practice, but that it allows an alternative (not requiring 'alternate') for situations in which it is not appropriate. > One of the key points seems to be that autodiscovery is not meant to > find all feeds linked to on a page, just the ones that serve as > alternates to the current one. If people wanted this functionality, they > would have done it by now. Done what? Linked to non-alternate feeds with rel="alternate" just so that it would trigger autodiscovery? People do that all the time. Give them an alternative that doesn't require such a hack. > I think you have three separate cases of autodiscovery: > * the feed for *this* page - handled by this autodiscovery proposal > * other feeds the author reads or recommends - usually done by linking > to a separate file. Some quick searching reveals one suggestion to use > rel="blogroll" for this > * any other feeds linked to for any reason at all - seems to be little > interest in > > I don't think combining these three into one case will do any good. In > fact, I think it's confusing and unusable. That makes sense. I think that you're missing one key use case, though: autodiscovery of a blog's main feed from sub-parts of it. A lot of websites link to the main blog feed from individual entries, for example, and they're doing it with rel="alternate", which is not appropriate. It frustrates me that there is no way of changing these links to not use rel="alternate". And for linking to other pages.. Here's a real-world example: The mozilla.org main page is an example of where rel="alternate" is a problem. There were three feeds on it: "Announcements", "mozillaZine News", and "Mozilla Weblogs" (now only two). Each one is an alternate of a web page, but of _other_ pages (http://www.mozilla.org/news.html, http://www.mozillazine.org/, and http://planet.mozilla.org/ respectively), not the mozilla.org front page. The last few headlines for each feed are listed on the front page, and the designer felt it was appropriate for autodiscovery to work on this page -- but it is not appropriate for rel="alternate" to be used for those autodiscovery links. They are not alternate representations of the front page. Here's another example: LiveJournal creates a "Friends" page, where it aggregates the blogs of all the users you've designated as "friends". It could create an Atom feed representing this aggregation, and mark that as rel="alternate". What could also be useful, however, would be linking to each of these blogs' feeds individually as well so that they're represented individually in my aggregator and it can aggregate them itself. Unlike the pre-aggregated feed, however, these are not alternate representations of the Friends page, and shouldn't be marked as such. Making it possible for pages to link to non-alternate autodiscoverable feeds without using rel="alternate" -- and encouraging this practice -- would make it possible for UAs to actually /discriminate/ between alternate and non-alternate feeds. Right now they can't, because everything is indiscriminately marked as "alternate". ~fantasai From owner-atom-syntax@mail.imc.org Thu May 5 05:01:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04575 for ; Thu, 5 May 2005 05:01: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 j458rQf9087558; Thu, 5 May 2005 01:53: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 j458rQnX087556; Thu, 5 May 2005 01:53:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j458rPg4087515 for ; Thu, 5 May 2005 01:53:25 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j458qnZ2011362; Thu, 5 May 2005 09:52:54 +0100 (BST) In-Reply-To: <73eb986f1cca36c77bfae6708e448e52@sun.com> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 09:52:46 +0100 To: Tim Bray X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 5:02 am, Tim Bray wrote: > My Portfolio > .... > MSFT > 2005-05-03T10:00:00-05:00 > Bid: 25.20 Ask: 25.50 Last: 25.20 > > MSFT > 2005-05-03T11:00:00-05:00 > Bid: 25.15 Ask: 25.25 Last: 25.20 > > MSFT > 2005-05-03T12:00:00-05:00 > Bid: 25.10 Ask: 25.15 Last: 25.10 > > Tim, model this as a blog first. Is it: a) One entry that's being updated? b) Hourly new postings with the latest price? See, I think it's b). Which under any sensible circumstance would count as new entries, and therefoe get new ids. You're trying to use atom:id as a category system here. Let's say I post a new picture of my cat every day. Should all my blog entries have the same id? Technical problems: The problem multiple ids is that we don't have a date element that provides a definitive answer to the question, "What is the current version?", which 99% of the time is all an aggregator needs. For example, what happens if I retract an update to an entry, and presumably roll back atom:updated? The new version stays? If so, the spec of atom:updated needs changing. I see you have the constraint "Their atom:updated timestamps SHOULD be different, and processing software SHOULD regard entries with duplicate atom:id and atom:updated values as evidence of an error in the feed generation". Does this apply temporally as well as spatially? For example, if the content changes the second time I load something, but the atom:updated doesn't, is that an error? Again, atom:updated falls short for this purpose. Finally, at pubsub, what happens when they download an entry from one feed, then the user edits it, but doesn't modify atom:updated, then they download the new entry from a second feed associated with the site. Different content, identical atom:ids, identical atom:updated => Invalid feed. They're not in any better position than they were before. This doesn't even solve the problem it's meant to. "If an Atom Feed Document contains multiple entries with the same atom:id, software MAY choose to display all of them or some subset of them" What does this even mean, other than "atom:id is meaningless, ignore it"? > I looked around and failed to find how we claimed we were going to > do that while still forbidding duplicates, but it's possible I > missed that. Duplicate ids is a constraint of the atom:feed element. Use a different top level element, atom:archive, for archives. Graham From owner-atom-syntax@mail.imc.org Thu May 5 05:07:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04813 for ; Thu, 5 May 2005 05:07: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 j458wqRu089703; Thu, 5 May 2005 01:58: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 j458wqNG089702; Thu, 5 May 2005 01:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j458wmHm089651 for ; Thu, 5 May 2005 01:58:51 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j458uDPU013507; Thu, 5 May 2005 09:56:13 +0100 (BST) In-Reply-To: <200505050120.DCD00084@ms8.netsolmail.com> References: <200505050120.DCD00084@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <01E9F5D4-6530-4655-BA02-A8A357E1A3A6@mac.com> Cc: atom-syntax From: Graham Subject: Re: http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs Date: Thu, 5 May 2005 09:56:11 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j458wpHm089695 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5 May 2005, at 2:20 am, Bob Wyman wrote: > Basically, you dont have to update atom:updated unless you think > it makes sense OR you are publishing to a feed that already has an > entry with the same atom:id as the atom:id of the entry you are > currently publishing. Or someone downstream is publishing one, of course. Which means you must always change atom:updated, just in case. No harm done, Tim. None at all. Graham From owner-atom-syntax@mail.imc.org Thu May 5 05:57:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07993 for ; Thu, 5 May 2005 05:57: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 j459oHao010888; Thu, 5 May 2005 02:50: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 j459oHeS010887; Thu, 5 May 2005 02:50: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j459oGGJ010836 for ; Thu, 5 May 2005 02:50:16 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 May 2005 09:50:04 -0000 Received: from p508FF16A.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.241.106] by mail.gmx.net (mp029) with SMTP; 05 May 2005 11:50:04 +0200 X-Authenticated: #1915285 Message-ID: <4279EC3B.1080007@gmx.de> Date: Thu, 05 May 2005 11:49:47 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Henderson CC: atom-syntax@imc.org Subject: Re: Atom feed refresh rates References: <20050505072510.OQCP1289.aamta02-winn.mailhost.ntl.com@AndyHenderson3> In-Reply-To: <20050505072510.OQCP1289.aamta02-winn.mailhost.ntl.com@AndyHenderson3> 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 Andy Henderson wrote: >>>>You can do that with the "Expires" response header. Everytime the > > resource is requestef, serve it with a value of "now + > minimumrefreshinterval".<<< > > Ah. I see what you mean. Thank you. > > The problem is that when you say "You can do that now with the "Expires" > response header" - I can't. It's a theoretical capability I have, but not a > practical one. > > I am directly responsible for three feeds. One is a feed associated with my > aggregator. It's a simple xml file stored on a shared server along with the > rest of my web site. I have no access to any HTML headers. When > aggregators access my feed, no code of mine runs - the transaction is > handled by the server alone. The other two are feeds generated on the fly > from a back-end database; again they are running on a shared server and, > again, my development tool (IBM's Domino) gives me no access to set the > Expires header. > > I just used Microsoft's Fiddler tool to check all the feeds I subscribe to > (not a scientific sample, I admit, but it's a pretty broad mix and includes > blog sites and blogging tools) and just two provide Expires headers. One is > the BBC, the other is Wired. Both set Expires to expire immediately. I'm > guessing they have good reason to do that. I re-subscribed to Slashdot > (which has implemented draconian bandwidth throttling measures) and it > doesn't use Expires headers. > > So, Expires is a measure that I could use in theory but is not available to > me either directly or, apparently, via third party blogging sites/tools. > When I look at best practice, I find Expires is either not used or is used > in a different way. > > Both from a provider viewpoint and from an aggregator viewpoint, Expires > does not seem a practical option. Well, we're designing a feed format here. When this feed is served through HTTP, (re-)using the caching features of HTTP will ensure that any standard HTTP client will take advantage of it. For instance, if you use an HTTP client component that maintains it's own cache, it will automatically do the right thing. Also, when you're accessing the feed through an HTTP proxy, you will get copies from the proxy's cache when available. I just checked and Apache allows you to set the "Expires" header through "mod_expires" (). Lotus Domino seems to do it though a thing called "Web Site Rule" (). I'm sure you can do it with other packages as well. On the other hand, of the feeds you checked, how many did actually implement the corresponding RSS feature ()? If you can demonstrate that lots of feeds use thos feature, and that aggregators indeed pay attention to it, you may be able to convince the WG that Atom needs this to achive feature parity. Best regards, Julian From owner-atom-syntax@mail.imc.org Thu May 5 06:44:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11543 for ; Thu, 5 May 2005 06:44: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 j45Aaeo2030887; Thu, 5 May 2005 03:36: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 j45Aaehe030886; Thu, 5 May 2005 03:36:40 -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 j45Aadbm030876 for ; Thu, 5 May 2005 03:36:39 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 45374 invoked by uid 17064); 5 May 2005 10:36:38 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 10:36:38 -0000 In-Reply-To: References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Tim Bray , atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 12:36:33 +0200 To: Graham X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I hope it won't be thought rude for me to answer your questions to Tim. On 5 May 2005, at 10:52, Graham wrote: > On 5 May 2005, at 5:02 am, Tim Bray wrote: [I have added the id's tim mentioned he forgot] > My Portfolio > .... > > MSFT > urn:uuid:1335c695-cfb8-4ebb-aaaa-80da344efa6a > 2005-05-03T10:00:00-05:00 > Bid: 25.20 Ask: 25.50 Last: 25.20 > > > MSFT > urn:uuid:1335c695-cfb8-4ebb-aaaa-80da344efa6a > 2005-05-03T11:00:00-05:00 > Bid: 25.15 Ask: 25.25 Last: 25.20 > > > MSFT > urn:uuid:1335c695-cfb8-4ebb-aaaa-80da344efa6a > 2005-05-03T12:00:00-05:00 > Bid: 25.10 Ask: 25.15 Last: 25.10 > > So with these additions lets look at your question: > Tim, model this as a blog first. Is it: > a) One entry that's being updated? > b) Hourly new postings with the latest price? Given that the ids are the same it is now clear that we have situation a) > See, I think it's b). Which under any sensible circumstance would > count as new entries, and therefoe get new ids. You're trying to > use atom:id as a category system here. No, this is just the way resources on the internet work. If you go to you will get a different web page every day. A resource can have different representation at different times. Google could of course architecture its web site differently and have be simply a redirect to a dated resource that would be unchanging. Both work. > Let's say I post a new picture of my cat every day. Should all my > blog entries have the same id? If all your cat blog entries had the same id, and you posted a new picture of your cat every day, then you should expect that some aggregators or clients might dump all but the latest version of your entry. So it depends on what you want. If you want a feed of how your cat changed, and you want to make sure that people will be able to see all the changes to your cat, then you would have a different entry for each of the cat states, and each of these would have their own "alternate" link. If you want an entry about what you think of your cat today, or what your cat looks like today, then you would have one entry with the same id changing on a daily basis. Aggregators could choose to keep the older versions, or they could choose to discard them. > Technical problems: > The problem multiple ids is that we don't have a date element that > provides a definitive answer to the question, "What is the current > version?", which 99% of the time is all an aggregator needs. You can never know about any resource on the net what the "current version" is. This is due to limits such as the speed of light, the speed at which data can travel through the pipes across the world, etc... But it does not matter. All you may be interested in at any point in time is what is the latest version that *you* have available. You can't do better than that. So if you get a feed with two entries with the same id, you just look at the time stamp and keep the latest. If you find the same id in another trusted feed, you make the same comparison. > For example, what happens if I retract an update to an entry, and > presumably roll back atom:updated? The new version stays? If so, > the spec of atom:updated needs changing. There are two situations here: A. You remove the later entry representation that you placed in your feed. You can do this, but it won't stop people who have already retrieved your feed from having received the old representation of the feed, with the non retracted entry. Remember that the internet has a memory, both long term [1] and short term. For example all the caches in the world that this representation may have travelled through may also contain that representation. The more intelligent caches (such as the one in an aggregator) may on later retrieving your altered feed and comparing the entry therein with the one they have in memory, decide to keep the one they have in memory, since that is a later version of your entry. B. You make clear that your retraction is an event, and so you add a new entry with that id (you may, but need not, remove the old entry representation (the ....)) and with a new time stamp, but with the old content. I suggest that B. would be the more honest and less confusing option to the readers of your feed. > I see you have the constraint "Their atom:updated timestamps SHOULD > be different, and processing software SHOULD regard entries with > duplicate atom:id and atom:updated values as evidence of an error > in the feed generation". Does this apply temporally as well as > spatially? For example, if the content changes the second time I > load something, but the atom:updated doesn't, is that an error? As I see, Tim's language is currently restricted to what happens with two entries with the same id in the same feed document. What happens across feed documents is not defined here. I myself think that having entries with different contents with the same id across feeds, would be confusing to receiving software and would be close to being an error. Ie. if you do that then you should not be surprised if your clients behave erratically, either ignoring the second version, or flagging an error, or keeping the second entry over the first. But then this would be the case for any similar situation. Imagine that your bank publishes xml of the history of your accounts, and changes the content for a particular month, without notifying you that anything has changed. I think this would be a cause for concern, and would justify you looking into it. In any case this is something we may or may not define. It is not a problem with PaceAllowDuplicateIDs. In fact you have just uncovered something that was problematic before. > > Again, atom:updated falls short for this purpose. No. You have just shown that if you make consequential changes to an entry and don't change your atom:updated field, you will end up with interoperability issues. > Finally, at pubsub, what happens when they download an entry from > one feed, then the user edits it, but doesn't modify atom:updated, Either the change they made is "significant" or it is not. If it is a significant change then by not changing the atom:updated field the user will have done something other than what he thought he was doing. For by not changing the date he is allowing receiving software to decide by themselves whether they wish to keep or drop the change. If it is not a significant change, then the receiving software won't be doing anything problematic by either dropping the later version received or keeping it. > then they download the new entry from a second feed associated with > the site. Different content, identical atom:ids, identical > atom:updated => Invalid feed. They're not in any better position > than they were before. This doesn't even solve the problem it's > meant to. > > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MAY choose to display all of them or some subset > of them" > > What does this even mean, other than "atom:id is meaningless, > ignore it"? If you try out the latest version of BlogEd you can see for yourself. Though BlogEd is a blog editor it keeps all the changes you make to your entry in its database allowing you to visit previous versions. It still in beta and buggy, but that aspect of the functionality works well. Instructions for installing with jnlp are available here: http://blogs.sun.com/bblfish So that would be one way to view the previous version of an entry. There will be many others. Many readers will be happy to drop the older versions, but many will be happy to keep them. > >> I looked around and failed to find how we claimed we were going to >> do that while still forbidding duplicates, but it's possible I >> missed that. >> > > Duplicate ids is a constraint of the atom:feed element. Use a > different top level element, atom:archive, for archives. Well that seems like a very complicated way of solving a problem where allowing entries with duplicate ids in a feed document from the start would be much simpler. If you are going to allow feeds to keep duplicates then why not just allow and be done with it? Henry Story http://bblfish.net/blog/ [1] http://bblfish.net/blog/page5.html#44 From owner-atom-syntax@mail.imc.org Thu May 5 07:27:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14700 for ; Thu, 5 May 2005 07: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 j45BHDnj049046; Thu, 5 May 2005 04:17: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 j45BHDeo049045; Thu, 5 May 2005 04:17:13 -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 j45BH8Cg048981 for ; Thu, 5 May 2005 04:17:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j45BHL6Z028167 for ; Thu, 5 May 2005 07:17:22 -0400 Message-ID: <427A00AC.5020007@intertwingly.net> Date: Thu, 05 May 2005 07:17:00 -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: AtomPubIssuesList for 2005/05/05 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> In-Reply-To: <421B5057.2020603@intertwingly.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 *************************** REMINDER ****************************** ** Use more specific subject lines when responding to this note! ** *************************** REMINDER ****************************** First the meat... here's the new atom pub issues list, conveniently sorted into categories: EntryId: http://intertwingly.net/wiki/pie/PaceAllowDuplicateIDs http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource http://intertwingly.net/wiki/pie/PaceExplainDuplicateIds FeedId: http://intertwingly.net/wiki/pie/PaceFeedIdOrAlternate http://intertwingly.net/wiki/pie/PaceFeedIdOrSelf http://intertwingly.net/wiki/pie/PaceOptionalFeedLink Provenance: http://intertwingly.net/wiki/pie/PaceOriginalAttribute http://intertwingly.net/wiki/pie/PaceSourceRecs Status: http://intertwingly.net/wiki/pie/PaceEntryState http://intertwingly.net/wiki/pie/PacePubControl http://intertwingly.net/wiki/pie/PacePubStatusResource Text: http://intertwingly.net/wiki/pie/PaceBriefExample http://intertwingly.net/wiki/pie/PaceCoConstraintsAreBad http://intertwingly.net/wiki/pie/PaceOptionalSummary http://intertwingly.net/wiki/pie/PaceRecommendPlainTextContent http://intertwingly.net/wiki/pie/PaceTextShouldBeProvided Recommended for Closure: http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly http://intertwingly.net/wiki/pie/PaceXmlContentWrapper Now for some administrivia. No progress was made on the last published issued list[1], so I've gone ahead and marked those issues that were recommended for closure, closed; and those currently under discussion were moved back to Needing to Revisit. Next, I'd like to remind everybody that last call for the Atom Format went out. Operationally, what this means is that the secretary and co-chairs are going to be increasingly reluctant to revisit things simply because somebody wants to bring them up again. What that means is that in order to successfully bring up an issue, you need to do a little homework. Demonstrate that you have revisited the previous discussion, and that you either have something new to add, or can point out some evidence that the previous consensus call was made in error. Tim has taken the opportunity to lead by example on this one with PaceAllowDuplicateIDs. The secretary and co-chairs all are in agreement that the XhtmlDiv related paces don't meet this criteria. If anyone disagrees, what we would like to ask is that you follow Tim's lead. Because we are in last call, I've scheduled everything related to the Format document. As one of the status paces touches on the format, I've scheduled all three. All we need to resolve now is the extent to which this is going to affect the format document. I believe that PaceBriefExample is truly editorial, meaning that the editors can act on this at their discretion. - Sam Ruby [1] http://www.imc.org/atom-syntax/mail-archive/msg13691.html From owner-atom-syntax@mail.imc.org Thu May 5 07:40:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15516 for ; Thu, 5 May 2005 07:40: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 j45BXjvp056418; Thu, 5 May 2005 04:33: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 j45BXjsC056416; Thu, 5 May 2005 04:33:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45BXilm056374 for ; Thu, 5 May 2005 04:33:45 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45BWpVx020012; Thu, 5 May 2005 12:32:56 +0100 (BST) In-Reply-To: References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <821BF7D1-F12B-4B14-9E44-3E1CCED36EE9@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 12:32:45 +0100 To: Henry Story X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 11:36 am, Henry Story wrote: >> Tim, model this as a blog first. Is it: >> a) One entry that's being updated? >> b) Hourly new postings with the latest price? >> > > Given that the ids are the same it is now clear that we have > situation a) I said "first", before we decide what ids we should use. If created as a blog, Tim's stock quotes would make most sense (to me) posted as hourly new entries. Ergo, they should each have different ids. Again, atom:id is not a category system. > Either the change they made is "significant" or it is not. If it is > a significant change then > by not changing the atom:updated field the user will have done > something other than what he thought > he was doing. For by not changing the date he is allowing receiving > software to decide by themselves > whether they wish to keep or drop the change. If it is not a > significant change, then the receiving > software won't be doing anything problematic by either dropping the > later version received or keeping it. atom:updated is used by the publisher to show what they consider a significant change. The user, on the other hand, wants to see the latest version, reliably, even if the publisher disagrees that the change was significant. This is the core problem with Tim's proposal. There is no way to create an aggregator that works in the way the user expects. I am lying down in the road here, as Tim would say. > Well that seems like a very complicated way of solving a problem > where allowing entries with duplicate ids in a feed document from > the start would be much simpler. If you are going to > allow feeds to keep duplicates then why not just allow > and be done with it? Because feeds are feeds and archives are archives? They have different audiences and different uses and different requirements. Graham From owner-atom-syntax@mail.imc.org Thu May 5 09:02:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22902 for ; Thu, 5 May 2005 09:02: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 j45CsM4a092435; Thu, 5 May 2005 05: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 j45CsMri092434; Thu, 5 May 2005 05:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45CsKkc092354 for ; Thu, 5 May 2005 05:54:21 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050505125414.SZJ2412.mta09-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Thu, 5 May 2005 13:54:14 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3>; Thu, 5 May 2005 13:54:14 +0100 From: "Andy Henderson" To: "'Julian Reschke'" Cc: Subject: RE: Atom feed refresh rates Date: Thu, 5 May 2005 13:54:14 +0100 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: <4279EC3B.1080007@gmx.de> Thread-Index: AcVRW446KVdoOCgYQrKzk6lpZBYjvwACz4Gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>we're designing a feed format here. When this feed is served through HTTP, (re-)using the caching features of HTTP will ensure that any standard HTTP client will take advantage of it. For instance, if you use an HTTP client component that maintains it's own cache, it will automatically do the right thing. Also, when you're accessing the feed through an HTTP proxy, you will get copies from the proxy's cache when available.<<< Understood. My issue is that creating the headers is outside the capability of many (most?) feed providers. >>>I just checked and Apache allows you to set the "Expires" header through "mod_expires" (). <<< I'm sure you're right, but it would mean little to most feed providers (including me). >>>Lotus Domino seems to do it though a thing called "Web Site Rule" (). <<< DWA is a sub-feature of the mail client so not helpful, I'm afraid. Thanks for looking into it, though. >>>I'm sure you can do it with other packages as well.<<< If it was available at the blogging package level, I'm sure people that use those packages would use the feature. The fact few feeds seem to use the Expires header, and those that do use it to immediately expire, seems to indicate an issue (proxy caching?). >>>On the other hand, of the feeds you checked, how many did actually implement the corresponding RSS feature ()?<<< Out of 33 RSS.9/2 feeds, 16 have ttl tags. Syndic8 reports that 16,840 RSS feeds use it. It says that's 7% of the total. The actual percentage is better than that because I believe ttl is RSS2 only; it's certainly not RSS1. That's pretty high considering that ttl is flawed because it was not originally designed to communicate minimum refresh intervals. >>>If you can demonstrate that lots of feeds use thos feature, and that aggregators indeed pay attention to it, you may be able to convince the WG that Atom needs this to achive feature parity.<<< I've no way to demonstrate aggregator use except my own - even though I support a tiny community I do observe and enforce the ttl tag. I'm sure that if there were a clearly-defined tag supported by Mark's implementation document, usage would significantly improve over RSS2 ttl levels. As for convincing the WG, I would simply point out that a mechanism widely available to, and understood by, feed providers and aggregators cannot do harm and has the potential to do a great deal of good. It seems to me to be a useful opportunity to demonstrate a clear improvement over both RSS1 and RSS2. Andy From owner-atom-syntax@mail.imc.org Thu May 5 09:13:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23655 for ; Thu, 5 May 2005 09: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 j45D7Lan097860; Thu, 5 May 2005 06: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 j45D7Lhf097859; Thu, 5 May 2005 06:07: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45D7KZE097842 for ; Thu, 5 May 2005 06:07:20 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so674361wri for ; Thu, 05 May 2005 06:07:15 -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=btvAJDJRwGbEhqYXXsLXIRcFkDBNmtf4p1v2kTxG3RNLoeGPTJwLfyMbMiGIAAdNrsUjxga7epqAIBnZCNO3yJS9iY496FBCGcDxEMms1bNlYXwjZLt4Jv2cuH3R19J+OYxBQi4J7Jcl5iCNZVpFeJLD1gd1Tv5s2FeKVXmCi+o= Received: by 10.54.11.42 with SMTP id 42mr173231wrk; Thu, 05 May 2005 06:07:15 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 06:07:15 -0700 (PDT) Message-ID: <14be96d30505050607180058e4@mail.gmail.com> Date: Thu, 5 May 2005 08:07:15 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates In-Reply-To: <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45D7KZE097854 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Andy Henderson wrote: > convincing the WG, I would simply point out that a mechanism widely > available to, and understood by, feed providers and aggregators cannot do > harm and has the potential to do a great deal of good. Not to be flippant, but we have one that's widely available. It's called the Expires header. I spoke with Roy Fielding at Apachecon 2003 and asked him this exact question: "If I set an Expires header on a feed of now + 3 hours, does that mean that I don't want the client to fetch the feed again for at least 3 hours?" And he said yes, that's exactly what it means. I sympathize with your dilemma that you have no control over your HTTP headers, but... wait, no I don't sympathize. At all. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 09:25:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25119 for ; Thu, 5 May 2005 09:25: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 j45DG9Te000148; Thu, 5 May 2005 06:16: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 j45DG9j6000147; Thu, 5 May 2005 06:16:09 -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 j45DG8OP000111 for ; Thu, 5 May 2005 06:16:08 -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 D118ABE for ; Thu, 5 May 2005 06:16:03 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j45DG2ng020005 for ; Thu, 5 May 2005 06:16:03 -0700 (PDT) Date: Thu, 05 May 2005 06:16:26 -0700 From: Walter Underwood To: "'Atom Syntax'" Subject: RE: Atom feed refresh rates Message-ID: <99320515C7212EBAF7B71610@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <20050505071512.FDXG1844.aamta08-winn.mailhost.ntl.com@AndyHenderson3> References: <20050505071512.FDXG1844.aamta08-winn.mailhost.ntl.com@AndyHenderson3> X-Mailer: Mulberry/4.0.0b1 (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 May 5, 2005 8:15:10 AM +0100 Andy Henderson wrote: > > here is no RSS2 feature I can see that allows feed providers to tell > aggregators the minimum refresh period. There's the ttl tag. That was, I > believe, introduced for a different purpose and determines the Maximum time > a feed should be cached in a certain situation. We need both a ttl (max-age) and expires. One or the other is appropriate for different publishing needs. We also need to specify what you do with those values, or you end up with a mess, like the RSS2 ttl meaning reversing over an undocumented value (Yikes!). > What has yet to be tried is a specific tag in the core feed standard that > promotes and determines good behaviour for aggregators refreshing their > feeds. Even if it were to prove only a limited benefit, it would still be a > benefit. It has been tried several ways, originally in robots.txt extensions and also in RSS. It doesn't work. The model is not rich enough for publishers or for spiders/aggregators. Max-age/expires is already designed and proven. By page count, 20% of the HTTP 1.1 spec is about caching. If we want to write a new caching/scheduling approach, we can expect it to be a 20 page spec, plus an additional 10 pages on how to work with the HTTP model. See the Notes section here for details on when to use max-age or expires, and on the problems with calendar-based schemes. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu May 5 09:29:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25519 for ; Thu, 5 May 2005 09:29: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 j45DD9VX099050; Thu, 5 May 2005 06:13: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 j45DD959099049; Thu, 5 May 2005 06:13: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DD8Dx099037 for ; Thu, 5 May 2005 06:13:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so176277wra for ; Thu, 05 May 2005 06:13: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=jDG4JqstZFp6hxqgtR8cPF+kYg9c3nqF1sBS3wsnHxBYgTCKCZpozZzwc6B3iFZ3py+RNj+8JThZOWR8X6/Dfa4CrL9aqcocS9fvzGowGrTiL7CtrnrfnW3ydKuo1l5EaZZcvfjxJDp4kcNr5JkPBzyUb1iJ80rYqQtiAesg5Ds= Received: by 10.54.70.2 with SMTP id s2mr185055wra; Thu, 05 May 2005 06:13:03 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 06:13:03 -0700 (PDT) Message-ID: <68fba5c5050505061343359155@mail.gmail.com> Date: Thu, 5 May 2005 09:13:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: status paces 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 j45DD9Dx099044 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Throw them all back. No reason we can't do this in an extension element. It would be big mistake to put these in right now. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 09:29:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25542 for ; Thu, 5 May 2005 09:29: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 j45DKmU0001199; Thu, 5 May 2005 06:20: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 j45DKmJW001198; Thu, 5 May 2005 06:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DKkii001182 for ; Thu, 5 May 2005 06:20:46 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45DJqNN021704; Thu, 5 May 2005 14:19:58 +0100 (BST) In-Reply-To: <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> References: <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom feed refresh rates Date: Thu, 5 May 2005 14:19:52 +0100 To: Andy Henderson X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 1:54 pm, Andy Henderson wrote: > I've no way to demonstrate aggregator use except my own - even > though I > support a tiny community I do observe and enforce the ttl tag. You seem to want the ttl element so that you have the publisher's permission to check less often. Why not just do so anyway if it causes so many problems? If that degrades the user experience too much, you're free to check more often. How is the ttl element useful to you? Graham From owner-atom-syntax@mail.imc.org Thu May 5 09:36:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26665 for ; Thu, 5 May 2005 09:36: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 j45DQdrO002113; Thu, 5 May 2005 06:26: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 j45DQdNl002112; Thu, 5 May 2005 06:26:39 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DQctT002096 for ; Thu, 5 May 2005 06:26:39 -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); Thu, 5 May 2005 23:26:34 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 05 May 2005 23:26:34 +1000 Subject: Re: PaceAllowDuplicateIDs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <821BF7D1-F12B-4B14-9E44-3E1CCED36EE9@mac.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/5/05 9:32 PM, "Graham" wrote: > atom:updated is used by the publisher to show what they consider a > significant change. The user, on the other hand, wants to see the > latest version, reliably, even if the publisher disagrees that the > change was significant. This is the core problem with Tim's proposal. > There is no way to create an aggregator that works in the way the > user expects. perhaps we needed atom:modified after all :-( >> Well that seems like a very complicated way of solving a problem >> where allowing entries with duplicate ids in a feed document from >> the start would be much simpler. If you are going to >> allow feeds to keep duplicates then why not just allow >> and be done with it? > > Because feeds are feeds and archives are archives? They have > different audiences and different uses and different requirements. And what about the use case of a wiki's RecentChanges log? Each entry refers to a specific page, and there may be multiple such entries for each page as it gets rapidly edited ... and wiki folks have found it important to be able to monitor all change events. I sure hope we don't have to define yet another atom document root element (eg. ). That sounds like such a hack. e. From owner-atom-syntax@mail.imc.org Thu May 5 09:37:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26750 for ; Thu, 5 May 2005 09:37: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 j45DOhVA001788; Thu, 5 May 2005 06:24: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 j45DOh2E001787; Thu, 5 May 2005 06:24: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 j45DOgf7001760 for ; Thu, 5 May 2005 06:24:42 -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 6CB48BE for ; Thu, 5 May 2005 06:24:37 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j45DOang020098 for ; Thu, 5 May 2005 06:24:36 -0700 (PDT) Date: Thu, 05 May 2005 06:24:59 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates Message-ID: In-Reply-To: <14be96d30505050607180058e4@mail.gmail.com> References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> X-Mailer: Mulberry/4.0.0b1 (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 May 5, 2005 8:07:15 AM -0500 Mark Pilgrim wrote: > > Not to be flippant, but we have one that's widely available. It's > called the Expires header. You need the information outside of HTTP. To quote from the RSS spec for ttl: This makes it possible for RSS sources to be managed by a file-sharing network such as Gnutella. Caching information is about knowing when your client cache is stale, regardless of how you got the feed. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu May 5 09:43:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27429 for ; Thu, 5 May 2005 09:43: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 j45DarsS003671; Thu, 5 May 2005 06:36: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 j45DarCR003670; Thu, 5 May 2005 06:36:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DarRR003637 for ; Thu, 5 May 2005 06:36:53 -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 <200505051336470140083hg5e>; Thu, 5 May 2005 13:36:48 +0000 Date: Thu, 5 May 2005 07:36:46 -0600 Subject: Re: Autodiscovery, real-world examples 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: <4279CAD8.5030301@inkedblade.net> 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 Thursday, May 5, 2005, at 01:27 AM, fantasai wrote: > And for linking to other pages.. Here's a real-world example: > The mozilla.org main page is an example > of where rel="alternate" is a problem. There were three feeds on > it: "Announcements", "mozillaZine News", and "Mozilla Weblogs" > (now only two). Each one is an alternate of a web page, but of > _other_ pages (http://www.mozilla.org/news.html, > http://www.mozillazine.org/, and http://planet.mozilla.org/ > respectively), not the mozilla.org > front page. The last few headlines for each feed are listed on > the front page, and the designer felt it was appropriate for > autodiscovery to work on this page -- but it is not appropriate > for rel="alternate" to be used for those autodiscovery links. > They are not alternate representations of the front page. > I'm beginning to sway in the direction of this argument, but I'm not sure whether I'll sway back or not. Given that @type will clearly (for Atom and RSS 2 anyway, if not for RSS 1) identify the feed as a feed (...or maybe an Atom Entry Document...the feed reader can deal with that issue when the user tries to subscribe), I don't think there's a big need for @rel to say "feed". But it wouldn't be illogical for use "alternate" for only the feed associated with a particular page (perhaps including the case of an individual entry archive page), and something else like "related" to point to other feeds. A UA could check @rel and @type and present a UI saying something like "subscribe to the feed for this page" and "subscribe to a feed related to this page". From owner-atom-syntax@mail.imc.org Thu May 5 09:47:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27735 for ; Thu, 5 May 2005 09:47: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 j45DdpPG004136; Thu, 5 May 2005 06:39: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 j45DdpJc004135; Thu, 5 May 2005 06:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DdooG004116 for ; Thu, 5 May 2005 06:39:50 -0700 (PDT) (envelope-from Andy@SeeITA.com) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050505133944.DTAF8086.mta13-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Thu, 5 May 2005 14:39:44 +0100 Received: from AndyHenderson3 ([80.0.70.144]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050505133944.LJKE1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3>; Thu, 5 May 2005 14:39:44 +0100 From: "Andy Henderson" To: "'Graham'" Cc: "'atom-syntax'" Subject: RE: Atom feed refresh rates Date: Thu, 5 May 2005 14:39:43 +0100 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: Thread-Index: AcVRdUT3doK+VgY3Tdu5XKSMJ1mv6wAAmJ/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050505133944.LJKE1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>You seem to want the ttl element so that you have the publisher's permission to check less often. Why not just do so anyway if it causes so many problems? If that degrades the user experience too much, you're free to check more often. How is the ttl element useful to you?<<< I allow anyone to specify any refresh interval higher than the greater of ttl or 60 minutes. The ttl allows me to extend the minimum refresh interval beyond 60 minutes. 'MSDN just published' at http://msdn.microsoft.com/rss.xml includes 1440. I therefore set the refresh interval to 1 day when the feed is added and I do not allow people to specify a lower refresh interval. If the ttl tag simply described the minimum refresh interval, I would also use it to allow people to specify refresh intervals less than 60 minutes knowing that was acceptable to the feed provider. Unfortunately, the genesis of the ttl tag means that lower ttl values are unreliable. The BBC, for example, specifies a ttl of 5 which I'm sure refers to that tag's original use, not a minimum refresh interval. Andy From owner-atom-syntax@mail.imc.org Thu May 5 09:47:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27782 for ; Thu, 5 May 2005 09:47: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 j45DfsKV004426; Thu, 5 May 2005 06: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 j45DfseZ004425; Thu, 5 May 2005 06:41: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DfrUs004399 for ; Thu, 5 May 2005 06:41:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so193946wra for ; Thu, 05 May 2005 06:41:47 -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=K1LqYpzA5+hjDNmH9SHfnRFKRzmLAwV0m/j5Mb15UukTrHmuE17NVLNmr7hHJQbOFTuj1pJcgldaTkbT3EY6RUzcyL/lVJJZad1osJrpw6DED5KyHH5mhRH8j4u+yUm+NkeHh+Ydm+L3n9zROaVhK6hRu4LM6jGCPLU5d07zJn0= Received: by 10.54.5.9 with SMTP id 9mr199801wre; Thu, 05 May 2005 06:41:47 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 06:41:47 -0700 (PDT) Message-ID: <68fba5c50505050641139bc53f@mail.gmail.com> Date: Thu, 5 May 2005 09:41:47 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: PaceAllowDuplicateIDs Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <821BF7D1-F12B-4B14-9E44-3E1CCED36EE9@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45DfrUs004420 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Eric Scheid wrote: > > Because feeds are feeds and archives are archives? They have > > different audiences and different uses and different requirements. > > And what about the use case of a wiki's RecentChanges log? Each entry refers > to a specific page, and there may be multiple such entries for each page as > it gets rapidly edited ... and wiki folks have found it important to be able > to monitor all change events. I'm much more sympathetic to the aggregate feed problem of multiple IDs. People advocating this type of thing seem to think the default action should be grouping, so they want to use the same ID. I think that's a bad idea, and there are plenty of other ways to indicate the fundamental sameness of entries. For example, NewsML URNs have a NewsItemID and a RevisionID, which would allow smart aggregators to group the entries without violating Atom's constraint. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 10:07:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00065 for ; Thu, 5 May 2005 10:07: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 j45DwNHZ007074; Thu, 5 May 2005 06:58: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 j45DwNuJ007073; Thu, 5 May 2005 06:58:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45DwKUY007065 for ; Thu, 5 May 2005 06:58:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45DtMBC014728; Thu, 5 May 2005 14:55:22 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 14:55:23 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 2:26 pm, Eric Scheid wrote: > perhaps we needed atom:modified after all :-( Yes we do, if we want to go down this route. I suggest appending the current time (or for old versions, the last time that version was current) at the source. > And what about the use case of a wiki's RecentChanges log? Each > entry refers > to a specific page, and there may be multiple such entries for each > page as > it gets rapidly edited ... and wiki folks have found it important > to be able > to monitor all change events. Each log entry is an entry in itself, with its own id. That seems a far better functional parallel to the basic blog feed. As with the share price example, the topic of the entry (the company, or the wiki page) is far more analogous to a category that the entry belongs to, than to an its identity. Everyone stop trying to use ids as a category system. Graham From owner-atom-syntax@mail.imc.org Thu May 5 10:08:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00314 for ; Thu, 5 May 2005 10:08: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 j45E24uw007314; Thu, 5 May 2005 07: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 j45E24x4007313; Thu, 5 May 2005 07:02:04 -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 j45E1x8B007289 for ; Thu, 5 May 2005 07:01:59 -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 0F84DAE for ; Thu, 5 May 2005 07:01:54 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j45E1qng020513 for ; Thu, 5 May 2005 07:01:53 -0700 (PDT) Date: Thu, 05 May 2005 07:02:15 -0700 From: Walter Underwood To: Atom-Syntax Subject: Re: AtomPubIssuesList for 2005/05/05 Message-ID: In-Reply-To: <427A00AC.5020007@intertwingly.net> 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> X-Mailer: Mulberry/4.0.0b1 (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 May 5, 2005 7:17:00 AM -0400 Sam Ruby wrote: > > Demonstrate that you have revisited the previous discussion, and that you either > have something new to add, or can point out some evidence that the previous > consensus call was made in error. PaceCaching was not discussed and rejected based on false information. It was rejected because it was HTTP-specific (it is not), and because it was non-core (similar features are common in other RSS specs). It does not interact with other features, so it should be a fairly clean, quick discussion. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu May 5 10:13:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01450 for ; Thu, 5 May 2005 10:13: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 j45E6Vwn007552; Thu, 5 May 2005 07:06: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 j45E6VUW007551; Thu, 5 May 2005 07:06: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 j45E6Tmj007539 for ; Thu, 5 May 2005 07:06:30 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 May 2005 14:06:20 -0000 Received: from xdsl-81-173-169-123.netcologne.de (EHLO klangraum) [81.173.169.123] by mail.gmx.net (mp019) with SMTP; 05 May 2005 16:06:20 +0200 X-Authenticated: #163624 Date: Thu, 5 May 2005 16:09:09 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Message-ID: <20050505140909.GA14882@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4277B471.7030100@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: Content-Transfer-Encoding: 8bit * Thomas Broyer [2005-05-03 19:35]: > This means type="text" content is a single paragraph of text. > If you need paragraphs, lists or any other "structural > formatting", you have to use type="html" or type="xhtml" with > the appropriate content. Or type="text/plain", I’d assume? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu May 5 10:18:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02227 for ; Thu, 5 May 2005 10:18: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 j45EBhOU008130; Thu, 5 May 2005 07:11: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 j45EBhFB008129; Thu, 5 May 2005 07:11:43 -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 j45EBgSR008120 for ; Thu, 5 May 2005 07:11:42 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so213009wra for ; Thu, 05 May 2005 07:11:36 -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=hSEpX023YGLKRGpSuG/at5Iab4Y4RNxqKWWAOoIFw32UKFczJs8wW1hlrC69x5nZUYZe0nFx0rCbCqbI7BlgANhiwEmWMkQwLrZTiRXtFQBJGxwmYehI+Ufn7HFIgnc7wWV/TlDLhauriQPZPdXudoXIBaTXmqSJqon6v7UEPMw= Received: by 10.54.50.66 with SMTP id x66mr214461wrx; Thu, 05 May 2005 07:11:36 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 07:11:36 -0700 (PDT) Message-ID: <68fba5c505050507111a37ed28@mail.gmail.com> Date: Thu, 5 May 2005 10:11:36 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: Autodiscovery, real-world examples Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4279CAD8.5030301@inkedblade.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45EBgSR008123 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Antone Roundy wrote: > > On Thursday, May 5, 2005, at 01:27 AM, fantasai wrote: > > front page. The last few headlines for each feed are listed on > > the front page, and the designer felt it was appropriate for > > autodiscovery to work on this page -- but it is not appropriate > > for rel="alternate" to be used for those autodiscovery links. > > They are not alternate representations of the front page. I can see your point, but the autodiscovery spec isn't standardizing all usages. Just the one we have a good grasp on. Secondly, there's nothing stopping UAs from "discovering" other feeds. Safari 2.0 already does this. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 10:21:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02739 for ; Thu, 5 May 2005 10:21: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 j45EFrpG008683; Thu, 5 May 2005 07:15: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 j45EFrYU008682; Thu, 5 May 2005 07:15:53 -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 j45EFqwc008672 for ; Thu, 5 May 2005 07:15:52 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so717858wri for ; Thu, 05 May 2005 07:15:44 -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=ETnM/zeQVKON9oVoBr6Cd1WjARcf3JR+ZwnxINVkQ2JyLcsf1IF/xUkxPQz6jZOtLXSJHqURRxo3uOHnDDArrDztsRHG+PBPWcJIVjZM746dwxCN3JakTu3//sFW/iP5kcuw65EzAM6Cvs0d0afvGekh+qMf2dVPM2ae/W4IQ3E= Received: by 10.54.29.14 with SMTP id c14mr207371wrc; Thu, 05 May 2005 07:15:44 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 07:15:44 -0700 (PDT) Message-ID: <14be96d305050507152f9762c1@mail.gmail.com> Date: Thu, 5 May 2005 09:15:44 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Atom-Syntax Subject: Re: AtomPubIssuesList for 2005/05/05 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <412B23C4.9010602@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> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45EFrwc008676 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Walter Underwood wrote: > It does not interact with other features, so it should be a fairly > clean, quick discussion. You must be new here. /ducks -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 10:25:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03143 for ; Thu, 5 May 2005 10:25: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 j45EAFmr008030; Thu, 5 May 2005 07:10: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 j45EAFkL008029; Thu, 5 May 2005 07:10: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EAEAA008009 for ; Thu, 5 May 2005 07:10:14 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so713948wri for ; Thu, 05 May 2005 07:10: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UxiuQkEDguUXzZCaCVFC2UIXeHEahF2jLz1HJSy7IevIWmKv0GkFjGBPyvCOjKlSKM6J1/xbdh0AU93Ci7GC3c8iwisa0awWh9SWBVeZZUCApDEX192wiyl2nm2r9W9d+OrwbL79/fy39QOwOf/8/3d+1GMdfbZmx6FQSg4kcpU= Received: by 10.54.148.15 with SMTP id v15mr210894wrd; Thu, 05 May 2005 07:10:09 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 07:10:09 -0700 (PDT) Message-ID: <14be96d3050505071064aeff7@mail.gmail.com> Date: Thu, 5 May 2005 09:10:09 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45EAFAA008022 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Walter Underwood wrote: > You need the information outside of HTTP. To quote from the RSS spec > for ttl: > > This makes it possible for RSS sources to be managed by a file-sharing > network such as Gnutella. Ignoring, for the moment, that this is a horrible idea and no one supports it, Gnutella has its own caching and time-to-live mechanisms that the RSS spec is ignoring. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 10:28:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03390 for ; Thu, 5 May 2005 10:28: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 j45EO2bV010221; Thu, 5 May 2005 07:24: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 j45EO2TT010220; Thu, 5 May 2005 07:24:02 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EO0tu010190 for ; Thu, 5 May 2005 07:24:02 -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); Fri, 6 May 2005 00:23:55 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 00:23:55 +1000 Subject: Re: PaceAllowDuplicateIDs 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/5/05 11:55 PM, "Graham" wrote: >> And what about the use case of a wiki's RecentChanges log? Each entry refers >> to a specific page, and there may be multiple such entries for each page as >> it gets rapidly edited ... and wiki folks have found it important to be able >> to monitor all change events. >> > Each log entry is an entry in itself, with its own id. Sorry, that makes as much sense as changing the id for a blog entry if that blog entry is updated. The functional parallel is wiki-page = blog-entry, and if a blog-entry is updated then that is reflected in the feed as an updated entry - with the same id. e. From owner-atom-syntax@mail.imc.org Thu May 5 10:29:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03411 for ; Thu, 5 May 2005 10:29: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 j45EMQne009930; Thu, 5 May 2005 07:22: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 j45EMQa6009929; Thu, 5 May 2005 07:22:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EMPjG009911 for ; Thu, 5 May 2005 07:22:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45EL3no001368; Thu, 5 May 2005 15:21:09 +0100 (BST) In-Reply-To: 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> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceCaching Date: Thu, 5 May 2005 15:21:02 +0100 To: Walter Underwood X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 3:02 pm, Walter Underwood wrote: > > PaceCaching was not discussed and rejected based on false information. > It was rejected because it was HTTP-specific (it is not), and because > it was non-core (similar features are common in other RSS specs). > > It does not interact with other features, so it should be a fairly > clean, quick discussion. Unless we can make providing incorrect or misleading information in either of these elements lead to the immediate purging of first born, they're not at all useful to anyone. The "expires date" can't apply to 99% of feeds since they don't work on a fixed or predictable schedule. Meanwhile "max-age" doesn't provide any actionable information to caches, beyond "I chose this random number off the top of my head when I wrote my Atom script 3 years ago. Deal." Do you seriously expect it to be interpreted as a promise that the feed won't change for the next x minutes? Graham From owner-atom-syntax@mail.imc.org Thu May 5 10:33:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03798 for ; Thu, 5 May 2005 10:33: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 j45EQr67010757; Thu, 5 May 2005 07:26: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 j45EQrRw010755; Thu, 5 May 2005 07:26:53 -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 j45EQqp5010730 for ; Thu, 5 May 2005 07:26:52 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so724841wri for ; Thu, 05 May 2005 07:26:47 -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=crh46Rv1PMks4j98o5b7Rt4cDf+gr1yc1NAhgPkXrDz1M0qJ0nj9uNEqHZliEJtHzBvsnbdeYVFZkqq4I4qMZcJrmtZznzeNHw5zSt3FlvYnTceRYaRjlBGzXR6FySOREdnehGoDVa/er0m4555FguIkiyKP4Sc3OFUHRxqEDY8= Received: by 10.54.29.40 with SMTP id c40mr212827wrc; Thu, 05 May 2005 07:26:46 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 07:26:46 -0700 (PDT) Message-ID: <14be96d305050507266064f2ff@mail.gmail.com> Date: Thu, 5 May 2005 09:26:46 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax Subject: Re: PaceCaching In-Reply-To: <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <412B23C4.9010602@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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45EQrp5010745 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Graham wrote: > seriously expect it to be interpreted as a promise that the feed > won't change for the next x minutes? No, but I do seriously expect it to be interpreted that the feed publisher does not wish clients to check it for the next x minutes. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 10:37:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04042 for ; Thu, 5 May 2005 10:37: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 j45EUbVL011285; Thu, 5 May 2005 07:30: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 j45EUbp4011284; Thu, 5 May 2005 07:30:37 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EUawd011270 for ; Thu, 5 May 2005 07:30:36 -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 1DThN5-00068c-00; Thu, 05 May 2005 15:30:35 +0100 Date: Thu, 5 May 2005 15:30:35 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates Message-ID: <20050505143035.GE23305@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d30505050607180058e4@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 Thu, May 05, 2005 at 08:07:15AM -0500, Mark Pilgrim wrote: > Not to be flippant, but we have one that's widely available. It's > called the Expires header. I spoke with Roy Fielding at Apachecon > 2003 and asked him this exact question: "If I set an Expires header on > a feed of now + 3 hours, does that mean that I don't want the client > to fetch the feed again for at least 3 hours?" And he said yes, > that's exactly what it means. I think the problem here may be that the HTTP/1.1 spec gives the impression that the Expires header is not designed to affect end clients (user agents). For instance, from 13.2.1 ("Server-Specified Expiration"), we get the sentence: "The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately to the requesting client." Now many clients themselves contain caches, but this distinction may still be the source of some confusion, especially as the number of people who know about the distinction (by having written a user agent) compared to the number who are affected by it (by writing server components) is pretty small. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu May 5 10:40:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04346 for ; Thu, 5 May 2005 10:40: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 j45EWt11011715; Thu, 5 May 2005 07:32: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 j45EWt6h011714; Thu, 5 May 2005 07:32:55 -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 j45EWsp9011707 for ; Thu, 5 May 2005 07:32:54 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 46363 invoked by uid 17064); 5 May 2005 14:32:54 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 14:32:54 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 16:32:50 +0200 To: Graham , atom-syntax Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 15:55, Graham wrote: > On 5 May 2005, at 2:26 pm, Eric Scheid wrote: > > >> perhaps we needed atom:modified after all :-( >> > > Yes we do, if we want to go down this route. I suggest appending > the current time (or for old versions, the last time that version > was current) at the source. Sorry I don't understand why we need atom:modified. > > >> And what about the use case of a wiki's RecentChanges log? Each >> entry refers >> to a specific page, and there may be multiple such entries for >> each page as >> it gets rapidly edited ... and wiki folks have found it important >> to be able >> to monitor all change events. >> > > Each log entry is an entry in itself, with its own id. That seems a > far better functional parallel to the basic blog feed. As I explained in my lengthy reply to your lengthy post, I think one should be able to do either. Each way has its advantages and disadvantages. Let the publisher decide which mechanism to use. > As with the share price example, the topic of the entry (the > company, or the wiki page) is far more analogous to a category that > the entry belongs to, than to an its identity. Again let the publisher choose what the identity criterion of his objects are. Some will stick some will not. But it is not up to us to decide for our users. Since it does not cause any interoperability issues, what's the problem? > Everyone stop trying to use ids as a category system. I don't think that one would be using ids as a category system. If you go to you get todays front page. Tomorrow you get tomorrows front page. What's the problem? Is a hidden category system? Henry Story http://bblfish.net/blog/ From owner-atom-syntax@mail.imc.org Thu May 5 10:41:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04490 for ; Thu, 5 May 2005 10:41: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 j45EYdV0012018; Thu, 5 May 2005 07:34: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 j45EYdvi012017; Thu, 5 May 2005 07:34: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EYbx2011998 for ; Thu, 5 May 2005 07:34:38 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so228198wra for ; Thu, 05 May 2005 07:34:32 -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=uIB8zjnBdba6oFs7Utb4LJyL1HqozxqS0ZbJTWL+cQRkIsA6z3+Ell/R8D6+xycaLQM9QmfRH4RkkjCN/XKzaGtlx4yvlg5DtDLo88Unuv/zYctng/b9EcGx8cJQnapn3JWR2iWwPr7NL+cbroht/1BL0fqWxP2WcZ4uCf9JaHk= Received: by 10.54.32.13 with SMTP id f13mr226120wrf; Thu, 05 May 2005 07:34:32 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 07:34:32 -0700 (PDT) Message-ID: <68fba5c505050507341ed2a9de@mail.gmail.com> Date: Thu, 5 May 2005 10:34:32 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: PaceAllowDuplicateIDs Cc: Atom Syntax 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 j45EYcx2012010 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Eric Scheid wrote: > > On 5/5/05 11:55 PM, "Graham" wrote: > >> > > Each log entry is an entry in itself, with its own id. > > Sorry, that makes as much sense as changing the id for a blog entry if that > blog entry is updated. Graham's got it exactly right. > The functional parallel is wiki-page = blog-entry, and if a blog-entry is > updated then that is reflected in the feed as an updated entry - with the > same id. That's right, that is the functional parallel. No software I know of shows both revisions of the entry in the feed when it's updated. If you are syndicating wiki changes, part of each entry is the diff and revision id--each revision is a unique thing. Another analogous use case would be a feed watching a certain file in CVS. Every entry would be about the same file, but each would have its own atom:id. Once again, there remains a downstream problem for PubSub, etc. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 10:48:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05225 for ; Thu, 5 May 2005 10:48: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 j45Efhw0013095; Thu, 5 May 2005 07:41: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 j45Efhtg013094; Thu, 5 May 2005 07:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45Efg6l013087 for ; Thu, 5 May 2005 07:41:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45EcjYa015026; Thu, 5 May 2005 15:38:45 +0100 (BST) In-Reply-To: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> References: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72F9DD66-7A14-4216-A7A1-11872B0A038F@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 15:38:45 +0100 To: Henry Story X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 3:32 pm, Henry Story wrote: > As I explained in my lengthy reply to your lengthy post, I think > one should be able to do either. > Each way has its advantages and disadvantages. Let the publisher > decide which mechanism to use. Well please flag it so that I can provide a consistent user interface to people's whims? > Since it does not cause any interoperability issues, what's the > problem? I have to come up with a new way to recognise and interpret such feeds where an entry (as defined by its id) isn't an entry but a feed of different entries. > I don't think that one would be using ids as a category system. If > you go to > you get todays front page. Tomorrow you get > tomorrows front page. > What's the problem? Is a hidden category system? Charter: "Atom defines a feed format for representing resources such as Weblogs, online journals, Wikis, and similar content" Atom is not a replacement for HTTP. Google.com is a web page, not "similar content". It's not relevant here. Graham From owner-atom-syntax@mail.imc.org Thu May 5 10:55:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06180 for ; Thu, 5 May 2005 10:55: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 j45EiWP2013498; Thu, 5 May 2005 07:44: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 j45EiW7p013497; Thu, 5 May 2005 07:44:32 -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 j45EiVYC013489 for ; Thu, 5 May 2005 07:44:32 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j45EikP1019594; Thu, 5 May 2005 10:44:46 -0400 Message-ID: <427A3148.3030506@intertwingly.net> Date: Thu, 05 May 2005 10:44:24 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom-Syntax Subject: Re: AtomPubIssuesList for 2005/05/05 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> 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 May 5, 2005 7:17:00 AM -0400 Sam Ruby wrote: > >>Demonstrate that you have revisited the previous discussion, and that you either >>have something new to add, or can point out some evidence that the previous >>consensus call was made in error. > > PaceCaching was not discussed and rejected based on false information. > It was rejected because it was HTTP-specific (it is not), and because > it was non-core (similar features are common in other RSS specs). Actually, it never has been rejected. I had miscategorized it as protocol. I've fixing that now, and scheduled it for this cycle. Sorry for the confusion. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 10:55:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06228 for ; Thu, 5 May 2005 10:55: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 j45EnnBa014311; Thu, 5 May 2005 07:49: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 j45Enn0j014310; Thu, 5 May 2005 07:49:49 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EnmDo014303 for ; Thu, 5 May 2005 07:49:49 -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 1DThff-0006ei-00; Thu, 05 May 2005 15:49:47 +0100 Date: Thu, 5 May 2005 15:49:47 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceCaching Message-ID: <20050505144947.GJ23305@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> <14be96d305050507266064f2ff@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14be96d305050507266064f2ff@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 Thu, May 05, 2005 at 09:26:46AM -0500, Mark Pilgrim wrote: > > seriously expect it to be interpreted as a promise that the feed > > won't change for the next x minutes? > > No, but I do seriously expect it to be interpreted that the feed > publisher does not wish clients to check it for the next x minutes. Indeed - Expires doesn't say it won't change, it says that you shouldn't care whether it's changed. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Thu May 5 10:55:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06300 for ; Thu, 5 May 2005 10:55: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 j45EiFUt013449; Thu, 5 May 2005 07:44: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 j45EiFv7013448; Thu, 5 May 2005 07:44:15 -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 j45EiFMf013427 for ; Thu, 5 May 2005 07:44:15 -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 <2005050514440901400g4cl6e>; Thu, 5 May 2005 14:44:09 +0000 Date: Thu, 5 May 2005 08:44:07 -0600 Subject: Re: PaceAllowDuplicateIDs 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: <73eb986f1cca36c77bfae6708e448e52@sun.com> Message-Id: <22A11496-BD74-11D9-AC04-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 If we accept this Pace, are we going to do anything to address the DOS issue for aggregated feeds? From owner-atom-syntax@mail.imc.org Thu May 5 10:56:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06365 for ; Thu, 5 May 2005 10:56: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 j45EkMsZ013782; Thu, 5 May 2005 07:46: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 j45EkMIQ013781; Thu, 5 May 2005 07:46:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EkLgn013741 for ; Thu, 5 May 2005 07:46:22 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45EjwiS022120; Thu, 5 May 2005 15:45:58 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F446FCF-C73F-4153-AD6E-9F13902C9293@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 15:45:59 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 3:23 pm, Eric Scheid wrote: >>> And what about the use case of a wiki's RecentChanges log? Each >>> entry refers >>> to a specific page, and there may be multiple such entries for >>> each page as >>> it gets rapidly edited ... and wiki folks have found it important >>> to be able >>> to monitor all change events. >>> >>> >> Each log entry is an entry in itself, with its own id. >> > > Sorry, that makes as much sense as changing the id for a blog entry > if that > blog entry is updated. Have a look here: http://en.wikipedia.org/w/index.php?title=Main_Page&action=history There you have a reverse chrono list, each with an author, date, and summary. Looks an awful lot like each one is an entry to me. Graham From owner-atom-syntax@mail.imc.org Thu May 5 11:05:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07106 for ; Thu, 5 May 2005 11:05: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 j45EwoCA015660; Thu, 5 May 2005 07:58: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 j45EwndW015659; Thu, 5 May 2005 07:58:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EwnfY015650 for ; Thu, 5 May 2005 07:58:49 -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 (rwcrmhc13) with SMTP id <200505051458430150071ohve>; Thu, 5 May 2005 14:58:43 +0000 Date: Thu, 5 May 2005 08:58:42 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceTextShouldBeProvided From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2BB858D6-BD76-11D9-AC04-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 +1 except for one thing: In section 4.1.2, I'd suggest something along these lines: atom:entry elements which do not contain an atom:content element, or whose atom:content element's type attribute indicates a MIME media type, SHOULD contain an atom:summary element. From owner-atom-syntax@mail.imc.org Thu May 5 11:05:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07132 for ; Thu, 5 May 2005 11:05: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 j45F0VI8015826; Thu, 5 May 2005 08:00: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 j45F0Vr5015825; Thu, 5 May 2005 08:00:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45F0Vg3015819 for ; Thu, 5 May 2005 08:00:31 -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 (rwcrmhc13) with SMTP id <200505051500250150073dgre>; Thu, 5 May 2005 15:00:25 +0000 Date: Thu, 5 May 2005 09:00:21 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceOptionalSummary From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <6733C8D3-BD76-11D9-AC04-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 +1. ...oh, and the wording I just suggested for part of PaceTextShouldBeProvided would depend on this also being accepted. From owner-atom-syntax@mail.imc.org Thu May 5 11:10:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07573 for ; Thu, 5 May 2005 11:10: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 j45F5rC1016126; Thu, 5 May 2005 08:05: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 j45F5rhL016125; Thu, 5 May 2005 08:05: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 j45F5qJI016119 for ; Thu, 5 May 2005 08:05:52 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 59230 invoked by uid 17064); 5 May 2005 15:05:52 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 15:05:52 -0000 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax Syntax From: Henry Story Subject: PaceAlternateLinkWeakening Date: Thu, 5 May 2005 17:05:48 +0200 X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have put PaceAlternateLinkWeakening on the wiki, though it was discusses on this list, as it might not have cought the eye of the editors/secretary. http://www.intertwingly.net/wiki/pie/PaceAlternateLinkWeakening I think this is very uncontroversial clarification. Henry Story From owner-atom-syntax@mail.imc.org Thu May 5 11:10:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07588 for ; Thu, 5 May 2005 11:10: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 j45F4tFV016081; Thu, 5 May 2005 08:04: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 j45F4teJ016080; Thu, 5 May 2005 08:04:55 -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 j45F4siR016069 for ; Thu, 5 May 2005 08:04:54 -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 <2005050515044801200sj1o1e>; Thu, 5 May 2005 15:04:48 +0000 Date: Thu, 5 May 2005 09:04:47 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceRecommendPlainTextContent From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <054EBCFF-BD77-11D9-AC04-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 -1. This is entirely up to the publisher. I think enough publishers are going to want things like links and line/paragraph breaks in their content that this recommendation would be so routinely ignored as to be meaningless. From owner-atom-syntax@mail.imc.org Thu May 5 11:17:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08308 for ; Thu, 5 May 2005 11: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 j45F9mJE016487; Thu, 5 May 2005 08:09: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 j45F9mLt016486; Thu, 5 May 2005 08:09:48 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45F9k5d016479 for ; Thu, 5 May 2005 08:09:47 -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); Fri, 6 May 2005 01:09:43 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 01:09:42 +1000 Subject: Re: PaceAllowDuplicateIDs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.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 6/5/05 12:32 AM, "Henry Story" wrote: > Sorry I don't understand why we need atom:modified. Graham suggested it : a reliable way for an aggregator to discern the latest version of an entry. > atom:updated is used by the publisher to show what they consider a > significant change. The user, on the other hand, wants to see the > latest version, reliably, even if the publisher disagrees that the > change was significant. This is the core problem with Tim's proposal. > There is no way to create an aggregator that works in the way the > user expects. ... no way, that is, unless we have atom:modified making each same-id entry distinct, and not just distinct but also time-ordered and time-distanced (an advantage over just using something similar to the NewsML RevisionID mechanism). e. From owner-atom-syntax@mail.imc.org Thu May 5 11:20:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08662 for ; Thu, 5 May 2005 11:20: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 j45FFQDO017237; Thu, 5 May 2005 08: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 j45FFQPB017236; Thu, 5 May 2005 08:15:26 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FFP1D017230 for ; Thu, 5 May 2005 08:15:26 -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); Fri, 6 May 2005 01:15:24 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 01:15:24 +1000 Subject: Re: PaceAllowDuplicateIDs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <6F446FCF-C73F-4153-AD6E-9F13902C9293@mac.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 6/5/05 12:45 AM, "Graham" wrote: > Have a look here: > http://en.wikipedia.org/w/index.php?title=Main_Page&action=history > > There you have a reverse chrono list, each with an author, date, and > summary. Looks an awful lot like each one is an entry to me. and looks to me like a stream of meta-data concerning the one entry to me. and not distinct and separable entries like you'd find in your every day blog. Henry has the right idea -- the spec should allow both kinds, rather than trying to shoe-horn everything into the one viewpoint of what is an entry. e. From owner-atom-syntax@mail.imc.org Thu May 5 11:27:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09186 for ; Thu, 5 May 2005 11: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 j45FKES4017663; Thu, 5 May 2005 08:20: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 j45FKE8p017662; Thu, 5 May 2005 08:20:14 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FKDGt017650 for ; Thu, 5 May 2005 08:20:14 -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 <2005050515200801600dr934e>; Thu, 5 May 2005 15:20:08 +0000 Date: Thu, 5 May 2005 09:20:06 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceOriginalAttribute From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2945124E-BD79-11D9-AC04-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 -1. I don't see that this solves any problem. It may help people avoid accidentally generating invalid feeds (if we stick to not to allowing duplication of atom:id within a feed), but it does it by simply shunting the issue off into a different element which doesn't have duplication constraints. It doesn't address the DOS problem--neither accidental nor intentional. And it doesn't make it any easier to determine whether or not entries in different feeds with the same atom:id are really the same entry or not. In fact, it just complicates the task by requiring the inspection of two elements instead of one. From owner-atom-syntax@mail.imc.org Thu May 5 11:27:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09252 for ; Thu, 5 May 2005 11:27: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 j45FMbO0017822; Thu, 5 May 2005 08: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 j45FMbFU017821; Thu, 5 May 2005 08:22:37 -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 j45FMahK017815 for ; Thu, 5 May 2005 08:22:36 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 66670 invoked by uid 17064); 5 May 2005 15:22:36 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 15:22:36 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <72F9DD66-7A14-4216-A7A1-11872B0A038F@mac.com> References: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> <72F9DD66-7A14-4216-A7A1-11872B0A038F@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 17:22:32 +0200 To: Graham , atom-syntax Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 16:38, Graham wrote: > On 5 May 2005, at 3:32 pm, Henry Story wrote: >> As I explained in my lengthy reply to your lengthy post, I think >> one should be able to do either. >> Each way has its advantages and disadvantages. Let the publisher >> decide which mechanism to use. > > Well please flag it so that I can provide a consistent user > interface to people's whims? What is the problem with the user interface that you have exactly? I have pointed you to BlogEd that keeps a history of all the changes to an entry. Try it out: http://blogs.sun.com/roller/page/bblfish/ Its open source, so you can also copy the code. If you don't want to keep a history of the entries all you need to do is drop all but the latest entry with the same id. There is nothing more to it. Just show the user the last one you came across. >> Since it does not cause any interoperability issues, what's the >> problem? > > I have to come up with a new way to recognise and interpret such > feeds where an entry (as defined by its id) isn't an entry but a > feed of different entries. No you don't. Just drop the old ones, if you don't care about the history. Really simple. As Tim Bray's text says [[ software MAY choose to display all of them or some subset of them ]] So just drop the older versions. >> I don't think that one would be using ids as a category system. If >> you go to >> you get todays front page. Tomorrow you get >> tomorrows front page. >> What's the problem? Is a hidden category system? > > Charter: "Atom defines a feed format for representing resources > such as Weblogs, online journals, Wikis, > and similar content" yes, and it must also allow the representation of [[ * a complete archive of all entries in a feed ]] This proposal permits this, and it does not harm anyone else. > Atom is not a replacement for HTTP. Google.com is a web page, not > "similar content". It's not relevant here. I don't know where you get the idea that I said atom is a replacement for HTTP. Take a breath perhaps and relax before you answer. > > Graham > From owner-atom-syntax@mail.imc.org Thu May 5 11:33:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09979 for ; Thu, 5 May 2005 11:33: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 j45FSJMI018156; Thu, 5 May 2005 08:28: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 j45FSJsv018155; Thu, 5 May 2005 08:28:19 -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 j45FSJaD018149 for ; Thu, 5 May 2005 08:28:19 -0700 (PDT) (envelope-from Davidm.Johnson@Sun.COM) Received: from fe3.sun.com (fe3.Sun.COM [192.18.108.80] (may be forged)) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j45FSEjO024569 for ; Thu, 5 May 2005 09:28:14 -0600 (MDT) Received: from conversion-daemon.fe3.sun.com by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IG000F01W373A00@fe3.sun.com> (original mail from Davidm.Johnson@Sun.COM) for atom-syntax@imc.org; Thu, 05 May 2005 09:28:14 -0600 (MDT) Received: from [192.168.1.103] ([24.211.236.180]) by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IG000MC6WB1BI70@fe3.sun.com> for atom-syntax@imc.org; Thu, 05 May 2005 09:28:14 -0600 (MDT) Date: Thu, 05 May 2005 11:27:56 -0400 From: David M Johnson Subject: Re: PaceAllowDuplicateIDs In-reply-to: <73eb986f1cca36c77bfae6708e448e52@sun.com> To: Atom Syntax Message-id: <080261f7bfddd3131c686e830ba65601@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <73eb986f1cca36c77bfae6708e448e52@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I'm -1 on PaceAllowDuplicateIDs Reasons: 1) We're supposed to be standardizing current practice not inventing new things. Current best practice is to have unique IDs and current software (e.g. Javablogs.com) is predicated on this practice. I know, this practice is not followed widely enough, but that is another matter. 2) I think it is *much* more useful to think of an Atom Entry as an event that occurred at a specific time. Typically, an event is the publication of an article or blog entry on the web. For example: event: CNET published article subject: CNET object: article But an event it could also represent other events. event: delivery van delivers package subject: delivery van object: package event: alarm system sends warning subject: alarm system object: warning event: server sends load warning subject: server object: load warning If you think of Atom Entries as events, then it makes sense to consider the Atom Entry ID to be the ID of the event, not the ID of the subject or object of the event. Events are unique (you can't have more than one version of an event) and can be assigned GUIDs and therefore you cannot have more than one entry with the same ID. In the case of earthquake data, each new data report is a new event. event: agency reports earthquake data subject: agency object: earthquake data The ID is the ID of the "data reported" event not the ID of the earthquake. We don't know what subjects and objects people are going to use in the future, so we can't specify Atom elements or IDs for subjects and objects -- that's what extensions are for. If you want to create a feed to syndicate information about earthquakes, then you introduce an extension for uniquely identifying earthquakes. The same goes for earthquakes. - Dave On May 5, 2005, at 12:02 AM, Tim Bray wrote: > > > > http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs > > This Pace was motivated by a talk I had with Bob Wyman today about the > problems the synthofeed-generator community has. > > Summary: > 1. There are multiple plausible use-cases for feeds with duplicate IDs > 2. Pro and Contra > 3. Alternate Paces > 4. Details about this Pace > > 1. Use-Cases > > Here's a stream of stock-market quotes. > > My Portfolio > .... > MSFT > 2005-05-03T10:00:00-05:00 > Bid: 25.20 Ask: 25.50 Last: 25.20 > > MSFT > 2005-05-03T11:00:00-05:00 > Bid: 25.15 Ask: 25.25 Last: 25.20 > > MSFT > 2005-05-03T12:00:00-05:00 > Bid: 25.10 Ask: 25.15 Last: 25.10 > > > > You could also imagine a stream of weather readings. Bob's actual > here-and-now today use-case from PubSub is earthquakes, an entry > describes an earthquake and they keep re-issuing it as new info about > strength/location comes in. > > Some people only care about the most recent version of the entry, > others might want to see all of them. Basically, each atom:entry > element describes the same Entry, only at a different point in time. > > You could argue that in some cases, these are representations of the > Web resources identified by the atom:id URI, but I don't think we need > to say that explicitly. > > Yes, you could think of alternate ways of representing stock quotes or > any of the other use-cases but this is simple and direct and > idiomatic. > > 2. Pro and Contra > > Given that I issued the consensus call rejecting the last attempt to > do this, which was PaceRepeatIdInDocument, I felt nervous about > revisiting the issue. So I went and reviewed the discussion around > that one, which I extracted and placed at > http://www.tbray.org/tmp/RepeatID.txt for the WG's convenience. > > Reviewing that discussion, I'm actually not impressed. There were a > few -1's but very few actual technical arguments about why this > shouldn't be done. The most common was "Software will screw this up". > On reflection, I don't believe that. You have a bunch of Entries, > some of them have the same ID and are distinguished by datestamp. > Some software will show the latest, some will show all of them, the > good software will allow switching back and forth. Doesn't seem like > rocket science to me. > > So here's how I see it: there are plausible use cases for doing this, > and one of the leading really large-scale implementors in the space > (PubSub) wants to do this right now. Bob's been making strong claims > about not being able to use Atom if this restriction remains in place. > > I believe strongly that if there's something that implementors want to > do, standards shouldn't get in the way unless there's real > interoperability damage. I'm certainly prepared to believe that this > could cause interoperability damage, but to date I haven't seen any > convincing arguments that it will. I think that if we nonetheless > forbid it, people who want to do this will (a) use RSS instead of > Atom, (b) cook up horrible kludges, or (c) ignore us and just do it. > > So my best estimate is that the cost of allowing dupes is probably > much lower than the cost of forbidding them. > > Finally, our charter does say that we're also supposed to specify how > you'd go about archiving feeds, and AllowDuplicateIDs makes this > trivial. I looked around and failed to find how we claimed we were > going to do that while still forbidding duplicates, but it's possible > I missed that. > > 3. Alternate Paces > > I didn't want to just revive PaceRepeatIdInDocument, because it used > the word "version" in what I thought was kind of a sloppy way, and > because it wasn't current against format-08. I don't like either > PaceDuplicateIDWithSource or ...WithSource2, they are complicated and > don't really meet PubSub's needs anyhow. So I'm strongly -1 on both > of those. Yes, that means that if this Pace fails, we'll allow no > duplicates at all. I prefer either "dupes OK" or "no dupes" to "dupes > OK in the following circumstances"; cleaner. > > 4. Details > > Section 4.1.2 of format-08 says that atom:entry "represents an > individual entry". The Pace says that if you have dupes, they > "represent the same entry", which I think is consistent with both the > letter and spirit of 4.1.2. > > The Pace discourages duplicate timestamps without resorting to MUST > language, because accidents can happen; this allows software to throw > such entries on the floor while positively encouraging noisy > complaining. On the other hand, if the WG wanted either to insist on > a MUST here or remove the discouragement altogether I could live with > that. > > Finally, it makes it clear that if there are entries with duplicate > atom:id, software is free to display all or a subset, and calls out > the likely common case where you discard all but the most recent. If > I were Brent Simmons or equivalent, I'd be coding up a button where > you can arrange to show them all or just one. > > > From owner-atom-syntax@mail.imc.org Thu May 5 11:34:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10311 for ; Thu, 5 May 2005 11:34: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 j45FS8X1018131; Thu, 5 May 2005 08:28: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 j45FS8Pj018129; Thu, 5 May 2005 08:28:08 -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 j45FS7Tf018123 for ; Thu, 5 May 2005 08:28:08 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j45FSK9R024569; Thu, 5 May 2005 11:28:20 -0400 Message-ID: <427A3B7E.4020001@intertwingly.net> Date: Thu, 05 May 2005 11:27:58 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceTextShouldBeProvided References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> In-Reply-To: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.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 Antone Roundy wrote: > > +1 except for one thing: In section 4.1.2, I'd suggest something along > these lines: > > atom:entry elements which do not contain an atom:content element, or > whose atom:content element's type attribute indicates a MIME media type, > SHOULD contain an atom:summary element. Incorporated. Thanks! - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 11:34:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10385 for ; Thu, 5 May 2005 11:34: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 j45FS0TC018118; Thu, 5 May 2005 08:28: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 j45FS04H018117; Thu, 5 May 2005 08:28:00 -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 j45FS0lx018111 for ; Thu, 5 May 2005 08:28:00 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 68278 invoked by uid 17064); 5 May 2005 15:28:00 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 15:28:00 -0000 Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: AtomPubIssuesList for 2005/05/05 Date: Thu, 5 May 2005 17:07:36 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Can you add PaceAlternateLinkWeakening. It was discussed but I never put it on the wiki. Henry On 5 May 2005, at 13:17, Sam Ruby wrote: > > *************************** REMINDER ****************************** > ** Use more specific subject lines when responding to this note! ** > *************************** REMINDER ****************************** > > First the meat... here's the new atom pub issues list, conveniently > sorted into categories: > > EntryId: > http://intertwingly.net/wiki/pie/PaceAllowDuplicateIDs > http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource2 > http://intertwingly.net/wiki/pie/PaceDuplicateIDWithSource > http://intertwingly.net/wiki/pie/PaceExplainDuplicateIds > > FeedId: > http://intertwingly.net/wiki/pie/PaceFeedIdOrAlternate > http://intertwingly.net/wiki/pie/PaceFeedIdOrSelf > http://intertwingly.net/wiki/pie/PaceOptionalFeedLink > > Provenance: > http://intertwingly.net/wiki/pie/PaceOriginalAttribute > http://intertwingly.net/wiki/pie/PaceSourceRecs > > Status: > http://intertwingly.net/wiki/pie/PaceEntryState > http://intertwingly.net/wiki/pie/PacePubControl > http://intertwingly.net/wiki/pie/PacePubStatusResource > > Text: > http://intertwingly.net/wiki/pie/PaceBriefExample > http://intertwingly.net/wiki/pie/PaceCoConstraintsAreBad > http://intertwingly.net/wiki/pie/PaceOptionalSummary > http://intertwingly.net/wiki/pie/PaceRecommendPlainTextContent > http://intertwingly.net/wiki/pie/PaceTextShouldBeProvided > > Recommended for Closure: > http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly > http://intertwingly.net/wiki/pie/PaceXmlContentWrapper > > Now for some administrivia. No progress was made on the last > published issued list[1], so I've gone ahead and marked those > issues that were recommended for closure, closed; and those > currently under discussion were moved back to Needing to Revisit. > > Next, I'd like to remind everybody that last call for the Atom > Format went out. Operationally, what this means is that the > secretary and co-chairs are going to be increasingly reluctant to > revisit things simply because somebody wants to bring them up > again. What that means is that in order to successfully bring up > an issue, you need to do a little homework. Demonstrate that you > have revisited the previous discussion, and that you either have > something new to add, or can point out some evidence that the > previous consensus call was made in error. > > Tim has taken the opportunity to lead by example on this one with > PaceAllowDuplicateIDs. The secretary and co-chairs all are in > agreement that the XhtmlDiv related paces don't meet this > criteria. If anyone disagrees, what we would like to ask is that > you follow Tim's lead. > > Because we are in last call, I've scheduled everything related to > the Format document. As one of the status paces touches on the > format, I've scheduled all three. All we need to resolve now is > the extent to which this is going to affect the format document. > > I believe that PaceBriefExample is truly editorial, meaning that > the editors can act on this at their discretion. > > - Sam Ruby > > [1] http://www.imc.org/atom-syntax/mail-archive/msg13691.html > > From owner-atom-syntax@mail.imc.org Thu May 5 11:35:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10455 for ; Thu, 5 May 2005 11:35: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 j45FRuqx018107; Thu, 5 May 2005 08:27: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 j45FRus9018106; Thu, 5 May 2005 08:27:56 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FRtv6018098 for ; Thu, 5 May 2005 08:27:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so264919wra for ; Thu, 05 May 2005 08:27:50 -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=Cy17ZRZhDfe8VT7Zg8BL0tpi/OOIavlTiT4n3Wt2jD7j0lh9gU5I+PkLs0pXzcdl3WbWzphyq8/ZA1X4RySXOdOy7zPNMJ5Gk3HMqO3025KEMdz4xI9w6f4J/lC4Tjb43DQWNVqleEF6A5QGmjd/IBpSdMMgnVUz4CvTgoS3l0I= Received: by 10.54.40.63 with SMTP id n63mr56352wrn; Thu, 05 May 2005 08:27:50 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 08:27:50 -0700 (PDT) Message-ID: <68fba5c5050505082741e31fa5@mail.gmail.com> Date: Thu, 5 May 2005 11:27:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: PaceTextShouldBeProvided Cc: atom-syntax@imc.org In-Reply-To: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45FRtv6018100 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Antone Roundy wrote: > > +1 except for one thing: In section 4.1.2, I'd suggest something along > these lines: > > atom:entry elements which do not contain an atom:content element, or > whose atom:content element's type attribute indicates a MIME media > type, SHOULD contain an atom:summary element. This Pace is incompatible with PaceOptionalSummary and incomplete. -1. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 11:36:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10526 for ; Thu, 5 May 2005 11:36: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 j45FQnfF018034; Thu, 5 May 2005 08:26: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 j45FQnb0018033; Thu, 5 May 2005 08:26:49 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FQnQh018017 for ; Thu, 5 May 2005 08:26:49 -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 <2005050515264301600dtkrse>; Thu, 5 May 2005 15:26:43 +0000 Date: Thu, 5 May 2005 09:26:42 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceSourceRecs From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <153AFB3A-BD7A-11D9-AC04-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 Looks good, but perhaps the recommendations could be slightly different: Start by calculating the the language of the atom:feed and the atom:entry. Second, if the language of atom:entry isn't the same as the aggregate feed, set it. Third, if the language of atom:feed isn't the same as the atom:entry, set it. Same process with the Base IRI. This process would prevent unnecessary duplication. From owner-atom-syntax@mail.imc.org Thu May 5 11:41:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11125 for ; Thu, 5 May 2005 11:41: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 j45FZQHx018698; Thu, 5 May 2005 08:35: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 j45FZQ5g018697; Thu, 5 May 2005 08:35:26 -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 j45FZPjY018691 for ; Thu, 5 May 2005 08:35:26 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:57873 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1229011AbVEEPfY (ORCPT ); Thu, 5 May 2005 18:35:24 +0300 In-Reply-To: References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5e42af79b9753227a1d601c57f04c998@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henri Sivonen Subject: Re: Atom feed refresh rates Date: Thu, 5 May 2005 18:35:08 +0300 To: Walter Underwood 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 May 5, 2005, at 16:24, Walter Underwood wrote: > --On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim > wrote: >> >> Not to be flippant, but we have one that's widely available. It's >> called the Expires header. > > You need the information outside of HTTP. To quote from the RSS spec > for ttl: > > This makes it possible for RSS sources to be managed by a > file-sharing > network such as Gnutella. > > Caching information is about knowing when your client cache is stale, > regardless of how you got the feed. Virtually everyone with IP connectivity can do HTTP, and HTTP has the Expires header. If this feature is important to you, why would you switch to a transfer protocol that doesn't have the feature? (I am not claiming anything about the actual Gnutella features.) To me, the "what if the feed is not over HTTP" argumentation seems theoretical over-generalization. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Thu May 5 11:41:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11143 for ; Thu, 5 May 2005 11:41: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 j45FZ4DP018683; Thu, 5 May 2005 08:35: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 j45FZ4rK018682; Thu, 5 May 2005 08:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FZ4WT018669 for ; Thu, 5 May 2005 08:35:04 -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 <2005050515345801400878sje>; Thu, 5 May 2005 15:34:58 +0000 Date: Thu, 5 May 2005 09:34:57 -0600 Subject: Re: PaceAllowDuplicateIDs 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: <3C699177-BD7B-11D9-AC04-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, May 5, 2005, at 09:15 AM, Eric Scheid wrote: >> Have a look here: >> http://en.wikipedia.org/w/index.php?title=Main_Page&action=history >> >> There you have a reverse chrono list, each with an author, date, and >> summary. Looks an awful lot like each one is an entry to me. > > and looks to me like a stream of meta-data concerning the one entry to > me. > > and not distinct and separable entries like you'd find in your every > day > blog. > > Henry has the right idea -- the spec should allow both kinds, rather > than > trying to shoe-horn everything into the one viewpoint of what is an > entry. > +1 -- allow the publisher to decide which model fits their intent. From owner-atom-syntax@mail.imc.org Thu May 5 11:43:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11494 for ; Thu, 5 May 2005 11:43: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 j45Fd3gu018934; Thu, 5 May 2005 08:39: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 j45Fd3lU018933; Thu, 5 May 2005 08:39:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pyramid-02.kattare.com (pyramid-02.kattare.com [69.59.195.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45Fd0qQ018926 for ; Thu, 5 May 2005 08:39:02 -0700 (PDT) (envelope-from dave.johnson@rollerweblogger.org) Received: from [192.168.1.103] (cpe-024-211-236-180.nc.res.rr.com [24.211.236.180]) (authenticated bits=0) by pyramid-02.kattare.com (8.12.10/8.12.11) with ESMTP id j45Fcxns006602 for ; Thu, 5 May 2005 08:38:59 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <080261f7bfddd3131c686e830ba65601@Sun.COM> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> Content-Transfer-Encoding: 7bit From: Dave Johnson Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 11:38:54 -0400 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 Immediately after sending this message, I had a rush of second thoughts. My point #2 is not very well thought out. I think it applies for things like earthquake data, but when Atom feeds represent blog entries or articles (in an archive or an Atom Protocol feed) the ID represents the article not an event in the blog entry's life. So, you can discount my second reason against the pace. - Dave On May 5, 2005, at 11:27 AM, David M Johnson wrote: > > I'm -1 on PaceAllowDuplicateIDs > > Reasons: > > 1) We're supposed to be standardizing current practice not inventing > new things. Current best practice is to have unique IDs and current > software (e.g. Javablogs.com) is predicated on this practice. I know, > this practice is not followed widely enough, but that is another > matter. > > 2) I think it is *much* more useful to think of an Atom Entry as an > event that occurred at a specific time. Typically, an event is the > publication of an article or blog entry on the web. For example: > > event: CNET published article > subject: CNET > object: article > > But an event it could also represent other events. > > event: delivery van delivers package > subject: delivery van > object: package > > event: alarm system sends warning > subject: alarm system > object: warning > > event: server sends load warning > subject: server > object: load warning > > If you think of Atom Entries as events, then it makes sense to > consider the Atom Entry ID to be the ID of the event, not the ID of > the subject or object of the event. Events are unique (you can't have > more than one version of an event) and can be assigned GUIDs and > therefore you cannot have more than one entry with the same ID. > > In the case of earthquake data, each new data report is a new event. > > event: agency reports earthquake data > subject: agency > object: earthquake data > > The ID is the ID of the "data reported" event not the ID of the > earthquake. > > We don't know what subjects and objects people are going to use in the > future, so we can't specify Atom elements or IDs for subjects and > objects -- that's what extensions are for. If you want to create a > feed to syndicate information about earthquakes, then you introduce an > extension for uniquely identifying earthquakes. The same goes for > earthquakes. > > - Dave > > > > On May 5, 2005, at 12:02 AM, Tim Bray wrote: > >> >> >> >> http://www.intertwingly.net/wiki/pie/PaceAllowDuplicateIDs >> >> This Pace was motivated by a talk I had with Bob Wyman today about >> the problems the synthofeed-generator community has. >> >> Summary: >> 1. There are multiple plausible use-cases for feeds with duplicate IDs >> 2. Pro and Contra >> 3. Alternate Paces >> 4. Details about this Pace >> >> 1. Use-Cases >> >> Here's a stream of stock-market quotes. >> >> My Portfolio >> .... >> MSFT >> 2005-05-03T10:00:00-05:00 >> Bid: 25.20 Ask: 25.50 Last: 25.20 >> >> MSFT >> 2005-05-03T11:00:00-05:00 >> Bid: 25.15 Ask: 25.25 Last: 25.20 >> >> MSFT >> 2005-05-03T12:00:00-05:00 >> Bid: 25.10 Ask: 25.15 Last: 25.10 >> >> >> >> You could also imagine a stream of weather readings. Bob's actual >> here-and-now today use-case from PubSub is earthquakes, an entry >> describes an earthquake and they keep re-issuing it as new info about >> strength/location comes in. >> >> Some people only care about the most recent version of the entry, >> others might want to see all of them. Basically, each atom:entry >> element describes the same Entry, only at a different point in time. >> >> You could argue that in some cases, these are representations of the >> Web resources identified by the atom:id URI, but I don't think we >> need to say that explicitly. >> >> Yes, you could think of alternate ways of representing stock quotes >> or any of the other use-cases but this is simple and direct and >> idiomatic. >> >> 2. Pro and Contra >> >> Given that I issued the consensus call rejecting the last attempt to >> do this, which was PaceRepeatIdInDocument, I felt nervous about >> revisiting the issue. So I went and reviewed the discussion around >> that one, which I extracted and placed at >> http://www.tbray.org/tmp/RepeatID.txt for the WG's convenience. >> >> Reviewing that discussion, I'm actually not impressed. There were a >> few -1's but very few actual technical arguments about why this >> shouldn't be done. The most common was "Software will screw this >> up". On reflection, I don't believe that. You have a bunch of >> Entries, some of them have the same ID and are distinguished by >> datestamp. Some software will show the latest, some will show all of >> them, the good software will allow switching back and forth. Doesn't >> seem like rocket science to me. >> >> So here's how I see it: there are plausible use cases for doing this, >> and one of the leading really large-scale implementors in the space >> (PubSub) wants to do this right now. Bob's been making strong claims >> about not being able to use Atom if this restriction remains in >> place. >> >> I believe strongly that if there's something that implementors want >> to do, standards shouldn't get in the way unless there's real >> interoperability damage. I'm certainly prepared to believe that this >> could cause interoperability damage, but to date I haven't seen any >> convincing arguments that it will. I think that if we nonetheless >> forbid it, people who want to do this will (a) use RSS instead of >> Atom, (b) cook up horrible kludges, or (c) ignore us and just do it. >> >> So my best estimate is that the cost of allowing dupes is probably >> much lower than the cost of forbidding them. >> >> Finally, our charter does say that we're also supposed to specify how >> you'd go about archiving feeds, and AllowDuplicateIDs makes this >> trivial. I looked around and failed to find how we claimed we were >> going to do that while still forbidding duplicates, but it's possible >> I missed that. >> >> 3. Alternate Paces >> >> I didn't want to just revive PaceRepeatIdInDocument, because it used >> the word "version" in what I thought was kind of a sloppy way, and >> because it wasn't current against format-08. I don't like either >> PaceDuplicateIDWithSource or ...WithSource2, they are complicated and >> don't really meet PubSub's needs anyhow. So I'm strongly -1 on both >> of those. Yes, that means that if this Pace fails, we'll allow no >> duplicates at all. I prefer either "dupes OK" or "no dupes" to >> "dupes OK in the following circumstances"; cleaner. >> >> 4. Details >> >> Section 4.1.2 of format-08 says that atom:entry "represents an >> individual entry". The Pace says that if you have dupes, they >> "represent the same entry", which I think is consistent with both the >> letter and spirit of 4.1.2. >> >> The Pace discourages duplicate timestamps without resorting to MUST >> language, because accidents can happen; this allows software to throw >> such entries on the floor while positively encouraging noisy >> complaining. On the other hand, if the WG wanted either to insist on >> a MUST here or remove the discouragement altogether I could live with >> that. >> >> Finally, it makes it clear that if there are entries with duplicate >> atom:id, software is free to display all or a subset, and calls out >> the likely common case where you discard all but the most recent. If >> I were Brent Simmons or equivalent, I'd be coding up a button where >> you can arrange to show them all or just one. >> >> >> > From owner-atom-syntax@mail.imc.org Thu May 5 11:44:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11663 for ; Thu, 5 May 2005 11:44: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 j45FcuXM018923; Thu, 5 May 2005 08:38: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 j45Fcusm018922; Thu, 5 May 2005 08:38:56 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FcsTV018914 for ; Thu, 5 May 2005 08:38:55 -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); Fri, 6 May 2005 01:38:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 01:37:06 +1000 Subject: Re: PaceRecommendPlainTextContent From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <054EBCFF-BD77-11D9-AC04-003065EA6144@geckotribe.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 -1 also. > Abstract > > Text containers and content blocks specifically may contain rich-text, which > must be down-stripped by more basic aggregators. Simply removing tags from > X/HTML streams can however easily truncate meaning as well. I am subscribed to multiple feeds which already down-strip their X/HTML content for their feeds, and definitely agree that such down-stripping does clobber a lot of meaning. This pace, if the recommendation takes effect, would result in yet more publishers down-stripping their rich content at the publishing end. Let a thousand buggy implementations bloom :-( I say leave the down-stripping in the aggregator - that way if it really is awful the user can choose a different aggregator. > The examples are of course construed. Most blogging software doesn't emit such > exotic HTML features. A far more common example (ie. less exotic html) is where
or get stripped. Reading the stripped-text version of that can be quite confusing. e. From owner-atom-syntax@mail.imc.org Thu May 5 11:45:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06183 for ; Thu, 5 May 2005 10:55: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 j45EnUxH014230; Thu, 5 May 2005 07: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 j45EnUjg014229; Thu, 5 May 2005 07:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45EnTeY014209 for ; Thu, 5 May 2005 07:49: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 (rwcrmhc11) with SMTP id <2005050514492401300529n6e>; Thu, 5 May 2005 14:49:24 +0000 Date: Thu, 5 May 2005 08:49:22 -0600 Subject: Re: status paces 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: <68fba5c5050505061343359155@mail.gmail.com> 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 Thursday, May 5, 2005, at 07:13 AM, Robert Sayre wrote: > Throw them all back. No reason we can't do this in an extension > element. +1 From owner-atom-syntax@mail.imc.org Thu May 5 12:07:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13978 for ; Thu, 5 May 2005 12:07: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 j45FtCpP020545; Thu, 5 May 2005 08:55: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 j45FtCmc020544; Thu, 5 May 2005 08:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45FtB8b020524 for ; Thu, 5 May 2005 08:55:11 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45Frin7005284; Thu, 5 May 2005 16:53:55 +0100 (BST) In-Reply-To: References: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> <72F9DD66-7A14-4216-A7A1-11872B0A038F@mac.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82523F74-7313-4264-94CD-B879144795A9@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 16:53:46 +0100 To: Henry Story X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 4:22 pm, Henry Story wrote: > If you don't want to keep a history of the entries all you need to > do is drop all but the > latest entry with the same id. There is nothing more to it. Just > show the user the last > one you came across. But, if we follow Eric's model of how a wiki changelog should be defined, I'll be missing entries in the log, because several different entries have the same id. Ergo, the user interface and data model for the new type of feed this proposal permits is very different. > This proposal permits this, and it does not harm anyone else. It harms everyone, by allowing a second, unrelated data model in Atom feeds. They may not be posting today, but I assure you, when other aggregator authors get the first user complaints about how Eric's wiki log displays incompletely in their program, they'll forgive Dave Winer everything. Graham From owner-atom-syntax@mail.imc.org Thu May 5 12:09:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14379 for ; Thu, 5 May 2005 12:09: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 j45FxKW4020913; Thu, 5 May 2005 08:59: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 j45FxKBo020912; Thu, 5 May 2005 08:59: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-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 j45FxEKn020902 for ; Thu, 5 May 2005 08:59:15 -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 j45FxEi7007693 for ; Thu, 5 May 2005 09:59:14 -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 <0IG0001FFXQQGA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 09:59:14 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG00004YXQP8A@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 09:59:14 -0600 (MDT) Date: Thu, 05 May 2005 09:00:18 -0700 From: Tim Bray Subject: Re: Atom feed refresh rates In-reply-to: <5e42af79b9753227a1d601c57f04c998@iki.fi> To: Henri Sivonen Cc: atom-syntax@imc.org, Walter Underwood Message-id: <823a58f5123fb0f43d3d2078ab3e30df@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <5e42af79b9753227a1d601c57f04c998@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Warning: we are into the end-game. What really counts is the set of outstanding Paces. When Paul and I are going through the list to figure out consensus calls, emails that don't have a Pace in the Subject line are apt to get ignored. So I'm not sure this endless thread entitled "feed refresh rates" is doing anyone any good unless it can coalesce around a Pace. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 12:22:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15735 for ; Thu, 5 May 2005 12:22: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 j45GEtH0021711; Thu, 5 May 2005 09:14: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 j45GEtN6021710; Thu, 5 May 2005 09:14:55 -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 j45GEs9o021699 for ; Thu, 5 May 2005 09:14:54 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so296661wra for ; Thu, 05 May 2005 09:14:43 -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=PrI+JXMmn/W4IYqAuIgy71ZBNhE44bzTABHRASCJJr9t0oYP8XAyiY1IHwyqwGzidXnw7oE2Ms42Wd8mi6WVSoSPX1GIIBpofJPxoXrC7KlNUPJGN/XGSMZTOTbFXceq/E5SflLrM91STRS88wjOBwHhQgbspZ0qixxDd0UR2Ok= Received: by 10.54.30.40 with SMTP id d40mr282141wrd; Thu, 05 May 2005 09:14:42 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 09:14:39 -0700 (PDT) Message-ID: <68fba5c505050509147b74a542@mail.gmail.com> Date: Thu, 5 May 2005 12:14:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: PaceOriginalAttribute Cc: atom-syntax@imc.org In-Reply-To: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45GEt9o021705 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Antone Roundy wrote: > > -1. > > I don't see that this solves any problem. I suggest you reread it. Your analysis is deeply flawed. > It may help people avoid > accidentally generating invalid feeds (if we stick to not to allowing > duplication of atom:id within a feed), but it does it by simply > shunting the issue off into a different element which doesn't have > duplication constraints. Incorrect. Think harder about what PubSub services do. They take an entry, and munge it (people like that). They move the feed data to atom:source, and probably add their own extension elements to it. I think they are "forwarding" a message. My proposal preserves the identity of the original message, while requiring the service to mint an identifier for its forwarded message. > It doesn't address the DOS problem--neither > accidental nor intentional. Oh yes it does. Each entry's provenance is documented. The data format accurately states that the intermediary has munged the original entry. > And it doesn't make it any easier to > determine whether or not entries in different feeds with the same > atom:id are really the same entry or not. In fact, it just complicates > the task by requiring the inspection of two elements instead of one. Incorrect. What it does is explicitly state that two different feeds think they are fowarding the same entry. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 12:28:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16091 for ; Thu, 5 May 2005 12:28: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 j45GBD3X021531; Thu, 5 May 2005 09:11: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 j45GBD2a021530; Thu, 5 May 2005 09:11:13 -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 j45GBCZO021521 for ; Thu, 5 May 2005 09:11:12 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 80617 invoked by uid 17064); 5 May 2005 16:11:12 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 16:11:12 -0000 In-Reply-To: <080261f7bfddd3131c686e830ba65601@Sun.COM> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20015BB3-1F8D-4AD1-BA67-782BAE886718@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 18:11:07 +0200 To: David M Johnson X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi Dave, nice to see you participate here. I understand your points, and I myself thought the way you did for a while. [Oops, I see now that you have retracted your point. Oh well. I had already started writing the following] On 5 May 2005, at 17:27, David M Johnson wrote: > I'm -1 on PaceAllowDuplicateIDs Please consider the following points before you vote. > Reasons: > > 1) We're supposed to be standardizing current practice not > inventing new things. Current best practice is to have unique IDs > and current software (e.g. Javablogs.com) is predicated on this > practice. I know, this practice is not followed widely enough, but > that is another matter. Atom is standardizing current practice, but it is also adding some features. For example name spaces and ids. The atom charter also requires us to allow archives [[ * a complete archive of all entries in a feed ]] Graham himself thinks that archives are possible, since he supports the use of an head element. > 2) I think it is *much* more useful to think of an Atom Entry as an > event that occurred at a specific time. Typically, an event is the > publication of an article or blog entry on the web. For example: > > event: CNET published article > subject: CNET > object: article > > But an event it could also represent other events. > > event: delivery van delivers package > subject: delivery van > object: package > > event: alarm system sends warning > subject: alarm system > object: warning > > event: server sends load warning > subject: server > object: load warning > > If you think of Atom Entries as events, then it makes sense to > consider the Atom Entry ID to be the ID of the event, not the ID of > the subject or object of the event. You are right. There are two types of objects that we need to think about: A- the event/state of a resource at a particular time B- the thing that makes these different states the state of the same thing Clearly we need (B) or else all the talk about an entry changing over time (atom:updated) would not make sense. So let us start off, as I did a long time ago, by thinking that the the id of an entry uniquely identifies the event/state of the entry. For every id there can be only one and only one "...." representation. That id is that representation. It is, if you wish, the name of a state of something else... and that would be? I think it is clear that one of the roles of the id is to make it possible for an entry to be moved from one web site to another, so that if your blog service provider lets you down, you can still refer to the entry even when you have moved it to a different "alternate" position. Graham has made such a point quite often. Entries it has often been said can change, but the id remains the same. I think this is clearly the consensus on this list. So the id URI is what identifies the different "..." representations as being representations of the same thing. > Events are unique (you can't have more than one version of an > event) and can be assigned GUIDs and therefore you cannot have more > than one entry with the same ID. yes. But I don't think that this is the consensus on this group. The good thing is that you can achieve the same identification of a state through the combination of the id and the modification time. [here I noticed that you had changed your mind, anyway. I think I had exactly the same thought as you did when I first started thinking about this. ] > In the case of earthquake data, each new data report is a new event. > > event: agency reports earthquake data > subject: agency > object: earthquake data > > The ID is the ID of the "data reported" event not the ID of the > earthquake. > > We don't know what subjects and objects people are going to use in > the future, so we can't specify Atom elements or IDs for subjects > and objects -- that's what extensions are for. If you want to > create a feed to syndicate information about earthquakes, then you > introduce an extension for uniquely identifying earthquakes. The > same goes for earthquakes. > > - Dave > > From owner-atom-syntax@mail.imc.org Thu May 5 12:31:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16275 for ; Thu, 5 May 2005 12:31: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 j45GKmWu022137; Thu, 5 May 2005 09:20: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 j45GKmaf022136; Thu, 5 May 2005 09:20:48 -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 j45GKmNL022130 for ; Thu, 5 May 2005 09:20:48 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 02A424F028; Thu, 5 May 2005 12:20:46 -0400 (EDT) Date: Thu, 5 May 2005 12:20:46 -0400 From: Dan Brickley To: Henri Sivonen Cc: Walter Underwood , atom-syntax@imc.org Subject: Re: Atom feed refresh rates Message-ID: <20050505162046.GG7680@homer.w3.org> References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <5e42af79b9753227a1d601c57f04c998@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e42af79b9753227a1d601c57f04c998@iki.fi> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Henri Sivonen [2005-05-05 18:35+0300] > > On May 5, 2005, at 16:24, Walter Underwood wrote: > > >--On May 5, 2005 8:07:15 AM -0500 Mark Pilgrim > >wrote: > >> > >>Not to be flippant, but we have one that's widely available. It's > >>called the Expires header. > > > >You need the information outside of HTTP. To quote from the RSS spec > >for ttl: > > > > This makes it possible for RSS sources to be managed by a > >file-sharing > > network such as Gnutella. > > > >Caching information is about knowing when your client cache is stale, > >regardless of how you got the feed. > > Virtually everyone with IP connectivity can do HTTP, and HTTP has the > Expires header. If this feature is important to you, why would you > switch to a transfer protocol that doesn't have the feature? (I am not > claiming anything about the actual Gnutella features.) To me, the "what > if the feed is not over HTTP" argumentation seems theoretical > over-generalization. +1 FWIW various P2P/filesharing protocols use HTTP, eg. Kazaa and others make use of HTTP's ability to request a byte range, handy if you're requesting chunks of the same file from different servers. Those who care to have HTTP header semantics show up in other environments can do various things (eg. reflect into an XML namespace). But it doesn't seem to me to be core business of the AtomPub WG to do this work... [googles a bit] OK it looks like Gnutella also uses HTTP for the file download part of it's protocol, fwiw. (including Range: header) http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf Dan From owner-atom-syntax@mail.imc.org Thu May 5 12:38:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16791 for ; Thu, 5 May 2005 12:38: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 j45GUKJl022923; Thu, 5 May 2005 09:30: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 j45GUK3M022922; Thu, 5 May 2005 09:30:20 -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 j45GUJwd022911 for ; Thu, 5 May 2005 09:30:19 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so811008wri for ; Thu, 05 May 2005 09:30: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M6bFtm5H8XjlPNPiLOnr/SEs6Fafs7L5wK4Q8rAHB/atD34aCTFiHf33r2jYbPgOJZqitqccA2fp9H0tfnjRwgvX6iWz+f/nPlxopj5meCrlVTduGXFmHmZojnqNoiMqDPB8p33JHq45m23TmPSiU+HrdfK4rrLqR+SojeqYdm0= Received: by 10.54.154.14 with SMTP id b14mr278965wre; Thu, 05 May 2005 09:30:13 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 09:30:13 -0700 (PDT) Message-ID: <14be96d3050505093062084be@mail.gmail.com> Date: Thu, 5 May 2005 11:30:13 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates In-Reply-To: <20050505162046.GG7680@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <5e42af79b9753227a1d601c57f04c998@iki.fi> <20050505162046.GG7680@homer.w3.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45GUJwd022917 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Dan Brickley wrote: > [googles a bit] OK it looks like Gnutella also uses HTTP for the file > download part of it's protocol, fwiw. (including Range: header) > http://www9.limewire.com/developer/gnutella_protocol_0.4.pdf You mean RSS's element is even more useless than I thought? I didn't think that was possible. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 12:45:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17278 for ; Thu, 5 May 2005 12: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 j45GcGQN023449; Thu, 5 May 2005 09:38: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 j45GcG3u023448; Thu, 5 May 2005 09:38:16 -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 j45GcGA4023442 for ; Thu, 5 May 2005 09:38:16 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 88856 invoked by uid 17064); 5 May 2005 16:38:13 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.102.88]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 16:38:13 -0000 In-Reply-To: <82523F74-7313-4264-94CD-B879144795A9@mac.com> References: <6DC0960F-460A-4C70-BDD9-9698396FBBCE@bblfish.net> <72F9DD66-7A14-4216-A7A1-11872B0A038F@mac.com> <82523F74-7313-4264-94CD-B879144795A9@mac.com> Mime-Version: 1.0 (Apple Message framework v728) 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: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 18:38:08 +0200 To: Graham X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 17:53, Graham wrote: > On 5 May 2005, at 4:22 pm, Henry Story wrote: > >> If you don't want to keep a history of the entries all you need to >> do is drop all but the >> latest entry with the same id. There is nothing more to it. Just >> show the user the last >> one you came across. >> > > But, if we follow Eric's model of how a wiki changelog should be > defined, I'll be missing entries in the log, because several > different entries have the same id. Ergo, the user interface and > data model for the new type of feed this proposal permits is very > different. If your tool (Is it Shrook2? [1]) only shows people the latest version available to you of an entry, then by showing them only the latest version, Shrook2 will be giving the user what he is expecting. When your news reader currently reads feeds on the internet what does it do with changed entries? Either it keeps the older version around, for the user to browse, or it does not. If your users don't mind you throwing away the older versions of an entry, then they won't mind you throwing away the older versions of the above entries either. There is no difference in the behavior between allowing changed entries across feed documents and changed entries inside a feed document. People who place two entries with the same id inside a feed document should be aware that tools like yours will have the behavior they do, and that this is ok. Other people may be interested in looking at things historically. They will get a historical viewer and be happy with it. I think the current proposal is good exactly because it allows the wiki people to express what they want to express correctly. Namely how their wiki entry is changing over time. >> This proposal permits this, and it does not harm anyone else. >> > > It harms everyone, by allowing a second, unrelated data model in > Atom feeds. They may not be posting today, but I assure you, when > other aggregator authors get the first user complaints about how > Eric's wiki log displays incompletely in their program, they'll > forgive Dave Winer everything. Again, has anyone yet complained to you that you have not kept a historical and browse-able track record of how the entries Shrook2 is looking at have changed over time? Clearly they could, as you sometimes let them know that an entry that they already have read has been updated. They could ask you what the changes were, no? How it changed, etc. If your users don't care that much about the history of an entry, then you can dump all but the latest entry. Or you could just keep the last two entries, so that you can show them a diff. > > Graham HJStory http://bblfish.net/blog/ [1] http://www.fondantfancies.com/apps/shrook/ From owner-atom-syntax@mail.imc.org Thu May 5 12:46:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17347 for ; Thu, 5 May 2005 12: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 j45Gci35023474; Thu, 5 May 2005 09:38: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 j45GciLM023473; Thu, 5 May 2005 09:38:44 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45GcgB9023464 for ; Thu, 5 May 2005 09:38:43 -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); Fri, 6 May 2005 02:38:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 02:38:38 +1000 Subject: Re: PaceAllowDuplicateIDs From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <82523F74-7313-4264-94CD-B879144795A9@mac.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 6/5/05 1:53 AM, "Graham" wrote: >> This proposal permits this, and it does not harm anyone else. > > It harms everyone, by allowing a second, unrelated data model in Atom > feeds. They may not be posting today, but I assure you, when other > aggregator authors get the first user complaints about how Eric's > wiki log displays incompletely in their program, they'll forgive Dave > Winer everything. Many wiki's offer options in displaying their change log with either most recent changes only, or all changes. Both models are commonly supported because some people want to see notifications of all changes, while others just want to see the most recent change. That is part of wiki culture, all the way back to ward's wiki. It wouldn't be surprising to find the same options made available for wiki logs in rss. Hey, here's one right now.... http://www.intertwingly.net/wiki/pie/RecentChanges?action=rss_rc Apparently, if you add an "unique=1" URL parameter you get a list of changes where page names are unique, i.e. where only the latest change of each page is reflected. e. From owner-atom-syntax@mail.imc.org Thu May 5 12:52:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17742 for ; Thu, 5 May 2005 12:52: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 j45GhdDB023796; Thu, 5 May 2005 09:43: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 j45GhdwA023795; Thu, 5 May 2005 09:43:39 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45GhcQv023767 for ; Thu, 5 May 2005 09:43: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 (sccrmhc13) with SMTP id <2005050516433201600dra1ae>; Thu, 5 May 2005 16:43:32 +0000 Date: Thu, 5 May 2005 10:43:31 -0600 Subject: Re: PaceOriginalAttribute 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: <68fba5c505050509147b74a542@mail.gmail.com> 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 Thursday, May 5, 2005, at 10:14 AM, Robert Sayre wrote: > On 5/5/05, Antone Roundy wrote: >> It may help people avoid >> accidentally generating invalid feeds (if we stick to not to allowing >> duplication of atom:id within a feed), but it does it by simply >> shunting the issue off into a different element which doesn't have >> duplication constraints. > > Incorrect. Think harder about what PubSub services do. They take an > entry, and munge it (people like that). They move the feed data to > atom:source, and probably add their own extension elements to it. I > think they are "forwarding" a message. My proposal preserves the > identity of the original message, while requiring the service to mint > an identifier for its forwarded message. Okay, the forwarded message has it's own all-in-one-element identifier. This sounds useful...except that someone may accidentally or intentionally duplicate that identifier too. >> It doesn't address the DOS problem--neither >> accidental nor intentional. > > Oh yes it does. Each entry's provenance is documented. The data format > accurately states that the intermediary has munged the original entry. Maybe I am missing something, but if so...well, by definition, I'm not seeing it. Let's look at an example. Say your aggregator sees these in different feeds: foo:foo foo:bar I'm the real thing bar:bar bar:foo foo:foo foo:bar I may be an imposter Do you display one or both? How would your decision making process differ from if you were to see the following in the second case? bar:bar foo:bar foo:foo I may be an imposter And what if we added a third case? qwerty:bar bar:foo foo:foo foo:bar I'm definitely an imposter >> And it doesn't make it any easier to >> determine whether or not entries in different feeds with the same >> atom:id are really the same entry or not. In fact, it just >> complicates >> the task by requiring the inspection of two elements instead of one. > > Incorrect. What it does is explicitly state that two different feeds > think they are fowarding the same entry. > Yeah, they think they are, or at least claim to think so. But isn't that the same thing that is stated if you see the following in two feeds? bar:bar foo:bar foo:foo I may be an imposter This says that this feed is (or at least claims it is) forwarding the entry with the id "foo:bar" from the feed "foo:foo". I am honestly trying to see more in this, but as yet, I don't. From owner-atom-syntax@mail.imc.org Thu May 5 12:53:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17917 for ; Thu, 5 May 2005 12:53: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 j45GlXiu024061; Thu, 5 May 2005 09:47: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 j45GlXJn024060; Thu, 5 May 2005 09:47:33 -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 j45GlXv5024054 for ; Thu, 5 May 2005 09:47:33 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j45Gllgu002931; Thu, 5 May 2005 12:47:48 -0400 Message-ID: <427A4E1C.5090304@intertwingly.net> Date: Thu, 05 May 2005 12:47:24 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: PaceTextShouldBeProvided References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> In-Reply-To: <68fba5c5050505082741e31fa5@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: > On 5/5/05, Antone Roundy wrote: > >>+1 except for one thing: In section 4.1.2, I'd suggest something along >>these lines: >> >>atom:entry elements which do not contain an atom:content element, or >>whose atom:content element's type attribute indicates a MIME media >>type, SHOULD contain an atom:summary element. > > This Pace is incompatible with PaceOptionalSummary and incomplete. -1. Something a little less curt would be appreciated. The stated abstract of PaceOptionalSummary (i.e., "removing the requirement for ") is met. In your mind, this equates to completely optional. That has yet to be conclusively established. What concerns me more, however, is that interoperability issues that PaceOptionalSummary not only creates, but also uncovered during its discussion. Unless there is some plan for addressing these interoperability issues (and by that, I mean something more constructive than "That's fine, but we're not here to tailor the format to your app."), then perhaps BOTH paces are incomplete. There are a number of ways to finesse the identification of the issue into the spec. For example, take a look at how Tim worded PaceAllowDuplicateIDs. Producers are put on effectively put on notice that if they include multiple entries with the same ID, that some or all of them may be ignored. How should we convey a similar sentiment about the reality that entries without a readily available textual representation may suffer the same fate? - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 13:33:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22022 for ; Thu, 5 May 2005 13: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 j45HKQ5L028578; Thu, 5 May 2005 10:20: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 j45HKQWh028577; Thu, 5 May 2005 10:20:26 -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 j45HKQfU028563 for ; Thu, 5 May 2005 10:20:26 -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 <2005050517202001400g26hke>; Thu, 5 May 2005 17:20:20 +0000 Date: Thu, 5 May 2005 11:20:19 -0600 Subject: Re: PaceAllowDuplicateIDs 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: <22A11496-BD74-11D9-AC04-003065EA6144@geckotribe.com> 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 Thursday, May 5, 2005, at 08:44 AM, Antone Roundy wrote: > If we accept this Pace, are we going to do anything to address the DOS > issue for aggregated feeds? Bob, if I may direct a few question to you, since you have the most experience with this issue: if PaceAllowDuplicateIDs is adopted, how would you anticipate that PubSub would go about handling entries with the same atom:id coming from different feeds? What if each appears to be claiming to be the original feed for the entry? What if both are getting aggregated into the same feed, but your system doesn't think they're really the same entry? I'm in favor of the Pace, as far as it goes, but was surprised to see that it doesn't talk about these issues, given that it was motivated by a conversation with you. From owner-atom-syntax@mail.imc.org Thu May 5 13:34:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22065 for ; Thu, 5 May 2005 13:34: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 j45HNM6Y028957; Thu, 5 May 2005 10:23: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 j45HNMmF028956; Thu, 5 May 2005 10:23: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 j45HNL0f028939 for ; Thu, 5 May 2005 10:23:21 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so340587wra for ; Thu, 05 May 2005 10:23:16 -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=OLS+ze5V4matw4g4fwWfMduyma21vo64AZndXDNuglVghetaNbq+KzvyiX7jI7Bt0rUrQJn8NT+xay/LM39TU1Hx0X5Lh/83bdFkB6xb7wAhIxVxT01VPADlr+wlwCHI4eO82up3oDnpU6ic2Qq+k41EJyHrn/XFGHCpZ7B1ERs= Received: by 10.54.70.2 with SMTP id s2mr311912wra; Thu, 05 May 2005 10:23:15 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 10:23:15 -0700 (PDT) Message-ID: <68fba5c5050505102373bad099@mail.gmail.com> Date: Thu, 5 May 2005 13:23:15 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceTextShouldBeProvided Cc: atom-syntax@imc.org In-Reply-To: <427A4E1C.5090304@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45HNL0f028951 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Sam Ruby wrote: > > > This Pace is incompatible with PaceOptionalSummary and incomplete. -1. > > Something a little less curt would be appreciated. > > The stated abstract of PaceOptionalSummary (i.e., "removing the > requirement for ") is met. In your mind, this equates to > completely optional. That has yet to be conclusively established. Well, consider the name of the Pace, and then consider this sentence: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. It would be deeply bogus to accept a Pace whose sole action was to remove a normative requirement, and simultaneously accept a Pace that puts it back in. Seems obvious to me. > What concerns me more, however, is that interoperability issues that > PaceOptionalSummary not only creates, but also uncovered during its > discussion. We know exactly what issues optional content has, because all of the other formats have it. > Unless there is some plan for addressing these interoperability issues > (and by that, I mean something more constructive than "That's fine, but > we're not here to tailor the format to your app."), then perhaps BOTH > paces are incomplete. Let's enumerate the issues, rather than insist they exist. Frankly, I seriously doubt that anyone with customers will outright reject a title-only feed. > There are a number of ways to finesse the identification of the issue > into the spec. For example, take a look at how Tim worded > PaceAllowDuplicateIDs. Producers are put on effectively put on notice > that if they include multiple entries with the same ID, that some or all > of them may be ignored. I don't think PaceAllowDuplicateIDs successfully finessed the issue. > How should we convey a similar sentiment about the reality that entries > without a readily available textual representation may suffer the same fate? So, we're looking for some way to say "provide as much information as you can." The problem with saying SHOULD is that we purport to know how much information the publisher can provide. It would be very easy to explain this issue in the spec, and I have no objection to doing so. Why do we need the RFC2119 words? Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 13:41:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22728 for ; Thu, 5 May 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 j45HOLJZ029076; Thu, 5 May 2005 10:24: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 j45HOLhl029075; Thu, 5 May 2005 10:24:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45HOKKs029051 for ; Thu, 5 May 2005 10:24:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45HNT7B016745; Thu, 5 May 2005 18:23:45 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90483E4F-EE9A-42E2-A5F3-D579092F3956@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 18:23:31 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 5:38 pm, Eric Scheid wrote: > Many wiki's offer options in displaying their change log with > either most > recent changes only, or all changes. Both models are commonly > supported > because some people want to see notifications of all changes, while > others > just want to see the most recent change. That is part of wiki > culture, all > the way back to ward's wiki. OK that makes sense. I still think it's the wrong way to model a change log as a feed. My other two criticisms still stand: "atom:updated is used by the publisher to show what they consider a significant change. The user, on the other hand, probably wants to see the latest version, reliably, even if the publisher disagrees that the change was significant. This is the core problem with Tim's proposal. There is no way to create an aggregator that works in the way the user expects." "Finally, at pubsub, what happens when they download an entry from one feed, then the user edits it, but doesn't modify atom:updated, then they download the new entry from a second feed associated with the site? Different content, identical atom:ids, identical atom:updated => Invalid feed. They're not in any better position than they were before. This doesn't even solve the problem it's meant to." Basically, atom:updated doesn't properly differentiate versions, and the way atom:updated is being used by the proposal doesn't gel with the actual spec of the element. Graham From owner-atom-syntax@mail.imc.org Thu May 5 13:59:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24577 for ; Thu, 5 May 2005 13:59: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 j45HqYvs033111; Thu, 5 May 2005 10:52: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 j45HqY7x033110; Thu, 5 May 2005 10:52: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 j45HqXbq033104 for ; Thu, 5 May 2005 10:52:33 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 13304 invoked by uid 17064); 5 May 2005 17:52:33 -0000 Received: from unknown (HELO [192.168.0.9]) ([81.249.225.89]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 May 2005 17:52:33 -0000 In-Reply-To: <90483E4F-EE9A-42E2-A5F3-D579092F3956@mac.com> References: <90483E4F-EE9A-42E2-A5F3-D579092F3956@mac.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4607042C-CCD7-4DA3-A3FD-0184AA1501C2@bblfish.net> Cc: Eric Scheid , atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 5 May 2005 19:52:28 +0200 To: Graham X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 19:23, Graham wrote: > On 5 May 2005, at 5:38 pm, Eric Scheid wrote: >> Many wiki's offer options in displaying their change log with >> either most >> recent changes only, or all changes. Both models are commonly >> supported >> because some people want to see notifications of all changes, >> while others >> just want to see the most recent change. That is part of wiki >> culture, all >> the way back to ward's wiki. >> > > OK that makes sense. I still think it's the wrong way to model a > change log as a feed. Cool. Rational argument does sometimes work :-) > My other two criticisms still stand: What was wrong with the arguments I gave? > "atom:updated is used by the publisher to show what they consider a > significant change. The user, on the other hand, probably wants to > see the latest version, reliably, even if the publisher disagrees > that the change was significant. This is the core problem with > Tim's proposal. There is no way to create an aggregator that works > in the way the user expects." I think this is relatively simple. If the publisher publishes a feed document with two entries containing the same id and the same atom:updated timestamp then he is claiming that there are no significant changes between them. In fact the same is true if he publishes those two entries in two different feed documents. So there really is no problem here that is particular to PaceAllowDuplicateIDs. If the feed reader wants reliability he can't get more reliability by making the spec tighter than the feed producer is able to give. If the feed producer is unreliable, then nothing in the spec can change that. The feed producer must understand that by creating feeds where the above described situation is true will lead to erratic behavior. If there is a significant difference between those entries then he had better change the time stamp. Otherwise his unreliable behavior will create unreliable effects. Nothing new here. > "Finally, at pubsub, what happens when they download an entry from > one feed, then the user edits it, but doesn't modify atom:updated, > then they download the new entry from a second feed associated with > the site? Different content, identical atom:ids, identical > atom:updated => Invalid feed. They're not in any better position > than they were before. This doesn't even solve the problem it's > meant to." I imagine this is simple, but I will leave the full details for Bob to answer. My guess is that if Bob comes across the above situation, then he will be confronted by a situation where he has according to the publisher two entries that are not significantly different. He can therefore choose between them randomly, and just add one of them. The publisher after all thinks that there are no significant differences between them. If the initial publisher thought that there were significant differences between these entries, then he should have given them different time stamps. > Basically, atom:updated doesn't properly differentiate versions, > and the way atom:updated is being used by the proposal doesn't gel > with the actual spec of the element. I think the above argument shows that there is in fact nothing wrong with atom:updated. We just have to think in terms of interoperability and not in terms of Platonic forms. Henry Story http://bblfish.net/blog/ From owner-atom-syntax@mail.imc.org Thu May 5 14:00:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24690 for ; Thu, 5 May 2005 14:00: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 j45HrwR9033310; Thu, 5 May 2005 10:53: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 j45Hrw6K033309; Thu, 5 May 2005 10:53:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45HrwWU033291 for ; Thu, 5 May 2005 10:53:58 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j45HrlD16839 for ; Thu, 5 May 2005 10:53:52 -0700 (PDT) Received: from [10.169.186.36] ([10.169.186.36]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IG131N01.I1I for ; Thu, 5 May 2005 10:53:47 -0700 Message-ID: <427A5DAC.4020203@aol.net> Date: Thu, 05 May 2005 10:53:48 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <20050505143035.GE23305@tartarus.org> In-Reply-To: <20050505143035.GE23305@tartarus.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 I assume an HTTP Expires header for Atom content will work and play well with caches such as the Google Accelerator (http://webaccelerator.google.com/). I'd also guess that a syntax-level tag won't. Is this important? The HTML solution for people who could not implement Expires: seems to be META tags with in theory equivalent information. Though in practice the whole thing is a mess, this seems like a conceptually simple workaround. Is there something obviously wrong with it? -John From owner-atom-syntax@mail.imc.org Thu May 5 14:09:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25530 for ; Thu, 5 May 2005 14:09: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 j45I2KfO034637; Thu, 5 May 2005 11:02: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 j45I2Kf7034636; Thu, 5 May 2005 11:02:20 -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 j45I2JO8034607 for ; Thu, 5 May 2005 11:02:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so363649wra for ; Thu, 05 May 2005 11:02: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=uDUGU7gVkXx+ywIbTiUuDQ6+xG8YLX9Epr8oFXy16y45neGqz8T+a+pHW3VYAN2T+Nj5Pznv01qlWW7ZoLGvlctGYv8joKaAQsd4MJf283y7JlXAZa9JNovfeOocW+WxO2Mkf1gfc541iyLqV65/oKxZL8y++9OrlGzolDGM01g= Received: by 10.54.5.9 with SMTP id 9mr327607wre; Thu, 05 May 2005 11:02:13 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 11:02:13 -0700 (PDT) Message-ID: <68fba5c50505051102a5b6934@mail.gmail.com> Date: Thu, 5 May 2005 14:02:13 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceTextShouldBeProvided Cc: atom-syntax , Tim Bray , Paul Hoffman , sah@428cobrajet.net In-Reply-To: <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45I2JO8034624 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Graham wrote: > On 5 May 2005, at 6:23 pm, Robert Sayre wrote: > > > It would be deeply bogus to accept a Pace whose sole action was to > > remove a normative requirement, and simultaneously accept a Pace that > > puts it back in. Seems obvious to me. > > Not really. Assuming PaceOptionalSummary is accepted, there are two > completely valid outcomes: > > 1. PaceTextShouldBeProvided rejected => summaries are not required, > and textual content is not encouraged > 2. PaceTextShouldBeProvided accepted => summaries are not required, > but textual content is encouraged > > I don't see a conflict there. What's wrong with accepting two similar > paces because one corrects the flaws in the other? Graham, that's just not true. It wasn't called PaceSummariesAreNotRequired, was it? It materially changes the only action PaceOptionalSummary takes. They are not compatible. In fact, let's get the chairs to clarify this. > > So, we're looking for some way to say "provide as much information as > > you can." The problem with saying SHOULD is that we purport to know > > how much information the publisher can provide. It would be very easy > > to explain this issue in the spec, and I have no objection to doing > > so. > > SHOULD here means "must unless you absolutely can't". We've covered lots of perfectly valid reasons not to include a summary, and we've heard from implementors that actually prefer its absence. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 14:09:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25591 for ; Thu, 5 May 2005 14:09: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 j45I1b9b034506; Thu, 5 May 2005 11:01: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 j45I1bQj034503; Thu, 5 May 2005 11:01:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45I1Zaf034487 for ; Thu, 5 May 2005 11:01:35 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j45I1TD17283 for ; Thu, 5 May 2005 11:01:29 -0700 (PDT) Received: from [10.169.186.36] ([10.169.186.36]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IG13EG02.41P; Thu, 5 May 2005 11:01:28 -0700 Message-ID: <427A5F79.4080906@aol.net> Date: Thu, 05 May 2005 11:01:29 -0700 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Eric Scheid , atom-syntax Subject: Re: PaceAllowDuplicateIDs References: <90483E4F-EE9A-42E2-A5F3-D579092F3956@mac.com> In-Reply-To: <90483E4F-EE9A-42E2-A5F3-D579092F3956@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: > > On 5 May 2005, at 5:38 pm, Eric Scheid wrote: > >> Many wiki's offer options in displaying their change log with either >> most >> recent changes only, or all changes. Both models are commonly supported >> because some people want to see notifications of all changes, while >> others >> just want to see the most recent change. That is part of wiki >> culture, all >> the way back to ward's wiki. > > > OK that makes sense. I still think it's the wrong way to model a > change log as a feed. > > My other two criticisms still stand: > > "atom:updated is used by the publisher to show what they consider a > significant change. The user, on the other hand, probably wants to > see the latest version, reliably, even if the publisher disagrees > that the change was significant. This is the core problem with Tim's > proposal. There is no way to create an aggregator that works in the > way the user expects." Just a thought: On the other hand, perhaps this is an opportunity to operationally define "significant change": A change which results in a new version being exposed on one's feed. If you think your users would care about seeing the change, then change the atom:updated field and 'republish' by adding to the feed. If not, just change your content and don't republish. Examples of this might include: Fixing irrelevant typos. Changing character set encodings. Changing formatting to match a new style guide. -John From owner-atom-syntax@mail.imc.org Thu May 5 15:53:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06157 for ; Thu, 5 May 2005 15:53: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 j45JiUsr050208; Thu, 5 May 2005 12:44: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 j45JiUnk050207; Thu, 5 May 2005 12:44: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45JiT4J050190 for ; Thu, 5 May 2005 12:44:29 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so926570wri for ; Thu, 05 May 2005 12:44:18 -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=o/NxZrT7AmBGRkfWPWTBXtKfulx1yA/ecb07DhhL5rsGaoVwwfUzhmHB1a6HAY0Kzjewx2Q9a0/KOC7byjoJqdnqzTYmYgMqP0ibfuy1b6zpmiatPS1mMfVNQB4uyJwLRpml1z3SI+Nh+wuuie4zjx62B6UFDIfil9jZg/hWFhA= Received: by 10.54.21.69 with SMTP id 69mr352998wru; Thu, 05 May 2005 12:44:17 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Thu, 5 May 2005 12:44:17 -0700 (PDT) Message-ID: <14be96d3050505124496cc7dd@mail.gmail.com> Date: Thu, 5 May 2005 14:44:17 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates In-Reply-To: <427A5DAC.4020203@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <20050505143035.GE23305@tartarus.org> <427A5DAC.4020203@aol.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45JiT4J050202 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, John Panzer wrote: > I assume an HTTP Expires header for Atom content will work and play well > with caches such as the Google Accelerator > (http://webaccelerator.google.com/). I'd also guess that a syntax-level > tag won't. Is this important? Yes, and yes. This is exactly the sort of software that we're talking about when we say that HTTP's native caching mechanism is widely supported. All the proxies in the world (which is what Google's Web Accelerator is, except it runs on your own machine and listens on port 9100) are able to reduce network traffic and therefore make the end user's experience faster because they understand and respect the HTTP caching mechanism. (Google Web Accelerator does other things too, like proxying requests through Google's servers. And what are those servers running? Another caching HTTP proxy.) Many ISPs do this at the ISP level, both to reduce their own upstream bandwidth costs and to make their end users happier. Many corporations do this as well (I would bet good money that IBM does it). At one time, I even had Squid installed on my home network to do this. HTTP caching works. > The HTML solution for people who could not implement Expires: seems to > be META tags with in theory equivalent information. Though in practice > the whole thing is a mess, this seems like a conceptually simple > workaround. Is there something obviously wrong with it? Other than being a God-awful mess? No, there's nothing wrong with it. ;) -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 5 16:30:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10139 for ; Thu, 5 May 2005 16:30: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 j45KM0lD054914; Thu, 5 May 2005 13:22: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 j45KM0D7054913; Thu, 5 May 2005 13:22:00 -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 j45KLx3h054895 for ; Thu, 5 May 2005 13:21:59 -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.12.11/8.12.11) with ESMTP id j45KLq2b099433 for ; Thu, 5 May 2005 22:21:58 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <427A805E.5080303@w3future.com> Date: Thu, 05 May 2005 22:21:50 +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 Syntax'" Subject: Re: Autodiscovery References: 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 Why not support hyperlinks too? So besides: also: Main Atom feed Most webpages already have a hyperlink to the feed, so they'd only need to add two attributes. It would be a waste to have to duplicate the information in the document head. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Thu May 5 16:34:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10858 for ; Thu, 5 May 2005 16:34: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 j45KRnI6055781; Thu, 5 May 2005 13:27: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 j45KRnpH055780; Thu, 5 May 2005 13:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45KRmq1055762 for ; Thu, 5 May 2005 13:27:48 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j45KRfpb029478 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 16:27:42 -0400 (EDT) Message-ID: <427A8491.60703@atrus.org> Date: Thu, 05 May 2005 16:39:45 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: "atom-syntax Syntax'" Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> In-Reply-To: <427A805E.5080303@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: > > Why not support hyperlinks too? > > So besides: > > > > also: > > href="/xml/index.atom">Main Atom feed > > Most webpages already have a hyperlink to the feed, so they'd only > need to add two attributes. It would be a waste to have to duplicate > the information in the document head. > The intent of the head element is to indicate a feed that serves as a substitute for the page you're currently viewing. This other case is locating all feeds linked to from a page. For that, the type attribute should be sufficient to indicate that you're linking to a feed. -Nikolas 'Atrus' Coukouma -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Thu May 5 16:43:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13248 for ; Thu, 5 May 2005 16:43: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 j45KZXW0057526; Thu, 5 May 2005 13: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 j45KZXLZ057525; Thu, 5 May 2005 13:35:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45KZUr9057508 for ; Thu, 5 May 2005 13:35:32 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j45KZReD000500; Thu, 5 May 2005 16:35:28 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCG50379 (AUTH bob@wyman.us); Thu, 5 May 2005 16:35:24 -0400 (EDT) Message-Id: <200505052035.DCG50379@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'fantasai'" , "'Atom Syntax'" , , Subject: RE: Autodiscovery, real-world examples Date: Thu, 5 May 2005 16:35:21 -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: <4279CAD8.5030301@inkedblade.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVRRZXvtiSFgjNQRRyaNjiA7DrHcQAV8X5A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Fantasia wrote: > Making it possible for pages to link to non-alternate > autodiscoverable feeds without using rel="alternate" -- and > encouraging this practice -- would make it possible for UAs to > actually /discriminate/ between alternate and non-alternate feeds. > Right now they can't, because everything is indiscriminately marked > as "alternate". +1. Being able to distinguish between "alternates" for the current page and "just other feeds" that are linked to from the page would be very useful. Also, in the case where there are multiple real alternates to the page, it would be useful to be able to mark which feed is "preferred." My concern here is the transition between Atom V0.3 and Atom V1.0. A page might link to feeds in both formats (as well as RSS, RDF, etc.) but it would be good to know which of these feeds is considered the "preferred" feed by the producer. In this way, people could migrate off the older feeds and one day we'd actually be able to stop producing multiple feeds on each site. We should also consider providing such "preferred" links in Atom, RSS, RDF, etc. feeds. I'd like to be able to publish something in my Atom 0.3 feeds that tell people "Don't keep reading this feed. Read the Atom 1.0 feed instead..." bob wyman From owner-atom-syntax@mail.imc.org Thu May 5 17:20:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19144 for ; Thu, 5 May 2005 17:20: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 j45LDMjK061725; Thu, 5 May 2005 14:13: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 j45LDM5e061724; Thu, 5 May 2005 14:13:22 -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 j45LDJs5061711 for ; Thu, 5 May 2005 14:13:20 -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.12.11/8.12.11) with ESMTP id j45LDC2H009008 for ; Thu, 5 May 2005 23:13:18 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <427A8C66.8000001@w3future.com> Date: Thu, 05 May 2005 23:13:10 +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 Syntax'" Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427A8491.60703@atrus.org> In-Reply-To: <427A8491.60703@atrus.org> 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 Nikolas 'Atrus' Coukouma wrote: > Sjoerd Visscher wrote: > > >>Why not support hyperlinks too? >> >>So besides: >> >> >> >>also: >> >>>href="/xml/index.atom">Main Atom feed >> >>Most webpages already have a hyperlink to the feed, so they'd only >>need to add two attributes. It would be a waste to have to duplicate >>the information in the document head. >> > > The intent of the head element is to indicate a feed that serves as a > substitute for the page you're currently viewing. > > This other case is locating all feeds linked to from a page. For that, > the type attribute should be sufficient to indicate that you're linking > to a feed. No, a hyperlink with a rel attribute means the same as a link element. The HTML spec describes the rel attribute on the a element thus: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Thu May 5 17:21:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19232 for ; Thu, 5 May 2005 17:21: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 j45LB7vP061347; Thu, 5 May 2005 14:11: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 j45LB6d1061345; Thu, 5 May 2005 14:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45LB0ep061288 for ; Thu, 5 May 2005 14:11:00 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j45LAdpb000044 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 17:10:45 -0400 (EDT) Message-ID: <427A8EA8.6090509@atrus.org> Date: Thu, 05 May 2005 17:22:48 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fantasai CC: Atom Syntax , pilgrim@gmail.com, Tim.Bray@Sun.COM Subject: Re: Autodiscovery - different cases should use different rel References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> <42795178.1080401@atrus.org> <4279CAD8.5030301@inkedblade.net> In-Reply-To: <4279CAD8.5030301@inkedblade.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 fantasai wrote: > > Nikolas 'Atrus' Coukouma wrote: > > > I think you have three separate cases of autodiscovery: > > * the feed for *this* page - handled by this autodiscovery proposal > > * other feeds the author reads or recommends - usually done by linking > > to a separate file. Some quick searching reveals one suggestion to use > > rel="blogroll" for this > > * any other feeds linked to for any reason at all - seems to be little > > interest in > > > > I don't think combining these three into one case will do any good. In > > fact, I think it's confusing and unusable. > > That makes sense. > > I think that you're missing one key use case, though: autodiscovery of > a blog's main feed from sub-parts of it. A lot of websites link to the > main blog feed from individual entries, for example, and they're doing > it with rel="alternate", which is not appropriate. It frustrates me that > there is no way of changing these links to not use rel="alternate". An excellent point. Perhaps these should use rel="home" :) > > And for linking to other pages.. Here's a real-world example: > The mozilla.org main page is an example > of where rel="alternate" is a problem. There were three feeds on > it: "Announcements", "mozillaZine News", and "Mozilla Weblogs" > (now only two). Each one is an alternate of a web page, but of > _other_ pages (http://www.mozilla.org/news.html, > http://www.mozillazine.org/, and http://planet.mozilla.org/ > respectively), not the mozilla.org > front page. The last few headlines for each feed are listed on > the front page, and the designer felt it was appropriate for > autodiscovery to work on this page -- but it is not appropriate > for rel="alternate" to be used for those autodiscovery links. > They are not alternate representations of the front page. These other feeds are suggestion/blogroll cases. > > Here's another example: > LiveJournal creates a "Friends" page, where it aggregates the > blogs of all the users you've designated as "friends". It could > create an Atom feed representing this aggregation, and mark that > as rel="alternate". Actually, a patch was just committed to do this ;) > What could also be useful, however, would be > linking to each of these blogs' feeds individually as well so > that they're represented individually in my aggregator and it > can aggregate them itself. Unlike the pre-aggregated feed, > however, these are not alternate representations of the Friends > page, and shouldn't be marked as such. I think this is a suggestion/blogroll case. > > Making it possible for pages to link to non-alternate autodiscoverable > feeds without using rel="alternate" -- and encouraging this practice -- > would make it possible for UAs to actually /discriminate/ between > alternate and non-alternate feeds. Right now they can't, because > everything is indiscriminately marked as "alternate". > > ~fantasai I've basically concluded that the keys to autodiscovery of feeds, in the general sense, should not be three (rel, type, and href), but two (type and href). Type is plenty of specification that it's a feed. Claiming it's relationship as "feed" doesn't seem correct. There are a few mime-types used, and the one for atom (application/atom+xml) will be an official standard as soon as the draft is accepted by the IETF. The value of rel, if present, will vary based on relation * the feed for *this* page - rel="alternate" * the feed for main feed for this blog, in general - rel="home" * other feeds the author reads or recommends - rel="suggested" * any other feeds linked to for any reason at all - no rel, just the type and href Is this acceptable? I'm not completely happy with "home" and "suggested" because they're not specified as link types in the HTML specs [1]. Sadly, it seems the HTML authors didn't consider these cases. "home" seems to be an informal standard. Close matches in the HTML list are "index", "contents", and "start". All of these are inaccurate, but I think "contents" is the best fit. "suggested" is just my own idea. I mentioned the rel="blogroll" before, but that seems overly specific. "bookmark" seems to be the closest match in the HTML list. Not in the way it's defined in the list, but the way people usually think of it. I'm not sure what the heck the HTML spec is indicating with: "Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document." That definition makes it a close match to "home," I suppose. Really, the definition there is so vague that it's useless. I can think of a couple other cases: - Comment feeds, which are only generated by a few pieces of software so far. These are close to, but not quite, alternate. they're usually missing the entry itself, from what I understand. I think more work needs to be done with comment feeds in general before we worry too much about linking to them. -Changelogs. Wikis are one of the use cases for Atom, yes? Perhaps they should have a rel="changelog" or something similar. [1] http://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Thu May 5 17:43:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23005 for ; Thu, 5 May 2005 17:43: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 j45LW7p7064156; Thu, 5 May 2005 14:32: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 j45LW7cX064155; Thu, 5 May 2005 14:32:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45LW6JW064137 for ; Thu, 5 May 2005 14:32:07 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j45LVxpb000300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 17:32:00 -0400 (EDT) Message-ID: <427A93A4.6020601@atrus.org> Date: Thu, 05 May 2005 17:44:04 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: "atom-syntax Syntax'" Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427A8491.60703@atrus.org> <427A8C66.8000001@w3future.com> In-Reply-To: <427A8C66.8000001@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: > Nikolas 'Atrus' Coukouma wrote: > >> Sjoerd Visscher wrote: >> >>> Why not support hyperlinks too? >>> >>> So besides: >>> >>> >>> >>> also: >>> >>> >> href="/xml/index.atom">Main Atom feed >>> >>> Most webpages already have a hyperlink to the feed, so they'd only >>> need to add two attributes. It would be a waste to have to duplicate >>> the information in the document head. >>> >> >> The intent of the head element is to indicate a feed that serves as a >> substitute for the page you're currently viewing. >> >> This other case is locating all feeds linked to from a page. For that, >> the type attribute should be sufficient to indicate that you're linking >> to a feed. > > > No, a hyperlink with a rel attribute means the same as a link element. > The HTML spec describes the rel attribute on the a element thus: > > This attribute describes the relationship from the current document to > the anchor specified by the href attribute. The value of this > attribute is a space-separated list of link types. What I was getting at is that link elements in the head are usually a kind of metadata intended for the user agent. Hyperlinks are usually meant to be displayed. This proposal is aimed at providing metadata for the user agent, so it makes since to put it in a link element in the head. I'm on the fence about whether or not a link element should be the *required*, even when a hyperlink is present in the body. Supporting general hyperlinks starts making more sense if we have cases other than alternate (I've written elsewhere about this) because the amount of duplicated information is much greater. If you're only supporting feeds that serve as an alternate form of the content, then it makes sense to repeat one link once just to make the programmer stuck writing the user agent. I'd hope that whatever library/toolkit they're using supports XPath queries. Using them makes it easy to pluck out anything with type="application/atom+xml" and an href property. It's worth noting that in recent versions of XHTML, anything with an href property is a hyperlink. There's no requirement to use an anchor or an xlink:link element. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Thu May 5 17:43:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23011 for ; Thu, 5 May 2005 17:43: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 j45LZFLl064493; Thu, 5 May 2005 14:35: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 j45LZFrF064492; Thu, 5 May 2005 14:35:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45LZENT064483 for ; Thu, 5 May 2005 14:35:14 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j45LZ5pb000339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 17:35:05 -0400 (EDT) Message-ID: <427A945D.3040104@atrus.org> Date: Thu, 05 May 2005 17:47:09 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nikolas 'Atrus' Coukouma" CC: Sjoerd Visscher , "atom-syntax Syntax'" Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427A8491.60703@atrus.org> <427A8C66.8000001@w3future.com> <427A93A4.6020601@atrus.org> In-Reply-To: <427A93A4.6020601@atrus.org> 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 Nikolas 'Atrus' Coukouma wrote: >I'm on the fence about whether or not a link element should be the >*required*, even when a hyperlink is present in the body. > >Supporting general hyperlinks starts making more sense if we have cases >other than alternate (I've written elsewhere about this) because the >amount of duplicated information is much greater. If you're only >supporting feeds that serve as an alternate form of the content, then it >makes sense to repeat one link once just to make the programmer stuck >writing the user agent. > > correction: "just to make [things easier for] the programmer stuck writing the user agent." -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Thu May 5 18:18:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26570 for ; Thu, 5 May 2005 18:18: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 j45M8lSd068997; Thu, 5 May 2005 15:08: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 j45M8ljj068996; Thu, 5 May 2005 15:08: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 j45M8kbl068990 for ; Thu, 5 May 2005 15:08: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 j45M8kjO000741 for ; Thu, 5 May 2005 16:08:46 -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 <0IG100I54EULMX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:08:46 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG10090LEUL8J@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:08:45 -0600 (MDT) Date: Thu, 05 May 2005 15:09:49 -0700 From: Tim Bray Subject: Re: status paces In-reply-to: <68fba5c5050505061343359155@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050505061343359155@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 5, 2005, at 6:13 AM, Robert Sayre wrote: > > Throw them all back. No reason we can't do this in an extension > element. It would be big mistake to put these in right now. +1. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:34:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29386 for ; Thu, 5 May 2005 18:34: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 j45MR4mu070809; Thu, 5 May 2005 15:27: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 j45MR4Ei070808; Thu, 5 May 2005 15:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45MR45W070800 for ; Thu, 5 May 2005 15:27:04 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from web2.messagingengine.com (web2.internal [10.202.2.211]) by frontend1.messagingengine.com (Postfix) with ESMTP id 677ADC89F72; Thu, 5 May 2005 18:27:02 -0400 (EDT) Received: by web2.messagingengine.com (Postfix, from userid 99) id 967652544; Thu, 5 May 2005 18:26:53 -0400 (EDT) Message-Id: <1115332013.16897.233478798@webmail.messagingengine.com> X-Sasl-Enc: sIutuaXfpglvGNv0/d6SpJscHc8mFPA/g+IhTvC9qYXm 1115332013 From: "James Tauber" To: bob@wyman.us, "'Atom Syntax'" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: <200505052035.DCG50379@ms8.netsolmail.com> Subject: RE: Autodiscovery, real-world examples In-Reply-To: <200505052035.DCG50379@ms8.netsolmail.com> Date: Fri, 06 May 2005 06:26:53 +0800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 5 May 2005 16:35:21 -0400, "Bob Wyman" said: > Being able to distinguish between "alternates" for the current > page and "just other feeds" that are linked to from the page would be > very useful. +1 > Also, in the case where there are multiple real alternates to the > page, it would be useful to be able to mark which feed is "preferred." +0.5 James From owner-atom-syntax@mail.imc.org Thu May 5 18:35:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29711 for ; Thu, 5 May 2005 18:35: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 j45MPu8m070670; Thu, 5 May 2005 15: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 j45MPugr070669; Thu, 5 May 2005 15:25:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45MPtBK070660 for ; Thu, 5 May 2005 15:25: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-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id j45MPmfX090468 for ; Fri, 6 May 2005 00:25:54 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <427A9D6A.5010508@w3future.com> Date: Fri, 06 May 2005 00:25:46 +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 Syntax'" Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427A8491.60703@atrus.org> <427A8C66.8000001@w3future.com> <427A93A4.6020601@atrus.org> In-Reply-To: <427A93A4.6020601@atrus.org> 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 > Supporting general hyperlinks starts making more sense if we have cases > other than alternate (I've written elsewhere about this) because the > amount of duplicated information is much greater. If you're only > supporting feeds that serve as an alternate form of the content, then it > makes sense to repeat one link once just to make the programmer stuck > writing the user agent. I'd hope that whatever library/toolkit they're > using supports XPath queries. Using them makes it easy to pluck out > anything with type="application/atom+xml" and an href property. Maybe atom needs only one link with a rel attribute, but there are others. I have a lot of hyperlinks with rel attributes on my weblog homepage, and I refuse to repeat them all as link elements. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Thu May 5 18:48:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02920 for ; Thu, 5 May 2005 18:48: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 j45MaHpM072222; Thu, 5 May 2005 15:36: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 j45MaH6K072221; Thu, 5 May 2005 15:36: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 j45MaGdW072215 for ; Thu, 5 May 2005 15:36: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 j45MaGi7002096 for ; Thu, 5 May 2005 16:36:16 -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 <0IG100KBMG4FZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:36:16 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002LJG4FUG@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:36:15 -0600 (MDT) Date: Thu, 05 May 2005 15:37:18 -0700 From: Tim Bray Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary In-reply-to: <68fba5c50505051102a5b6934@mail.gmail.com> To: atom-syntax Message-id: <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 5, 2005, at 11:02 AM, Robert Sayre wrote: >> I don't see a conflict there. What's wrong with accepting two similar >> paces because one corrects the flaws in the other? > > Graham, that's just not true. It wasn't called > PaceSummariesAreNotRequired, was it? It materially changes the only > action PaceOptionalSummary takes. They are not compatible. > > In fact, let's get the chairs to clarify this. Speaking not as the chair but as an interested WG member, I read them about eight times and I do not understand why they are in conflict. Someone please explain, as simply as possible, what the problem is, because I just don't get it. On the face of it, I am inclined to be +1 to both PaceOptionalSummary and PaceTextShouldBeProvided. Note: I totally fail to understand the "Notes" bit at the end of PaceTextShouldBeProvided. It is underspecified to the extent that I can't figure out what language change it is actually saying is necessary. Basically, allowing title-only feeds seems OK to me, and encouraging people to provide text also seems OK to me, so what's the problem? In fact, these seem pretty orthogonal; it seems quite plausible that one could like either of these without liking both. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:53:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03098 for ; Thu, 5 May 2005 18: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 j45MfZDN072945; Thu, 5 May 2005 15:41: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 j45MfZgT072938; Thu, 5 May 2005 15:41: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-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 j45MfW9W072897 for ; Thu, 5 May 2005 15:41:32 -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 j45MfVjO027453 for ; Thu, 5 May 2005 16:41:31 -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 <0IG100K10GD7ZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:31 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:31 -0600 (MDT) Date: Thu, 05 May 2005 15:42:36 -0700 From: Tim Bray Subject: PaceBriefExample To: atom-syntax Syntax Message-id: <15df35fe00aa1f8c8c17c1f808273ac7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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. Precision is good. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:53:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03116 for ; Thu, 5 May 2005 18:53: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 j45MfR8H072836; Thu, 5 May 2005 15:41: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 j45MfRVA072835; Thu, 5 May 2005 15:41:27 -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 j45MfLF9072810 for ; Thu, 5 May 2005 15:41:25 -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 j45MfLi7006414 for ; Thu, 5 May 2005 16:41:21 -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 <0IG100LSQGCXH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:21 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:21 -0600 (MDT) Date: Thu, 05 May 2005 15:42:25 -0700 From: Tim Bray Subject: PacePubStatusResource To: Atom Syntax Message-id: <5fbc6f2ff201ad18d5efbd1cd8af7959@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Mu This is interesting but orthogonal to finalizing the format spec. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:54:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03142 for ; Thu, 5 May 2005 18: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 j45MfY1w072925; Thu, 5 May 2005 15: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 j45MfXZW072914; Thu, 5 May 2005 15:41:33 -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 j45MfQ6I072833 for ; Thu, 5 May 2005 15:41:28 -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 j45MfQjO027364 for ; Thu, 5 May 2005 16:41:26 -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 <0IG100IMDGD1MX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:26 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:25 -0600 (MDT) Date: Thu, 05 May 2005 15:42:29 -0700 From: Tim Bray Subject: PaceOptionalFeedLink To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 There are people who want to publish feeds without rel="alternate" links. I'm against telling people they can't do something they want to do without strong reasons, as in loss of interoperability. I don't see the reasons here as strong enough. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:54:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03172 for ; Thu, 5 May 2005 18:54: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 j45MfZkn072940; Thu, 5 May 2005 15:41: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 j45MfZbd072937; Thu, 5 May 2005 15:41: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 j45MfUjZ072876 for ; Thu, 5 May 2005 15:41:31 -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 j45MfUi7006561 for ; Thu, 5 May 2005 16:41: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 <0IG100K0SGD5ZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:30 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:29 -0600 (MDT) Date: Thu, 05 May 2005 15:42:35 -0700 From: Tim Bray Subject: PaceCoConstraintsAreBad To: atom-syntax Syntax Message-id: <0d0806aa3c012d07b44fd6893cf11e21@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Uh, this one is redundant, right? It's covered by various combinations of other Paces, or am I missing something? -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:54:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03192 for ; Thu, 5 May 2005 18:54: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 j45MfR1S072838; Thu, 5 May 2005 15:41: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 j45MfRjs072837; Thu, 5 May 2005 15:41:27 -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 j45MfNp5072813 for ; Thu, 5 May 2005 15:41:25 -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 j45MfMi7006431 for ; Thu, 5 May 2005 16:41:22 -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 <0IG100KZCGCYZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:22 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:22 -0600 (MDT) Date: Thu, 05 May 2005 15:42:26 -0700 From: Tim Bray Subject: PacePubControl To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 kind of, there was all sorts of discussion over in Atom-Protocol around improvements and extensibility of the various fields; so I don't think work is done. In any case, this is the right place for this stuff, so its discussion is orthogonal to consideration of the Atompub format Format draft. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:54:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03347 for ; Thu, 5 May 2005 18:54: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 j45MfZcP072939; Thu, 5 May 2005 15:41: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 j45MfZBu072936; Thu, 5 May 2005 15:41: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-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 j45MfVaW072887 for ; Thu, 5 May 2005 15:41:32 -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 j45MfUjO027439 for ; Thu, 5 May 2005 16:41: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 <0IG100K0SGD5ZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:30 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:30 -0600 (MDT) Date: Thu, 05 May 2005 15:42:34 -0700 From: Tim Bray Subject: PaceDuplicateIDWithSource To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Either we're OK with duplicates or we're not. If we're not, we shouldn't relax that condition just because they come from different feeds. The definition of atom:id says it's supposed to be *universally* unique, not unique per-source. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03474 for ; Thu, 5 May 2005 18: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 j45MfYA5072924; Thu, 5 May 2005 15: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 j45MfX9L072915; Thu, 5 May 2005 15:41:33 -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 j45MfR3X072834 for ; Thu, 5 May 2005 15:41:28 -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 j45MfRjO027375 for ; Thu, 5 May 2005 16:41: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 <0IG100KZWGD2ZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:27 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:26 -0600 (MDT) Date: Thu, 05 May 2005 15:42:31 -0700 From: Tim Bray Subject: PaceFeedIdOrSelf To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Too complicated, not enough benefit. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03558 for ; Thu, 5 May 2005 18: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 j45MfYSM072923; Thu, 5 May 2005 15: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 j45MfXWg072901; Thu, 5 May 2005 15:41:33 -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 j45MfOiF072822 for ; Thu, 5 May 2005 15:41:28 -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 j45MfOjO027327 for ; Thu, 5 May 2005 16:41:24 -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 <0IG100LT6GCZH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:24 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:23 -0600 (MDT) Date: Thu, 05 May 2005 15:42:28 -0700 From: Tim Bray Subject: PaceOriginalAttribute To: Atom Syntax Message-id: <64a444657a0030e17dae00b60a2de80b@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 I'm not 100% convinced it solves the problems Rob says it does, but it seems cheap, lightweight, and unlikely to cause any harm. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03576 for ; Thu, 5 May 2005 18:55: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 j45MfZ2P072934; Thu, 5 May 2005 15:41: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 j45MfYYZ072932; Thu, 5 May 2005 15:41:34 -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 j45MfUqX072875 for ; Thu, 5 May 2005 15:41:30 -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 j45MfTi7006538 for ; Thu, 5 May 2005 16:41:29 -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 <0IG100IMZGD5MX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:29 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:29 -0600 (MDT) Date: Thu, 05 May 2005 15:42:33 -0700 From: Tim Bray Subject: PaceDuplicateIDWithSource2 To: Atom Syntax Message-id: <9f7f49f576cfeecd648532b68662e68c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Either we're OK with duplicates or we're not. If we're not, we shouldn't relax that condition just because they come from different feeds. The definition of atom:id says it's supposed to be *universally* unique, not unique per-source. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03578 for ; Thu, 5 May 2005 18:55: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 j45MfX3F072921; Thu, 5 May 2005 15: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 j45MfWHd072899; Thu, 5 May 2005 15:41: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 j45MfKZb072807 for ; Thu, 5 May 2005 15:41:28 -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 j45MfKjO027248 for ; Thu, 5 May 2005 16:41:20 -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 <0IG100LS7GCVH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:20 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:19 -0600 (MDT) Date: Thu, 05 May 2005 15:42:23 -0700 From: Tim Bray Subject: PaceRecommendPlainTextContent To: atom-syntax Syntax Message-id: <0f3f1e961dec9807e16e9908ea1ae6fb@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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, ill-formed. The sentiment is worthy but this does not suggest specific language for the draft. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03612 for ; Thu, 5 May 2005 18:55: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 j45MfZ9s072935; Thu, 5 May 2005 15:41: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 j45MfYSE072933; Thu, 5 May 2005 15:41:34 -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 j45MfT4s072874 for ; Thu, 5 May 2005 15:41:30 -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 j45MfSjO027402 for ; Thu, 5 May 2005 16:41:28 -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 <0IG100LTNGD4H4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:28 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:27 -0600 (MDT) Date: Thu, 05 May 2005 15:42:33 -0700 From: Tim Bray Subject: PaceDuplicateIDWithSource2 To: Atom Syntax Message-id: <9f7f49f576cfeecd648532b68662e68c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Either we're OK with duplicates or we're not. If we're not, we shouldn't relax that condition just because they come from different feeds. The definition of atom:id says it's supposed to be *universally* unique, not unique per-source. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03630 for ; Thu, 5 May 2005 18:55: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 j45MfYe9072922; Thu, 5 May 2005 15: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 j45MfXcK072902; Thu, 5 May 2005 15:41:33 -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 j45MfRTO072841 for ; Thu, 5 May 2005 15:41:28 -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 j45MfRjO027383 for ; Thu, 5 May 2005 16:41: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 <0IG100KZWGD2ZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:27 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:27 -0600 (MDT) Date: Thu, 05 May 2005 15:42:32 -0700 From: Tim Bray Subject: PaceEntryState To: Atom Syntax Message-id: <25c235b67bbe0f8017f82d615937198e@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 I want to decouple this stuff from the format spec, i.e. I believe in PacePubControl. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 18:55:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03650 for ; Thu, 5 May 2005 18:55: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 j45MfWMe072905; Thu, 5 May 2005 15: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 j45MfWxe072900; Thu, 5 May 2005 15:41: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 j45MfJ2M072805 for ; Thu, 5 May 2005 15:41:28 -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 j45MfJjO027243 for ; Thu, 5 May 2005 16:41: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 <0IG100LS7GCVH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:19 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002KJGCUZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 16:41:19 -0600 (MDT) Date: Thu, 05 May 2005 15:42:22 -0700 From: Tim Bray Subject: PaceSourceRecs To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Irrespective of whether I agree with this or not, I think the material belongs in an implementor's guide, not the specification. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 19:25:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07078 for ; Thu, 5 May 2005 19:25: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 j45NH8jd078129; Thu, 5 May 2005 16:17: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 j45NH8qk078128; Thu, 5 May 2005 16:17:08 -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 j45NH760078120 for ; Thu, 5 May 2005 16:17:07 -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 j45NH7jO003727 for ; Thu, 5 May 2005 17:17:07 -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 <0IG100K4NI0IZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 17:17:07 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG1002O7I0HZZ@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 17:17:06 -0600 (MDT) Date: Thu, 05 May 2005 16:18:09 -0700 From: Tim Bray Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary In-reply-to: <68fba5c50505051552623360cd@mail.gmail.com> To: atom-syntax Syntax Message-id: <693e52e7e790d1f21f5fc10371b571dc@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 5, 2005, at 3:52 PM, Robert Sayre wrote: > Everything in the proposal section is fine with me, as well. It's that > "Notes" section that's the problem. > >> Note: I totally fail to understand the "Notes" bit at the end of >> PaceTextShouldBeProvided. It is underspecified to the extent that I >> can't figure out what language change it is actually saying is >> necessary. > > That section says is "If PaceOptionalSummary is 'accepted', this Pace > changes summary to SHOULD." That's OK to propose, but you can't accept > both of them. They conflict. No it doesn't, it says something about inserting the phrase "...is either not present or..." which, by the way, I don't understand. Are we looking at the same document? >> Basically, allowing title-only feeds seems OK to me, and encouraging >> people to provide text also seems OK to me, so what's the problem? > > Current spec: MUST contain a summary > after PaceOptionalSummary: MAY contain a summary > after PaceTextShouldBeProvided: SHOULD contain a summary So what you're actually objecting to is the last part of the Pace before the "Impacts" section, that wants 4.1.2 to say that summary SHOULD be there if Content is absent. Or am I missing something? -Tim From owner-atom-syntax@mail.imc.org Thu May 5 19:29:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07569 for ; Thu, 5 May 2005 19: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 j45NLuap079191; Thu, 5 May 2005 16:21: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 j45NLuoi079190; Thu, 5 May 2005 16:21:56 -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 j45NLtIt079169 for ; Thu, 5 May 2005 16:21:56 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so527791wra for ; Thu, 05 May 2005 16:21:50 -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=or2IpmU1Sqo24Launr0tdNCLCbFdGUUnN80rr5dTQgs+tjYVWMgvCtGThBVID4H0vdQUDzpyelydxz+QKgQNoW6BhEQ/Gh5706bcQOwH/9jX1rFAN/kehKydt4xWa0vjiSb/YTO8r9HzNVSLbkr3LeMSkHoVNtHk+Z8UMH/Lhig= Received: by 10.54.40.63 with SMTP id n63mr252576wrn; Thu, 05 May 2005 16:21:50 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 16:21:50 -0700 (PDT) Message-ID: <68fba5c5050505162152be48bd@mail.gmail.com> Date: Thu, 5 May 2005 19:21:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: PaceOriginalAttribute Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505050509147b74a542@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45NLuIt079183 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Antone Roundy wrote: > > > Yeah, they think they are, or at least claim to think so. But isn't > that the same thing that is stated if you see the following in two > feeds? > > > bar:bar > > foo:bar > > foo:foo > > I may be an imposter > > > This says that this feed is (or at least claims it is) forwarding the > entry with the id "foo:bar" from the feed "foo:foo". > > I am honestly trying to see more in this, but as yet, I don't. OK, now let's say you're subscribed to "imposter" in PubSub. bar:bar quux:quux1 foo:foo I may be an imposter quux:quux2 baz:baz I may be an imposter Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 19:31:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07708 for ; Thu, 5 May 2005 19:31: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 j45HoOZr032753; Thu, 5 May 2005 10:50: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 j45HoO3N032752; Thu, 5 May 2005 10:50:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45HoMqi032741 for ; Thu, 5 May 2005 10:50:23 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j45HnN9g025441; Thu, 5 May 2005 18:49:23 +0100 (BST) In-Reply-To: <68fba5c5050505102373bad099@mail.gmail.com> References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceTextShouldBeProvided Date: Thu, 5 May 2005 18:49:23 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 May 2005, at 6:23 pm, Robert Sayre wrote: > It would be deeply bogus to accept a Pace whose sole action was to > remove a normative requirement, and simultaneously accept a Pace that > puts it back in. Seems obvious to me. Not really. Assuming PaceOptionalSummary is accepted, there are two completely valid outcomes: 1. PaceTextShouldBeProvided rejected => summaries are not required, and textual content is not encouraged 2. PaceTextShouldBeProvided accepted => summaries are not required, but textual content is encouraged I don't see a conflict there. What's wrong with accepting two similar paces because one corrects the flaws in the other? > We know exactly what issues optional content has, because all of the > other formats have it. Yes, and we don't like it. A basic title only feed gives you fuck all to work with - it displays poorly when mixed with rich-content feeds, it isn't searchable because there aren't many keywords in the title, etc etc. They cause all sorts of problems. > So, we're looking for some way to say "provide as much information as > you can." The problem with saying SHOULD is that we purport to know > how much information the publisher can provide. It would be very easy > to explain this issue in the spec, and I have no objection to doing > so. SHOULD here means "must unless you absolutely can't". That seems like a perfectly dandy explanation of the intention of encouraging high quality feeds. Graham From owner-atom-syntax@mail.imc.org Thu May 5 19:40:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08359 for ; Thu, 5 May 2005 19:40: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 j45NVLJ0080687; Thu, 5 May 2005 16:31: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 j45NVLp5080686; Thu, 5 May 2005 16:31: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j45NVJ7N080657 for ; Thu, 5 May 2005 16:31:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so531564wra for ; Thu, 05 May 2005 16:31:14 -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=OXRtFShxzpmjSERt6+CTGTveINFFh7vEkstozwQ3zM4+JVCvy+WwXoi++NHUUlPhu1QPCisxTVjumhzwUxRrbPG56oaXaL4WeeNP0N+tD+/AgGLKenVeC/UNzQAqrs0v+u3fo3XG5yF/T/DI5fl0nTLKkjkT++jzXTF17yk4SHo= Received: by 10.54.84.2 with SMTP id h2mr459287wrb; Thu, 05 May 2005 16:31:14 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 16:31:14 -0700 (PDT) Message-ID: <68fba5c505050516314bd3014c@mail.gmail.com> Date: Thu, 5 May 2005 19:31:14 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary Cc: atom-syntax Syntax In-Reply-To: <693e52e7e790d1f21f5fc10371b571dc@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45NVK7N080680 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Tim Bray wrote: > > No it doesn't, it says something about inserting the phrase "...is > either not present or..." which, by the way, I don't understand. Are > we looking at the same document? Ah, it's been updated since I last looked. The proposed text for 4.1.2 didn't used to account for an absent content element. > >> Basically, allowing title-only feeds seems OK to me, and encouraging > >> people to provide text also seems OK to me, so what's the problem? > > > > Current spec: MUST contain a summary > > after PaceOptionalSummary: MAY contain a summary > > after PaceTextShouldBeProvided: SHOULD contain a summary > > So what you're actually objecting to is the last part of the Pace > before the "Impacts" section, that wants 4.1.2 to say that summary > SHOULD be there if Content is absent. Yes. If that SHOULD goes through, it becomes OK to write an Atom Processor that catches fire when summary and content are both absent. That is not what the folks who supported PaceOptionalSummary were advocating. They conflict. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 19:55:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09088 for ; Thu, 5 May 2005 19:55: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 j45NnBHt084364; Thu, 5 May 2005 16: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 j45NnBcn084363; Thu, 5 May 2005 16:49: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j45Nn7MX084282 for ; Thu, 5 May 2005 16:49:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 May 2005 23:49:00 -0000 Received: from xdsl-81-173-228-175.netcologne.de (EHLO klangraum) [81.173.228.175] by mail.gmx.net (mp010) with SMTP; 06 May 2005 01:49:00 +0200 X-Authenticated: #163624 Date: Fri, 6 May 2005 01:52:15 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Atom feed refresh rates Message-ID: <20050505235215.GA2127@klangraum> Mail-Followup-To: Atom Syntax References: <20050504081036.JSZQ1280.aamta05-winn.mailhost.ntl.com@AndyHenderson3> <0659A553-E426-4503-93E9-4C6F7DDF7D6B@mac.com> <540e373205050409321f1624b3@mail.gmail.com> <96d7d77c05050409495e337377@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <96d7d77c05050409495e337377@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: 8bit * Lance Lavandowska [2005-05-04 19:00]: > In the toy aggregator I wrote I played with a scheduler that > tried to throttle itself based on the feeds response. I believe that is the right way to do this, though your algorithm is a little too simple IMHO. A better approach for Atom consumers in absence of applicable HTTP headers would be to intelligently calculate an average update interval based on atom:published / atom:updated / etc. [ Of course, for RSS feeds without pubDate and any applicable HTTP headers, the algorithm is a *lot* more complicated. Something like exponential backoff with a low radix reducing (not resetting) the backoff depending on the number of new items you got would keep the update interval close to an ideal. ] Furthermore I’d suggest not giving users any option to manually change intervals – only a way to force a refresh immediately. This is a usability win. When I started using an aggregator, I never had any idea what value to realistically supply when the aggregator asked me how often I wanted a feed to be refreshed. How is my grandfather supposed to make an intelligent decision? And why should he? The software has all the information it needs to refresh about as often as it can expect to find new content. This entire issue is just a matter of lazy aggregator implementors, IMO. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu May 5 20:31:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11670 for ; Thu, 5 May 2005 20:30: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 j460M6t3090314; Thu, 5 May 2005 17:22: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 j460M6dx090313; Thu, 5 May 2005 17:22:06 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j460M4ej090295 for ; Thu, 5 May 2005 17:22:05 -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, 6 May 2005 10:21:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 10:14:02 +1000 Subject: Re: Autodiscovery - different cases should use different rel From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <427A8EA8.6090509@atrus.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 6/5/05 7:22 AM, "Nikolas 'Atrus' Coukouma" wrote: > I've basically concluded that the keys to autodiscovery of feeds, in the > general sense, should not be three (rel, type, and href), but two (type > and href). Type is plenty of specification that it's a feed. Claiming > it's relationship as "feed" doesn't seem correct. There are a few > mime-types used, and the one for atom (application/atom+xml) will be an > official standard as soon as the draft is accepted by the IETF. Using @type only is not sufficient, since both Atom Feed Documents *and* Atom Entry Documents use the same mime-type. One is a feed, the other is not. Similarly, RSS 1.0 isn't clearly distinguished by mime-type - there are lots of other resources which are 'application/rdf+xml' (eg. FOAF) e. From owner-atom-syntax@mail.imc.org Thu May 5 21:32:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17271 for ; Thu, 5 May 2005 21:32: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 j461MuZE006579; Thu, 5 May 2005 18:22: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 j461MuRX006578; Thu, 5 May 2005 18:22:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j461MtLx006570 for ; Thu, 5 May 2005 18:22:56 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-b-18.princeton.edu ([128.112.34.190]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTrYJ-0001VT-Hj; Thu, 05 May 2005 21:22:51 -0400 Message-ID: <427AC6DE.5090404@inkedblade.net> Date: Thu, 05 May 2005 21:22:38 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nikolas 'Atrus' Coukouma" CC: Atom Syntax , pilgrim@gmail.com, Tim.Bray@Sun.COM Subject: Re: Autodiscovery - different cases should use different rel References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> <42795178.1080401@atrus.org> <4279CAD8.5030301@inkedblade.net> <427A8EA8.6090509@atrus.org> In-Reply-To: <427A8EA8.6090509@atrus.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas 'Atrus' Coukouma wrote: > fantasai wrote: > > An excellent point. Perhaps these should use rel="home" :) > > ... > > The value of rel, if present, will vary based on relation > * the feed for *this* page - rel="alternate" > * the feed for main feed for this blog, in general - rel="home" > * other feeds the author reads or recommends - rel="suggested" > * any other feeds linked to for any reason at all - no rel, just the > type and href > > Is this acceptable? I'm not completely happy with "home" and "suggested" > because they're not specified as link types in the HTML specs [1]. > Sadly, it seems the HTML authors didn't consider these cases. "home" > seems to be an informal standard. Close matches in the HTML list are > "index", "contents", and "start". All of these are inaccurate, but I > think "contents" is the best fit. Actually, I think "start" is the best fit. The main feed is often not a table of contents to the entire weblog, but something partial. It is, however, the "starting point of the collection". BTW, you might want to take a look at http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html ~fantasai From owner-atom-syntax@mail.imc.org Thu May 5 21:40:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17942 for ; Thu, 5 May 2005 21:40: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 j461TChi007534; Thu, 5 May 2005 18:29: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 j461TCAF007533; Thu, 5 May 2005 18:29:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j461TCco007526 for ; Thu, 5 May 2005 18:29:12 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-b-18.princeton.edu ([128.112.34.190]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTreO-0001lJ-Jp for atom-syntax@imc.org; Thu, 05 May 2005 21:29:08 -0400 Message-ID: <427AC85D.7000004@inkedblade.net> Date: Thu, 05 May 2005 21:29:01 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> In-Reply-To: <427A805E.5080303@w3future.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > Why not support hyperlinks too? > > So besides: > > href="/xml/index.atom"> > > also: > > href="/xml/index.atom">Main Atom feed > > Most webpages already have a hyperlink to the feed, so they'd only need > to add two attributes. It would be a waste to have to duplicate the > information in the document head. The difference between and is that - applies to the document as a whole: it indicates a relationship between this document and the href destination. - is a contextual link: it indicates a relationship between the linking context and the href destination. They have different purposes. It is imho perfectly reasonable to limit autodiscovery to s only. It is also perfectly reasonable to link to feeds with , and expect that the UA will recognize it as a feed rather than a generic XML document. ~fantasai From owner-atom-syntax@mail.imc.org Thu May 5 21:51:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18833 for ; Thu, 5 May 2005 21:51: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 j461baFM009419; Thu, 5 May 2005 18: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 j461babw009418; Thu, 5 May 2005 18:37: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j461bY2R009380 for ; Thu, 5 May 2005 18:37:35 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 06 May 2005 01:37:25 -0000 Received: from xdsl-81-173-228-175.netcologne.de (EHLO klangraum) [81.173.228.175] by mail.gmx.net (mp003) with SMTP; 06 May 2005 03:37:25 +0200 X-Authenticated: #163624 Date: Fri, 6 May 2005 03:40:19 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Autodiscovery Message-ID: <20050506014019.GA2454@klangraum> Mail-Followup-To: Atom Syntax References: <20050503235648.GC2161@home.fastolfe.net> <42785EE2.5080207@inkedblade.net> <68fba5c5050504061177627f8f@mail.gmail.com> <4279016B.80606@inkedblade.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4279016B.80606@inkedblade.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: 8bit * fantasai [2005-05-04 19:15]: > How is a link from the top of my homepage to my friend's weblog > feed designating a "substitute version for the document in > which the link occurs"? It’s not. And it’s offtopic. It’s called the “autodiscovery” spec, not the “feed directory” spec. If you want to link your friend’s blog’s feed, supply an OPML or FOAF blogroll. Covering this ground is not within the scope of autodiscovery. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu May 5 22:30:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22840 for ; Thu, 5 May 2005 22:30: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 j462J7Yu018382; Thu, 5 May 2005 19:19: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 j462J7TL018381; Thu, 5 May 2005 19:19:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j462J5bh018352 for ; Thu, 5 May 2005 19:19:06 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j462Irpb003121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 22:18:55 -0400 (EDT) Message-ID: <427AD6E3.9010804@atrus.org> Date: Thu, 05 May 2005 22:30:59 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fantasai CC: Atom Syntax , pilgrim@gmail.com, Tim.Bray@Sun.COM Subject: Re: Autodiscovery - different cases should use different rel References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> <42795178.1080401@atrus.org> <4279CAD8.5030301@inkedblade.net> <427A8EA8.6090509@atrus.org> <427AC6DE.5090404@inkedblade.net> In-Reply-To: <427AC6DE.5090404@inkedblade.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 fantasai wrote: > > Nikolas 'Atrus' Coukouma wrote: > >> fantasai wrote: >> >> An excellent point. Perhaps these should use rel="home" :) >> >> > > ... > >> >> The value of rel, if present, will vary based on relation >> * the feed for *this* page - rel="alternate" >> * the feed for main feed for this blog, in general - rel="home" >> * other feeds the author reads or recommends - rel="suggested" >> * any other feeds linked to for any reason at all - no rel, just the >> type and href >> >> Is this acceptable? I'm not completely happy with "home" and "suggested" >> because they're not specified as link types in the HTML specs [1]. >> Sadly, it seems the HTML authors didn't consider these cases. "home" >> seems to be an informal standard. Close matches in the HTML list are >> "index", "contents", and "start". All of these are inaccurate, but I >> think "contents" is the best fit. > > > Actually, I think "start" is the best fit. The main feed is often not a > table of contents to the entire weblog, but something partial. It is, > however, the "starting point of the collection". Actually, I disagree with start because of the first sentence in the HTML spec: "Refers to the first document in a collection of documents." This indicates that start should point to the first post in a weblog. end would be the most recent (not that end exists in the HTML spec) "This link type tells search engines which document is considered by the author to be the starting point of the collection." This is a completely different meaning and I'm not sure why it's bundled with the first. According to this, start pointing to the homepage is fine. The end or last would be the most recent (not that the HTML specs have an end or last rel) > > BTW, you might want to take a look at > > http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html > http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html > > ~fantasai No offense, but with all the tripod ads, I would have much preferred a link to the "Hypertext links in HTML" draft [1]. Section four is what I want. It's not indexed alphabetically and doesn't combine other documents, but it's the covers everything pretty well. [1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt -Nikolas 'Atrus' From owner-atom-syntax@mail.imc.org Thu May 5 22:48:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24438 for ; Thu, 5 May 2005 22:48: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 j462dh7u023149; Thu, 5 May 2005 19:39: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 j462dhT9023148; Thu, 5 May 2005 19:39:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j462dhPa023139 for ; Thu, 5 May 2005 19:39:43 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j462dgWj005228; Thu, 5 May 2005 22:39:42 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCH65434; Thu, 5 May 2005 22:39:41 -0400 (EDT) Message-Id: <200505060239.DCH65434@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sjoerd Visscher'" , "'atom-syntax Syntax''" Subject: RE: Autodiscovery via body elements like a, div, span, etc. Date: Thu, 5 May 2005 22:39:37 -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: <427A805E.5080303@w3future.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVRtJ7LwAaVYDwjSDqx4GineAuTwQAJdTOw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > Why not support hyperlinks too? > href="/xml/index.atom">Main Atom feed One very interesting side-effect of putting the autodiscovery data in elements of the body is that it then becomes visible in many more environments. For instance, if I were to cut some text from a web page and paste it into blog post or another web page, then if that text had links with rel="alternate" in it, those links would travel along with the quote. If I built a page of quotes from many sites, I might end up with "alternate" links to many different sites, feeds, etc. This might not be as "bad" as it sounds... This might argue against using "alternate" in body elements that might be cut out and pasted into or quoted in other pages since clearly, the thing which is an alternate is an alternate of the page which originally contained the quote -- not the page into which the quote has been pasted or an alternate form of the quote itself. While there are some problems to be worked on, I very much like the idea of a chunk of HTML carrying around some indication of its provenance, original source and alternate sources. bob wyman From owner-atom-syntax@mail.imc.org Thu May 5 22:57:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25266 for ; Thu, 5 May 2005 22:57: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 j462oMBV024883; Thu, 5 May 2005 19:50: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 j462oMc1024882; Thu, 5 May 2005 19:50:22 -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 j462oLFU024874 for ; Thu, 5 May 2005 19:50:21 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j462oYwj003581; Thu, 5 May 2005 22:50:40 -0400 Message-ID: <427ADB61.7010805@intertwingly.net> Date: Thu, 05 May 2005 22:50:09 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceOptionalFeedLink 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 Tim Bray wrote: > > +1 > > There are people who want to publish feeds without rel="alternate" > links. I'm against telling people they can't do something they want to > do without strong reasons, as in loss of interoperability. I don't see > the reasons here as strong enough. -Tim FYI: we have an instance proof of this requiring an existing tool to do additional work: http://www.imc.org/atom-syntax/mail-archive/msg13983.html - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 22:57:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25354 for ; Thu, 5 May 2005 22:57: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 j462pONg025012; Thu, 5 May 2005 19:51: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 j462pOD0025011; Thu, 5 May 2005 19:51:24 -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 j462pNL7025004 for ; Thu, 5 May 2005 19:51:23 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j462pfNr003660 for ; Thu, 5 May 2005 22:51:42 -0400 Message-ID: <427ADBA6.4060805@intertwingly.net> Date: Thu, 05 May 2005 22:51:18 -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: PaceFeedIdOrSelf 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 From prior discussion, people have indicated that they want *something* that they can use to track feeds identity, and the consensus seemed to be that id and/or self was more appropriate than link. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 23:02:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25809 for ; Thu, 5 May 2005 23:02: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 j462ttJD025802; Thu, 5 May 2005 19: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 j462tt9c025801; Thu, 5 May 2005 19:55:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j462trfh025782 for ; Thu, 5 May 2005 19:55:54 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j462tZpb003499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 22:55:42 -0400 (EDT) Message-ID: <427ADF82.6060707@atrus.org> Date: Thu, 05 May 2005 23:07:46 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Autodiscovery - different cases should use different rel 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 Eric Scheid wrote: >On 6/5/05 7:22 AM, "Nikolas 'Atrus' Coukouma" wrote: > > > >>I've basically concluded that the keys to autodiscovery of feeds, in the >>general sense, should not be three (rel, type, and href), but two (type >>and href). Type is plenty of specification that it's a feed. Claiming >>it's relationship as "feed" doesn't seem correct. There are a few >>mime-types used, and the one for atom (application/atom+xml) will be an >>official standard as soon as the draft is accepted by the IETF. >> >> > >Using @type only is not sufficient, since both Atom Feed Documents *and* >Atom Entry Documents use the same mime-type. One is a feed, the other is >not. > >Similarly, RSS 1.0 isn't clearly distinguished by mime-type - there are lots >of other resources which are 'application/rdf+xml' (eg. FOAF) > >e. > > Hrm. This is an interesting point. I'm not too concerned about "find every feed, regardless of relevance" because I think only search engines will be interested in it, especially if all the other cases are marked. They can bear to check the feed and see what the root element is. This also makes rel="alternate" seem like an even worse choice for *feed* autodiscovery because it would make sense to link to an atom *entry* as rel="alternate" from the page for an individual entry. I really don't think @rel is the place to address concerns about type. That's really the job of @type (of course). If we need to declare more mime-types, then so be it. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Thu May 5 23:05:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26099 for ; Thu, 5 May 2005 23:05: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 j462vfrx026100; Thu, 5 May 2005 19:57: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 j462vfjq026099; Thu, 5 May 2005 19:57: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 j462ve2F026091 for ; Thu, 5 May 2005 19:57:40 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j462vvrG004277; Thu, 5 May 2005 22:57:57 -0400 Message-ID: <427ADD1C.9080305@intertwingly.net> Date: Thu, 05 May 2005 22:57:32 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Tim Bray , atom-syntax Syntax Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> <68fba5c505050516314bd3014c@mail.gmail.com> In-Reply-To: <68fba5c505050516314bd3014c@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: > On 5/5/05, Tim Bray wrote: > >>No it doesn't, it says something about inserting the phrase "...is >>either not present or..." which, by the way, I don't understand. Are >>we looking at the same document? > > Ah, it's been updated since I last looked. The proposed text for 4.1.2 > didn't used to account for an absent content element. The notes section is now gone. PaceTextShouldBeProvides now contains a proper superset of the instructions contained in PaceOptionalSummary. Perhaps now we can get beyond discussing alleged incompatibilities. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 5 23:05:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26128 for ; Thu, 5 May 2005 23:05: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 j45MqLCF074385; Thu, 5 May 2005 15:52: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 j45MqLSo074384; Thu, 5 May 2005 15:52: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 j45MqI90074366 for ; Thu, 5 May 2005 15:52:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so514313wra for ; Thu, 05 May 2005 15:52:10 -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=WebceQqXT4FvTtC0zArJ7+Y3OTCSXLA3vIjE2uE/oXQ7fiEhLZtES7R73NCc464415U0vGHXbfj1R/Kv2t8vXgXULS4GkXsQZAteQjCdT6j8oDe1HcvVVP2NIUITBUDbK4jsHuqGd997L5IF7Aeyff+pWRT3XO31+mHe35aIBPA= Received: by 10.54.70.2 with SMTP id s2mr439016wra; Thu, 05 May 2005 15:52:09 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 15:52:09 -0700 (PDT) Message-ID: <68fba5c50505051552623360cd@mail.gmail.com> Date: Thu, 5 May 2005 18:52:09 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary Cc: atom-syntax In-Reply-To: <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j45MqK90074378 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Tim Bray wrote: > > Speaking not as the chair but as an interested WG member, I read them > about eight times and I do not understand why they are in conflict. > Someone please explain, as simply as possible, what the problem is, > because I just don't get it. On the face of it, I am inclined to be +1 > to both PaceOptionalSummary and PaceTextShouldBeProvided. Everything in the proposal section is fine with me, as well. It's that "Notes" section that's the problem. > Note: I totally fail to understand the "Notes" bit at the end of > PaceTextShouldBeProvided. It is underspecified to the extent that I > can't figure out what language change it is actually saying is > necessary. That section says is "If PaceOptionalSummary is 'accepted', this Pace changes summary to SHOULD." That's OK to propose, but you can't accept both of them. They conflict. > > Basically, allowing title-only feeds seems OK to me, and encouraging > people to provide text also seems OK to me, so what's the problem? Current spec: MUST contain a summary after PaceOptionalSummary: MAY contain a summary after PaceTextShouldBeProvided: SHOULD contain a summary Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 23:14:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27385 for ; Thu, 5 May 2005 23:14: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 j4636Hbx028683; Thu, 5 May 2005 20:06: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 j4636HYj028682; Thu, 5 May 2005 20:06:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4636GUV028651 for ; Thu, 5 May 2005 20:06:17 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4634S0J003809; Fri, 6 May 2005 04:04:29 +0100 (BST) In-Reply-To: <427ADB61.7010805@intertwingly.net> References: <427ADB61.7010805@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalFeedLink Date: Fri, 6 May 2005 04:04:27 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 3:50 am, Sam Ruby wrote: > FYI: we have an instance proof of this requiring an existing tool > to do additional work: > > http://www.imc.org/atom-syntax/mail-archive/msg13983.html Tools will have to be updated to work with Atom? Scandalous. +1 to the Pace Graham From owner-atom-syntax@mail.imc.org Thu May 5 23:34:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28868 for ; Thu, 5 May 2005 23:34: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 j463SO0S032395; Thu, 5 May 2005 20:28: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 j463SOnn032394; Thu, 5 May 2005 20:28: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-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 j463SNlJ032386 for ; Thu, 5 May 2005 20:28:24 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j463SNi7009253 for ; Thu, 5 May 2005 21:28:23 -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 <0IG100IVGTNAMX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 05 May 2005 21:28:23 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG100A3UTN9OI@mail.sun.net> for atom-syntax@imc.org; Thu, 05 May 2005 21:28:22 -0600 (MDT) Date: Thu, 05 May 2005 20:29:26 -0700 From: Tim Bray Subject: Autodiscovery discussion & editorship To: atom-syntax Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Given the volume of debate, it's obvious there may be more work to do here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery spec, and he's accepted. Between Mark and Phil we should have no trouble getting the editing done. Paul, is there any reason Mark or Phil shouldn't submit the most recent autodiscovery-01 as a committee draft? The discussion in recent days has been lively but unstructured. If I were forced to make a consensus call right now, I'm pretty sure I wouldn't be able to pick out any one spec change that I could say clearly has consensus. So argue as much as you want, but if you really want a specific change to the draft, I think you need to draw up a Pace with specific change suggestions and see if you can use that to focus the discussion and gather support. If possible, I'd like us to focus on getting the format draft done just now; we promise to have a focused discussion on autodisco once format is put to bed. -Tim From owner-atom-syntax@mail.imc.org Thu May 5 23:40:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29487 for ; Thu, 5 May 2005 23:40: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 j463QiSV032109; Thu, 5 May 2005 20:26: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 j463Qimc032108; Thu, 5 May 2005 20:26:44 -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 j463QgcF032088 for ; Thu, 5 May 2005 20:26:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so616936wra for ; Thu, 05 May 2005 20:26:37 -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=YGm/JswvcW7C/evSs8I4a1orpJyv5Pipa4Fk2CNGm3De2bJZM2l2dQcqYoVd7/yJc6ZxL6hdeENG9z1K7jCo/rw28E8bbz/DwIWrbZAdUmg2UJ63aEjIix/uHXi5J5Pf5qv0n9hdqACS/zNKP1rWcMvjH0cpjTSSqftt+GzKMXQ= Received: by 10.54.73.2 with SMTP id v2mr570378wra; Thu, 05 May 2005 20:26:37 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 20:26:37 -0700 (PDT) Message-ID: <68fba5c5050505202663d33c44@mail.gmail.com> Date: Thu, 5 May 2005 23:26:37 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary Cc: Tim Bray , atom-syntax Syntax In-Reply-To: <427ADD1C.9080305@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> <68fba5c505050516314bd3014c@mail.gmail.com> <427ADD1C.9080305@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j463QhcF032094 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Sam Ruby wrote: > > The notes section is now gone. PaceTextShouldBeProvides now contains a > proper superset of the instructions contained in PaceOptionalSummary. > > Perhaps now we can get beyond discussing alleged incompatibilities. PaceTextShouldBeProvided: SHOULD have a summary PaceOptionalSummary: MAY have a summary Pick one. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 5 23:53:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00512 for ; Thu, 5 May 2005 23:53: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 j463karr035743; Thu, 5 May 2005 20:46: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 j463kaOj035742; Thu, 5 May 2005 20:46:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j463kZSl035719 for ; Thu, 5 May 2005 20:46:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j463jlqQ010024; Fri, 6 May 2005 04:45:53 +0100 (BST) In-Reply-To: <68fba5c5050505202663d33c44@mail.gmail.com> References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> <68fba5c505050516314bd3014c@mail.gmail.com> <427ADD1C.9080305@intertwingly.net> <68fba5c5050505202663d33c44@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary Date: Fri, 6 May 2005 04:45:47 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 4:26 am, Robert Sayre wrote: > PaceTextShouldBeProvided: SHOULD have a summary > PaceOptionalSummary: MAY have a summary No, Robert: Current situation: MUST have a summary PaceOptionalSummary: No explicit opinion PaceTextShouldBeProvided: SHOULD have a summary PaceOptionalSummary simply says remove the "MUST", it doesn't say what it should be replaced with. Graham From owner-atom-syntax@mail.imc.org Thu May 5 23:57:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00858 for ; Thu, 5 May 2005 23: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 j463nPph036144; Thu, 5 May 2005 20:49: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 j463nP6Z036143; Thu, 5 May 2005 20:49: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j463nOV1036120 for ; Thu, 5 May 2005 20:49:24 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so625921wra for ; Thu, 05 May 2005 20:49:16 -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=FMz8pPUWWCpyma+7u4wp67+ETlm0D1NY76/ZQ7fD4aIBH/N58wvS+USgdvkriAA1VM30NkWTitUX/WEZG6mgh6NtLeUFXnaOBNr2+kKp1zHgBXX4sVRXO6x+jJ+wmUTua4m6amDb9oabCfS28lRDZ7dzTg9xOSTMVEMu1KMday0= Received: by 10.54.36.79 with SMTP id j79mr580378wrj; Thu, 05 May 2005 20:49:15 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 5 May 2005 20:49:15 -0700 (PDT) Message-ID: <68fba5c505050520493c6a4849@mail.gmail.com> Date: Thu, 5 May 2005 23:49:15 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> <68fba5c505050516314bd3014c@mail.gmail.com> <427ADD1C.9080305@intertwingly.net> <68fba5c5050505202663d33c44@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j463nOV1036136 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Graham wrote: > > PaceOptionalSummary simply says remove the "MUST", it doesn't say > what it should be replaced with. What part of OPTIONAL don't you understand? Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 6 02:27:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03857 for ; Fri, 6 May 2005 02:27: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 j466InTc090253; Thu, 5 May 2005 23:18: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 j466In30090252; Thu, 5 May 2005 23:18: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j466IjfT090189 for ; Thu, 5 May 2005 23:18:48 -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, 6 May 2005 16:18:43 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 May 2005 16:18:39 +1000 Subject: Re: Autodiscovery - different cases should use different rel From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <427ADF82.6060707@atrus.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 6/5/05 1:07 PM, "Nikolas 'Atrus' Coukouma" wrote: > Hrm. This is an interesting point. I'm not too concerned about "find > every feed, regardless of relevance" because I think only search engines > will be interested in it, especially if all the other cases are marked. finding every feed is not my concern either. > They can bear to check the feed and see what the root element is. this won't work ... see below. > This also makes rel="alternate" seem like an even worse choice for > *feed* autodiscovery because it would make sense to link to an atom > *entry* as rel="alternate" from the page for an individual entry. absolutely! > I really don't think @rel is the place to address concerns about type. > That's really the job of @type (of course). If we need to declare more > mime-types, then so be it. Just to throw more fuel on the fire: It is quite conceivable for an Atom Feed Document (AFD) to contain a set of entries which won't grow or be updated, such as an AFD which contains all postings for a calendar period, or an AFD which contains one entry for each chapter of a book, and so on. Thus, neither mime-types nor root-element-sniffing will be reliable enough to discover the resource which is appropriate for "subscribing" to - ie. discovering which Atom Feed Document is the one which will be updated as time goes by in the usual sliding window manner, and not the monthly archive that page happens to be contained within. e. From owner-atom-syntax@mail.imc.org Fri May 6 03:55:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11576 for ; Fri, 6 May 2005 03:55: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 j467mCOt037091; Fri, 6 May 2005 00:48: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 j467mCxP037090; Fri, 6 May 2005 00:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j467mAi5037075 for ; Fri, 6 May 2005 00:48:11 -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-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id j467m3xX065001 for ; Fri, 6 May 2005 09:48:09 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <427B212F.70905@w3future.com> Date: Fri, 06 May 2005 09:47:59 +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 Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> In-Reply-To: <427AC85D.7000004@inkedblade.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 fantasai wrote: > > The difference between and is that > - applies to the document as a whole: it indicates a relationship > between this document and the href destination. > - is a contextual link: it indicates a relationship between the > linking context and the href destination. > > They have different purposes. It is imho perfectly reasonable to limit > autodiscovery to s only. It is also perfectly reasonable to link > to feeds with , and expect that the UA will recognize it as a feed > rather than a generic XML document. > Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that matter) defines the rel attribute on a hyperlink: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Fri May 6 04:15:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13192 for ; Fri, 6 May 2005 04:15: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 j4688Jnx046255; Fri, 6 May 2005 01:08: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 j4688Jtw046254; Fri, 6 May 2005 01:08:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4688Iom046244 for ; Fri, 6 May 2005 01:08:19 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from dynamic-oit-equadnet-b-18.princeton.edu ([128.112.34.190]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DTxsg-0002lf-3f for atom-syntax@imc.org; Fri, 06 May 2005 04:08:18 -0400 Message-ID: <427B25E2.8010709@inkedblade.net> Date: Fri, 06 May 2005 04:08:02 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Autodiscovery - different cases should use different rel References: <42784696.1060409@gmail.com> <31750ab13687e0b55c9eb9cdd2ffdd66@iki.fi> <14be96d305050323162633186b@mail.gmail.com> <0ddadc99a41ce83550ede71051ea02ae@iki.fi> <4279245B.4020907@inkedblade.net> <42795178.1080401@atrus.org> <4279CAD8.5030301@inkedblade.net> <427A8EA8.6090509@atrus.org> <427AC6DE.5090404@inkedblade.net> <427AD6E3.9010804@atrus.org> In-Reply-To: <427AD6E3.9010804@atrus.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas 'Atrus' Coukouma wrote: > fantasai wrote: > >>Actually, I think "start" is the best fit. The main feed is often not a >>table of contents to the entire weblog, but something partial. It is, >>however, the "starting point of the collection". > > Actually, I disagree with start because of the first sentence in the > HTML spec: > "Refers to the first document in a collection of documents." > This indicates that start should point to the first post in a weblog. > end would be the most recent (not that end exists in the HTML spec) I think "first" here should not be taken as chronological, but as foremost. This would make it consistent with the second sentence: > "This link type tells search engines which document is considered by the > author to be the starting point of the collection." > This is a completely different meaning and I'm not sure why it's bundled > with the first. According to this, start pointing to the homepage is fine. >>BTW, you might want to take a look at >> >> http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html >> http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html > > No offense, but with all the tripod ads, I would have much preferred a > link to the "Hypertext links in HTML" draft [1]. Sorry. > Section four is what I want. It's not indexed alphabetically and > doesn't combine other documents, but it's the covers everything > pretty well. > > [1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Not quite everything. Some of the values (like "start") are not covered in that draft. ~fantasai From owner-atom-syntax@mail.imc.org Fri May 6 04:15:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13214 for ; Fri, 6 May 2005 04:15: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 j467wTqv041926; Fri, 6 May 2005 00: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 j467wT1h041924; Fri, 6 May 2005 00:58:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j467wM0I041834 for ; Fri, 6 May 2005 00:58:22 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j467wDpc006100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 May 2005 03:58:14 -0400 (EDT) Message-ID: <427B24A0.5080400@atrus.org> Date: Fri, 06 May 2005 04:02:40 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Autodiscovery - different cases should use different rel 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 6/5/05 1:07 PM, "Nikolas 'Atrus' Coukouma" wrote: > > > >>Hrm. This is an interesting point. I'm not too concerned about "find >>every feed, regardless of relevance" because I think only search engines >>will be interested in it, especially if all the other cases are marked. >> >> > >finding every feed is not my concern either. > > > >>They can bear to check the feed and see what the root element is. >> >> > >this won't work ... see below. > > > >>This also makes rel="alternate" seem like an even worse choice for >>*feed* autodiscovery because it would make sense to link to an atom >>*entry* as rel="alternate" from the page for an individual entry. >> >> > >absolutely! > > > >>I really don't think @rel is the place to address concerns about type. >>That's really the job of @type (of course). If we need to declare more >>mime-types, then so be it. >> >> > >Just to throw more fuel on the fire: > >It is quite conceivable for an Atom Feed Document (AFD) to contain a set of >entries which won't grow or be updated, such as an AFD which contains all >postings for a calendar period, or an AFD which contains one entry for each >chapter of a book, and so on. > >Thus, neither mime-types nor root-element-sniffing will be reliable enough >to discover the resource which is appropriate for "subscribing" to - ie. >discovering which Atom Feed Document is the one which will be updated as >time goes by in the usual sliding window manner, and not the monthly archive >that page happens to be contained within. > > > >e. > This warrants groaning. I think it's safe to say that user agents shouldn't subscribe to entry docments. Feeds may be worth bothering with. Source: (HTML/XHTML) Clearly the friendlier end to do autodiscovery on. Remember, the goal here is to indicate that the URI from @href is worth subscribing to. I'm running out of attributes to abuse. From the XHTML Link Module: [1] charset, href, hreflang, media, rel, rev, type Link Module: [2] target All of these are listed in the 4.01 spec[3]. There's also the slim chance of using XLink's link semantics [4]. They seem to be mostly redundant with @target. Speaking of @target, I'm currently favoring it because it's used for indicating where a link whould be loaded. This makes a hair more sense with today's browser-feed integration. Destination: (Atom) The only way I can see to indicate that a feed is "alive" and worth subscribing to (assuming existing Atom spec) is to include cache control (Expires or Cache-Control headers). [1] http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_targetmodule [2] http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_linkmodule [3] http://www.w3.org/TR/html4/struct/links.html#h-12.3 [4] http://www.w3.org/TR/xlink/#link-semantics -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Fri May 6 04:33:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14869 for ; Fri, 6 May 2005 04:33: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 j468RQ3M054424; Fri, 6 May 2005 01:27: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 j468RQqL054423; Fri, 6 May 2005 01:27:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j468RPkI054371 for ; Fri, 6 May 2005 01:27:25 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j468RHpc006342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 May 2005 04:27:17 -0400 (EDT) Message-ID: <427B2B71.6030300@atrus.org> Date: Fri, 06 May 2005 04:31:45 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: Atom Syntax Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> In-Reply-To: <427B212F.70905@w3future.com> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > > fantasai wrote: > >> >> The difference between and is that >> - applies to the document as a whole: it indicates a >> relationship >> between this document and the href destination. >> - is a contextual link: it indicates a relationship between the >> linking context and the href destination. >> >> They have different purposes. It is imho perfectly reasonable to limit >> autodiscovery to s only. It is also perfectly reasonable to link >> to feeds with , and expect that the UA will recognize it as a feed >> rather than a generic XML document. >> > > Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that > matter) defines the rel attribute on a hyperlink: > > This attribute describes the relationship from the current document to > the anchor specified by the href attribute. The value of this > attribute is a space-separated list of link types. Using @rel with any linking element is perfectly valid and has been for years. @rel not being supported for anything other than the link element itself has also been an outstanding bug for just as long. There's lot of debate attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). Can we agree that this should be supported, but currently isn't? Unless there's a compelling reason not to, I think we might as well allow autodiscovery via either element. Any implementation guide should recommend duplicating the information in the interest of autodiscovery actually working. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Fri May 6 04:35:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15044 for ; Fri, 6 May 2005 04:35: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 j468V9EM056117; Fri, 6 May 2005 01: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 j468V9I9056116; Fri, 6 May 2005 01:31:09 -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 j468V8sR056066 for ; Fri, 6 May 2005 01:31:08 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59091 messnum 7058973 invoked from network[83.70.217.193/unknown]); 6 May 2005 08:31:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail01.svc.cra.dublin.eircom.net (qp 59091) with SMTP; 6 May 2005 08:31:02 -0000 Message-ID: <427B2B42.1030604@dehora.net> Date: Fri, 06 May 2005 09:30: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: Robert Sayre CC: Eric Scheid , Atom Syntax Subject: Re: PaceAllowDuplicateIDs References: <821BF7D1-F12B-4B14-9E44-3E1CCED36EE9@mac.com> <68fba5c50505050641139bc53f@mail.gmail.com> In-Reply-To: <68fba5c50505050641139bc53f@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: > I'm much more sympathetic to the aggregate feed problem of multiple > IDs. People advocating this type of thing seem to think the default > action should be grouping, so they want to use the same ID. I think > that's a bad idea, and there are plenty of other ways to indicate the > fundamental sameness of entries. For example, NewsML URNs have a > NewsItemID and a RevisionID, which would allow smart aggregators to > group the entries without violating Atom's constraint. Then you have two ways of indicating fundamental sameness of entries, one for when the same entry appears multiple times in a feed, and one for everything else. Back to basics then. Does anyone remember why having the same id in a feed is a bad idea? cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 05:25:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19032 for ; Fri, 6 May 2005 05: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 j469He4K075494; Fri, 6 May 2005 02:17: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 j469HeCM075493; Fri, 6 May 2005 02:17:40 -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 j469HdL0075424 for ; Fri, 6 May 2005 02:17:40 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 15550 messnum 273277 invoked from network[83.70.217.193/unknown]); 6 May 2005 09:17:33 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail03.svc.cra.dublin.eircom.net (qp 15550) with SMTP; 6 May 2005 09:17:33 -0000 Message-ID: <427B362A.3090904@dehora.net> Date: Fri, 06 May 2005 10:17:30 +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: Dave Johnson CC: Atom Syntax Subject: Re: PaceAllowDuplicateIDs References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> In-Reply-To: <1d5387c3d355cc6673b741192650950e@rollerweblogger.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 Dave Johnson wrote: > > Immediately after sending this message, I had a rush of second thoughts. > > My point #2 is not very well thought out. I think it applies for things > like earthquake data, but when Atom feeds represent blog entries or > articles (in an archive or an Atom Protocol feed) the ID represents the > article not an event in the blog entry's life. So, you can discount my > second reason against the pace. Good, because not everyone would agree that's what's being modeled. Now I also think your 1) starts to fall away as well because 2) no longer holds. That is, some of the argument for "Current best practice" you're talking about (you sure about "best" in there? ;) is predicated on entries being like events. Aggregators tend, or would like, to treat entries as singular happenings. Finally some events are not easily modeled in the discrete way you're talking about (in turn some of that comes down to how you model time), I don't think we have to worry about those here. Put it this way, under either "this is an event stream" or "this is a stream of entries", having multiple entries in a single feed is not an unreasonable request. We came up with the id approach to allow people to zero in on duplicates; that's the primary case. We did that without really articulating what an entry stands for, some effort was done post-hoc, but it doesn't seem to have made it as spec text. Consider. Is the XML entry in a feed a representation of an entry, a la REST? If so, does the id identify the representation or the entry? If the id identifies the entry representation, how (or should) we identify the entry? If the id identifies the entry, how (or need) we identify the representation? Those are just some of the questions, we could ask. We could then ask the whole set over regarding what a feed is, as that has a bearing too. I've said this before - the technical problem we have is that we can't distinguish between a buggy feed with the same ids and an aggregate feed with the same ids under the current spec. Because you can't have it both ways, that rationale should have been provided in the spec. It's an architectural constraint - you can not say this with your feed because we can't make sense of it - done, not to preserve some notion of identity we have here, but to allow people to drop duplicates and normalize their streams. The downside is that 1) some people do want to aggregate versions of an entry in a single feed, which presumably have the same id, so "they or others can say, these are all of the same thing", 2) some people do re-edit their entries or edit their entry dates around so the entry reappears with updated content. Bray does this with his Sunday server logs and no-one convinced me it's not equally as questionable an approach at some level as allow duplicate ids, or munging URLs the way ad people do - who cares as long as it gets into people's clients? And it's clear now, that ids don't solve "the get rid of all those duplicates problem", dates are required also, to cater for cases where someone updates the entry, but we don't want people to miss that because of over-eager reaping on the clients. It's a mess, that's our fault. As a first step we need to be able to say what's being identified. If we decide we don't care about that, we just want to illegalise duplicates, then maybe ids were not the right idea to begin with. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 06:43:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27500 for ; Fri, 6 May 2005 06:43: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 j46AW9QW006860; Fri, 6 May 2005 03:32: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 j46AW9Cg006859; Fri, 6 May 2005 03:32:09 -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 j46AW7S1006813 for ; Fri, 6 May 2005 03:32:08 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 06 May 2005 10:32:01 -0000 Received: from p508FEA2A.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.234.42] by mail.gmx.net (mp024) with SMTP; 06 May 2005 12:32:01 +0200 X-Authenticated: #1915285 Message-ID: <427B479A.60604@gmx.de> Date: Fri, 06 May 2005 12:31:54 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Sam Ruby , atom-syntax Subject: Re: PaceOptionalFeedLink References: <427ADB61.7010805@intertwingly.net> In-Reply-To: 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 Graham wrote: > > > On 6 May 2005, at 3:50 am, Sam Ruby wrote: > >> FYI: we have an instance proof of this requiring an existing tool to >> do additional work: >> >> http://www.imc.org/atom-syntax/mail-archive/msg13983.html > > > Tools will have to be updated to work with Atom? Scandalous. > > +1 to the Pace +1 as well. That something which has been developed against a previous draft will not work with a change in the format seems to be quite natural. On the other hand, we also heard of feeds that need to "make up" links (which doesn't seem very useful to me). Best regards, Julian From owner-atom-syntax@mail.imc.org Fri May 6 07:18:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00608 for ; Fri, 6 May 2005 07:18: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 j46BAAg3020572; Fri, 6 May 2005 04:10: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 j46BAAxM020571; Fri, 6 May 2005 04:10: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46BA8VQ020533 for ; Fri, 6 May 2005 04:10:09 -0700 (PDT) (envelope-from jalkanen@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1301065wri for ; Fri, 06 May 2005 04:10: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=RAOvhvPqPzlE1Sr4NbUBG3QcSSLlefQ8mYn2jysaWxi4CiG6HAkbUwUFd4pHuogMAv0/TZ6JFvrQx2KS7gOTONvqoWiKCzm4xPz5yn94FX7co32oPKltCmOQnCW62wTRTUv/cb1NO1cdRuWIC/hEHs1vzd+hYzG/iQsv+Qpx2n4= Received: by 10.54.21.69 with SMTP id 69mr748506wru; Fri, 06 May 2005 04:10:02 -0700 (PDT) Received: by 10.54.28.37 with HTTP; Fri, 6 May 2005 04:10:01 -0700 (PDT) Message-ID: <7aebae7d0505060410632786ad@mail.gmail.com> Date: Fri, 6 May 2005 14:10:01 +0300 From: Janne Jalkanen Reply-To: Janne Jalkanen To: bob@wyman.us Subject: Re: Atom on portable wireless device (was: RE: Atom feed refresh rates) Cc: Chris DeSalvo , atom-syntax@imc.org In-Reply-To: <200505050049.DCC93621@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <10ce37ae0e9056b880c4d2af526dcf9d@desalvo.org> <200505050049.DCC93621@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46BAAVQ020564 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > You've written on your blog that you want to see more "304" > responses. Well, I would suggest that what you *really* should want is more > "226" responses -- 226 is the success code for an RFC3229+feed GET > operation. I like so agree. 226 support would be highly commendable for everyone, who wants to serve feeds for mobiles... But considering the status these days, even 304 would be good. *sigh* Though, the real solution probably lies in notification protocols, such as SIP. Reduce the need of polling, do a proper SIP subscribe-notify... Of course, these are not solutions for current devices. /Janne From owner-atom-syntax@mail.imc.org Fri May 6 08:14:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05862 for ; Fri, 6 May 2005 08: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 j46C2QCH042565; Fri, 6 May 2005 05:02: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 j46C2QgS042564; Fri, 6 May 2005 05:02:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46C2P2a042483 for ; Fri, 6 May 2005 05:02:25 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.1.8] (trillian.student.umd.edu [129.2.249.178]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j46C2Hpb008260 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 May 2005 08:02:18 -0400 (EDT) Message-ID: <427B5CCB.8030201@atrus.org> Date: Fri, 06 May 2005 08:02:19 -0400 From: Nikolas Coukouma User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sjoerd Visscher CC: Atom Syntax Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> In-Reply-To: <427B212F.70905@w3future.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 Sjoerd Visscher wrote: > Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that > matter) defines the rel attribute on a hyperlink: > > This attribute describes the relationship from the current document to > the anchor specified by the href attribute. The value of this > attribute is a space-separated list of link types. > Completely separately, to the anchor versus link debate: "space-separated list of link types." is a find worthy of points (redeemable at your local ego shop). This means we can have our pie and eat it too. If we define rel="feed", there's no reason it can't be combined with other rel types :) For example, we could allow Using @rel for type-ish hinting is an ugly hack, but this allows us to at least let @rel function the way it was intended to in addition to the hack. It's that or choose another attribute to be our victim -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Fri May 6 08:25:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06756 for ; Fri, 6 May 2005 08:25: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 j46CIk4S050112; Fri, 6 May 2005 05:18: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 j46CIkme050111; Fri, 6 May 2005 05:18:46 -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 j46CIjUd050059 for ; Fri, 6 May 2005 05:18:46 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 23931 messnum 4218422 invoked from network[83.70.217.193/unknown]); 6 May 2005 12:18:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail13.svc.cra.dublin.eircom.net (qp 23931) with SMTP; 6 May 2005 12:18:39 -0000 Message-ID: <427B609C.3070206@dehora.net> Date: Fri, 06 May 2005 13:18:36 +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: PaceOptionalSummary 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, in case it got lost in the earlier threads. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 08:35:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08167 for ; Fri, 6 May 2005 08:35: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 j46CQh8c053536; Fri, 6 May 2005 05:26: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 j46CQhDh053535; Fri, 6 May 2005 05:26:43 -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 j46CQgww053521 for ; Fri, 6 May 2005 05:26:42 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46CR0md008942; Fri, 6 May 2005 08:27:03 -0400 Message-ID: <427B6279.5070601@intertwingly.net> Date: Fri, 06 May 2005 08:26:33 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: PaceOptionalFeedLink References: <427ADB61.7010805@intertwingly.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 Graham wrote: > > On 6 May 2005, at 3:50 am, Sam Ruby wrote: > >> FYI: we have an instance proof of this requiring an existing tool to >> do additional work: >> >> http://www.imc.org/atom-syntax/mail-archive/msg13983.html > > Tools will have to be updated to work with Atom? Scandalous. > > +1 to the Pace This Pace is not one that I plan to lie down in the road over. However, it continues to puzzle the bejeebers out of me. The channel link element is required in every version of RSS from 0.91 to 1.0 to 2.0. And as a co-author of the feedvalidator, I have seen a lot of broken feeds where people have either inadvertently or deliberately ignored the specification, but I don't recall ever seeing one where this element was not present. My concern is not that tools will need to be updated. My concern is that tools won't know that they need to update. How will they know that they need to update to handle a set of feeds that nobody is currently providing? Something that WOULD attract my attention is somebody saying "here is a set of feeds that I would like to provide that I can't provide in a valid way according to any of the available RSS specifications." - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 08:43:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10333 for ; Fri, 6 May 2005 08: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 j46Ca9Pr057529; Fri, 6 May 2005 05:36: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 j46Ca90Y057528; Fri, 6 May 2005 05:36:09 -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 j46Ca8pM057479 for ; Fri, 6 May 2005 05:36:09 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 90065 messnum 4214357 invoked from network[83.70.217.193/unknown]); 6 May 2005 12:36:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail13.svc.cra.dublin.eircom.net (qp 90065) with SMTP; 6 May 2005 12:36:03 -0000 Message-ID: <427B64AF.7020400@dehora.net> Date: Fri, 06 May 2005 13:35:59 +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: atom-syntax Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> In-Reply-To: <82052f8d4aa95bd00abc28dff2e7bca4@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: > Speaking not as the chair but as an interested WG member, I read them > about eight times and I do not understand why they are in conflict. > Someone please explain, as simply as possible, what the problem is, > because I just don't get it. On the face of it, I am inclined to be +1 > to both PaceOptionalSummary and PaceTextShouldBeProvided. 1. The pace's rationale has claims which have already been refuted by Robert and others in the discussion on optional summaries: "Encourage interoperability and accessibility" this rationale has no merit, imo. 2. It has a bias that is squarely aimed at title only feeds, which is the outcome of PaceOptionalSummary "Unfortunately, there are also existence proofs of title-only feeds" it clearly takes a shot across the bows of PaceOptionalSummary. 3. It's the kind of spec text we have rejected in the past as impletation specific and/or "best current practice" guidance: "those that follow these suggestions will find that their feeds are useful to a wider audience than they would be otherwise." we have a decision making legacy that speaks for itself, this is not demstrated to be a special case we ought to cater for. 4. It would appear to contradict PaceOptionalSummary by highlighted that legal usage as bad practice. That's contradictory in spirit, and personally speaking it's the kind of wording and deliberate vagueness that infuriates me about software specs. fFutzing about like this is showing poor form to the users of the spec 2 alone should be enough for you. Technically these things are not in contradiction, in sprit they are. I'm on the record already here: http://www.imc.org/atom-syntax/mail-archive/msg14535.html cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 09:01:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11708 for ; Fri, 6 May 2005 09:01: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 j46Cht6c061156; Fri, 6 May 2005 05:43: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 j46Chtax061155; Fri, 6 May 2005 05:43:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Chsb6061106 for ; Fri, 6 May 2005 05:43:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46ChFrr016456; Fri, 6 May 2005 13:43:20 +0100 (BST) In-Reply-To: <427B6279.5070601@intertwingly.net> References: <427ADB61.7010805@intertwingly.net> <427B6279.5070601@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44E98F72-AF95-4166-9465-51A52FA7D166@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalFeedLink Date: Fri, 6 May 2005 13:43:14 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 1:26 pm, Sam Ruby wrote: > My concern is not that tools will need to be updated. My concern > is that tools won't know that they need to update. How will they > know that they need to update to handle a set of feeds that nobody > is currently providing? How is this different to any of the other new features in Atom? No one agrees with you on this point; If you don't have anything else, please stop making everyone else's life harder by labouring a point that doesn't affect you in any way. > Something that WOULD attract my attention is somebody saying "here > is a set of feeds that I would like to provide that I can't provide > in a valid way according to any of the available RSS specifications." I have private RSS feeds showing new referrals for my websites. They do not have corresponding web pages, and don't have feed-level links. I think these kind of feeds make up a significant chunk of the demand for dropping the requirement. Graham From owner-atom-syntax@mail.imc.org Fri May 6 09:01:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11797 for ; Fri, 6 May 2005 09:01: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 j46CtVsC066856; Fri, 6 May 2005 05:55: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 j46CtV2S066855; Fri, 6 May 2005 05:55:31 -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 j46CtUM7066846 for ; Fri, 6 May 2005 05:55:31 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46CtkMu012459; Fri, 6 May 2005 08:55:46 -0400 Message-ID: <427B692E.8090704@intertwingly.net> Date: Fri, 06 May 2005 08:55:10 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: atom-syntax Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <427B64AF.7020400@dehora.net> In-Reply-To: <427B64AF.7020400@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > > 3. It's the kind of spec text we have rejected in the past as > impletation specific and/or "best current practice" guidance: > > "those that follow these suggestions will find that their feeds are > useful to a wider audience than they would be otherwise." Um, that text is not part of the proposal. It is part of the rationale. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 09:20:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13342 for ; Fri, 6 May 2005 09:20: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 j46DAwMv072887; Fri, 6 May 2005 06:10: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 j46DAwEg072885; Fri, 6 May 2005 06:10:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pyramid-02.kattare.com (pyramid-02.kattare.com [69.59.195.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46DAvWE072874 for ; Fri, 6 May 2005 06:10:57 -0700 (PDT) (envelope-from dave.johnson@rollerweblogger.org) Received: from [192.168.1.102] (cpe-024-211-236-180.nc.res.rr.com [24.211.236.180]) (authenticated bits=0) by pyramid-02.kattare.com (8.12.10/8.12.11) with ESMTP id j46DAubh004060 for ; Fri, 6 May 2005 06:10:56 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <427B362A.3090904@dehora.net> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> <427B362A.3090904@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> From: Dave Johnson Subject: Re: PaceAllowDuplicateIDs Date: Fri, 6 May 2005 09:10:50 -0400 To: Atom Syntax X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46DAvWE072875 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 6, 2005, at 5:17 AM, Bill de hra wrote: > Dave Johnson wrote: >> Immediately after sending this message, I had a rush of second >> thoughts. >> My point #2 is not very well thought out. I think it applies for >> things like earthquake data, but when Atom feeds represent blog >> entries or articles (in an archive or an Atom Protocol feed) the ID >> represents the article not an event in the blog entry's life. So, >> you can discount my second reason against the pace. > > Good, because not everyone would agree that's what's being modeled. > Now I also think your 1) starts to fall away as well because 2) no > longer holds. That is, some of the argument for "Current best > practice" you're talking about (you sure about "best" in there? ;) is > predicated on entries being like events. Aggregators tend, or would > like, to treat entries as singular happenings. Finally some events are > not easily modeled in the discrete way you're talking about (in turn > some of that comes down to how you model time), I don't think we have > to worry about those here. Yes, I think both of my arguments fail to hold and I no longer have a real objection to duplicates. Allowing duplicates gives feed produces to model events or other objects (versioned documents in a wiki) as they wish. Like you, I wonder "Does anyone remember why having the same id in a feed is a bad idea?" - Dave From owner-atom-syntax@mail.imc.org Fri May 6 09:48:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15989 for ; Fri, 6 May 2005 09: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 j46DX6Es077057; Fri, 6 May 2005 06:33: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 j46DX6bZ077056; Fri, 6 May 2005 06:33: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 j46DX4fe077026 for ; Fri, 6 May 2005 06:33:05 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 06 May 2005 13:32:58 -0000 Received: from p508FEA2A.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.234.42] by mail.gmx.net (mp021) with SMTP; 06 May 2005 15:32:58 +0200 X-Authenticated: #1915285 Message-ID: <427B71F7.3090008@gmx.de> Date: Fri, 06 May 2005 15:32:39 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Graham , atom-syntax Subject: Re: PaceOptionalFeedLink References: <427ADB61.7010805@intertwingly.net> <427B6279.5070601@intertwingly.net> In-Reply-To: <427B6279.5070601@intertwingly.net> 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 Sam Ruby wrote: > > Graham wrote: > >> >> On 6 May 2005, at 3:50 am, Sam Ruby wrote: >> >>> FYI: we have an instance proof of this requiring an existing tool to >>> do additional work: >>> >>> http://www.imc.org/atom-syntax/mail-archive/msg13983.html >> >> >> Tools will have to be updated to work with Atom? Scandalous. >> >> +1 to the Pace > > > This Pace is not one that I plan to lie down in the road over. However, > it continues to puzzle the bejeebers out of me. > > The channel link element is required in every version of RSS from 0.91 > to 1.0 to 2.0. And as a co-author of the feedvalidator, I have seen a > lot of broken feeds where people have either inadvertently or > deliberately ignored the specification, but I don't recall ever seeing > one where this element was not present. Which shows that those who don't have a useful link to report just make something up. If Atom requires the link, the situation will likely be the same. I just don't get how this is better than just stating "there's no alternative representation" instead. Out of the three feeds I currently generate/author, only one has meaningful "alternate" version. > My concern is not that tools will need to be updated. My concern is > that tools won't know that they need to update. How will they know that > they need to update to handle a set of feeds that nobody is currently > providing? Which tools are you talking about? Tools that consume RSS variants, or tools that consume earlier Atom format versions? The latter will have to be upgraded anyway because of the changing XML namespace. > Something that WOULD attract my attention is somebody saying "here is a > set of feeds that I would like to provide that I can't provide in a > valid way according to any of the available RSS specifications." As stated earlier, this is the case here. I had to make up the "alternate" link value just to satisfy the validator (). Best regards, Julian From owner-atom-syntax@mail.imc.org Fri May 6 09:48:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16007 for ; Fri, 6 May 2005 09:48: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 j46DcsUh078370; Fri, 6 May 2005 06:38: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 j46Dcsq4078368; Fri, 6 May 2005 06:38:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46DcrB8078347 for ; Fri, 6 May 2005 06:38:53 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46Dbtde017831; Fri, 6 May 2005 14:38:00 +0100 (BST) In-Reply-To: <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> <427B362A.3090904@dehora.net> <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Fri, 6 May 2005 14:37:54 +0100 To: Dave Johnson X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 2:10 pm, Dave Johnson wrote: > > Yes, I think both of my arguments fail to hold and I no longer have > a real objection to duplicates. Allowing duplicates gives feed > produces to model events or other objects (versioned documents in a > wiki) as they wish. Like you, I wonder "Does anyone remember why > having the same id in a feed is a bad idea?" Beacuse instead of a fixed model where a feed is a stream of entries each with their own id, it is now a stream of entries each of which does not have its own id, but shares it with similar entries. This is bullshit. Graham From owner-atom-syntax@mail.imc.org Fri May 6 09:50:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16271 for ; Fri, 6 May 2005 09:50: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 j46DhlC3079682; Fri, 6 May 2005 06:43: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 j46DhlHa079680; Fri, 6 May 2005 06:43:47 -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 j46DhkRn079655 for ; Fri, 6 May 2005 06:43:46 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1385664wri for ; Fri, 06 May 2005 06:43:40 -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=aPBH2LbRfbiLbEMdATwqcAZ7ZtaVE2UrK7Dm/47D0TDGhQy7gAtvuovPxO7Su4BUtvXykK92gvFwaxzqtzmMcxw4PJFlNww49SjYKn/8ptVUQUaP43T2LtCYQ+ZbwcrITs7JnaheV/jqNSOEpGzxbOrvodE98YAv+yjXAGB/5wM= Received: by 10.54.78.2 with SMTP id a2mr825299wrb; Fri, 06 May 2005 06:43:39 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Fri, 6 May 2005 06:43:39 -0700 (PDT) Message-ID: <14be96d30505060643f25caba@mail.gmail.com> Date: Fri, 6 May 2005 08:43:39 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Tim Bray Subject: Re: Autodiscovery discussion & editorship Cc: atom-syntax Syntax 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 j46DhkRn079671 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/5/05, Tim Bray wrote: > The discussion in recent days has been lively but unstructured. If I > were forced to make a consensus call right now, I'm pretty sure I > wouldn't be able to pick out any one spec change that I could say > clearly has consensus. The one suggestion I did see, which should be acted on immediately, is to update the references section to point to the newest versions of the XML and URI specs (and associated link changes throughout the text). -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri May 6 10:02:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17454 for ; Fri, 6 May 2005 10: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 j46DpqZP081006; Fri, 6 May 2005 06:51: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 j46DpqWs081005; Fri, 6 May 2005 06:51: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Dpp7p080982 for ; Fri, 6 May 2005 06:51:51 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1392116wri for ; Fri, 06 May 2005 06:51:45 -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=SsCl34qAYYR81MdgtQhA3w49IBsmCT/H1tEUAhjBHDaZBZ2h4g0/k7w9Y6bAT6Zjr7YnUBUTwWJ2O4aFrDBVqnXjhK5h89eA3SJyGhqYjfR4txwa5v8sZyvXppTNoN3tnc4AT/KLFf1hvc+L8XPaNXoDXNLI/bhvGq4tGtLaH8w= Received: by 10.54.34.28 with SMTP id h28mr830603wrh; Fri, 06 May 2005 06:51:45 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Fri, 6 May 2005 06:51:45 -0700 (PDT) Message-ID: <14be96d30505060651264b179a@mail.gmail.com> Date: Fri, 6 May 2005 08:51:45 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax Subject: Atom Implementation Guide: seeking co-editor 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 j46Dpp7p080999 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In case this got buried in the previous thread, last fall I wrote but never publicized a minimal draft of an Atom Implementation Guide. http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html Due to my commitments elsewhere, I can not promise that I will ever finish this alone. If the WG wants to publish an implementation guide as an RFC, I need a co-editor who is willing to write -- not provide feedback, not sit in the peanut gallery and poke at it with sharp pointy objects, but actually *write* -- a substantial portion of it. You would have complete control over its direction and be listed as the primary author; I may be able to contribute specific sections as time permits. Please reply on-list. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Fri May 6 10:10:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18589 for ; Fri, 6 May 2005 10:10: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 j46E2I4v082638; Fri, 6 May 2005 07:02: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 j46E2HgC082637; Fri, 6 May 2005 07:02:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46E2HiM082629 for ; Fri, 6 May 2005 07:02:17 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j46E2GnA014903 for ; Fri, 6 May 2005 07:02:16 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j46E4WHC014488 for ; Fri, 6 May 2005 09:04:32 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j46E2FVp021679 for ; Fri, 6 May 2005 09:02:15 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IG2000OJMZQXA@ims1.labs.mot.com> for atom-syntax@imc.org; Fri, 06 May 2005 09:02:14 -0500 (CDT) Date: Fri, 06 May 2005 09:02:14 -0500 From: Brett Lindsley Subject: Re: PaceAllowDuplicateIDs To: atom-syntax Message-id: <427B78E6.3080309@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> <427B362A.3090904@dehora.net> <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Unique IDs allow clients to determine the state of the feed. If entry ids are not unique, then we still need some other way to determine the unique state of the feed. If we allow duplicate IDs but *require* something else to be different (e.g. update time), then we can still determine the unique state of a feed and repeated IDs are OK. We would need to properly document which elements make an entry unique in the event of a duplicated ID. Brett. > > On 6 May 2005, at 2:10 pm, Dave Johnson wrote: > >> >> Yes, I think both of my arguments fail to hold and I no longer have >> a real objection to duplicates. Allowing duplicates gives feed >> produces to model events or other objects (versioned documents in a >> wiki) as they wish. Like you, I wonder "Does anyone remember why >> having the same id in a feed is a bad idea?" > > > From owner-atom-syntax@mail.imc.org Fri May 6 10:19:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19723 for ; Fri, 6 May 2005 10:19: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 j46E9n6T083945; Fri, 6 May 2005 07:09: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 j46E9n2r083943; Fri, 6 May 2005 07:09:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46E9mJW083887 for ; Fri, 6 May 2005 07:09:48 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46E9A2X005964 for ; Fri, 6 May 2005 15:09:16 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: PaceAllowDuplicateIDs alteration Date: Fri, 6 May 2005 15:09:10 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As the WG may have noticed, I have some serious problems with the Pace. One small change would eliminate about 75% of them: Replace the line: "If an Atom Feed Document contains multiple entries with the same atom:id, software MAY choose to display all of them or some subset of them" with: "If an Atom Feed Document contains multiple entries with the same atom:id, software MUST treat them as multiple versions of the same entry" I don't think this changes the technical meaning of the proposal, but does make it very explicit. Would anyone object to this change? Graham From owner-atom-syntax@mail.imc.org Fri May 6 10:39:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21464 for ; Fri, 6 May 2005 10:39: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 j46EVQrt088197; Fri, 6 May 2005 07:31: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 j46EVQPN088196; Fri, 6 May 2005 07:31:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46EVP24088181 for ; Fri, 6 May 2005 07:31:25 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46EVNgt028808; Fri, 6 May 2005 10:31:23 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCJ96725; Fri, 6 May 2005 10:31:21 -0400 (EDT) Message-Id: <200505061431.DCJ96725@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'Dave Johnson'" Cc: "'atom-syntax'" Subject: RE: PaceAllowDuplicateIDs Date: Fri, 6 May 2005 10:31:17 -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.2900.2180 Thread-Index: AcVSQ3zM64T/AwK1RYWMJiLwY7uwHQAAKRvw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: >>"Does anyone remember why having the same id in a feed is a bad idea?" > Beacuse instead of a fixed model where a feed is a stream of > entries each with their own id, it is now a stream of entries each > of which does not have its own id, but shares it with similar > entries. This is bullshit. I completely disagree on this. I think the problem here is people focusing too much on characteristics of the feed when the real issue here is Entries. Like I've said in the past, "It's about the Entries, Stupid!" (don't take offense...) As long as we allow entries to be updated, it is inevitable that the stream of entries that is created over time will contain instances of entries that share common atom:id values. The only question here is whether or not we're willing to allow a feed document to *accurately* represent the stream of entries -- as they were created -- or whether we insist that the feed document "censor" the history of the stream by removing old instances of updated entries before allowing updates to be inserted. The reality is that no matter which decision we make in this case, any useful aggregator must have code to deal with multiple instances of an entries that share the same atom:id. This is the case since even if we don't permit duplicate IDs in a single instance of a feed document, we would still permit duplicate ID's *over time." Because duplicate ids appear, over time, whenever you update an entry, the aggregator has to have all the logic needed to handle them in the *stream* of entries that it reads -- over time. This issue only becomes interesting if we try to provide special rules for the handling of data within a single instance of a feed document. The reality is, however, that any aggregator that actually pays attention to these special case rules is going to either get more complex (since it can't simply treat everything as a stream of entries) or it will get confused (since folk will intentionally or unintentionally create duplicate ids). This ban on duplicate ids provides no benefit for aggregators, it makes feed producers more complex, it tempts aggregator or client writers to do dangerous things, it forces deletion of data that is useful to some people for some applications, it puts too much emphasis on "feeds" when we should be working on "entries", etc... It is a really bad thing to do. bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 10:39:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21487 for ; Fri, 6 May 2005 10:39: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 j46EVYex088224; Fri, 6 May 2005 07:31: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 j46EVY6N088223; Fri, 6 May 2005 07:31:34 -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 j46EVXYP088199 for ; Fri, 6 May 2005 07:31:33 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 58708 messnum 4219853 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:31:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail13.svc.cra.dublin.eircom.net (qp 58708) with SMTP; 6 May 2005 14:31:27 -0000 Message-ID: <427B7FBB.2020502@dehora.net> Date: Fri, 06 May 2005 15:31:23 +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: PaceTextShouldBeProvided vs PaceOptionalSummary References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <427B64AF.7020400@dehora.net> <427B692E.8090704@intertwingly.net> In-Reply-To: <427B692E.8090704@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 wrote: > Bill de hra wrote: > >> >> 3. It's the kind of spec text we have rejected in the past as >> impletation specific and/or "best current practice" guidance: >> >> "those that follow these suggestions will find that their feeds are >> useful to a wider audience than they would be otherwise." > > > Um, that text is not part of the proposal. It is part of the rationale. I know. I don't see the point of considering PaceTextShouldBeProvided if the rationale doesn't hold up. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 10:43:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21738 for ; Fri, 6 May 2005 10:43: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 j46EZNSR088897; Fri, 6 May 2005 07:35: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 j46EZN8g088896; Fri, 6 May 2005 07:35:23 -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 j46EZNUb088890 for ; Fri, 6 May 2005 07:35:23 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j46EbthO008898 for ; Fri, 6 May 2005 07:37:55 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j46EcHPq013004 for ; Fri, 6 May 2005 09:38:18 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j46EZMVp022234; Fri, 6 May 2005 09:35:22 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IG2000YROIYXA@ims1.labs.mot.com>; Fri, 06 May 2005 09:35:22 -0500 (CDT) Date: Fri, 06 May 2005 09:35:22 -0500 From: Brett Lindsley Subject: Re: PaceAllowDuplicateIDs alteration To: Graham Cc: atom-syntax Message-id: <427B80AA.9030305@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT What determines a "version"? If we have multiple entries with identical information, these are copies, not versions. The real issue is feed state. Given there are identical IDs, can we determine if the entries are identical or different? The end client can then deal with it any way it wants (e.g.): - Keep only the most recent. - Display them all. - Combine them all into a single entry with a history. - Show changes. - Drop duplicates. - etc. Sorry I don't have an answer here, just an observation of the exact problem. Brett Graham wrote: > > > > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MUST treat them as multiple versions of the same > entry" > > > From owner-atom-syntax@mail.imc.org Fri May 6 10:44:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21903 for ; Fri, 6 May 2005 10:44: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 j46EboK2089377; Fri, 6 May 2005 07: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 j46EboZC089376; Fri, 6 May 2005 07:37:50 -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 j46EbnDl089347 for ; Fri, 6 May 2005 07:37:50 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 55040 messnum 6395315 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:37:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 55040) with SMTP; 6 May 2005 14:37:44 -0000 Message-ID: <427B8134.4020000@dehora.net> Date: Fri, 06 May 2005 15:37:40 +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: PaceTextShouldBeProvided 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. I agree with Robert; it conflicts with PaceOptionalSummary and I doubt it would exist if PaceOptionalSummary had not make the cut. At best level of specification belongs in the Fabled Implementor's Guide, not the specification. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 10:44:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21906 for ; Fri, 6 May 2005 10:44: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 j46EavV0089220; Fri, 6 May 2005 07:36: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 j46EavCE089219; Fri, 6 May 2005 07:36: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 j46Eaucf089209 for ; Fri, 6 May 2005 07:36: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 j46EaujO028019 for ; Fri, 6 May 2005 08:36:56 -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 <0IG200KR5OLJZG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 06 May 2005 08:36:56 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG200ATTOLJTI@mail.sun.net> for atom-syntax@imc.org; Fri, 06 May 2005 08:36:55 -0600 (MDT) Date: Fri, 06 May 2005 07:37:59 -0700 From: Tim Bray Subject: Re: PaceAllowDuplicateIDs alteration In-reply-to: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> To: Graham Cc: atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 6, 2005, at 7:09 AM, Graham wrote: > Replace the line: > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MAY choose to display all of them or some subset of > them" > > with: > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MUST treat them as multiple versions of the same > entry" Hmmm; the Pace already says "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry." So what you want is almost there. > I don't think this changes the technical meaning of the proposal, but > does make it very explicit. My problem is that when you say "software MUST", I think you should follow up with something specific and testable. This assertion feels fairly vague and leaves room for lots of argument. Maybe a first step to tightening it up would be to provide some specific examples of software behaviors that would be forbidden/allowed by this MUST-clause. -Tim [who has yet to express a +1 or any other final opinion about this Pace] From owner-atom-syntax@mail.imc.org Fri May 6 10:45:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22009 for ; Fri, 6 May 2005 10: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 j46EdL79089622; Fri, 6 May 2005 07:39: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 j46EdLEK089621; Fri, 6 May 2005 07:39:21 -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 j46EdKhT089600 for ; Fri, 6 May 2005 07:39:20 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 9265 messnum 280055 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:39:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail03.svc.cra.dublin.eircom.net (qp 9265) with SMTP; 6 May 2005 14:39:14 -0000 Message-ID: <427B818E.3050109@dehora.net> Date: Fri, 06 May 2005 15: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: Mark Pilgrim CC: atom-syntax Subject: Re: Atom Implementation Guide: seeking co-editor References: <14be96d30505060651264b179a@mail.gmail.com> In-Reply-To: <14be96d30505060651264b179a@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 Mark Pilgrim wrote: > In case this got buried in the previous thread, last fall I wrote but > never publicized a minimal draft of an Atom Implementation Guide. > > http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html > > Due to my commitments elsewhere, I can not promise that I will ever > finish this alone. If the WG wants to publish an implementation guide > as an RFC, I need a co-editor who is willing to write -- not provide > feedback, not sit in the peanut gallery and poke at it with sharp > pointy objects, but actually *write* -- a substantial portion of it. > You would have complete control over its direction and be listed as > the primary author; I may be able to contribute specific sections as > time permits. Tim at a time into my inbox earlier than the above: "Given the volume of debate, it's obvious there may be more work to do here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery spec, and he's accepted. " Crossed wires? cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 10:50:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22558 for ; Fri, 6 May 2005 10:50: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 j46Ef5wv089896; Fri, 6 May 2005 07: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 j46Ef5SL089895; Fri, 6 May 2005 07:41:05 -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 j46Ef4cd089888 for ; Fri, 6 May 2005 07:41:04 -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 j46Ef4jO001505 for ; Fri, 6 May 2005 08:41:04 -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 <0IG2009KJOSF64@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 06 May 2005 08:41:04 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG200AVPOSFTI@mail.sun.net> for atom-syntax@imc.org; Fri, 06 May 2005 08:41:03 -0600 (MDT) Date: Fri, 06 May 2005 07:42:08 -0700 From: Tim Bray Subject: A quick note on process To: atom-syntax Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Your co-chairs would like to ask a favor of the group. When doing our last consensus call, it's going to be prohibitively difficult to go back to the beginning of time. Thus, we'd like to start with Sam's announcement of the issues list revision at http://www.imc.org/atom-syntax/mail-archive/msg14742.html So if you have a strong feeling, pro or contra, about any of the Paces currently in play, please make sure you've put it on the record since then. Thanks in advance. -Tim From owner-atom-syntax@mail.imc.org Fri May 6 10:50:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22561 for ; Fri, 6 May 2005 10: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 j46EjKDp090841; Fri, 6 May 2005 07:45: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 j46EjK02090840; Fri, 6 May 2005 07:45:20 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46EjGxe090809 for ; Fri, 6 May 2005 07:45:19 -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, 7 May 2005 00:45:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 00:45:08 +1000 Subject: Re: PaceAllowDuplicateIDs 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 6/5/05 11:37 PM, "Graham" wrote: > Beacuse instead of a fixed model where a feed is a stream of entries > each with their own id, it is now a stream of entries each of which > does not have its own id, but shares it with similar entries. This is > bullshit. See the spec: [...] Put another way, 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. [...] This clearly implies that a feed is a stream of *instantiations* of an entry. Put another way, the map is not the territory, the is not the 'entry'. e. From owner-atom-syntax@mail.imc.org Fri May 6 10:53:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22839 for ; Fri, 6 May 2005 10: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 j46Em4ie091570; Fri, 6 May 2005 07:48: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 j46Em42B091569; Fri, 6 May 2005 07:48:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j46Em3rK091533 for ; Fri, 6 May 2005 07:48:04 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 37117 messnum 2898050 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:47:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail06.svc.cra.dublin.eircom.net (qp 37117) with SMTP; 6 May 2005 14:47:57 -0000 Message-ID: <427B839A.5090606@dehora.net> Date: Fri, 06 May 2005 15:47:54 +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: EntryId 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 PaceAllowDuplicateIDs +1. PaceDuplicateIDWithSource2 -1 PaceDuplicateIDWithSource -1 PaceExplainDuplicateIds +1 We have no clear reason to disallow the use-case, until we put our cards on the table re what's being identified. So either PaceAllowDuplicateIDs or PaceExplainDuplicateIds are fine by me. An alternative option that might get consensus is to pace a profile that switches the duplicate per feed restriction off; the security question there is whether anyone will pay attention to such a directive. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 10:54:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22940 for ; Fri, 6 May 2005 10:54: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 j46Eg1Nl090086; Fri, 6 May 2005 07:42: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 j46Eg1G1090085; Fri, 6 May 2005 07:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Eg0IH090054 for ; Fri, 6 May 2005 07:42:00 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 4928 invoked by uid 10); 6 May 2005 14:41:54 -0000 Received: (vexira-qq 04911-4D2C6A91 invoked from network) 06 May 2005 16:41:53 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 May 2005 14:41:53 -0000 Message-ID: <427B823D.20607@annevankesteren.nl> Date: Fri, 06 May 2005 16:42:05 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?77+9?= CC: Mark Pilgrim , atom-syntax Subject: Re: Atom Implementation Guide: seeking co-editor References: <14be96d30505060651264b179a@mail.gmail.com> <427B818E.3050109@dehora.net> In-Reply-To: <427B818E.3050109@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit � wrote: > Tim at a time into my inbox earlier than the above: > > "Given the volume of debate, it's obvious there may be more work to do > here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery > spec, and he's accepted. " > > Crossed wires? Euh, the autodiscovery specification is not really equal to the implementation guide. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Fri May 6 11:01:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23473 for ; Fri, 6 May 2005 11: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 j46EsisZ092779; Fri, 6 May 2005 07:54: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 j46EsiYP092778; Fri, 6 May 2005 07:54:44 -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 j46EshSG092760 for ; Fri, 6 May 2005 07:54:44 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59621 messnum 11073503 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:54:37 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail11.svc.cra.dublin.eircom.net (qp 59621) with SMTP; 6 May 2005 14:54:37 -0000 Message-ID: <427B8529.9000708@dehora.net> Date: Fri, 06 May 2005 15:54:33 +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: Anne van Kesteren CC: Mark Pilgrim , atom-syntax Subject: Re: Atom Implementation Guide: seeking co-editor References: <14be96d30505060651264b179a@mail.gmail.com> <427B818E.3050109@dehora.net> <427B823D.20607@annevankesteren.nl> In-Reply-To: <427B823D.20607@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Anne van Kesteren wrote: > > � wrote: > >> Tim at a time into my inbox earlier than the above: >> >> "Given the volume of debate, it's obvious there may be more work to do >> here. Paul and I have asked Phil Ringnalda to co-edit the >> autodiscovery spec, and he's accepted. " >> >> Crossed wires? > > > Euh, the autodiscovery specification is not really equal to the > implementation guide. To tell you the truth, in all this excitement, I've kinda lost track myself. My crossed wires then, never mind. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:05:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23940 for ; Fri, 6 May 2005 11: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 j46Exg5n093730; Fri, 6 May 2005 07:59: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 j46ExgXU093729; Fri, 6 May 2005 07:59: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46ExeZH093714 for ; Fri, 6 May 2005 07:59: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); Sat, 7 May 2005 00:59:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 00:59:35 +1000 Subject: Re: Atom Implementation Guide: seeking co-editor From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <427B818E.3050109@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46ExgZH093724 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 7/5/05 12:39 AM, "Bill de hra" wrote: >> http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html >> >> Due to my commitments elsewhere, I can not promise that I will ever >> finish this alone. If the WG wants to publish an implementation guide >> as an RFC, I need a co-editor who is willing to write -- not provide >> feedback, not sit in the peanut gallery and poke at it with sharp >> pointy objects, but actually *write* -- a substantial portion of it. >> You would have complete control over its direction and be listed as >> the primary author; I may be able to contribute specific sections as >> time permits. > > Tim at a time into my inbox earlier than the above: > > "Given the volume of debate, it's obvious there may be more work to do > here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery > spec, and he's accepted. " > > Crossed wires? auto discovery spec != implementation guide e. From owner-atom-syntax@mail.imc.org Fri May 6 11:07:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24185 for ; Fri, 6 May 2005 11:07: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 j46F18Me094196; Fri, 6 May 2005 08: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 j46F18M6094195; Fri, 6 May 2005 08:01:08 -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 j46F175p094104 for ; Fri, 6 May 2005 08:01:08 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 86460 messnum 11065444 invoked from network[83.70.217.193/unknown]); 6 May 2005 15:01:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail11.svc.cra.dublin.eircom.net (qp 86460) with SMTP; 6 May 2005 15:01:01 -0000 Message-ID: <427B86A9.5010102@dehora.net> Date: Fri, 06 May 2005 16:00: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: FeedId 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 PaceFeedIdOrAlternate, withdrawn, no comment PaceFeedIdOrSelf 0 PaceOptionalFeedLink +1 I agree with the rationale; no point making people things they can't do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is a MUST. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:07:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24224 for ; Fri, 6 May 2005 11:07: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 j46EqNxr092344; Fri, 6 May 2005 07: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 j46EqNkw092343; Fri, 6 May 2005 07: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46EqMUW092335 for ; Fri, 6 May 2005 07:52:23 -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, 7 May 2005 00:52:23 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 00:52:19 +1000 Subject: Re: PaceAllowDuplicateIDs alteration From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.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 7/5/05 12:09 AM, "Graham" wrote: > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MUST treat them as multiple versions of the same > entry" > > I don't think this changes the technical meaning of the proposal, but > does make it very explicit. +1, with one minor amendment. s/versions/instantiations/ the spec uses that word elsewhere, and 'versions' might suggest a media adaptation, language variant, etc. e. From owner-atom-syntax@mail.imc.org Fri May 6 11:09:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24605 for ; Fri, 6 May 2005 11:09: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 j46EwgvH093641; Fri, 6 May 2005 07:58: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 j46Ewg3R093640; Fri, 6 May 2005 07:58:42 -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 j46Ewet1093613 for ; Fri, 6 May 2005 07:58:41 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 83291 messnum 277703 invoked from network[83.70.217.193/unknown]); 6 May 2005 14:58:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail03.svc.cra.dublin.eircom.net (qp 83291) with SMTP; 6 May 2005 14:58:34 -0000 Message-ID: <427B8617.9070204@dehora.net> Date: Fri, 06 May 2005 15:58:31 +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: Dave Johnson , atom-syntax Subject: Re: PaceAllowDuplicateIDs References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> <427B362A.3090904@dehora.net> <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> 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 Graham wrote: > > On 6 May 2005, at 2:10 pm, Dave Johnson wrote: > >> >> Yes, I think both of my arguments fail to hold and I no longer have a >> real objection to duplicates. Allowing duplicates gives feed produces >> to model events or other objects (versioned documents in a wiki) as >> they wish. Like you, I wonder "Does anyone remember why having the >> same id in a feed is a bad idea?" > > > Beacuse instead of a fixed model where a feed is a stream of entries > each with their own id, it is now a stream of entries each of which > does not have its own id, but shares it with similar entries. This is > bullshit. No, it's not, not yet. You can't reasonably call bullshit on this either way until we know what's being identified. When I boil it down, this is what I get: "the technical problem we have is that we can't distinguish between a buggy feed with the same ids and an aggregate feed with the same ids under the current spec" I have no good answer to that until I know what what an id stands for. The answer "an entry" isn't sufficient. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:13:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24961 for ; Fri, 6 May 2005 11:13: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 j46F6YvU094651; Fri, 6 May 2005 08:06: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 j46F6YNq094650; Fri, 6 May 2005 08:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-m15.mx.aol.com (imo-m15.mx.aol.com [64.12.138.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F6X8M094639 for ; Fri, 6 May 2005 08:06:33 -0700 (PDT) (envelope-from Svgdeveloper@aol.com) Received: from Svgdeveloper@aol.com by imo-m15.mx.aol.com (mail_out_v38_r1.7.) id 7.1c4.27d7d4f3 (2519); Fri, 6 May 2005 11:06:27 -0400 (EDT) From: Svgdeveloper@aol.com Message-ID: <1c4.27d7d4f3.2face1f2@aol.com> Date: Fri, 6 May 2005 11:06:26 EDT Subject: Re: Atom Implementation Guide: seeking co-editor To: pilgrim@gmail.com, atom-syntax@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1c4.27d7d4f3.2face1f2_boundary" X-Mailer: 8.0 for Windows sub 670 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part1_1c4.27d7d4f3.2face1f2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Mark, Like you, I am not short of things to do but would be willing to contribute to this process. I guess the first thing to be clarified is whether the WG wants an Implementation Guide or not. Then, assuming they do, an idea of hoped-for timetable and scope would be good. Since I have, on the whole, sat back and let the discussion/war flow on this list I guess I should briefly mention some relevant credentials. Since writing text seems to be the main task which needs to be done I will focus comments in that direction. I guess the most recent relevant writing is as co-author with Danny Ayers of Beginning RSS & Atom Programming which should be published by Wrox any day now. I have also written all or part of various XML or XML-associated books including Pro XML (2nd Edition), Beginning XML (3rd Edition), Pro XSL, Teach Yourself XML in 10 Minutes, XPath Essentials, XML Schema Essentials and Designing SVG Web Graphics. I have also, in times past, poked hard with the pointy stick at assorted W3C working drafts including XSLT 2.0, XPath 2.0, XQuery 1.0, SVG 1.x and XForms 1.0. If anyone well-qualified has lots of time on their hands I would be happy to let them proceed with the task. :) Andrew Watt In a message dated 06/05/2005 14:52:28 GMT Daylight Time, pilgrim@gmail.com writes: > In case this got buried in the previous thread, last fall I wrote but > never publicized a minimal draft of an Atom Implementation Guide. > > http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html > > Due to my commitments elsewhere, I can not promise that I will ever > finish this alone. If the WG wants to publish an implementation guide > as an RFC, I need a co-editor who is willing to write -- not provide > feedback, not sit in the peanut gallery and poke at it with sharp > pointy objects, but actually *write* -- a substantial portion of it. > You would have complete control over its direction and be listed as > the primary author; I may be able to contribute specific sections as > time permits. > > Please reply on-list. > > -- > Cheers, > -Mark > --part1_1c4.27d7d4f3.2face1f2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Mark,

Like you, I am not short of things to do but would be willing to contribute=20= to this process.

I guess the first thing to be clarified is whether the WG wants an Implement= ation Guide or not. Then, assuming they do, an idea of hoped-for timetable a= nd scope would be good.

Since I have, on the whole, sat back and let the discussion/war flow on this= list I guess I should briefly mention some relevant credentials. Since writ= ing text seems to be the main task which needs to be done I will focus comme= nts in that direction.

I guess the most recent relevant writing is as co-author with Danny Ayers of= Beginning RSS & Atom Programming which should be published by Wrox any=20= day now.

I have also written all or part of various XML or XML-associated books inclu= ding Pro XML (2nd Edition), Beginning XML (3rd Edition), Pro XSL, Teach Your= self XML in 10 Minutes, XPath Essentials, XML Schema Essentials and Designin= g SVG Web Graphics.

I have also, in times past, poked hard with the pointy stick at assorted W3C= working drafts including XSLT 2.0, XPath 2.0, XQuery 1.0, SVG 1.x and XForm= s 1.0.

If anyone well-qualified has lots of time on their hands I would be happy to= let them proceed with the task. :)

Andrew Watt

In a message dated 06/05/2005 14:52:28 GMT Daylight Time, pilgrim@gmail.com=20= writes:

In case this got buried in the=20= previous thread, last fall I wrote but
never publicized a minimal draft of an Atom Implementation Guide.

http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html

Due to my commitments elsewhere, I can not promise that I will ever
finish this alone.  If the WG wants to publish an implementation guide<= BR> as an RFC, I need a co-editor who is willing to write -- not provide
feedback, not sit in the peanut gallery and poke at it with sharp
pointy objects, but actually *write* -- a substantial portion of it.
You would have complete control over its direction and be listed as
the primary author; I may be able to contribute specific sections as
time permits.

Please reply on-list.

--
Cheers,
-Mark


 --part1_1c4.27d7d4f3.2face1f2_boundary-- From owner-atom-syntax@mail.imc.org Fri May 6 11:14:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25302 for ; Fri, 6 May 2005 11:14: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 j46F891n094776; Fri, 6 May 2005 08:08: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 j46F89Um094775; Fri, 6 May 2005 08:08: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F88GR094768 for ; Fri, 6 May 2005 08:08:09 -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, 7 May 2005 01:08:09 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 01:08:06 +1000 Subject: Re: Atom Implementation Guide: seeking co-editor From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <14be96d30505060651264b179a@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 6/5/05 11:51 PM, "Mark Pilgrim" wrote: > In case this got buried in the previous thread, last fall I wrote but > never publicized a minimal draft of an Atom Implementation Guide. > > http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html > > Due to my commitments elsewhere, I can not promise that I will ever > finish this alone. If the WG wants to publish an implementation guide > as an RFC, I need a co-editor who is willing to write -- not provide > feedback, not sit in the peanut gallery and poke at it with sharp > pointy objects, but actually *write* -- a substantial portion of it. > You would have complete control over its direction and be listed as > the primary author; I may be able to contribute specific sections as > time permits. I believe I can commit to this. You've provided a good outline, which is 80% of the work (writing the content is the other 80% ;-) e. From owner-atom-syntax@mail.imc.org Fri May 6 11:15:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25484 for ; Fri, 6 May 2005 11:15: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 j46FAhM5094974; Fri, 6 May 2005 08:10: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 j46FAhdd094973; Fri, 6 May 2005 08:10:43 -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 j46FAgTO094948 for ; Fri, 6 May 2005 08:10:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29126 messnum 6687272 invoked from network[83.70.217.193/unknown]); 6 May 2005 15:10:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 29126) with SMTP; 6 May 2005 15:10:36 -0000 Message-ID: <427B88E8.5070700@dehora.net> Date: Fri, 06 May 2005 16:10: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: Atom Syntax Subject: Status 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 PaceEntryState -1 PacePubControl -1, strongly PacePubStatusResource 0 I agree very much with Tim's ob about decoupling state from format for PaceEntryState. I think PacePubControl has a similar looking problem, so I don't believe in PacePubControl, as Tim does. That's because it puts the control code into the format and creates a new processing directive as a consequence of whether we're in protocol mode or not. That couples protocol with format in a messy way. The pub:control directive should wrap the entry not be embedded in it. I'm 0 on PacePubStatusResource, as I think it's the right approach, but I'm holding for someone with WebDAV/REST clout, who isn't Robert, to confirm whether they think it's ok. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:18:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26021 for ; Fri, 6 May 2005 11:18: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 j46FCsD5095183; Fri, 6 May 2005 08:12: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 j46FCsHZ095182; Fri, 6 May 2005 08:12:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46FCrUk095176 for ; Fri, 6 May 2005 08:12:54 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46FCqWj001983; Fri, 6 May 2005 11:12:52 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCK10416; Fri, 6 May 2005 11:12:47 -0400 (EDT) Message-Id: <200505061512.DCK10416@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceAllowDuplicateIDs Date: Fri, 6 May 2005 11:12:42 -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.2900.2180 Thread-Index: AcVSTCRNQ8/Of24tTD2w25SZIJRiEwAAIrGw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > a feed is a stream of *instantiations* of an entry. > Put another way, the map is not the territory, the is not > the 'entry'. Right. We have abstract feeds and entries and we have concrete feeds and entries. The abstract feed is the actual stream of entries and updates to entries as they are created over time. Feed documents are "concrete" snapshots of this stream or abstract feed of entries. An abstract entry is made "concrete" in entry documents or entry elements. An abstract entry may change over time and may have one or more concrete instantiations. Some applications are only interested in being exposed to those concrete entries that reflect the "current" or "most recent" state of the abstract entries -- these apps would prefer to see no duplicate ids in concrete feed documents even though these duplicates *will* occur in the abstract feed. Other applications will require visibility to the entire stream of changes to abstract entries -- these applications will wish to see concrete feeds that may contain multiple, differing concrete instantiations of abstract entries. i.e. they will want the concrete feed to be an accurate representation of the abstract feed. Two needs, to views... bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 11:22:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27228 for ; Fri, 6 May 2005 11:22: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 j46FGrML095687; Fri, 6 May 2005 08:16: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 j46FGrgU095686; Fri, 6 May 2005 08:16:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46FGqRb095680 for ; Fri, 6 May 2005 08:16:53 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46FGpqp025578; Fri, 6 May 2005 11:16:51 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCK11864; Fri, 6 May 2005 11:16:49 -0400 (EDT) Message-Id: <200505061516.DCK11864@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'atom-syntax'" Subject: RE: PaceAllowDuplicateIDs alteration Date: Fri, 6 May 2005 11:16: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: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVSR/EJB+qiphBQRAmneBrtjUkulQABnK6A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > "If an Atom Feed Document contains multiple entries with the > same atom:id, software MUST treat them as multiple versions of > the same entry" Are they still the same entry if they have different source elements that identify their source as being different feeds? bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 11:23:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27564 for ; Fri, 6 May 2005 11:23: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 j46FGEZr095529; Fri, 6 May 2005 08:16: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 j46FGE8E095528; Fri, 6 May 2005 08:16:14 -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 j46FGDuc095499 for ; Fri, 6 May 2005 08:16:13 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 46729 messnum 11070204 invoked from network[83.70.217.193/unknown]); 6 May 2005 15:16:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail11.svc.cra.dublin.eircom.net (qp 46729) with SMTP; 6 May 2005 15:16:07 -0000 Message-ID: <427B8A33.7020207@dehora.net> Date: Fri, 06 May 2005 16:16:03 +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: PaceAllowDuplicateIDs alteration References: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> In-Reply-To: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@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: > > As the WG may have noticed, I have some serious problems with the Pace. > One small change would eliminate about 75% of them: > > Replace the line: > > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MAY choose to display all of them or some subset of > them" > > with: > > "If an Atom Feed Document contains multiple entries with the same > atom:id, software MUST treat them as multiple versions of the same entry" > > I don't think this changes the technical meaning of the proposal, but > does make it very explicit. > > Would anyone object to this change? Looks promising. Would you replace "versions" with "representations"? cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:27:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28681 for ; Fri, 6 May 2005 11:27: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 j46FKKve096272; Fri, 6 May 2005 08:20: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 j46FKKEB096271; Fri, 6 May 2005 08:20:20 -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 j46FKJJi096250 for ; Fri, 6 May 2005 08:20:19 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 10986 messnum 5246173 invoked from network[83.70.217.193/unknown]); 6 May 2005 15:20:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail02.svc.cra.dublin.eircom.net (qp 10986) with SMTP; 6 May 2005 15:20:13 -0000 Message-ID: <427B8B29.2070205@dehora.net> Date: Fri, 06 May 2005 16:20:09 +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: Sam Ruby CC: Graham , atom-syntax Subject: Re: PaceOptionalFeedLink References: <427ADB61.7010805@intertwingly.net> <427B6279.5070601@intertwingly.net> In-Reply-To: <427B6279.5070601@intertwingly.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 Sam Ruby wrote: > Something that WOULD attract my attention is somebody saying "here is a > set of feeds that I would like to provide that I can't provide in a > valid way according to any of the available RSS specifications." Sam, would: work for you? This could make/encourage those who don't have alternates to say so and might allow downstream code to make better assumptions. If you like the idea, and we're not past the point, I'll write a pace. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:27:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28848 for ; Fri, 6 May 2005 11:27: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 j46FJRUu096131; Fri, 6 May 2005 08:19: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 j46FJR3J096130; Fri, 6 May 2005 08:19: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 j46FJQZR096116 for ; Fri, 6 May 2005 08:19:26 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46FJkeZ031770; Fri, 6 May 2005 11:19:46 -0400 Message-ID: <427B8AF6.90907@intertwingly.net> Date: Fri, 06 May 2005 11:19:18 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: FeedId References: <427B86A9.5010102@dehora.net> In-Reply-To: <427B86A9.5010102@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > > PaceFeedIdOrAlternate, withdrawn, no comment > PaceFeedIdOrSelf 0 > PaceOptionalFeedLink +1 > > I agree with the rationale; no point making people things they can't do. > I'm assuming that if PaceOptionalFeedLink goes through feed:id is a MUST. On what do you base that assumption? - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 11:41:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02341 for ; Fri, 6 May 2005 11:41: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 j46FSuRZ097776; Fri, 6 May 2005 08:28: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 j46FSubC097775; Fri, 6 May 2005 08:28:56 -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 j46FSt6A097758 for ; Fri, 6 May 2005 08:28:55 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 92859 messnum 5274814 invoked from network[83.70.217.193/unknown]); 6 May 2005 15:28:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail04.svc.cra.dublin.eircom.net (qp 92859) with SMTP; 6 May 2005 15:28:49 -0000 Message-ID: <427B8D2D.3030807@dehora.net> Date: Fri, 06 May 2005 16:28:45 +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: Sam Ruby CC: Atom Syntax Subject: Re: FeedId References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> In-Reply-To: <427B8AF6.90907@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 wrote: > Bill de hra wrote: > >> >> PaceFeedIdOrAlternate, withdrawn, no comment >> PaceFeedIdOrSelf 0 >> PaceOptionalFeedLink +1 >> >> I agree with the rationale; no point making people things they can't >> do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is >> a MUST. > > > On what do you base that assumption? That there is consensus we'll want to identify a feed, even if we can't provide a link. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 6 11:55:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04038 for ; Fri, 6 May 2005 11:55: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 j46Fn92R001097; Fri, 6 May 2005 08:49: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 j46Fn996001096; Fri, 6 May 2005 08:49: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Fn7t1001090 for ; Fri, 6 May 2005 08:49: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); Sat, 7 May 2005 01:49:07 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 01:49:04 +1000 Subject: Re: PaceAllowDuplicateIDs alteration From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200505061516.DCK11864@ms8.netsolmail.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 7/5/05 1:16 AM, "Bob Wyman" wrote: > Graham wrote: >> "If an Atom Feed Document contains multiple entries with the >> same atom:id, software MUST treat them as multiple versions of >> the same entry" > Are they still the same entry if they have different source elements > that identify their source as being different feeds? I don't see why. I subscribe to a Local News feed, a National News feed, and a Science News feed. All from the same publisher. The same story may appear in one, two, or three of those feeds. I don't believe each of those feeds would have the same feed/source values. e. From owner-atom-syntax@mail.imc.org Fri May 6 12:54:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09666 for ; Fri, 6 May 2005 12:54: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 j46GmrXw010671; Fri, 6 May 2005 09:48: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 j46Gmr2w010670; Fri, 6 May 2005 09:48:53 -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 j46Gmq0V010647 for ; Fri, 6 May 2005 09:48:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so994600wra for ; Fri, 06 May 2005 09:48:47 -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=BqChbWLT/QyQMIoiqfJs2QwIXtLp4gECQsK1ZxEXwt8sEO288C8Jte7gNGh2PcaRnTgaG8/FUhJctvKzy1ZtIcSTK6UnF8RlvmewKbPrIrnRuLQp+byohNsMLJJHuMgcAh/Ubq3+cwZg4It78XaZgQ7QF/aVlhyfvxOokPtpieY= Received: by 10.54.18.12 with SMTP id 12mr457925wrr; Fri, 06 May 2005 09:48:47 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Fri, 6 May 2005 09:48:47 -0700 (PDT) Message-ID: <68fba5c5050506094856f327e0@mail.gmail.com> Date: Fri, 6 May 2005 12:48:47 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: A quick note on process Cc: atom-syntax Syntax 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 j46Gmr0V010664 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, Tim Bray wrote: > So if you have a strong feeling, pro or contra, about any of the Paces > currently in play, please make sure you've put it on the record since > then. PaceOptionalSummary addresses a last call issue. I expect every single last call comment will be taken into account. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 6 12:57:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09893 for ; Fri, 6 May 2005 12:56: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 j46Gl53l010412; Fri, 6 May 2005 09:47: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 j46Gl5b7010411; Fri, 6 May 2005 09:47:05 -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 j46Gl5Rr010405 for ; Fri, 6 May 2005 09:47:05 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 29404 invoked by uid 17064); 6 May 2005 16:47:04 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.105.66]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 May 2005 16:47:04 -0000 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax Syntax From: Henry Story Subject: entry definition Date: Fri, 6 May 2005 18:46:59 +0200 X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some have been clamoring for a good definition of an entry. Here is one I have thought of recently. An Atom Entry is a resource (identified by atom:id) whose representations (atom:entry) describe the state of a web resource at a time (the link alternate) Any thoughts? Henry From owner-atom-syntax@mail.imc.org Fri May 6 13:56:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14821 for ; Fri, 6 May 2005 13:56: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 j46HnZCo021777; Fri, 6 May 2005 10:49: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 j46HnZvQ021776; Fri, 6 May 2005 10:49:35 -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 j46HnXkC021759 for ; Fri, 6 May 2005 10:49:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1029838wra for ; Fri, 06 May 2005 10:49: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=CqkDb5OyCduRjSRxXVqKPHU9lWvSPEVH2PlzVGJz3lFNBqu6n/CSWTXu88Ld2c9e99GVyItg/8G+j+ym+AjQcBuZxJdd7dl9wC1mf/YU/rdraLFVusoNRJ56PJE2t3+jcGiJNNsXaRNF2wql2Cxx7plwYFhbV7XE7SL/fQ4rWSE= Received: by 10.54.41.20 with SMTP id o20mr871761wro; Fri, 06 May 2005 10:49:28 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Fri, 6 May 2005 10:49:28 -0700 (PDT) Message-ID: <68fba5c5050506104973c6a9ba@mail.gmail.com> Date: Fri, 6 May 2005 13:49:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: PaceAllowDuplicateIDs alteration Cc: Graham , atom-syntax In-Reply-To: <200505061516.DCK11864@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.com> <200505061516.DCK11864@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46HnYkC021763 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, Bob Wyman wrote: > > Graham wrote: > > "If an Atom Feed Document contains multiple entries with the > > same atom:id, software MUST treat them as multiple versions of > > the same entry" > Are they still the same entry if they have different source elements > that identify their source as being different feeds? I would say yes. Entries IDs are globally unique. If they aren't the same entry, it's a collision, right? Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 6 13:57:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14968 for ; Fri, 6 May 2005 13:57: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 j46HZ3Gw019305; Fri, 6 May 2005 10:35: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 j46HZ3dU019304; Fri, 6 May 2005 10:35: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 j46HZ3n3019298 for ; Fri, 6 May 2005 10:35:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46HZKar015268; Fri, 6 May 2005 13:35:23 -0400 Message-ID: <427BAABC.9000500@intertwingly.net> Date: Fri, 06 May 2005 13:34:52 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: FeedId References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> <427B8D2D.3030807@dehora.net> In-Reply-To: <427B8D2D.3030807@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > > Sam Ruby wrote: > >> Bill de hra wrote: >> >>> PaceFeedIdOrAlternate, withdrawn, no comment >>> PaceFeedIdOrSelf 0 >>> PaceOptionalFeedLink +1 >>> >>> I agree with the rationale; no point making people things they can't >>> do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is >>> a MUST. >> >> On what do you base that assumption? > > That there is consensus we'll want to identify a feed, even if we can't > provide a link. At the moment, there is not such a proposal on the table for the chairs to even determine if there is consensus around it. My take (as a non-chair) is that after a lengthy discussion about this, people did want *something* that they could use to identify the feed. Some initially rallied around feed link, some around id, some around feed rel=self. A number of proposals surfaced. The one proposal on the table that has a chance is PaceFeedIdOrSelf, but it is in trouble. So, at current course and speed, I see us coming to a conclusion that feed link be made optional with nothing to replace it. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 14:05:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15816 for ; Fri, 6 May 2005 14:05: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 j46HrgF7022499; Fri, 6 May 2005 10: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 j46Hrgc1022498; Fri, 6 May 2005 10:53: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 j46HqBNQ022228 for ; Fri, 6 May 2005 10:52:11 -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 j46HqBi7026853 for ; Fri, 6 May 2005 11:52:11 -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 <0IG2009U7XMY64@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 06 May 2005 11:52:11 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG200918XMX8J@mail.sun.net> for atom-syntax@imc.org; Fri, 06 May 2005 11:52:10 -0600 (MDT) Date: Fri, 06 May 2005 10:53:14 -0700 From: Tim Bray Subject: Re: PaceAllowDuplicateIDs alteration In-reply-to: To: Eric Scheid Cc: Atom Syntax Message-id: <9d27817395c2bf3e140d33f01c9d269c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; 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 May 6, 2005, at 8:49 AM, Eric Scheid wrote: >> Are they still the same entry if they have different source elements >> that identify their source as being different feeds? > > I don't see why. I subscribe to a Local News feed, a National News > feed, and > a Science News feed. All from the same publisher. The same story may > appear > in one, two, or three of those feeds. I don't believe each of those > feeds > would have the same feed/source values. Right.... but the story's would have the same atom:id in each of those feeds, right? So they are the same entry, right? -Tim From owner-atom-syntax@mail.imc.org Fri May 6 14:06:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15845 for ; Fri, 6 May 2005 14:06: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 j46HZ0IA019284; Fri, 6 May 2005 10:35: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 j46HZ0eA019283; Fri, 6 May 2005 10:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46HYxmD019260 for ; Fri, 6 May 2005 10:34:59 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46HYCVh013401; Fri, 6 May 2005 18:34:18 +0100 (BST) In-Reply-To: <200505061516.DCK11864@ms8.netsolmail.com> References: <200505061516.DCK11864@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs alteration Date: Fri, 6 May 2005 18:34:10 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 4:16 pm, Bob Wyman wrote: > Graham wrote: > >> "If an Atom Feed Document contains multiple entries with the >> same atom:id, software MUST treat them as multiple versions of >> the same entry" >> > Are they still the same entry if they have different source > elements > that identify their source as being different feeds? Why wouldn't they be? It would mean "Here's how the entry looked when it was published in feed A" and "Here's how the entry looked when it was in feed B". But if the publisher has assigned them the same ID, that's a fairly clear expression that they're versions of the same thing. (obviously there's the danger of spoofing, but that's a general problem with IDs and not something that needs to be noted in every sentence) Graham From owner-atom-syntax@mail.imc.org Fri May 6 14:15:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16533 for ; Fri, 6 May 2005 14:15: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 j46I95sX028112; Fri, 6 May 2005 11:09: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 j46I95LY028111; Fri, 6 May 2005 11:09:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46I93Jb028087 for ; Fri, 6 May 2005 11:09:04 -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-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id j46I92V8004241 for ; Fri, 6 May 2005 20:09:02 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <427BB2B8.2050102@w3future.com> Date: Fri, 06 May 2005 20:08:56 +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 Subject: Re: Autodiscovery References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> <427B2B71.6030300@atrus.org> In-Reply-To: <427B2B71.6030300@atrus.org> 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 Nikolas 'Atrus' Coukouma wrote: > Using @rel with any linking element is perfectly valid and has been for > years. > @rel not being supported for anything other than the link element itself > has also been an outstanding bug for just as long. There's lot of debate > attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). > > Can we agree that this should be supported, but currently isn't? Unless > there's a compelling reason not to, I think we might as well allow > autodiscovery via either element. Any implementation guide should > recommend duplicating the information in the interest of autodiscovery > actually working. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 Yes, absolutely, that was my point. As David Baron says in Bugzilla: "The spec was designed with the idea that any application that looked at rel/rev on LINK elements should do the same for A elements." -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Fri May 6 14:17:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16631 for ; Fri, 6 May 2005 14:17: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 j46IADNO028921; Fri, 6 May 2005 11: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 j46IADOj028920; Fri, 6 May 2005 11:10:13 -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 j46IADmU028852 for ; Fri, 6 May 2005 11:10:13 -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 01C6BD3 for ; Fri, 6 May 2005 11:10:08 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j46I9xnk011169 for ; Fri, 6 May 2005 11:10:07 -0700 (PDT) Date: Fri, 06 May 2005 10:55:31 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: Atom feed refresh rates Message-ID: In-Reply-To: <427A5DAC.4020203@aol.net> References: <4279EC3B.1080007@gmx.de> <20050505125414.MMEH5678.aamta06-winn.mailhost.ntl.com@AndyHenderson3> <14be96d30505050607180058e4@mail.gmail.com> <20050505143035.GE23305@tartarus.org> <427A5DAC.4020203@aol.net> X-Mailer: Mulberry/4.0.0b1 (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 May 5, 2005 10:53:48 AM -0700 John Panzer wrote: > > I assume an HTTP Expires header for Atom content will work and play well with > caches such as the Google Accelerator (http://webaccelerator.google.com/). > I'd also guess that a syntax-level tag won't. Is this important? The syntax-level tag is useful inside a client program with a cache. It can reduce the number of requests at the source, rather than reducing them in the middle of the network at an HTTP cache. There is extra benefit from putting that info into the HTTP headers, because the HTTP cache is shared between multiple clients. The source webserver sees one GET per HTTP cache instead of one GET per Atom client. The syntax-level tag also provides a way for the feed author to specify the info without depending on webserver-specific controls. It does depend on some extra bit of software to take that info and put it in the HTTP Expires or Cache-control headers. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri May 6 14:51:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22632 for ; Fri, 6 May 2005 14:51: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 j46IeqFO038134; Fri, 6 May 2005 11:40: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 j46IeqrC038133; Fri, 6 May 2005 11:40:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46IeppY038121 for ; Fri, 6 May 2005 11:40:51 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46Iebqv009825; Fri, 6 May 2005 14:40:48 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCK88530 (AUTH bob@wyman.us); Fri, 6 May 2005 14:40:37 -0400 (EDT) Message-Id: <200505061840.DCK88530@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Henry Story'" , "'atom-syntax Syntax'" Subject: RE: entry definition Date: Fri, 6 May 2005 14:40:34 -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.1441 In-Reply-To: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> Thread-Index: AcVSXyjPkupUC7wSRoiGVfMq1NKReQAC6RCQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > An Atom Entry is a resource (identified by atom:id) whose > representations (atom:entry) describe the state of a web resource > at a time (the link alternate). I think that if this is not 100% "correct" then it is at least very close to whatever correct actually is. bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 14:53:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22826 for ; Fri, 6 May 2005 14:53: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 j46Ij063038809; Fri, 6 May 2005 11:45: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 j46Ij0Zw038808; Fri, 6 May 2005 11:45:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46IixSp038764 for ; Fri, 6 May 2005 11:45:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46Ii8L8001412; Fri, 6 May 2005 19:44:13 +0100 (BST) In-Reply-To: <427B8D2D.3030807@dehora.net> References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> <427B8D2D.3030807@dehora.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: atom-syntax From: Graham Subject: Re: FeedId Date: Fri, 6 May 2005 19:44:06 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46Ij0Sp038803 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 6 May 2005, at 4:28 pm, Bill de hra wrote: > That there is consensus we'll want to identify a feed, even if we > can't provide a link. I'd +1 an ordinary "make feed:id required" Pace. PaceFeedIdOrSelf is too awful an idea for words. Graham From owner-atom-syntax@mail.imc.org Fri May 6 15:28:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27365 for ; Fri, 6 May 2005 15:28: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 j46JLO57045612; Fri, 6 May 2005 12:21: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 j46JLOFo045611; Fri, 6 May 2005 12:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46JLNhh045605 for ; Fri, 6 May 2005 12:21:24 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46JLNWj013099; Fri, 6 May 2005 15:21:23 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCL02846 (AUTH bob@wyman.us); Fri, 6 May 2005 15:21:21 -0400 (EDT) Message-Id: <200505061921.DCL02846@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sjoerd Visscher'" , "'Atom Syntax'" Subject: RE: Autodiscovery Date: Fri, 6 May 2005 15:21:19 -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.1441 In-Reply-To: <427B212F.70905@w3future.com> Thread-Index: AcVSEdwRyz/e7BxYRRWg8vTZaDgUrgAXm5Uw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > [HTML 4.01 says:] This attribute describes the relationship from > the current document to the anchor specified by the href attribute. > The value of this attribute is a space-separated list of link types. But, if you copy HTML from one document to another, or you construct an HTML document from parts, you risk carrying tags with rel attributes from one document to another. If I quote some HTML in a new HTML document and the quoted HTML includes rel="alternate" in an tag, are we really saying that the presence of rel="alternate" in the quoted text establishes a relation of the new HTML document as a whole? Personally, I think there is a serious scoping problem here. We've got attributes of separable components of a page establishing metadata for the page as a whole. Not good. bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 15:50:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29590 for ; Fri, 6 May 2005 15:50: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 j46Jf5lN048939; Fri, 6 May 2005 12: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 j46Jf5hb048938; Fri, 6 May 2005 12:41:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Jf4mq048932 for ; Fri, 6 May 2005 12:41:04 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46Jf3gt013806 for ; Fri, 6 May 2005 15:41:03 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCL09322 (AUTH bob@wyman.us); Fri, 6 May 2005 15:41:02 -0400 (EDT) Message-Id: <200505061941.DCL09322@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: Selfish Feeds... Date: Fri, 6 May 2005 15:41:00 -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.1441 Thread-Index: AcVSc4ftN4SzWYLCQGOtY9e9inMaXA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've got another example of a selfish feed which is producing dynamic content which will cause many duplicate entries to float around the blogosphere. The feed in question here is an RSS feed. Nonetheless, I think we must expect people will do the same stupid tricks with Atom feeds. Check out: http://www.b-eye-network.com/xml/articles.php What you'll get is a feed with entries that look something like the one at the bottom of this page. The interesting thing to note is that the item has a element with the url: http://www.b-eye-network.com/view/index.php? cid=836&fc=0&frss=1&ua=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar) What's happened here is that the site has appended my User Agent to the URL in the link. I assume that this is to allow some kind of tracking. However, the impact is that the contents of the feed depend on what tool you use to read the feed. If you access the feed, you will undoubtedly get different content then I did... For instance, if PubSub's crawler had read the feed, the value of the "ua" attribute in the URL would have been different and the URL would have read: http://www.b-eye-network.com/view/index.php? cid=836&fc=0&frss=1&ua=PubSub.com RSS reader - http://www.pubsub.com/ If this feed is read by more than one synthetic feed generator or if items from the feed are copied from this feed to another, it is inevitable that we'll have multiple copies of the item floating around and we'll have very little means for determining which one is authoritative -- essentially they all are. It would be handy to have a "dynamic content flag" that allows us to ignore this stuff... This business of people including dynamic content in their feeds for selfish purposes is making it very difficult to build a decent infrastructure for distributing and caching RSS/Atom entries... We've got a "tragedy of the commons" situation going on here. The much-too-respectable SEO crowd is trying to seek profit at the expense of the network at large... Because they can. bob wyman ====== Full example entry from the feed ============= Nanotechnology Basics Defined Find out how Hyperion can help: An Intelligent Approach to Business Intelligence

Nanotechnology is the Next Big Thing. ]]> http://www.b-eye-network.com/view/index.php?cid=836&fc=0&frss=1&ua=Moz illa/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar) Thu, 5 May 2005 00:00:00 MST From owner-atom-syntax@mail.imc.org Fri May 6 15:56:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01097 for ; Fri, 6 May 2005 15:56: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 j46Jm3G2049952; Fri, 6 May 2005 12:48: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 j46Jm3ld049950; Fri, 6 May 2005 12:48: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 j46Jm1p0049944 for ; Fri, 6 May 2005 12:48:03 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46JmKFL030448; Fri, 6 May 2005 15:48:21 -0400 Message-ID: <427BC9E7.2090400@intertwingly.net> Date: Fri, 06 May 2005 15:47:51 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) 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: FeedId References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> <427B8D2D.3030807@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham wrote: > > On 6 May 2005, at 4:28 pm, Bill de hra wrote: > >> That there is consensus we'll want to identify a feed, even if we >> can't provide a link. > > I'd +1 an ordinary "make feed:id required" Pace. I'd +1 any Pace that has a chance of achieving consensus that makes at least one element that can be used as a feed identifier mandatory. At the moment, alternate link is the element of record. -1 to PaceOptionalFeedLink if it to be accepted in isolation or to be portrayed as "inconsistent" with any other feed id related paces (hey, I might be dumb, but I learn quick) +1 to any Pace that moves this to responsibility to a more appropriate home. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 16:00:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02864 for ; Fri, 6 May 2005 16:00: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 j46JsPiW050934; Fri, 6 May 2005 12:54: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 j46JsPKI050933; Fri, 6 May 2005 12:54:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46JsOCr050905 for ; Fri, 6 May 2005 12:54:24 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050506195417.MEST2412.mta09-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Fri, 6 May 2005 20:54:17 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050506195417.KDJQ24880.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Fri, 6 May 2005 20:54:17 +0100 Date: Fri, 6 May 2005 20:54:15 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC2) Professional X-Priority: 3 (Normal) Message-ID: <1904061208.20050506205415@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: PaceSourceRecs In-Reply-To: References: 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 Thursday, May 5, 2005, 11:42:22 PM, Tim Bray wrote: > -1 > Irrespective of whether I agree with this or not, I think the material > belongs in an implementor's guide, not the specification. -Tim I'm a bit uncomfortable with punting yet another issue into the Implementor's Guide when the WG has made no commitment to produce an Implementor's Guide. I'd be less suspicious of being fobbed off, if our charter was updated to include the Implementor's Guide as a deliverable. -- Dave From owner-atom-syntax@mail.imc.org Fri May 6 16:07:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05699 for ; Fri, 6 May 2005 16:07: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 j46K1WfA051983; Fri, 6 May 2005 13:01: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 j46K1WPF051982; Fri, 6 May 2005 13:01: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46K1TAi051973 for ; Fri, 6 May 2005 13:01:30 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1099765wra for ; Fri, 06 May 2005 13:01: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=qd/d/HBKH6vf/4n6YvHgUsPSHZe4fTQRO9ljdpFTxwWrzlYzy/Dat79mML612Wgtyse6Fizdg2ftQYl54Dpq7ZU4xWlSQznVVmYMdk/Qq7X+Vpu0ODxWOAtmWQeyuQUhn8zzKJyrK/SPR2zhZIYBaX8brVyCi3ayuyIIUGOnSLo= Received: by 10.54.35.43 with SMTP id i43mr1041882wri; Fri, 06 May 2005 13:01:23 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Fri, 6 May 2005 13:01:23 -0700 (PDT) Message-ID: <68fba5c5050506130147f2903e@mail.gmail.com> Date: Fri, 6 May 2005 16:01:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: FeedId Cc: Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax In-Reply-To: <427BC9E7.2090400@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> <427B8D2D.3030807@dehora.net> <427BC9E7.2090400@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46K1UAi051976 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, Sam Ruby wrote: > > At the moment, alternate link is the element of record. Do any applications use it as such? In my experience, applications use the URI they retrieved the feed from as the feed identifier. For example, I believe every single pubsub.com match feed uses the same alternate link. > -1 to PaceOptionalFeedLink if it to be accepted in isolation or to be > portrayed as "inconsistent" with any other feed id related paces (hey, I > might be dumb, but I learn quick) > > +1 to any Pace that moves this to responsibility to a more appropriate home. I'd like to point out that writing a proposal doesn't necessarily imply support on the part of the author. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 6 16:09:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06241 for ; Fri, 6 May 2005 16:09: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 j46K3KwM052076; Fri, 6 May 2005 13:03: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 j46K3K3Q052075; Fri, 6 May 2005 13:03:20 -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 j46K3JB2052065 for ; Fri, 6 May 2005 13:03:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1100719wra for ; Fri, 06 May 2005 13:03: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=JD0NG4Kn7QLcTJeR6y51ElBUepJ4uLCewJi9g4rqee74F6ZWQe7uF+d167TgPcerqv02//Za6lyBNVAug7Nvy9zthayxjEVr4tLY3L7u4RNsg58BnZcyxsvg0J8eb0Xe//2j7DKQfi0x3pcofDk+e4OGKg59TFEr6Fc/EigCJyQ= Received: by 10.54.13.50 with SMTP id 50mr656964wrm; Fri, 06 May 2005 13:03:13 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Fri, 6 May 2005 13:03:13 -0700 (PDT) Message-ID: <68fba5c5050506130314bc6d32@mail.gmail.com> Date: Fri, 6 May 2005 16:03:13 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: PaceSourceRecs Cc: Tim Bray , Atom Syntax In-Reply-To: <1904061208.20050506205415@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1904061208.20050506205415@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46K3JB2052070 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, David Powell wrote: > I'd be less suspicious of being fobbed off, if our charter was updated > to include the Implementor's Guide as a deliverable. Indeed. This sounds like BCP material. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 6 16:21:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07475 for ; Fri, 6 May 2005 16:21: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 j46KDVn6052835; Fri, 6 May 2005 13:13: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 j46KDVZD052834; Fri, 6 May 2005 13:13:31 -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 j46KDU3T052827 for ; Fri, 6 May 2005 13:13:30 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46KDqd8000712; Fri, 6 May 2005 16:13:53 -0400 Message-ID: <427BCFE3.9040805@intertwingly.net> Date: Fri, 06 May 2005 16:13:23 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom Syntax'" Subject: Re: Selfish Feeds... References: <200505061941.DCL09322@ms8.netsolmail.com> In-Reply-To: <200505061941.DCL09322@ms8.netsolmail.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: > I've got another example of a selfish feed which is producing dynamic > content which will cause many duplicate entries to float around the > blogosphere. The feed in question here is an RSS feed. Nonetheless, I think > we must expect people will do the same stupid tricks with Atom feeds. Check > out: > > http://www.b-eye-network.com/xml/articles.php > > What you'll get is a feed with entries that look something like the one at > the bottom of this page. The interesting thing to note is that the item has > a element with the url: > > http://www.b-eye-network.com/view/index.php? > cid=836&fc=0&frss=1&ua=Mozilla/4.0 (compatible; > MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar) > > What's happened here is that the site has appended my User Agent to the URL > in the link. I assume that this is to allow some kind of tracking. However, > the impact is that the contents of the feed depend on what tool you use to > read the feed. If you access the feed, you will undoubtedly get different > content then I did... For instance, if PubSub's crawler had read the feed, > the value of the "ua" attribute in the URL would have been different and the > URL would have read: > http://www.b-eye-network.com/view/index.php? > cid=836&fc=0&frss=1&ua=PubSub.com RSS reader - > http://www.pubsub.com/ > > If this feed is read by more than one synthetic feed generator or if items > from the feed are copied from this feed to another, it is inevitable that > we'll have multiple copies of the item floating around and we'll have very > little means for determining which one is authoritative -- essentially they > all are. It would be handy to have a "dynamic content flag" that allows us > to ignore this stuff... It seems to me that instead of adding a dynamic content flag, having a separate id element (or in RSS 2.0's case, utilizing the guid element) would be more to the point. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 16:27:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07937 for ; Fri, 6 May 2005 16:27: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 j46KMA8v053518; Fri, 6 May 2005 13:22: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 j46KMADT053517; Fri, 6 May 2005 13:22:10 -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 j46KM9df053509 for ; Fri, 6 May 2005 13:22:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46KMQD7001760; Fri, 6 May 2005 16:22:26 -0400 Message-ID: <427BD1E5.7090007@intertwingly.net> Date: Fri, 06 May 2005 16:21:57 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Graham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Subject: Re: FeedId References: <427B86A9.5010102@dehora.net> <427B8AF6.90907@intertwingly.net> <427B8D2D.3030807@dehora.net> <427BC9E7.2090400@intertwingly.net> <68fba5c5050506130147f2903e@mail.gmail.com> In-Reply-To: <68fba5c5050506130147f2903e@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: > On 5/6/05, Sam Ruby wrote: > >>At the moment, alternate link is the element of record. > > Do any applications use it as such? In my experience, applications use > the URI they retrieved the feed from as the feed identifier. For > example, I believe every single pubsub.com match feed uses the same > alternate link. My thoughts mirror this discussion from just barely over a month ago: http://www.imc.org/atom-syntax/mail-archive/msg14008.html Would people be happy with the following? If so, I would gladly write up a Pace: Alternate Link: OPTIONAL Self Link: SHOULD (rationale: existing pain point) ID: MUST - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 16:43:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08991 for ; Fri, 6 May 2005 16:43: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 j46KbR3u054684; Fri, 6 May 2005 13:37: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 j46KbRhI054683; Fri, 6 May 2005 13:37:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46KbQ8r054676 for ; Fri, 6 May 2005 13:37:26 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46KbPTh021790; Fri, 6 May 2005 16:37:25 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCL26109 (AUTH bob@wyman.us); Fri, 6 May 2005 16:37:24 -0400 (EDT) Message-Id: <200505062037.DCL26109@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" Cc: "'Atom Syntax'" Subject: RE: Selfish Feeds... Date: Fri, 6 May 2005 16:37:23 -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.1441 In-Reply-To: <427BCFE3.9040805@intertwingly.net> Thread-Index: AcVSeBwLcOkaF9A3TAuJpedSHCPeigAATEdw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > It seems to me that instead of adding a dynamic content flag, having > a separate id element (or in RSS 2.0's case, utilizing the guid > element) would be more to the point. Relying on a GUID alone only works if you implement a policy that says that you are only interested in seeing content with "new" GUIDs and you are willing to ignore any "updates" to previously seen entries/items. Similarly, relying on atom:id + atom:updated implies a policy of only being interested in content changes which are explicitly flagged by the publisher as being "worthy of notice." These are certainly appropriate policies for *some* aggregators addressing *some* user needs. However, other aggregators implement different policies which address other user needs. For instance, many aggregators will update their content stores whenever *any* change occurs in an item whether or not the GUID or Atom:id has changed. Some of these aggregators will flag any change as a "new or unread" entry. (which I think is a really stupid policy...) Others will, like Gush, distinguish between "new" items and "updated" items. (I think this is much more sensible, others will say it is overly complex and unnecessary.) Conceivably, once Atom is released, some aggregators will wish to record three states for an entry: "new", "major update" and "minor update." (I would support anyone doing this, others would not.) To understand this issue and many other syndication issues, it is vital that you try to consider the full range of policies that are implemented by aggregators and that you try to look beyond your personal preferences. Please try to understand that this isn't a simple issue -- at least not from the point of view of a channel intermediary like PubSub. As was recently pointed out, a very large percentage of the HTTP specification covers issues related to proxies (which is very much the role that PubSub plays.) The same is true of the State Management (Cookie) RFC. I remember that when we were working on that RFC, proxy issues were just about the *only* thing we discussed... Problems which are "simple" in point to point networks become much more complex when you introduce intermediaries. Frankly, I really wish that we had done the "blog architecture" work many months ago so that we would all have a shared understanding of the system-wide issues and components rather than the widely divergent personal and partial views that are obvious in many our conversations today... bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 17:03:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10373 for ; Fri, 6 May 2005 17:03: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 j46Koaks056089; Fri, 6 May 2005 13: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 j46Koa4l056084; Fri, 6 May 2005 13:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46KoaOP056077 for ; Fri, 6 May 2005 13:50:36 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j46KoYgv018505; Fri, 6 May 2005 16:50:34 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCL29784 (AUTH bob@wyman.us); Fri, 6 May 2005 16:50:33 -0400 (EDT) Message-Id: <200505062050.DCL29784@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceSourceRecs Date: Fri, 6 May 2005 16:50:31 -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.1441 In-Reply-To: <153AFB3A-BD7A-11D9-AC04-003065EA6144@geckotribe.com> Thread-Index: AcVRiVSA+ElNdBplQNyzg80UrTy3+AA8lPLQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Start by calculating the the language of the atom:feed and > the atom:entry. Second, if the language of atom:entry isn't > the same as the aggregate feed, set it. Third, if the > language of atom:feed isn't the same as the atom:entry, > set it. I'm curious about this "calculation" word... The Pace says that "Language values should be calculated, according to the rules of [W3C.REC-xml-20040204], by processing the xml:lang values of the element in question and its ancestors." This raises an interesting point... What should we do if we know that the language that results from the calculation is not the actual language of the entry? For instance, language recognition technology is relatively well known and works with reasonable accuracy these days. The fact is that the language fields in both RSS and existing Atom files are wrong in a very large percentage of cases. (i.e. folk writing Chinese blogs on US-based systems are getting feeds that claim "en-us" as the language and often have no way to correct the language tag since US developers hardly ever think about I18N issues...) We've had folk suggest to us that we should run Language Recognition algorithms to calculate the actual language of entries and then "fix" their tags in cases where the tags are missing or clearly wrong. I've resisted such suggestions if only because I can't figure out where to write the "correct" language tags. What would you suggest we do? Or, should we do nothing? What would you suggest we do when trying to insert an entry into an aggregate feed if the original entry had no language tag yet we are very confident that our Language Recognition code has determined the actual language of the entry and it is not the same as the language of the enclosing feed? bob wyman From owner-atom-syntax@mail.imc.org Fri May 6 17:03:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10396 for ; Fri, 6 May 2005 17:03: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 j46KrLDK056277; Fri, 6 May 2005 13:53: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 j46KrLo6056276; Fri, 6 May 2005 13:53:21 -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 j46KrKQ7056268 for ; Fri, 6 May 2005 13:53:20 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j46KrfCI005016; Fri, 6 May 2005 16:53:42 -0400 Message-ID: <427BD938.4080903@intertwingly.net> Date: Fri, 06 May 2005 16:53:12 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceOriginalAttribute References: <64a444657a0030e17dae00b60a2de80b@sun.com> In-Reply-To: <64a444657a0030e17dae00b60a2de80b@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: > > +1 > > I'm not 100% convinced it solves the problems Rob says it does, but it > seems cheap, lightweight, and unlikely to cause any harm. -Tim I'm growing increasingly comfortable with the concept of allowing redistributors to assign new ids as long as they track the original (i.e.: not immediate predecessor!) entry. That being said, I have two things I want to think more about w.r.t. how this Pace is currently worded. (Note: the first is actually only a nit concerning the current draft, not the Pace itself): 1) "MAY be preserved" I would prefer if this were recast not so much as an RFC 2119 interoperability statement, but rather as a definitional one. "original attributes in atom:source elements are used to indicate..." Something along those lines. 2) "Atom feeds MUST NOT contain duplicate atom:id values" How did that get in there? Depending on how you read it, this Pace is incompatible with PaceAllowDuplicateIDs, implying that Tim's +1 above can be construed as voting against a Pace he authored! Whether or not the work group comes to consensus about allowing multiple entries to share the same ID in a feed, it still is true that entries may change over time. Perhaps atom:source elements could also define an @updated attribute. As atom:updated is a required element for atom:entry, it would not be an unreasonable burden to require @updated attributes on atom:source elements. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 6 17:03:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10416 for ; Fri, 6 May 2005 17:03: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 j46KlHXv055739; Fri, 6 May 2005 13:47: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 j46KlHPk055738; Fri, 6 May 2005 13:47:17 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46KlEmS055730; Fri, 6 May 2005 13:47:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 6 May 2005 13:47:12 -0700 To: Tim Bray , atom-syntax Syntax From: Paul Hoffman Subject: Re: Autodiscovery discussion & editorship 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 8:29 PM -0700 5/5/05, Tim Bray wrote: >Paul, is there any reason Mark or Phil shouldn't submit the most >recent autodiscovery-01 as a committee draft? No reason at all. We can poke at it, regardless of the -nn.txt numbering. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri May 6 17:33:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12939 for ; Fri, 6 May 2005 17:33: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 j46LRev7062273; Fri, 6 May 2005 14:27: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 j46LRepG062272; Fri, 6 May 2005 14:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46LRdN4062260 for ; Fri, 6 May 2005 14:27:39 -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 (rwcrmhc13) with SMTP id <20050506212733015006usk5e>; Fri, 6 May 2005 21:27:33 +0000 Date: Fri, 6 May 2005 15:27:32 -0600 Subject: Re: PaceAllowDuplicateIDs alteration 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: <200505061516.DCK11864@ms8.netsolmail.com> 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, May 6, 2005, at 09:16 AM, Bob Wyman wrote: > Graham wrote: >> "If an Atom Feed Document contains multiple entries with the >> same atom:id, software MUST treat them as multiple versions of >> the same entry" > Are they still the same entry if they have different source elements > that identify their source as being different feeds? > In a perfect world with no malicious, undereducated, misinformed, intellectually challenged or other people people who don't mint ids appropriately, yes, they're the same entry. In the real world, I have no idea. A human looking at them could probably determine whether they're the same if they're different enough, but if they're substantially similar, then even a human wouldn't necessarily be able to determine whether they're the same or whether one is a malicious alteration. There's no automated way to decide (unless their contents are identical). Authors of consuming applications will have to decide whether or not to obey the commandment from the spec (if adopted) to treat them as being the same, or whether to give their users the option of making that decision. Specifying that publishers who publish the same entry in multiple feeds MUST choose one to be the "original" source and express the rest as aggregated entries from that feed would make it much easier to justify treating them as different entries if they claimed to originate in different feeds. From owner-atom-syntax@mail.imc.org Fri May 6 17:41:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13496 for ; Fri, 6 May 2005 17:41: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 j46LYBqc063299; Fri, 6 May 2005 14: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 j46LYBwT063298; Fri, 6 May 2005 14:34: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 j46LYA0M063280 for ; Fri, 6 May 2005 14:34: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 BDC5CBE for ; Fri, 6 May 2005 14:34:05 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j46LY4ng013701 for ; Fri, 6 May 2005 14:34:05 -0700 (PDT) Date: Fri, 06 May 2005 14:34:30 -0700 From: Walter Underwood To: "'Atom Syntax'" Subject: RE: Selfish Feeds... Message-ID: <44438144C160F8676D7EAF0B@Wunders-Computer.local> In-Reply-To: <200505062037.DCL26109@ms8.netsolmail.com> References: <200505062037.DCL26109@ms8.netsolmail.com> X-Mailer: Mulberry/4.0.0b1 (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 May 6, 2005 4:37:23 PM -0400 Bob Wyman wrote: > Frankly, I really wish that we had done the "blog architecture" work > many months ago so that we would all have a shared understanding of the > system-wide issues and components rather than the widely divergent personal > and partial views that are obvious in many our conversations today... Agreed. "A conceptual model of a resource" is up there at the front of our charter, and if we don't have that, it doesn't seem like the WG is done. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri May 6 17:55:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14604 for ; Fri, 6 May 2005 17: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 j46LoDAX065605; Fri, 6 May 2005 14: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 j46LoDJk065604; Fri, 6 May 2005 14:50:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46LoCYt065585 for ; Fri, 6 May 2005 14:50:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46Ln5Dq013826; Fri, 6 May 2005 22:49:10 +0100 (BST) In-Reply-To: <200505062037.DCL26109@ms8.netsolmail.com> References: <200505062037.DCL26109@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Selfish Feeds... Date: Fri, 6 May 2005 22:49:06 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 9:37 pm, Bob Wyman wrote: > Relying on a GUID alone only works if you implement a policy that > says that you are only interested in seeing content with "new" > GUIDs and you > are willing to ignore any "updates" to previously seen entries/items. > Similarly, relying on atom:id + atom:updated implies a policy of > only being > interested in content changes which are explicitly flagged by the > publisher > as being "worthy of notice." Well if you won't trust info in the feed, there's nothing any format can do for you. Get thee some venture capital and hire a few linguistics/statistics undergrads to work out a real "significant update" algorithm for yourself. If you're complaining because people are putting tracking info in links, you're obviously not doing a very good job at this at the moment. Graham From owner-atom-syntax@mail.imc.org Fri May 6 17:56:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14693 for ; Fri, 6 May 2005 17:56: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 j46LngsF065540; Fri, 6 May 2005 14:49: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 j46LngrK065538; Fri, 6 May 2005 14:49: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 j46Lnfcw065524 for ; Fri, 6 May 2005 14:49: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 <2005050621493301100ilg1ne>; Fri, 6 May 2005 21:49:33 +0000 Date: Fri, 6 May 2005 15:49:32 -0600 Subject: Re: PaceOriginalAttribute 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: <68fba5c5050505162152be48bd@mail.gmail.com> 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 Thursday, May 5, 2005, at 05:21 PM, Robert Sayre wrote: > On 5/5/05, Antone Roundy wrote: >> Yeah, they think they are, or at least claim to think so. But isn't >> that the same thing that is stated if you see the following in two >> feeds? >> >> >> bar:bar >> >> foo:bar >> >> foo:foo >> >> I may be an imposter >> >> > >> This says that this feed is (or at least claims it is) forwarding the >> entry with the id "foo:bar" from the feed "foo:foo". > > OK, now let's say you're subscribed to "imposter" in PubSub. > > > bar:bar > > quux:quux1 > > foo:foo > > I may be an imposter > > > quux:quux2 > > baz:baz > > I may be an imposter > > Sorry, I don't understand the point of this example. I read it as saying that these two entries from different feeds claimed the same id. I don't know whether they really are the same entry, or whether one or both of their original ids were minted erroneously (accidentally duplicating another entry's id) or maliciously (attempting to DOS someone else's entry). I can't see any way of resolving that question that I wouldn't have if PubSub had given me this instead: bar:bar foo:bar foo:foo I may be an imposter foo:bar baz:baz I may be an imposter From owner-atom-syntax@mail.imc.org Fri May 6 18:58:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19911 for ; Fri, 6 May 2005 18:58: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 j46Mf42m071927; Fri, 6 May 2005 15:41: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 j46Mf4hV071926; Fri, 6 May 2005 15:41:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Mf3nj071904 for ; Fri, 6 May 2005 15:41:03 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.4.36] ([128.8.244.15]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j46Metpb016408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 May 2005 18:40:56 -0400 (EDT) Message-ID: <427BF553.8090402@atrus.org> Date: Fri, 06 May 2005 18:53:07 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050325) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Sjoerd Visscher'" , "'Atom Syntax'" Subject: Re: Autodiscovery References: <200505061921.DCL02846@ms8.netsolmail.com> In-Reply-To: <200505061921.DCL02846@ms8.netsolmail.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 Bob Wyman wrote: >Sjoerd Visscher wrote: > > >>[HTML 4.01 says:] This attribute describes the relationship from >>the current document to the anchor specified by the href attribute. >>The value of this attribute is a space-separated list of link types. >> >> > But, if you copy HTML from one document to another, or you construct >an HTML document from parts, you risk carrying tags with rel attributes >from one document to another. If I quote some HTML in a new HTML document >and the quoted HTML includes rel="alternate" in an tag, are we really >saying that the presence of rel="alternate" in the quoted text establishes a >relation of the new HTML document as a whole? > Personally, I think there is a serious scoping problem here. We've >got attributes of separable components of a page establishing metadata for >the page as a whole. Not good. > > bob wyman > > Since the HTML spec is where this originates, I'm inclined to say that this is something that should be handled by whatever is manging content (user or program) is copying the link. Clearly, @rel should be copied with caution or simply left behind entirely. I think calling this "components of a page establishing metadata for the page as a whole" is a bit misleading. The metadata (@rel) say nothing about the document it's in. It's metadata about the link between the two documents. This metadata is context-Dependant because it depends on an implicit @from counterpart to the explicit @href (@to, in XLink). and both suffer from this weakness. I can't pick up a link element from one element and move it to another. I can have a pile of them in the template I use to make my pages. It's considered a usability problem in the case of because appears in a place where it's a it more likely to be copied: the body. The problem is fortunately mitigated because user agents usually only offer copying @href ("copy link location"). I'm under the impression that they do something similar with rich-text copying. If someone's copying HTML "source" by hand, then they should know to be wary of @rel. The best we can do is add a note. It's also not likely to bother programs that put content into syndication feeds because links to feeds generally appear in the periphery of presentation and not the main content of a feed. If people do include @rel in content that's included in syndicated content, then it should be stripped. Again, no one uses @rel in because it's unsupported. Coincidentally, most programs do the right thing. If we push for @rel support in in the autodiscovery spec, then I think there may be an increase in usage, at which time users can authors can educate themselves and programs can make changes. They should have done this years ago. We're not creating @rel, just encouraging it's use. All of that said, it seems sensible to include a warning or a note or somesuch. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Fri May 6 20:16:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25303 for ; Fri, 6 May 2005 20:16: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 j470AIrt085252; Fri, 6 May 2005 17:10: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 j470AIH4085251; Fri, 6 May 2005 17:10:18 -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 j470AFXS085244; Fri, 6 May 2005 17:10:17 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> 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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> Date: Fri, 6 May 2005 16:28:44 -0700 To: Atom WG From: Paul Hoffman Subject: Re: PaceCaching Cc: atom-syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -1. Having two mechanisms in two different layers is a recipe for disaster. If HTTP headers are good enough for everything else on the web, they're good enough for Atom. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri May 6 20:29:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26755 for ; Fri, 6 May 2005 20:29: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 j46JsqxJ051013; Fri, 6 May 2005 12:54: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 j46Jsqul051012; Fri, 6 May 2005 12:54:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46JspCQ050996 for ; Fri, 6 May 2005 12:54:52 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j46Js5Uq018736; Fri, 6 May 2005 20:54:10 +0100 (BST) In-Reply-To: <200505061941.DCL09322@ms8.netsolmail.com> References: <200505061941.DCL09322@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <275E6A9C-FEC7-432D-B0B8-1933A591E8AF@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Selfish Feeds... Date: Fri, 6 May 2005 20:54:02 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 May 2005, at 8:41 pm, Bob Wyman wrote: > I've got another example of a selfish feed which is producing dynamic > content which will cause many duplicate entries to float around the > blogosphere. The feed in question here is an RSS feed. Nonetheless, > I think > we must expect people will do the same stupid tricks with Atom > feeds. Check > out: Bob, what the fuck do you think ids are for? Graham From owner-atom-syntax@mail.imc.org Fri May 6 20:37:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28005 for ; Fri, 6 May 2005 20:37: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 j46KOpG8053898; Fri, 6 May 2005 13: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 j46KOpxU053897; Fri, 6 May 2005 13:24:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46KOnF9053888 for ; Fri, 6 May 2005 13:24:50 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050506202443.RQSB2412.mta09-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Fri, 6 May 2005 21:24:43 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050506202443.ZWOX1844.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Fri, 6 May 2005 21:24:43 +0100 Date: Fri, 6 May 2005 21:24:41 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC2) Professional X-Priority: 3 (Normal) Message-ID: <6510673318.20050506212441@djpowell.net> To: Henry Story CC: atom-syntax Syntax Subject: Re: entry definition In-Reply-To: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> References: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.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 Friday, May 6, 2005, 5:46:59 PM, you wrote: > Some have been clamoring for a good definition of an entry. > Here is one I have thought of recently. > An Atom Entry is a resource (identified by atom:id) whose > representations > (atom:entry) describe the state of a web resource at a time > (the link alternate) > Any thoughts? The entry's alternate link is optional isn't it? -- Dave From owner-atom-syntax@mail.imc.org Fri May 6 22:58:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06402 for ; Fri, 6 May 2005 22:58: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 j472os3M013947; Fri, 6 May 2005 19:50: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 j472osE2013946; Fri, 6 May 2005 19:50: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j472orj9013913 for ; Fri, 6 May 2005 19:50:53 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1760564wri for ; Fri, 06 May 2005 19:50: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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pdMjn+c0kC1HChS3VRz+EtZqU60QZI8zgbGjEjL57UmFRurveQ3EVqhm1qdbBzMOyz3t59NFYn7xImjaTTfWQ+PCbvVKGCrV0v8qHKGRNy+es4NXDkotuWLRDQvEiFijcTKLAQu3gaBB357g+dBvTs8sptjfV4Qaf9+3ZLpDhQ8= Received: by 10.54.11.42 with SMTP id 42mr1170591wrk; Fri, 06 May 2005 19:50:47 -0700 (PDT) Received: from ?12.45.57.104? ([12.45.57.104]) by mx.gmail.com with ESMTP id d61sm553639wra.2005.05.06.19.50.45; Fri, 06 May 2005 19:50:47 -0700 (PDT) Message-ID: <427C2D00.3000508@gmail.com> Date: Fri, 06 May 2005 19:50:40 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nikolas 'Atrus' Coukouma" CC: Sjoerd Visscher , Atom Syntax Subject: Re: Autodiscovery in as well as References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> <427B2B71.6030300@atrus.org> In-Reply-To: <427B2B71.6030300@atrus.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 Nikolas 'Atrus' Coukouma wrote: > Using @rel with any linking element is perfectly valid and has been for > years. > @rel not being supported for anything other than the link element itself > has also been an outstanding bug for just as long. There's lot of debate > attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). > > Can we agree that this should be supported, but currently isn't? Unless > there's a compelling reason not to, I think we might as well allow > autodiscovery via either element. Any implementation guide should > recommend duplicating the information in the interest of autodiscovery > actually working. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 -1 to saying in the spec that you can use either element, and in the guide saying to use both if you want it to work, not just look pretty. As I remember it, when RSS autodiscovery started this cowpath, aggregator developers generally didn't have an SGML parser handy, and weren't especially happy about the idea of having to write their own HTML parser. Finding one (or a few) of relatively few s in the first bit of the document feels a lot easier than having to look at every in the whole document. Now? I'd say most don't have an SGML parser handy, and won't be especially happy about writing their own HTML parser. It's fairly rare for someone to comment out bits of their , and quite common for them to comment out huge swaths of their , including things a template came with, like Atom feed, with no thought that something will be seeing and using that invisible link with an incorrect path. I added Atom autodiscovery to my current aggregator, Feed on Feeds, with a ten second copy/paste/change mime-type of the results of it using a regular expression on the HTML. If instead I had to correctly parse the entire HTML document, I'd... switch to something in Python, I guess. Then, since I foolishly took the Firefox bug for better autodiscovery, I'll also need to do it where I do have an excellent HTML parser, but I have to do it on every single page that every single Firefox user loads, whether or not they have any interest in feeds, or subscribed to the feed ten thousand loads of that particular page ago. is easy, we've got a DOMLinkAdded event and most pages have very few of them. ? Well, the performance hit probably won't be noticeable on most pages. Phil Ringnalda From owner-atom-syntax@mail.imc.org Fri May 6 23:01:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06664 for ; Fri, 6 May 2005 23:01: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 j472ruHB014603; Fri, 6 May 2005 19: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 j472ruNx014602; Fri, 6 May 2005 19:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j472ruXS014594 for ; Fri, 6 May 2005 19:53:56 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 39F10C8B34E; Fri, 6 May 2005 22:53:54 -0400 (EDT) X-Sasl-enc: GhPqMlc5jRxbUt4kVgRUAK4nNFQVGNEunf7QXtb51pNiH60MWmzm 1115434434 Received: from [10.1.5.23] (pangeatech-162.pangeatech.primenet.com [207.218.87.162]) by frontend3.messagingengine.com (Postfix) with ESMTP id BD69988; Fri, 6 May 2005 22:53:53 -0400 (EDT) In-Reply-To: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> References: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73103F7C-8DA1-4E2F-B5F2-FAB037DFCCFD@jtauber.com> Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: James Tauber Subject: Re: entry definition Date: Fri, 6 May 2005 22:53:52 -0400 To: Henry Story X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In the case where there is an "alternate" I think this is correct, but it: 1. highlights the inaccuracy of the word "alternate" 2. doesn't address the case where there is no link alternate James On 06/05/2005, at 12:46 PM, Henry Story wrote: > > Some have been clamoring for a good definition of an entry. > Here is one I have thought of recently. > > An Atom Entry is a resource (identified by atom:id) whose > representations > (atom:entry) describe the state of a web resource at a time > (the link alternate) From owner-atom-syntax@mail.imc.org Sat May 7 00:41:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13555 for ; Sat, 7 May 2005 00:40: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 j474WjYD029679; Fri, 6 May 2005 21:32: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 j474Wjpc029678; Fri, 6 May 2005 21:32:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j474WiaY029654 for ; Fri, 6 May 2005 21:32:44 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j474RQpc019431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 7 May 2005 00:27:27 -0400 (EDT) Message-ID: <427C44BE.6060701@atrus.org> Date: Sat, 07 May 2005 00:31:58 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Ringnalda CC: Sjoerd Visscher , Atom Syntax Subject: Re: Autodiscovery in as well as References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> <427B2B71.6030300@atrus.org> <427C2D00.3000508@gmail.com> In-Reply-To: <427C2D00.3000508@gmail.com> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Phil Ringnalda wrote: > > Nikolas 'Atrus' Coukouma wrote: > >> Using @rel with any linking element is perfectly valid and has been for >> years. >> @rel not being supported for anything other than the link element itself >> has also been an outstanding bug for just as long. There's lot of debate >> attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20). >> >> Can we agree that this should be supported, but currently isn't? Unless >> there's a compelling reason not to, I think we might as well allow >> autodiscovery via either element. Any implementation guide should >> recommend duplicating the information in the interest of autodiscovery >> actually working. >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399 > > > -1 to saying in the spec that you can use either element, and in the > guide saying to use both if you want it to work, not just look pretty. You're absolutely right. I was thing in more immediate terms before, but if we're going to make this part of the Atom working group, land of well-defined and reasonable specs, everything should work. > > As I remember it, when RSS autodiscovery started this cowpath, > aggregator developers generally didn't have an SGML parser handy, and > weren't especially happy about the idea of having to write their own > HTML parser. Finding one (or a few) of relatively few s in the > first bit of the document feels a lot easier than having to look at > every in the whole document. > > Now? I'd say most don't have an SGML parser handy, and won't be > especially happy about writing their own HTML parser. It's fairly rare > for someone to comment out bits of their , and quite common for > them to comment out huge swaths of their , including things a > template came with, like Atom > feed, with no thought that something will be seeing and using that > invisible link with an incorrect path. I added Atom autodiscovery to > my current aggregator, Feed on Feeds, with a ten second > copy/paste/change mime-type of the results of it using a regular > expression on the HTML. If instead I had to correctly parse the entire > HTML document, I'd... switch to something in Python, I guess. Is there something wrong with the HTML parsers? Perl has HTML::Parser Python has htmllib.py Ruby has ymHTML and a port of of the Python library called html-parseer PHP has PHP-HTML Common Lisp has phtml The W3C provides a simple parser written in C I'm sure I can find more, but I think the above is a sufficiently long list to illustrate my point. > Then, since I foolishly took the Firefox bug for better autodiscovery, > I'll also need to do it where I do have an excellent HTML parser, but > I have to do it on every single page that every single Firefox user > loads, whether or not they have any interest in feeds, or subscribed > to the feed ten thousand loads of that particular page ago. is > easy, we've got a DOMLinkAdded event and most pages have very few of > them. ? Well, the performance hit probably won't be noticeable on > most pages. This is a single XPath query. Gecko has native support for it. I'm not sure about the others, but Sarissa is a fine library for DOM manipulation (including XSLT and XPath) from Javascript and it works with IE, KHTML, Opera ... > > Phil Ringnalda > Of course, if your XML library copes with all the errors present in normal HTML, it's probably nicer to use than any HTML parser. The point here is that most developers have access to an HTML parser. I admit that they might need patching, but at least 90% of the work is done. I'll try to find time to examine each of these libraries and make any changes needed. Hopefully they're already in good shape or the author is open to this sort thing. If all else fails, there's forking. If the problem is ignorance, I'll happily maintain a list. I'm also willing to write some sample implementations in all of the languages I listed before and more. I don't think this is terribly difficult. In fact, I just took a shot at altering Feeds on Feeds to support this and found it incredibly easy. patch: http://zaphod.student.umd.edu/~atrus/FoF_mod/a-support.patch There's other stuff in the same directory there if you want to poke at it. The changes just use PHP-HTML, which I mentioned earlier. Cheers, -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Sat May 7 01:21:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16811 for ; Sat, 7 May 2005 01:21: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 j475E0OL039328; Fri, 6 May 2005 22:14: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 j475E03k039327; Fri, 6 May 2005 22:14: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j475Dv2H039253 for ; Fri, 6 May 2005 22:13:59 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1794121wri for ; Fri, 06 May 2005 22:13:51 -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=WZXvgKXK/F/6BU3LUR4AOnopvrZOCLvLsgq6pHXu/IaMvW5i/uDVvNU2ZQxiY3s8dDoelVxwCBgWpfpxchrqhsOgYGyH3raXV+KSJY7lT4yrvEIwNGFfDUR0/Z3refG+GWl/MWq1+QTri6XD7jU0W30rCVCYr0NUqLdgCI5N/Ws= Received: by 10.54.29.33 with SMTP id c33mr1235464wrc; Fri, 06 May 2005 22:13:48 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Fri, 6 May 2005 22:13:47 -0700 (PDT) Message-ID: <540e373205050622135b419792@mail.gmail.com> Date: Sat, 7 May 2005 00:13:47 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Autodiscovery in as well as In-Reply-To: <427C44BE.6060701@atrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> <427B2B71.6030300@atrus.org> <427C2D00.3000508@gmail.com> <427C44BE.6060701@atrus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j475Dx2H039320 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Is there something wrong with the HTML parsers? Nikolas: Are they installed by default on most servers? If not, can those running in sandboxes install them? From the perspective of my niche, I can tell you that Coldfusion can use jTidy to make sense of random HTML, but it is (a) installed in virtually zero CF hosting environments, and (b) cannot normally be added by an individual developer working in a sandbox. (It's also riddled with bugs, but I'm just grateful to have it at all... I steer clear of gift horses' mouths whenever possible.) -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat May 7 01:50:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19065 for ; Sat, 7 May 2005 01:50: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 j475fE3o055224; Fri, 6 May 2005 22:41: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 j475fEZ1055222; Fri, 6 May 2005 22:41: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j475fD5F055142 for ; Fri, 6 May 2005 22:41:14 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1800482wri for ; Fri, 06 May 2005 22:41:08 -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=DWh4/X+5WogM+Xb2yNRt3CvDx386b3LR5Ej51uzi/ln69+UQls7iEfERqF5QZ+4cak2NTAZceiaonQHloPg5xPVwVw/YDfXPySummuvMSqTNRMFCdZ7y3U7VaV2YK7FM98dm7oleist/dhUxZvgbzOXqTbrLXz8KT83YUhE3xr4= Received: by 10.54.29.33 with SMTP id c33mr1249240wrc; Fri, 06 May 2005 22:41:08 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Fri, 6 May 2005 22:41:08 -0700 (PDT) Message-ID: <540e3732050506224160895477@mail.gmail.com> Date: Sat, 7 May 2005 00:41:08 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Autodiscovery In-Reply-To: <427BF553.8090402@atrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505061921.DCL02846@ms8.netsolmail.com> <427BF553.8090402@atrus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j475fE5F055210 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The problem is fortunately mitigated because user agents usually > only offer copying @href ("copy link location").> I'm under the > impression that they do something similar with rich-text copying. Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's XFN-friendly links page and paste it into my WYSIWYG editor, I get all of his @rel="whatevers" in my post. This is the same behavior I've noted in every IE- and Mozilla-based WYSIWYG editor I've tried. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat May 7 02:14:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04187 for ; Sat, 7 May 2005 02: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 j4767BUD068240; Fri, 6 May 2005 23:07: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 j4767Bjb068237; Fri, 6 May 2005 23:07:11 -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 j4767Aof068173 for ; Fri, 6 May 2005 23:07:10 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j47673m13116; Sat, 7 May 2005 15:07:03 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 83f421da_bebf_11d9_8c30_0030482532aa_10499; Sat, 07 May 2005 15:16:14 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005406; 7 May 05 15:09:25 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 7 May 05 15:09:06 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005402; 7 May 05 15:08:58 +0900 Message-Id: <6.0.0.20.2.20050506184319.067140f0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 06 May 2005 18:44:39 +0900 To: Sam Ruby , Tim Bray From: Martin Duerst Subject: Re: PaceOptionalFeedLink Cc: Atom Syntax In-Reply-To: <427ADB61.7010805@intertwingly.net> References: <427ADB61.7010805@intertwingly.net> 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 11:50 05/05/06, Sam Ruby wrote: > >Tim Bray wrote: >> +1 >> There are people who want to publish feeds without rel="alternate" links. I'm against telling people they can't do something they want to do without strong reasons, as in loss of interoperability. I don't see the reasons here as strong enough. -Tim +1 here, too, since long ago. >FYI: we have an instance proof of this requiring an existing tool to do additional work: > > http://www.imc.org/atom-syntax/mail-archive/msg13983.html Well, yes, but how much work can that possibly be? Regards, Martin. From owner-atom-syntax@mail.imc.org Sat May 7 02:14:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04686 for ; Sat, 7 May 2005 02:14: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 j4767Bww068245; Fri, 6 May 2005 23:07: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 j4767BW5068243; Fri, 6 May 2005 23:07:11 -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 j47678Y4068161 for ; Fri, 6 May 2005 23:07:09 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j47672m13112; Sat, 7 May 2005 15:07:02 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 8368adc6_bebf_11d9_8c30_0030482532aa_10499; Sat, 07 May 2005 15:16:13 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005401; 7 May 05 15:09:24 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 7 May 05 15:08:55 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0053FE; 7 May 05 15:08:53 +0900 Message-Id: <6.0.0.20.2.20050504103039.06ca8610@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 04 May 2005 10:31:10 +0900 To: Thomas Broyer , Anne van Kesteren From: Martin Duerst Subject: Re: hreflang attribute should be allowed to be empty as well Cc: Atom Syntax In-Reply-To: <4277AFC3.1030500@cegetel.net> References: <42775C77.8000009@annevankesteren.nl> <4277AFC3.1030500@cegetel.net> 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:07 05/05/04, Thomas Broyer wrote: > >Anne van Kesteren wrote: >> I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. -1. Thomas explains it all very well below. Regards, Martin. >xml:lang is allowed to be empty to override a previous, inherited, xml:lang declaration without specifying a new language. > >As xml:lang doesn't apply to the content of the linked resource, hreflang does not need to allow an empty value. If you don't want to or can't specify the language of the linked resource, just omit the hreflang attribute. >We might want to distinguish those two cases: not providing a language hint vs. explicitly telling the linked resource can't be "language qualified" but I'm not sure why this would be needed and what would be the difference (interop, accessibility, etc.) > >However, we may need to make clearer that an xml:lang doesn't apply to the linked resource. > >-- >Thomas Broyer > From owner-atom-syntax@mail.imc.org Sat May 7 02:15:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05119 for ; Sat, 7 May 2005 02:15: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 j4767B8u068244; Fri, 6 May 2005 23:07: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 j4767BRp068242; Fri, 6 May 2005 23:07:11 -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 j47678Xj068162 for ; Fri, 6 May 2005 23:07:09 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4766xm13108; Sat, 7 May 2005 15:06:59 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 813b880c_bebf_11d9_8c30_0030482532aa_10499; Sat, 07 May 2005 15:16:10 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005400; 7 May 05 15:09:21 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 7 May 05 15:08:55 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0053FC; 7 May 05 15:08:49 +0900 Message-Id: <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 04 May 2005 10:39:45 +0900 To: Thomas Broyer From: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: Alexey Melnikov , Mark Nottingham , Robert Sayre , iesg@ietf.org, atom-syntax@imc.org In-Reply-To: <4277B471.7030100@cegetel.net> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> 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:27 05/05/04, Thomas Broyer wrote: > >Martin Duerst wrote: >> At 03:33 05/04/29, Alexey Melnikov wrote: >> > > If the value is "text", the content of the Text construct MUST NOT >> > > contain child elements. Such text is intended to be presented to >> > > humans in a readable fashion. Thus, Atom Processors MAY collapse >> > > white-space (including line-breaks), >> > >> >Ok, maybe it is just me, but what does it mean to "collapse >white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a >single space? >> Making this more precise is definitely desirable. But there is also >> an i18n issue: This works fine for languages that use spaces between >> words. It doesn't work for languages that don't have spaces between >> words (Chinese, Japanese, Thai,...). If Text elements are only used >> for short things such as names or titles, that's not a big issue, >> the text in question can just be put on a single line. However, >> when the texts in question are long, it's a serious issue, and >> should be fixed. > >My understanding of type="text" is that this is "just text" without any "formatting". That's my understanding, too. >Hence, it is not meant to be "preformatted text" such as text/plain or inside an (X)HTML "pre". Yes. But that's exactly where the spacing problems with Chinese/Japanese/Thai are. There are no such problems for preformatted text, because the line breaking in the source (as sent) is the same as the line breaking when displayed. For free-flowing text, however, the line breaks in the source and those in the display are not (necessarily) the same, and so linebreaks have to be changed to spaces for Western languages, but to nothing for Chinese/Japanese (and most possibly to a zero-width non-breaking space for Thai), and the spec has to say something about this. Regards, Martin. >This means type="text" content is a single paragraph of text. If you need paragraphs, lists or any other "structural formatting", you have to use type="html" or type="xhtml" with the appropriate content. > >I was about to writing a Pace about white-space handling in type="text" (either using xml:space or an attribute that would have mimic'd the "white-space" CSS property) when I understood/recalled that Text Constructs have accessibility in mind (hence their limitation to textual contents) and preformatted text is not accessible enough. > >-- >Thomas Broyer > From owner-atom-syntax@mail.imc.org Sat May 7 02:15:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05193 for ; Sat, 7 May 2005 02:15: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 j4767ADm068226; Fri, 6 May 2005 23:07: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 j4767Awm068225; Fri, 6 May 2005 23:07:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j47678oJ068164 for ; Fri, 6 May 2005 23:07:09 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j47673717748; Sat, 7 May 2005 15:07:03 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 83ad22c6_bebf_11d9_8c30_0030482532aa_10499; Sat, 07 May 2005 15:16:14 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005405; 7 May 05 15:09:25 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 7 May 05 15:09:06 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0053FD; 7 May 05 15:08:57 +0900 Message-Id: <6.0.0.20.2.20050504104024.0627eb50@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 04 May 2005 10:41:49 +0900 To: Graham , Alexey Melnikov From: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: atom-syntax In-Reply-To: <05BDB9EA-9D4A-41AD-8A6E-D1B998A922AA@mac.com> References: <42712C6D.4030905@isode.com> <05BDB9EA-9D4A-41AD-8A6E-D1B998A922AA@mac.com> 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 04:32 05/05/04, Graham wrote: > >On 28 Apr 2005, at 7:33 pm, Alexey Melnikov wrote: > >> Ok, maybe it is just me, but what does it mean to "collapse white- space"? Does this mean to replace FWS (in RFC 2822 sense) with a >> single space? > >Since the statement is a MAY, I don't think any exact meaning is >necessary. It's simply a hint to publishers that whitespace may not >be preserved. > > >On 29 Apr 2005, at 10:17 am, Martin Duerst wrote: > >> Making this more precise is definitely desirable. But there is also >> an i18n issue: This works fine for languages that use spaces between >> words. It doesn't work for languages that don't have spaces between >> words (Chinese, Japanese, Thai,...). If Text elements are only used >> for short things such as names or titles, that's not a big issue, >> the text in question can just be put on a single line. However, >> when the texts in question are long, it's a serious issue, and >> should be fixed. > >A consumer may do anything that can reasonably be described as >"collapsing whitespace", but are not required to. How does this cause >problems in Asian languages? If the consumer does the right thing, it won't cause problems. But the chance that the consumer does the right thing without being told what this is (or, without being told that this is different for different languages or scripts) is rather low. So we better improve the spec to help consumers do a better job. Regards, Martin. From owner-atom-syntax@mail.imc.org Sat May 7 02:40:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13322 for ; Sat, 7 May 2005 02:40: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 j476WAqQ079789; Fri, 6 May 2005 23:32: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 j476WAQ5079788; Fri, 6 May 2005 23:32: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j476W9qu079740 for ; Fri, 6 May 2005 23:32:10 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1811167wri for ; Fri, 06 May 2005 23:32:04 -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=ewoCWMRzv+Ro1+/SBWjzUqs7ZP8f8Pf1HyglMUKbY245iqmy8UAzZirUBvYUoSExy3CRIrnJ6EzcfYnZ7yGp4e2dZTahxoV3bY1ZsCRpSNjIcZ50neIC+XNs2gD7Rpz+loOUjMERbbSzlQ97pLtCWbVwjNJAZSu5pmGjyC5Lxls= Received: by 10.54.49.17 with SMTP id w17mr1244980wrw; Fri, 06 May 2005 23:32:04 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Fri, 6 May 2005 23:32:04 -0700 (PDT) Message-ID: <540e373205050623325c9be890@mail.gmail.com> Date: Sat, 7 May 2005 01:32:04 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: PaceAllowDuplicateIDs In-Reply-To: <427B8617.9070204@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <080261f7bfddd3131c686e830ba65601@Sun.COM> <1d5387c3d355cc6673b741192650950e@rollerweblogger.org> <427B362A.3090904@dehora.net> <4b88bec651a462a164fb065a8b75d3d6@rollerweblogger.org> <427B8617.9070204@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j476WAqu079780 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I have no good answer to that until I know what what an id stands for. > The answer "an entry" isn't sufficient. Bill: Semi-random thoughts... * An atom:id is a globally unique name for a specific database query. * There is no "stream of instances over time". There's just old data that's out of sync with that query. * If duplicate ids are allowed, the world won't come to an end. I'm almost sure. I think. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat May 7 03:10:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14986 for ; Sat, 7 May 2005 03:10: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 j47720FD094458; Sat, 7 May 2005 00:02: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 j47720VD094457; Sat, 7 May 2005 00:02: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4771xne094432 for ; Sat, 7 May 2005 00:01:59 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1817337wri for ; Sat, 07 May 2005 00:01:53 -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=KwCXj5SyYgLAYm07NpmKG3Rf6oHUlvTaHlAgXODQIyWrBuD1+o/cKfdmg18x9/T1RsJ8jaj6KL/KmSzxKveaFM7S6WJyDZl6TlV+AqD5ewj3n1Zn2UqMXvFacqVQRQa5ixn1+GQV+tKnFs7V10gudbfgitX7z/BSn1D8N8dpcHY= Received: by 10.54.61.12 with SMTP id j12mr1254170wra; Sat, 07 May 2005 00:01:53 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Sat, 7 May 2005 00:01:53 -0700 (PDT) Message-ID: <540e37320505070001745c315e@mail.gmail.com> Date: Sat, 7 May 2005 02:01:53 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Syntax Subject: Re: PaceTextShouldBeProvided vs PaceOptionalSummary In-Reply-To: <68fba5c505050516314bd3014c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2BB858D6-BD76-11D9-AC04-003065EA6144@geckotribe.com> <68fba5c5050505082741e31fa5@mail.gmail.com> <427A4E1C.5090304@intertwingly.net> <68fba5c5050505102373bad099@mail.gmail.com> <816FB3D0-3B06-4E00-89F8-AAB4BDC31E6B@mac.com> <68fba5c50505051102a5b6934@mail.gmail.com> <82052f8d4aa95bd00abc28dff2e7bca4@sun.com> <68fba5c50505051552623360cd@mail.gmail.com> <693e52e7e790d1f21f5fc10371b571dc@sun.com> <68fba5c505050516314bd3014c@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4771xne094451 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Yes. If that SHOULD goes through, it becomes OK to write an Atom > Processor that catches fire when summary and content are both absent. Robert: Nothing about either pace will make it "not OK" to drop content- and summary-free entries on the floor, or come to a full stop when they're encountered. Such feeds would be completely useless in some apps, and therefore deserve to be tossed. PaceOptionalSummary simply enables an infinite loop of "talk to the other guy about that" responses to user questions, while PaceTextShouldBeProvided says that the tie goes to the aggregator. Kinda funny when you look at it that way, given the heated discussion on the subject. They could both be rolled into a single PaceWhoYouGonnaBlame and save everyone unnecessary reading. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat May 7 04:41:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21134 for ; Sat, 7 May 2005 04:41: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 j478U3Gp032796; Sat, 7 May 2005 01:30: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 j478U3g3032795; Sat, 7 May 2005 01:30:03 -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 j478U0Rk032760 for ; Sat, 7 May 2005 01:30:01 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:53219 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228726AbVEGI36 (ORCPT ); Sat, 7 May 2005 11:29:58 +0300 In-Reply-To: <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, atom-syntax@imc.org, Mark Nottingham , Robert Sayre , Thomas Broyer , Alexey Melnikov From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Sat, 7 May 2005 11:29:07 +0300 To: Martin Duerst 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 May 4, 2005, at 04:39, Martin Duerst wrote: > For free-flowing text, however, the line breaks in the source and > those in > the display are not (necessarily) the same, and so linebreaks have to > be > changed to spaces for Western languages, but to nothing for > Chinese/Japanese > (and most possibly to a zero-width non-breaking space for Thai), and > the spec > has to say something about this. Why would you put line breaks in the CJK source, then? Isn't the "problem" solved with the least heuristics by the producer not putting breaks there? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Sat May 7 04:51:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21770 for ; Sat, 7 May 2005 04:51: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 j478k7f7039525; Sat, 7 May 2005 01: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 j478k7UV039524; Sat, 7 May 2005 01:46: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j478k2gn039470 for ; Sat, 7 May 2005 01:46:06 -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, 7 May 2005 18:45:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 May 2005 18:45:51 +1000 Subject: Re: PaceAllowDuplicateIDs alteration From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <9d27817395c2bf3e140d33f01c9d269c@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 On 7/5/05 3:53 AM, "Tim Bray" wrote: > On May 6, 2005, at 8:49 AM, Eric Scheid wrote: > >>> Are they still the same entry if they have different source elements that >>> identify their source as being different feeds? >>> >> I don't see why. I subscribe to a Local News feed, a National News feed, and >> a Science News feed. All from the same publisher. The same story may appear >> in one, two, or three of those feeds. I don't believe each of those feeds >> would have the same feed/source values. >> > Right.... but the story's would have the same atom:id in each of > those feeds, right? So they are the same entry, right? -Tim > typo: "I don't see why not." d'oh! (Tim: yes) e. From owner-atom-syntax@mail.imc.org Sat May 7 07:53:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02839 for ; Sat, 7 May 2005 07:53: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 j47BjcJp016061; Sat, 7 May 2005 04:45: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 j47BjcIW016051; Sat, 7 May 2005 04:45:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j47BjbUd015983 for ; Sat, 7 May 2005 04:45:37 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j47BjTpc023218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 7 May 2005 07:45:29 -0400 (EDT) Message-ID: <427CAB6C.3040705@atrus.org> Date: Sat, 07 May 2005 07:50:04 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roger B." CC: Atom Syntax Subject: Re: Autodiscovery in as well as References: <427A805E.5080303@w3future.com> <427AC85D.7000004@inkedblade.net> <427B212F.70905@w3future.com> <427B2B71.6030300@atrus.org> <427C2D00.3000508@gmail.com> <427C44BE.6060701@atrus.org> <540e373205050622135b419792@mail.gmail.com> In-Reply-To: <540e373205050622135b419792@mail.gmail.com> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger B. wrote: >>Is there something wrong with the HTML parsers? >> >> > >Nikolas: Are they installed by default on most servers? If not, can >those running in sandboxes install them? > > Everything except perhaps the C libraries. All the other implementations I listed are written purely in their respective scripting language and should work if you just copy the source. Well, there's the possiblity that some require an obscure lib somewhere, but the source I skimmed indicated that they were based on basic string functions and/or regular expressions. I should also note that I'm not sure how well each of them stands up to crazy real world input because I've never tried using them on arbitrary pages. Hrm, I find, or make up, some test inputs ... >>From the perspective of my niche, I can tell you that Coldfusion can >use jTidy to make sense of random HTML, but it is (a) installed in >virtually zero CF hosting environments, and (b) cannot normally be >added by an individual developer working in a sandbox. (It's also >riddled with bugs, but I'm just grateful to have it at all... I steer >clear of gift horses' mouths whenever possible.) > >-- >Roger Benningfield > My condolences. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Sat May 7 08:07:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04092 for ; Sat, 7 May 2005 08: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 j47BwxaN021593; Sat, 7 May 2005 04:58: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 j47Bwx0k021592; Sat, 7 May 2005 04:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j47BwuKN021534 for ; Sat, 7 May 2005 04:58:58 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j47Bwlpc023326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 7 May 2005 07:58:47 -0400 (EDT) Message-ID: <427CAE8A.1090303@atrus.org> Date: Sat, 07 May 2005 08:03:22 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roger B." CC: Atom Syntax Subject: Re: Autodiscovery References: <200505061921.DCL02846@ms8.netsolmail.com> <427BF553.8090402@atrus.org> <540e3732050506224160895477@mail.gmail.com> In-Reply-To: <540e3732050506224160895477@mail.gmail.com> 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 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger B. wrote: >>The problem is fortunately mitigated because user agents usually >>only offer copying @href ("copy link location").> I'm under the >>impression that they do something similar with rich-text copying. >> >> > >Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's >XFN-friendly links page and paste it into my WYSIWYG editor, I get all >of his @rel="whatevers" in my post. This is the same behavior I've >noted in every IE- and Mozilla-based WYSIWYG editor I've tried. > >-- >Roger Benningfield > > Crud. To the bug databases I go. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Sat May 7 08:43:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06974 for ; Sat, 7 May 2005 08:43: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 j47CZmCl038121; Sat, 7 May 2005 05:35: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 j47CZmZl038120; Sat, 7 May 2005 05:35:48 -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 j47CZmK7038112 for ; Sat, 7 May 2005 05:35:48 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 83236 invoked by uid 17064); 7 May 2005 12:35:48 -0000 Received: from unknown (HELO [192.168.0.9]) ([81.249.225.74]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 May 2005 12:35:48 -0000 In-Reply-To: <73103F7C-8DA1-4E2F-B5F2-FAB037DFCCFD@jtauber.com> References: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> <73103F7C-8DA1-4E2F-B5F2-FAB037DFCCFD@jtauber.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: entry definition Date: Sat, 7 May 2005 14:35:42 +0200 To: James Tauber X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 May 2005, at 04:53, James Tauber wrote: > In the case where there is an "alternate" I think this is correct, > but it: > > 1. highlights the inaccuracy of the word "alternate" > 2. doesn't address the case where there is no link alternate > > James I agree. My definition is making me wonder whether I should not in fact accept that link alternate is a MUST. There may be ways of tweaking the definition which mean that I don't need to come to that conclusion. Or perhaps one can think of entries without an alternate as speaking about themselves? I agree also that the definition would make it more appropriate to have an ... node (or something similar) to highlight its importance. A good one sentence definition can help a lot in conveying the complexities of something. As a result I may feel inclined to change my positions on matters elsewhere to have them in accord with the definition, as opposed to making the definition more complicated. It all depends. But I am pretty sure that a clear definition of a core element of the spec would really help in spreading the understanding of what we are doing. > On 06/05/2005, at 12:46 PM, Henry Story wrote: > >> Some have been clamoring for a good definition of an entry. >> Here is one I have thought of recently. >> >> An Atom Entry is a resource (identified by atom:id) whose >> representations >> (atom:entry) describe the state of a web resource at a time >> (the link alternate) > From owner-atom-syntax@mail.imc.org Sat May 7 18:03:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22291 for ; Sat, 7 May 2005 18: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 j47LtKoe025282; Sat, 7 May 2005 14: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 j47LtKnr025281; Sat, 7 May 2005 14:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j47LtJ3C025264 for ; Sat, 7 May 2005 14:55:19 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 14512 invoked by uid 500); 7 May 2005 22:29:12 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 May 2005 22:29:12 -0000 Date: Sat, 7 May 2005 18:29:12 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Atom WG Subject: the "atom:copyright" element Message-ID: 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: The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless. Using the element name 'atom:rights', as argued below, could enhance interoperability and avoid some unforeseen and unintended legal implications that may emerge from use of the term ("copyright"). The term "copyright" has an established legal meaning -- or rather, set of established legal meanings, in various languages and jurisdictions, whereas "rights" is capable of a generic meaning that extends to the rights of readers (consumers) as well as to the rights of authors (creators). Why should the Atom spec support the latter and not the former? I agree with 99% of earlier list postings [0] to the effect that: DRM is a snakepit; we don't want to come anywhere near it; DRM patent terrorism is a scourge; rights management constructs per se DO NOT belong in the Atom design, etc. So, I do not advocate 'atom:rights' over 'atom:copyright' because I want Atom to support rights management (enforcement), but because I think using 'atom:copyright' gives privilege to the wrong set of stakeholders, and potentially leads to a legal mess. The label "rights" has no clear association with intellectual property law(s); by its genericity, it would allow for and support the (established) concept of "IP rights claim + prohibition against copy/reuse/CreateDerivativeWork", which roughly == "copyright", while allowing other concepts like "you're free to use this, please include some kind of attribution for the source, thanks!" Stated otherwise, a declaration like (version -08 example) "Copyright (c) 2003, Mark Pilgrim" serves the need of an author to assert IP ownership and to (possibly) discourage certain -- but unclear -- uses of the embedding Atom entry/feed. A declaration "... " does nothing to encourage syndication, or to clearly communicate that the content of an Atom feed/entry may be re-used freely, by permission. Two other major initiatives have recognized that rights properly belong to users/readers as well as to authors, and have registered this opinion in the technical design of XML markup vocabularies: the Open Archives Initiative (OAI) [4] and Dublin Core Metadata Initiative (DCMI) [5]. OAI supports a model for federated databases and unified search engines that access archives at hundreds of digital libraries and archive centers; DCMI's "Dublin Core metadata" model has been adopted for use in many HTML, XHTML, and XML markup applications. Formal specifications from both organizations allow generic "rights" markup elements that contain free-form text as well as by-reference (URI) pointers to resources that document the relevant "rights" -- which users are free to consult or ignore. I believe the Atom spec can do this similarly (and minimally) with an 'atom:rights' element in place of 'atom:copyright'. It can do so optimally by allowing one (optional) generic URI reference to a resource that documents the "rights" statement(s) from the creator of an Atom feed/entry. Something non-legal, like 'rightsDescription="URI"'. I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread "abuse" of the 'atom:copyright' element. Surely, "multiple (incompatible) ad hoc solutions will be invented" ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless. In making this request for WG reconsideration of the appropriateness of the element name 'atom:copyright', I respect the fact that the The Atom Syndication Format specification is in last call [6], "near that finish line" and "onto the last lap" [7]. Thanks, Robin Cover OASIS XML Cover Pages http://xml.coverpages.org/ PS [Bob Wyman,] Note that I have not referenced the Creative Commons or (machine-readable) "licenses" at all in the above. While I approve of both, I think any such use should be a decision left to an Atom author -- and I do not think it should be the role of the Atom spec designers to positively *prevent* an Atom author from referencing a machine-readable license in an unambiguous manner if s/he wishes to do so. Surely, enabling an Atom author to clearly declare her/his intent is preferable to enforcing "intentional prose ambiguity" through spec constraints. ====== Excursus on OAI and DCMI models for "rights" ====== I would *NOT* recommend modeling any Atom design after the OAI and DCMI designs, specifically, and I would *NOT* suggest that Atom recommend any behavior with respect to processing of assertions made in connection with an 'atom:rights' element instance. My point is that other public initiatives have not felt the need to capitulate to the implied threat from DRM vendors to the extent of saying "we cannot allow Atom authors to express anything that even smells like "rights" lest we be sued for DRM patent infringement." The DRM world is indeed a snake pit, if not also a den of thieves (RMS: "DRM is theft"), but arguably, that reality can hardly be used to justify a one-sided Atom model which predicates legal rights of content owners and denies the right to predicate the rights of readers. Having clarified that I'm not suggesting an Atom replica of the OAI and DCMI designs, let me summarize both, cribbed from news stories I composed earlier 1. Open Archives Initiative ================================================================== The OAI Protocol for Metadata Harvesting (OAI-PMH) has now become the most widely adopted approach for publication of both "data" and "metadata" by online digital libraries and archive centers. A list of registered OAI conforming repositories (perhaps not current) identifies some 286 digital library projects using this federated database approach, and the OAIster Digital Library Production Service at the University of Michigan stores some 5,366,375 records of digital resources from 472 institutions. The essence of the open archives approach is "to enable access to Web-accessible material through interoperable repositories for (meta-)data sharing, publishing and archiving. OAI develops and promotes a low-barrier interoperability framework and associated standards based upon open protocols. In the OAI model, a data provider maintains one or more repositories (web servers) that support the OAI-PMH as a means of exposing metadata; a service provider issues OAI-PMH requests to data providers and uses the metadata as a basis for building value-added services. According to the online tutorial, OAI-PMH provides "a simple technical option for data providers to make their metadata available to services, based on the open standards HTTP (Hypertext Transport Protocol) and XML (Extensible Markup Language). The metadata that is harvested may be in any format that is agreed by a community (or by any discrete set of data and service providers), although unqualified Dublin Core is specified to provide a basic level of interoperability. MARCXML, METS, and OLAC are also popular supported formats. The OAI-PMH protocol is based on HTTP with support for flow control. Request arguments are issued as GET or POST parameters. OAI-PMH supports six request types, known as verbs; responses are encoded in XML syntax. OAI-PMH supports any metadata format encoded in XML, and OAI-PMH defines a single XML Schema to validate responses to all OAI-PMH requests." The new OAI Guidelines document specifies the mechanisms by which rights expressions can be conveyed at three different levels representing OAI-PMH data model entities: the record level, the repository level, and the set aggregation level. At the record level, metadata returned in OAI-PMH ListRecords and GetRecord responses "is packaged in elements. Each may include one or more containers that provide information about the metadata. A rights expression can be associated with the metadata by including an optional package in an container. The specification defines an XML schema to which such packages must conform. The schema allows for actual rights expressions to be specified by one of two mutually exclusive alternatives: in-line within a package, or by-reference via a URI of a network-accessible rights expression. In the by-reference encoding, there are no restrictions on the nature of the resource referenced by this URI; however, to facilitate machine processing, it is recommended that an XML formatted rights expression is accessible via the URI." ================================================================== 2. Dublin Core Metadata Initiative (DCMI) http://dublincore.org/usage/decisions/2004/2004-01.Rights-terms.shtml In June 2004, the Usage Board of the Dublin Core Metadata Initiative (DCMI) announced approval of the rights-related terms "License" and "Rights Holder" in machine-readable metadata declarations; "license" as a refinement of "dc:rights". The proposed standard of practice for encoding formal rights declarations identifying IP owners and machine-readable licenses provides a basis for distributed de-centralized rights management systems. Use of Dublin Core specifications and Creative Commons licenses involves no royalty or usage fee, as is true also for the XML-based Open Digital Rights Language (ODRL). The Dublin Core Metadata Initiative is "an open forum engaged in the development of interoperable online metadata standards that support a broad range of purposes and business models." The Dublin Core Metadata Element Set is a standard for cross-domain information resource description, implemented in markup languages perhaps more widely than any other metadata specification. Version 1.1 has been endorsed as ISO Standard 15836-2003, NISO Standard Z39.85-2001, and CEN Workshop Agreement CWA 13874. The new DCMI term "license" is an element-refinement for "rights" and provides for reference of a legal document giving official permission to do something with the resource. The DCMI recommended best practice is to identify the license using a URI. Examples of such licenses can be found at the Creative Commons web site. ==================== References ==================== [0] Atom Syntax list, circa 92 postings on copyright/DRM http://xml.coverpages.org/AtomCopyright.html [1] RCover, earlier request for element name "rights", http://www.imc.org/atom-syntax/mail-archive/msg04048.html "You missed nothing. I did not intend to propose formalizing machine readable rights statements. My principal intent was to suggest use of the term "rights" and to allow a URI reference. My secondary objective was to point out that the use of "copyright" (as a sole designator, label) is prejudicial in favor of legal formulations that deny the right to copy/reuse/CreateDerivativeWork. [3] Norman Walsh Mon, 24 May 2004 14:04:44 -0400 http://www.imc.org/atom-syntax/mail-archive/msg03942.html [3] Bob Wyman http://www.imc.org/atom-syntax/mail-archive/msg04060.html "I wholeheartedly agree with you that "rights" would be better than "copyright". All to often, people think that copyrights are the only rights that need to be dealt with. It simply isn't so. [4] Open Archives Initiative (OAI) http://xml.coverpages.org/ni2005-05-06-a.html http://xml.coverpages.org/OAI-RightsExpressionSpec.html [5] Dublin Core Metadata Initiative (DCMI) http://xml.coverpages.org/ni2004-07-09-a.html http://dublincore.org/usage/decisions/2004/2004-01.Rights-terms.shtml [6] The Last Atom Issue ("last lap") http://www.tbray.org/ongoing/When/200x/2005/05/04/Last-Atom-Issue [7] Atom Format spec Last Call http://xml.coverpages.org/ni2005-04-20-a.html http://xml.coverpages.org/draft-ietf-atompub-format-08.txt http://xml.coverpages.org/atom.html#atompub08 From owner-atom-syntax@mail.imc.org Sat May 7 18:54:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26452 for ; Sat, 7 May 2005 18:54: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 j47MkipB031862; Sat, 7 May 2005 15:46: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 j47Mkir8031861; Sat, 7 May 2005 15:46:44 -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 j47MkfgF031842; Sat, 7 May 2005 15:46:42 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 7 May 2005 15:46:33 -0700 To: Robin Cover , Atom WG From: Paul Hoffman Subject: Re: the "atom:copyright" element 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 6:29 PM -0400 5/7/05, Robin Cover wrote: >The publication of a new Implementation Guideline by the >Open Archives Initiative (OAI) compels me to suggest once >again [1], as Norm Walsh [2], Bob Wyman [3], and others have >done before, that the name 'atom:rights' would be better >than the (current) element name 'atom:copyright'. As before, -1. In fact, I would prefer to remove atom:copyright from the core before we make a post-last-call move to substitute a less-defined element such as atom:rights. >Since this element name change is not likely to have any >secondary ramifications that would affect other areas of >the format design, it should be harmless. Fully disagree. Later, you suggested that the renamed element would have a URI that pointed to the rights asserted by the author. That has a *lot* of effects, including the need for someone to resolve that URI before republishing the content in another feed, and storing the resolution of that URI with a copy of the contents (so that that author can't change the contents and then come after you). That is far from harmless. > Using the element >name 'atom:rights', as argued below, could enhance >interoperability Sorry, I didn't see anything in the rest of the post that showed how this could increase interop. Please be specific here. To me, you can't get much more interoperable than an unstructured, human-readable, free-text blob such as atom:copyright. > and avoid some unforeseen and unintended >legal implications that may emerge from use of the term >("copyright"). Legal FUD doesn't help here. The current atom:copyright entry has no properties different than allowing someone to type in whatever human-readable copyright notice they want in an HTML document. If someone is comfortable with asserting a copyright, they can; if they're not, they don't have to. >Something non-legal, >like 'rightsDescription="URI"'. Please explain how "rightsDescription" is "non-legal" while "copyright" is legal. Seriously, I don't see how they can be differentiated. If you claim particular rights, that's a legal assertion of the same strength as claiming a copyright. >I predict that if the Atom spec does not make this >kind of accommodation to support this widely attested >requirement, multiple (incompatible) ad hoc solutions >will be invented, alongside widespread "abuse" of the >'atom:copyright' element. Surely, "multiple (incompatible) >ad hoc solutions will be invented" ANYWAY, but providing >the basic markup construct in the Atom syntax spec would >point users in the right direction, rather than leaving >them directionless. This goes back to the question of what goes into the core and what is done as an extension. I would strongly support the latter because, as you posit, people will disagree on how they should be able to assert rights. Coming up with a single extension structure that will keep everyone happy will take a lot of wrangling, but the effort would probably be worth it. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat May 7 20:19:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01022 for ; Sat, 7 May 2005 20:19: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 j4809iw6041231; Sat, 7 May 2005 17: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 j4809iPM041230; Sat, 7 May 2005 17:09:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4809hkP041222 for ; Sat, 7 May 2005 17:09:43 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 14576 invoked by uid 500); 8 May 2005 00:43:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 May 2005 00:43:38 -0000 Date: Sat, 7 May 2005 20:43:38 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Atom WG Subject: Re: the "atom:copyright" element In-Reply-To: Message-ID: 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 Sat, 7 May 2005, Paul Hoffman wrote: > At 6:29 PM -0400 5/7/05, Robin Cover wrote: > >The publication of a new Implementation Guideline by the > >Open Archives Initiative (OAI) compels me to suggest once > >again [1], as Norm Walsh [2], Bob Wyman [3], and others have > >done before, that the name 'atom:rights' would be better > >than the (current) element name 'atom:copyright'. > > As before, -1. In fact, I would prefer to remove atom:copyright from > the core before we make a post-last-call move to substitute a > less-defined element such as atom:rights. > > >Since this element name change is not likely to have any > >secondary ramifications that would affect other areas of > >the format design, it should be harmless. > > Fully disagree. Later, you suggested that the renamed element would > have a URI that pointed to the rights asserted by the author. That > has a *lot* of effects, including the need for someone to resolve > that URI before republishing the content in another feed, and storing > the resolution of that URI with a copy of the contents (so that that > author can't change the contents and then come after you). That is > far from harmless. I distinguished between minimal and optimal: minimally, I simply asked for 'atom:rights' in place of 'atom:copyright'. How is that harmful (other than to existing implementations that people don't want to change)? As I envisioned both the minimal and optimal encoding, a user is not under any obligation to read (parse out) the meaning of the "human-readable, free-text blob" of textual content in the 'atom:copyright' element -- or did I miss some Atom statement about compliance? My understanding is that users of Atom feeds/entries are at liberty to either consult or ignore the free-text blob -- not required to behave in some particular way in relation to some copyright claim that may or may not be stated coherently in ... Certainly, in the case of any (I said, "optional") URI reference, which would be part of an optimal solution but not required by the minimal element name change: I do not envision any *need* for anyone to resolve any URI. Its intent would be to provide a mechanism for unambiguous reference ONLY for parties that wished to use this mechanism for resource discovery and other purposes. > > > Using the element > >name 'atom:rights', as argued below, could enhance > >interoperability > > Sorry, I didn't see anything in the rest of the post that showed how > this could increase interop. Please be specific here. To me, you > can't get much more interoperable than an unstructured, > human-readable, free-text blob such as atom:copyright. OK, "interoperability" may not have been the best term. I mean interoperability in terms of programs that look for a particular kind of factoid in some predictable place. The alternative is a hundred and one kinds of adhockery thrown into the free-text blob; a URI reference would be generically "see also, if you care to", but also "the license is here, for users that want to fetch licenses, that's what you'll see if you dereference the URI." > > and avoid some unforeseen and unintended > >legal implications that may emerge from use of the term > >("copyright"). > > Legal FUD doesn't help here. The current atom:copyright entry has no > properties different than allowing someone to type in whatever > human-readable copyright notice they want in an HTML document. If > someone is comfortable with asserting a copyright, they can; if > they're not, they don't have to. No legal FUD intended: I think it's common consensus that the word "copyright" is a legal term related to intellectual property law. The term "rights" is not because it can mean moral rights, civil rights, etc. etc. The term "rights" certainly can subsume "copyright," and so, this makes sense: Copyright (c) 2003, Mark Pilgrim However, I ask you, does this make sense: The corporate entity that owns this Atom document as its intellectual property does not wish to be identified by name, but I, although not the owner, certify that I am empowered to declare that you may legally display the text in your browser, and print it on paper, and display it on any website under your control, provided that you are an employee of a company having fewer than 20 employees as of 2005-05-03. It's a silly example, intended to remind that declarations about rights may be of greater interest with respect to the particular uses and and particular users of information -- none of which is (as I understand copyright law and practice) covered by "copyright" law per se. But of course, IANAL. > > >Something non-legal, > >like 'rightsDescription="URI"'. > > Please explain how "rightsDescription" is "non-legal" while > "copyright" is legal. Seriously, I don't see how they can be > differentiated. If you claim particular rights, that's a legal > assertion of the same strength as claiming a copyright. I only meant that "copyright" is a legal term, and that "rightsDescription" is not inherently a legal term, because it could be used of many kinds of rights that are not "legal." To make the point clearer (WRT this optional attribute name, hypothetical, only on the optimum solution), the label could be 'seeAlso' as in seeAlso="http://example.com/myStuff" > cat myStuff MyStuff Plea for Funding

I worked on this a ong time, so if you use it in some public setting, please contribute to my PayPal account #9586956, but if you're poor, that's OK, just use it for free.

> >I predict that if the Atom spec does not make this > >kind of accommodation to support this widely attested > >requirement, multiple (incompatible) ad hoc solutions > >will be invented, alongside widespread "abuse" of the > >'atom:copyright' element. Surely, "multiple (incompatible) > >ad hoc solutions will be invented" ANYWAY, but providing > >the basic markup construct in the Atom syntax spec would > >point users in the right direction, rather than leaving > >them directionless. > > This goes back to the question of what goes into the core and what is > done as an extension. I would strongly support the latter because, as > you posit, people will disagree on how they should be able to assert > rights. Coming up with a single extension structure that will keep > everyone happy will take a lot of wrangling, but the effort would > probably be worth it. The "optimal" solution that's usef by OAI and DCMI, but also by many others, is actually quite simple, because it's not intended to be used for enforcement; there's no need to agree on how to assert rights, in detail: just point to the resource via a URI. I think this is why, irrespective of Atom designers' attempts to stop this, people will invent a lot of solutions that use URIs, as in (John Panzer) http://www.imc.org/atom-syntax/mail-archive/msg13901.html "http://creativecommons.org/licenses/by/2.0/" /> I don't know if 'license' is registered yet, but this will probably be one of the cleaner solutions, amongst many dirty ones, most of which ignore the proposed single extension structure. Thanks for your feedback. > > --Paul Hoffman, Director > --Internet Mail Consortium > -- From owner-atom-syntax@mail.imc.org Sat May 7 20:43:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02478 for ; Sat, 7 May 2005 20:43: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 j480aRGf044708; Sat, 7 May 2005 17:36: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 j480aRj9044707; Sat, 7 May 2005 17:36:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j480aQEj044689 for ; Sat, 7 May 2005 17:36:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j480Zrex024438; Sun, 8 May 2005 01:36:04 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AB08C18-C7CB-4089-94B4-6A622E544F80@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: the "atom:copyright" element Date: Sun, 8 May 2005 01:35:53 +0100 To: Robin Cover X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 1:43 am, Robin Cover wrote: > I distinguished between minimal and optimal: minimally, I simply asked > for 'atom:rights' in place of 'atom:copyright'. How is that harmful > (other than to existing implementations that people don't want to > change)? Because "copyright" is the better understood and more widely used term. "rights" is meaningless. > However, I ask you, does this make sense: > > The corporate entity that owns this Atom document as > its intellectual property does not wish to be identified by name, > but I, although not the owner, certify that I am empowered to > declare that you may legally display the text in your browser, > and print it on paper, and display it on any website under your > control, provided that you are an employee of a company having > fewer than 20 employees as of 2005-05-03. Yes. The "corporate entity that owns this document" would be the copyright holder, non? Is that a Che Guevara t-shirt you're wearing? Graham From owner-atom-syntax@mail.imc.org Sat May 7 21:16:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04923 for ; Sat, 7 May 2005 21:16: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 j4817jHu049765; Sat, 7 May 2005 18:07: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 j4817jkc049764; Sat, 7 May 2005 18:07:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4817hS4049743 for ; Sat, 7 May 2005 18:07:44 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 14625 invoked by uid 500); 8 May 2005 01:41:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 May 2005 01:41:39 -0000 Date: Sat, 7 May 2005 21:41:39 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Graham cc: atom-syntax Subject: Re: the "atom:copyright" element In-Reply-To: <6AB08C18-C7CB-4089-94B4-6A622E544F80@mac.com> Message-ID: 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 Sun, 8 May 2005, Graham wrote: > > On 8 May 2005, at 1:43 am, Robin Cover wrote: > > > I distinguished between minimal and optimal: minimally, I simply asked > > for 'atom:rights' in place of 'atom:copyright'. How is that harmful > > (other than to existing implementations that people don't want to > > change)? > > Because "copyright" is the better understood and more widely used > term. "rights" is meaningless. The designers of Dublin Core and OAI-PMH didn't think so: that's why they adopted markup elements spelled "rights" http://dublincore.org/documents/dces/ "Element Name: Rights Definition: Information about rights held in and over the resource. Typically, Rights will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions may be made about any rights held in or over the resource." OAI-PMH http://www.openarchives.org/OAI/2.0/guidelines-rights.htm#record_level See the XML schema there. > > > However, I ask you, does this make sense: > > > > The corporate entity that owns this Atom document as > > its intellectual property does not wish to be identified by name, > > but I, although not the owner, certify that I am empowered to > > declare that you may legally display the text in your browser, > > and print it on paper, and display it on any website under your > > control, provided that you are an employee of a company having > > fewer than 20 employees as of 2005-05-03. > > Yes. The "corporate entity that owns this document" would be the > copyright holder, non? I assume so, but that wasn't the point. The point was the same as that made by Dublin Core in its definition of the rights element (above): "Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights..." A "rights" description might talk about trademarks, registered trademarks, service marks, and so forth: different from copyright. Cheers, -rcc > > Is that a Che Guevara t-shirt you're wearing? > > Graham > > -- From owner-atom-syntax@mail.imc.org Sat May 7 23:26:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13187 for ; Sat, 7 May 2005 23:26: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 j483JODG069567; Sat, 7 May 2005 20:19: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 j483JOBB069566; Sat, 7 May 2005 20:19:24 -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 j483JN5H069546 for ; Sat, 7 May 2005 20:19:23 -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 1B705AB for ; Sat, 7 May 2005 20:19:18 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j483JGng001609 for ; Sat, 7 May 2005 20:19:17 -0700 (PDT) Date: Sat, 07 May 2005 20:19:43 -0700 From: Walter Underwood To: Atom WG Subject: Re: PaceCaching Message-ID: <3EBEAF3AA3F6CCC94C04F11F@Wunders-Computer.local> In-Reply-To: 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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> X-Mailer: Mulberry/4.0.0b1 (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 May 6, 2005 4:28:44 PM -0700 Paul Hoffman wrote: > > -1. Having two mechanisms in two different layers is a recipe for disaster. > If HTTP headers are good enough for everything else on the web, they're good > enough for Atom. That would be a problem. But this is one mechanism with two ways to specify it. One is out-of-band in a server-specific way, the other is in the document in a standard way. Either way, it is HTTP rules for caching at all intermediate caches and at the client. Architecturally, this is exactly the same as HTTP-EQUIV meta tags for HTTP headers, and very similar to the ROBOTS meta tag for /robots.txt. In both cases, they provide a way for the document author to specify something without having permissions on the server software config. Further, these should be implemented exactly like HTTP-EQUIV, where the server software reads them and sets the header. The HTTP-EQUIV meta tag is proof "put it in the header" is not good enough for everything else. If that wasn't needed, it would be deprecated by now. There is a problem here, though. We need to specify the priority of the in-document specs vs. the HTTP header specs. I propose following the HTTP standard, in saying that the HTTP headers trump anything in the body. I'll even assume that following the HTTP spec is non-controversial, and go update the PACE. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat May 7 23:38:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13983 for ; Sat, 7 May 2005 23: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 j483ULn1071094; Sat, 7 May 2005 20:30: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 j483ULFX071093; Sat, 7 May 2005 20:30: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 j483UKhB071075 for ; Sat, 7 May 2005 20:30: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 04924AB; Sat, 7 May 2005 20:30:14 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j483Tmng001694; Sat, 7 May 2005 20:29:52 -0700 (PDT) Date: Sat, 07 May 2005 20:30:15 -0700 From: Walter Underwood To: Henri Sivonen , Martin Duerst Cc: iesg@ietf.org, atom-syntax@imc.org, Mark Nottingham , Robert Sayre , Thomas Broyer , Alexey Melnikov Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Message-ID: <605EF059B8737EC84E00239B@Wunders-Computer.local> In-Reply-To: References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.0b1 (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 May 7, 2005 11:29:07 AM +0300 Henri Sivonen wrote: > > Why would you put line breaks in the CJK source, then? Isn't the "problem" > solved with the least heuristics by the producer not putting breaks there? It would be even better if they would just speak English. :-) White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. There will be plenty of content from other formats with this linguistically meaningless white space. If we get this wrong, Atom-delivered content will look broken in some languages, and a bunch of extra-spec practice will build up about how to fix it. Much better to get it right in 1.0. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sun May 8 01:27:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21269 for ; Sun, 8 May 2005 01:27: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 j485KD4a093739; Sat, 7 May 2005 22: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 j485KDNB093738; Sat, 7 May 2005 22:20:13 -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 j485KCEA093715 for ; Sat, 7 May 2005 22:20:12 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.5] (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 CFC3AA32E2; Sun, 8 May 2005 01:20:10 -0400 (EDT) In-Reply-To: <3EBEAF3AA3F6CCC94C04F11F@Wunders-Computer.local> 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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> <3EBEAF3AA3F6CCC94C04F11F@Wunders-Computer.local> 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 X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceCaching Date: Sat, 7 May 2005 22:20:01 -0700 To: Walter Underwood 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 Walter, On May 7, 2005, at 8:19 PM, Walter Underwood wrote: > Architecturally, this is exactly the same as HTTP-EQUIV meta tags for > HTTP headers, and very similar to the ROBOTS meta tag for /robots.txt. > In both cases, they provide a way for the document author to specify > something without having permissions on the server software config. > > Further, these should be implemented exactly like HTTP-EQUIV, where > the server software reads them and sets the header. Servers don't do this with HTTP-EQUIV because it's too much of a performance hit; HTTP-EQUIV was a nice idea that never took off. > The HTTP-EQUIV meta tag is proof "put it in the header" is not good > enough for everything else. If that wasn't needed, it would be > deprecated > by now. I'm sympathetic to this problem, but I think the right answer is to fix the server configuration mechanisms, not to mix transport issues into formats. > There is a problem here, though. We need to specify the priority of the > in-document specs vs. the HTTP header specs. I propose following the > HTTP > standard, in saying that the HTTP headers trump anything in the body. > I'll even assume that following the HTTP spec is non-controversial, and > go update the PACE This was the approach taken in determining the character encoding for XML, and it cause a lot of confusion and problems. Also, realise that HTTP's caching mechanism is very much reliant on the constraints of HTTP; Expires brings clock sync issues, and max-age places requirements on the behaviour of intermediaries. It's not very easy to abstract these away into a generic mechanism. So, I'm -1 to PaceCaching. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun May 8 02:40:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17361 for ; Sun, 8 May 2005 02:40: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 j486VV8h032198; Sat, 7 May 2005 23:31: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 j486VV4C032197; Sat, 7 May 2005 23:31:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j486VQZi032122 for ; Sat, 7 May 2005 23:31:27 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j486VF718768; Sun, 8 May 2005 15:31:15 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id e5ab69c6_bf8a_11d9_99b0_0030482533a1_17504; Sun, 08 May 2005 15:32:06 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00548E; 8 May 05 15:33:40 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 8 May 05 15:33:30 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00548C; 8 May 05 15:33:18 +0900 Message-Id: <6.0.0.20.2.20050508145408.06272b20@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 08 May 2005 15:20:52 +0900 To: , "'Eric Scheid'" , "'Atom Syntax'" From: Martin Duerst Subject: RE: PaceAllowDuplicateIDs In-Reply-To: <200505061512.DCK10416@ms8.netsolmail.com> References: <200505061512.DCK10416@ms8.netsolmail.com> 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 00:12 05/05/07, Bob Wyman wrote: > Right. We have abstract feeds and entries and we have concrete feeds >and entries. The abstract feed is the actual stream of entries and updates >to entries as they are created over time. Feed documents are "concrete" >snapshots of this stream or abstract feed of entries. An abstract entry is >made "concrete" in entry documents or entry elements. An abstract entry may >change over time and may have one or more concrete instantiations. > Some applications are only interested in being exposed to those >concrete entries that reflect the "current" or "most recent" state of the >abstract entries -- these apps would prefer to see no duplicate ids in >concrete feed documents even though these duplicates *will* occur in the >abstract feed. Other applications will require visibility to the entire >stream of changes to abstract entries -- these applications will wish to see >concrete feeds that may contain multiple, differing concrete instantiations >of abstract entries. i.e. they will want the concrete feed to be an accurate >representation of the abstract feed. Two needs, to views... You say 'some applications' and 'other applications', as if they were on the same footing. In my view, the 'some applicaitons' (only interested in latest version) should be the usual case, and the 'other applications' (interested in more than one version) should be the exception. Mapping that back to the origin, applications generating feeds that in one way or another rely on the user getting more than one, or more than the latest, versions of their entries have made a design error, they have taken the wrong thing for the 'entry'. If they think that they have two different kinds of audiences, interested in two different things, they should publish two feeds. Some people claim that we need a definition for 'entry' to finish this discussion, but once we confirm that a feed can only contain one version of an entry with the same ID, the definition of entry is as clear as we need it to be. This is just the same as for Web pages. If somebody puts up a Web page for the current weather, there is nothing in HTTP that will help me get the past versions of this page. If the publisher thinks that people may be interested in past weather info, they will make up separate pages. If we think that it would be valuable to be able to correlate the entries in both feeds, we should define an extension for that, not mess around with the basic model. An extension would be rather easy, we only need two rel values for links in entries. One rel value could be called "permaentry", the other could be called "updatingentry". Maybe a third called "updatingfeed", if there is an updating feed for a single changing entry. I'm sure there are better names. The main use I see for documents with multiple entries with the same ID is archives. Everything else can be handled by the creater doing the right thing, or by an immediary offering a new feed with versions of the entry (no guarantee to have all of them, in that case). Even archives could be handled that way if really needed, but it's difficult to immagine that everybody will publish an archive feed. We can easily define an top level element, and that problem is solved. For aggregators, wanting to forward two or more entries with the same ID for me means that they are simply not doing their job. Aggregators should aggregate, not just function as GIGO (garbage in, garbage out) processors. So it should be clear that I'm -1 on PaceAllowDuplicateIDs. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun May 8 03:34:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21190 for ; Sun, 8 May 2005 03:34: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 j487QvgY061535; Sun, 8 May 2005 00:26: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 j487Qvba061534; Sun, 8 May 2005 00:26:57 -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 j487Qs5t061497 for ; Sun, 8 May 2005 00:26:55 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:55154 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228728AbVEHH0w (ORCPT ); Sun, 8 May 2005 10:26:52 +0300 In-Reply-To: <605EF059B8737EC84E00239B@Wunders-Computer.local> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <605EF059B8737EC84E00239B@Wunders-Computer.local> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70478bc828782710dbb5b0bdb053626c@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org, Martin Duerst , Mark Nottingham , iesg@ietf.org, Robert Sayre , Thomas Broyer , Alexey Melnikov From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Sun, 8 May 2005 10:26:22 +0300 To: Walter Underwood 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 May 8, 2005, at 06:30, Walter Underwood wrote: > White space is not particularly meaningful in some of these languages, > so we cannot expect them to suddenly pay attention to that just so > they can use Atom. Why not? We expect them not no insert other random characters there. What do the same producers do with XHTML? Opera 7.53 and Safari 1.3 render a space between the second and third Kanji in http://hsivonen.iki.fi/test/cjk-whitespace.xhtml > There will be plenty of content from other formats > with this linguistically meaningless white space. Why not just get rid of it in the producer end like you have to get rid of form feeds? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Sun May 8 04:36:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24562 for ; Sun, 8 May 2005 04:36: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 j488SFpU091403; Sun, 8 May 2005 01:28: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 j488SFTn091402; Sun, 8 May 2005 01:28: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j488SELZ091341 for ; Sun, 8 May 2005 01:28:14 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so2165566wri for ; Sun, 08 May 2005 01:28:08 -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=FPcYk4loxfv3h7io7hKyQParWUA8259Sku8ldF1RBHjOaRca8LV0pcHeTaJm0SzQvwUUlRoQCTsUtUdCGBnkhpqMoyIP1Lu8YpvxCAPiCidWaX+wSL+ye9PLaNqFJNh1DEwNSdguFOF3WgXYDKpQ8DmnuJVkuCJZcrRVBQ1SoNE= Received: by 10.54.29.14 with SMTP id c14mr1808579wrc; Sun, 08 May 2005 01:28:08 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Sun, 8 May 2005 01:28:08 -0700 (PDT) Message-ID: <540e3732050508012810d3595f@mail.gmail.com> Date: Sun, 8 May 2005 03:28:08 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: the "atom:copyright" element In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6AB08C18-C7CB-4089-94B4-6A622E544F80@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j488SELZ091391 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > A "rights" description might talk about trademarks, registered > trademarks, service marks, and so forth: different from copyright. Robin: In my opinion, the only place an atom:copyright should appear is at the feed level, as an assertion of ownership of the feed document itself. Rights statements relating to individual entries should live within the content, particularly references to trademarks and the like. So I guess I'm -1 on atom:rights. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sun May 8 05:38:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29051 for ; Sun, 8 May 2005 05:38: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 j489UV45019680; Sun, 8 May 2005 02:30: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 j489UVHS019679; Sun, 8 May 2005 02:30:31 -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 j489USkK019656 for ; Sun, 8 May 2005 02:30:29 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 33764 invoked by uid 17064); 8 May 2005 09:30:27 -0000 Received: from unknown (HELO [192.168.0.8]) ([83.112.225.35]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 May 2005 09:30:27 -0000 In-Reply-To: <6.0.0.20.2.20050508145408.06272b20@itmail.it.aoyama.ac.jp> References: <200505061512.DCK10416@ms8.netsolmail.com> <6.0.0.20.2.20050508145408.06272b20@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: , "'Eric Scheid'" , "'Atom Syntax'" Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Sun, 8 May 2005 11:30:20 +0200 To: Martin Duerst X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If I can summarize your point: You prefer applications that only allow one entry with the same id per feed. Those that don't should use a different format that has not been defined yet. This seems little weak an argument to me. I think we should permit certain types of communication to take place. The applications and the consumers should decide which are the most helpful to them at the time. More details below... On 8 May 2005, at 08:20, Martin Duerst wrote: > At 00:12 05/05/07, Bob Wyman wrote: > > > Right. We have abstract feeds and entries and we have concrete > feeds > >and entries. The abstract feed is the actual stream of entries and > updates > >to entries as they are created over time. Feed documents are > "concrete" > >snapshots of this stream or abstract feed of entries. An abstract > entry is > >made "concrete" in entry documents or entry elements. An abstract > entry may > >change over time and may have one or more concrete instantiations. > > Some applications are only interested in being exposed to those > >concrete entries that reflect the "current" or "most recent" state > of the > >abstract entries -- these apps would prefer to see no duplicate > ids in > >concrete feed documents even though these duplicates *will* occur > in the > >abstract feed. Other applications will require visibility to the > entire > >stream of changes to abstract entries -- these applications will > wish to see > >concrete feeds that may contain multiple, differing concrete > instantiations > >of abstract entries. i.e. they will want the concrete feed to be > an accurate > >representation of the abstract feed. Two needs, to views... > > You say 'some applications' and 'other applications', as if they > were on > the same footing. In my view, the 'some applicaitons' (only interested > in latest version) should be the usual case, and the 'other > applications' > (interested in more than one version) should be the exception. One does not need to rule what most types of applications will be most common by making a ruling on the format of the spec. Pragmatics will work for you very well: - It takes work to keep an archive of the past. As a result archives will be less common. - Most people are interested in current changes, as opposed to past changes Most applications will therefore work to satisfy current users needs, and so again feeds with multiply entries with the same id will be rarer. > Mapping that back to the origin, applications generating feeds that in > one way or another rely on the user getting more than one, or more > than > the latest, versions of their entries have made a design error, they > have taken the wrong thing for the 'entry'. If they think that they > have two different kinds of audiences, interested in two different > things, they should publish two feeds. Exactly. There is no need to have two formats, an archive format and a feed format. Let applications just create two feeds for the different uses that are made of them. > Some people claim that we > need a definition for 'entry' to finish this discussion, but once > we confirm that a feed can only contain one version of an entry with > the same ID, the definition of entry is as clear as we need it to be. Sorry to pick a nit, but that may help in giving one an understanding of what a feed is, but not of what an entry is. > This is just the same as for Web pages. If somebody puts up a Web page > for the current weather, there is nothing in HTTP that will help me > get the past versions of this page. ((Note: Nothing stops browser from keeping a history of every url you have ever seen though. I for one would find such a browser at times extremely useful. We are what we read and see on the internet. Being able to keep track of changes would help reduce the danger of the Orwellian rewriting of history.)) > If the publisher thinks that people may be interested in past > weather info, > they will make up separate pages. But there is nothing in these separate pages that says that they are two versions of the same thing. This point is clearer with the wiki example. As wikis change one can put the old versions of the wiki at separate urls. But there is nothing to say in HTTP that these are two versions of the same content, one older that the other. What a collection of entry representations with the same id give us is the notion of identity (and so change) over time and across uris. This is a really important and useful concept. > If we think that it would be valuable to be able > to correlate the entries in both feeds, we should define an > extension for that, not mess around with the basic model. > An extension would be rather easy, we only need two rel values > for links in entries. One rel value could be called "permaentry", > the other could be called "updatingentry". Maybe a third called > "updatingfeed", if there is an updating feed for a single changing > entry. I'm sure there are better names. Yes. I agree. We can write an extension to name the particular states (that are currently anonymous) and give pointers to a resource that maintains the past state present. Those will be cool extensions. Why disallow those extensions by ruling now that feeds can't have multiple entries with the same id? > The main use I see for documents with multiple entries with the same > ID is archives. Everything else can be handled by the creater doing > the right thing, or by an immediary offering a new feed with versions > of the entry (no guarantee to have all of them, in that case). Even > archives could be handled that way if really needed, but it's > difficult > to immagine that everybody will publish an archive feed. We can easily > define an top level element, and that problem is solved. Yes, but what is the real advantage of defining an archive top level element that will never make it into this spec, when we can have all that we need by being flexible? In any case by admitting that a top level archive element could exist you are admitting that there is not really any problem with grouping multiple entry versions together. > For aggregators, wanting to forward two or more entries with the > same ID for me means that they are simply not doing their job. > Aggregators should aggregate, not just function as GIGO (garbage > in, garbage out) processors. I wonder why we need to specify what a good aggregator is and what it is not. Let the applications and the market decide. We just need to make certain types of communication possible. > So it should be clear that I'm -1 on PaceAllowDuplicateIDs. Should I be -1 on UTF-8 and internationalization because most people I know are english, french or german and so that ISO-latin x is good enough for me? > > Regards, Martin. > From owner-atom-syntax@mail.imc.org Sun May 8 07:38:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05807 for ; Sun, 8 May 2005 07:38: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 j48BRgGD064247; Sun, 8 May 2005 04:27: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 j48BRgVO064246; Sun, 8 May 2005 04:27:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48BRfqj064198 for ; Sun, 8 May 2005 04:27:42 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050508112735.JGNC21532.mta08-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Sun, 8 May 2005 12:27:35 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050508112734.PXTU1289.aamta02-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 8 May 2005 12:27:34 +0100 Date: Sun, 8 May 2005 12:27:31 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC4) Professional X-Priority: 3 (Normal) Message-ID: <11910230369.20050508122731@djpowell.net> To: "Roger B." CC: atom-syntax Subject: Re: the "atom:copyright" element In-Reply-To: <540e3732050508012810d3595f@mail.gmail.com> References: <6AB08C18-C7CB-4089-94B4-6A622E544F80@mac.com> <540e3732050508012810d3595f@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 Sunday, May 8, 2005, 9:28:08 AM, you wrote: > Robin: In my opinion, the only place an atom:copyright should appear > is at the feed level, as an assertion of ownership of the feed > document itself. [Disregarding the name and legal meaning of the element...] What about entry documents though, surely they should be allowed a copyright statement? If I understand it correctly, I agree with Bob Wyman's view: "It's all about the Entries, Stupid!". Despite the structure of Atom Feed Documents putting atom:feed at the root, I see feed containment to be just one of many pieces of optional metadata about entries. atom:feed elements currently contain either: a) metadata about the feed or b) metadata about the feed and contained entries, which can be overridden within atom:entry I don't think that we should expand this to c) metadata about the feed and contained entries, which can't be overridden within atom:entry -- Dave From owner-atom-syntax@mail.imc.org Sun May 8 10:02:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16588 for ; Sun, 8 May 2005 10:02: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 j48DrjlU001694; Sun, 8 May 2005 06: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 j48Drjrs001693; Sun, 8 May 2005 06:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j48Dri1w001686 for ; Sun, 8 May 2005 06:53:44 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 24708 invoked by uid 500); 8 May 2005 14:27:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 May 2005 14:27:49 -0000 Date: Sun, 8 May 2005 10:27:49 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: "Roger B." cc: atom-syntax Subject: Re: the "atom:copyright" element In-Reply-To: <540e3732050508012810d3595f@mail.gmail.com> Message-ID: 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 Sun, 8 May 2005, Roger B. wrote: > > > A "rights" description might talk about trademarks, registered > > trademarks, service marks, and so forth: different from copyright. Isolating this statement creates a misrepresentation of the argument for using the label "rights". The quoted statement is a reminder that "copyright" is only ONE kind of "right" typically treated as intellectual property right. However, the more substantive argument for using the label "rights" is that users nowadays want to express an intent about permissions for usage (particular usages, in particular usage contexts, by particular classes of corporate entities, with particular financial restrictions, etc), and these expression for permission fall outside the realm of "copyright." I made a survey of the major metadata specifications in use, as well as a number of syndication formats: most of them formally recognize the difference between "rights" and "copyright" with respect to digital works. I won't bother this Atom list with a list of such specifications/standards, beause it's (apparently) irrelevant. One example, might help, in case the examples already given (Dublin Core, dc:rights etc, and Open Archive Initiative) [1] are unclear. A new example is IPTC's NewsML [2]. Here's a summary of NewsML followed by a summary of the NewsML documentation explaining why the markup language uses a 'RightsMetadata' markup element, and not just 'copyright' NewsML, according to the developers, is "the versatile News Markup Language for global news exchange. NewsML is designed to provide a media-independent, structural framework for multi-media news. It's used by Business Wire, Reuters, and many others (e.g., Agence France Presse, ANA, ANSA, Japan Newspaper Publishers & Editors Association NSK, JCN Newswire, MarketWire, PA News, PR Newswire, SDA/ATS, The Irish Times, United Press International, Wall Street Journal Online). NewsML can be applied at all stages in the (electronic) news lifecycle. Typical use would include: (1) in and between editorial systems; (2) between news agencies and their customers; (3) between publishers and news aggregators; (4) and between news service providers and end users." Hopefully, it's obvious why Atom and NewsML often appear in the same list of technologies for news syndication. NewsML and Atom both have markup elements for "metadata"; NewsML has a few more than Atom's 15x, but the idea is the same: there's "content" and "metadata" (about content). In the NewsML documentation for metadata markup elements, the distinction is made between "copyrights" and "usage rights": arguably, forcing all "rights" information into "copyright" is suboptimal, as well as simply incorrect with respect to bodies of law that govern these concepts. NewsML documentation: [4] "4.1.1 Classes of metadata NewsML divides the world of Metadata at the NewsComponent level into four classes: 1) Administrative Metadata: information about a package of news objects, or about the creation of the content contained in or referenced by the constituents of the NewsComponent. 2) Descriptive Metadata: information about the content contained in or referenced by the constituents of the NewsComponent. 3) Rights Metadata: information about the copyrights and usage rights of the content contained in or referenced by the constituents 4) Miscellaneous: other metadata... The RightsMetadata element contains information about the rights pertaining to the constituents of a NewsComponent, and any relevant usage rights that have been granted by the copyright holder to other parties." There's the difference, as articulated by NewsML, very similar to the markup terms used by Dublin Core, OAI-PMH, and a large number of other syndication/metadata formats: "copyright" is a narrow legal term that distinct from usage rights and other kinds of rights that are commonly expressed for Internet resources. > Robin: In my opinion, the only place an atom:copyright should appear > is at the feed level, Interesting: the Atom spec does not seem to share this point of view, if I have read it correctly Cheers, -rcc > as an assertion of ownership of the feed > document itself. Rights statements relating to individual entries > should live within the content, particularly references to trademarks > and the like. > > So I guess I'm -1 on atom:rights. > > -- > Roger Benningfield [1] http://www.imc.org/atom-syntax/mail-archive/msg14944.html [2] http://www.newsml.org/pages/index.php [3] http://www.newsml.org/pages/whouse_main.php [4] http://www.newsml.org/IPTC/NewsML/1.2/documentation/NewsML_1.2-doc-Guidelines_1.00.pdf > > -- From owner-atom-syntax@mail.imc.org Sun May 8 10:26:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19129 for ; Sun, 8 May 2005 10:26: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 j48EIhRs002912; Sun, 8 May 2005 07:18: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 j48EIhjJ002911; Sun, 8 May 2005 07:18:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48EIfMR002896 for ; Sun, 8 May 2005 07:18:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j48EIQwD010093; Sun, 8 May 2005 15:18:31 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) 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 "atom:copyright" element Date: Sun, 8 May 2005 15:18:23 +0100 To: Robin Cover X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robin, are we actually talking about any rights here beyond the rights to copy (which includes display and redistribution)? > The quoted statement is a reminder that "copyright" is only ONE > kind of "right" typically treated as intellectual property right. What other rights can be associated with content? Habeas Corpus? The right to bear arms? Take your agenda elsewhere. Graham From owner-atom-syntax@mail.imc.org Sun May 8 10:44:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20387 for ; Sun, 8 May 2005 10: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 j48EZhVp003840; Sun, 8 May 2005 07:35: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 j48EZhGQ003839; Sun, 8 May 2005 07:35:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48EZgeO003821 for ; Sun, 8 May 2005 07:35:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j48EZ8Ou013053; Sun, 8 May 2005 15:35:09 +0100 (BST) In-Reply-To: References: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> <73103F7C-8DA1-4E2F-B5F2-FAB037DFCCFD@jtauber.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30AD6514-6614-4159-9624-1A2238C79EA4@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: entry definition Date: Sun, 8 May 2005 15:35:06 +0100 To: Henry Story X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 May 2005, at 1:35 pm, Henry Story wrote: > My definition is making me wonder whether I should not in fact > accept that > link alternate is a MUST. Not really. There's no reason why the resource an Atom entry describes has to be visible online anywhere else. >>> An Atom Entry is a resource (identified by atom:id) whose >>> representations >>> (atom:entry) describe the state of a web resource at a time >>> (the link alternate) But in theory there's a one-to-one relationship between atom:id and the resource being described, and not between it and the link alternate (eg Alternate versions of several entries may all appear on the same webpage). This makes more sense to me: An Atom Entry is a resource whose representations (atom:entry) describe the state of a resource (identified by atom:id) at a time. [One or more alternate representations of that resource may also be available (link alternate)] The part in square brackets isn't really part of the definition of an entry. The "at a time" not having an associated element bugs me. It's too late now, but we really should have had a "When was this snapshot taken?" date element. Graham From owner-atom-syntax@mail.imc.org Sun May 8 10:56:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21003 for ; Sun, 8 May 2005 10:56: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 j48EkQgv005101; Sun, 8 May 2005 07:46: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 j48EkQnO005100; Sun, 8 May 2005 07:46:26 -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 j48EkPnN005088 for ; Sun, 8 May 2005 07:46:25 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 59311 messnum 279424 invoked from network[83.70.217.193/unknown]); 8 May 2005 14:46:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail03.svc.cra.dublin.eircom.net (qp 59311) with SMTP; 8 May 2005 14:46:19 -0000 Message-ID: <427E2638.40602@dehora.net> Date: Sun, 08 May 2005 15:46:16 +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: PaceCaching 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> <1A018C17-474C-4C70-85F2-12112465E5CD@mac.com> <3EBEAF3AA3F6CCC94C04F11F@Wunders-Computer.local> 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 Mark Nottingham wrote: > So, I'm -1 to PaceCaching. I agree with Paul and Mark, this is mixing layers. -1 to PaceCaching. cheers Bill From owner-atom-syntax@mail.imc.org Sun May 8 12:16:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26289 for ; Sun, 8 May 2005 12:16: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 j48G7cV5009557; Sun, 8 May 2005 09: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 j48G7cg0009556; Sun, 8 May 2005 09:07: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-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 j48G7bq9009550 for ; Sun, 8 May 2005 09:07:37 -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 j48G7bjO008016 for ; Sun, 8 May 2005 10:07:37 -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 <0IG600MT2I4OV6@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 08 May 2005 10:07:37 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG600ARTI4OTI@mail.sun.net> for atom-syntax@imc.org; Sun, 08 May 2005 10:07:36 -0600 (MDT) Date: Sun, 08 May 2005 09:08:43 -0700 From: Tim Bray Subject: Re: the "atom:copyright" element In-reply-to: To: Robin Cover Cc: Atom WG Message-id: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; 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 May 7, 2005, at 3:29 PM, Robin Cover wrote: > The publication of a new Implementation Guideline by the > Open Archives Initiative (OAI) compels me to suggest once > again [1], as Norm Walsh [2], Bob Wyman [3], and others have > done before, that the name 'atom:rights' would be better > than the (current) element name 'atom:copyright'. +1 Speaking as a publisher, Robin's proposal meets my needs better then what we have now. The legal advice I've received is that in many cases it's not necessary to assert copyright, unless it's being claimed by a party other than the other. On the other hand, I think many online publishers will want to specify various kinds of licensing and rights statements. Right now, 4.2.4 of format-08 says "The "atom:copyright" element is a Text construct that conveys a human-readable copyright statement for an entry or feed." Well, this fails to meet the needs in the very common case where you don't want to talk about copyright but you do want to talk about re-use limitations and so on. On the other hand, if you want to specify some details about the actual copyright, is an OK place to do so. > I believe the Atom spec can do this similarly (and > minimally) with an 'atom:rights' element in place of > 'atom:copyright'. It can do so optimally by allowing > one (optional) generic URI reference to a resource > that documents the "rights" statement(s) from the > creator of an Atom feed/entry. Something non-legal, > like 'rightsDescription="URI"'. Once again, speaking as a publisher who's not a lawyer, I find it very helpful to use widely-shared rights statements by reference - in my case, Creative Commons. So having a standardized URI to point to whatever I'm using would be a value-add for me. Once again, I'm not speaking for implementors, but for authors and publishers. Robin's suggestions would be of benefit to that community. -Tim From owner-atom-syntax@mail.imc.org Sun May 8 12:57:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29210 for ; Sun, 8 May 2005 12:57: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 j48Goff8012037; Sun, 8 May 2005 09:50: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 j48Gofsw012036; Sun, 8 May 2005 09:50: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48GodFh012030 for ; Sun, 8 May 2005 09:50:39 -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, 9 May 2005 02:50:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 09 May 2005 02:50:29 +1000 Subject: Re: the "atom:copyright" element 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 9/5/05 12:18 AM, "Graham" wrote: > What other rights can be associated with content? Robin, Tim: would atom:rights be the appropriate container for declarations like "foo is a trademark of (some third party), used with permission" e. From owner-atom-syntax@mail.imc.org Sun May 8 13:02:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29550 for ; Sun, 8 May 2005 13:02: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 j48GjWEj011751; Sun, 8 May 2005 09:45: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 j48GjWDC011750; Sun, 8 May 2005 09:45:32 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48GjU0k011741 for ; Sun, 8 May 2005 09:45:31 -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, 9 May 2005 02:45:27 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 09 May 2005 02:45:17 +1000 Subject: Re: the "atom:copyright" element 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 9/5/05 12:18 AM, "Graham" wrote: > What other rights can be associated with content? Habeas Corpus? The > right to bear arms? trademarks? moral rights (not just attribution)? e. From owner-atom-syntax@mail.imc.org Sun May 8 13:10:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00092 for ; Sun, 8 May 2005 13:10: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 j48H2lk2014786; Sun, 8 May 2005 10:02: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 j48H2lpY014785; Sun, 8 May 2005 10:02:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48H2kCm014767 for ; Sun, 8 May 2005 10:02:46 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j48H29wC008943; Sun, 8 May 2005 18:02:16 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13A65A98-B66F-491A-92B0-9952ACE4E47A@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: the "atom:copyright" element Date: Sun, 8 May 2005 18:02:10 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 5:50 pm, Eric Scheid wrote: > would atom:rights be the appropriate container for declarations > like "foo is > a trademark of (some third party), used with permission" How about an atom:footnote element? The biggest flaw in atom:rights and atom:copyright is the absence of any hint for either publishers or consumers as to how it's meant to be displayed. Graham From owner-atom-syntax@mail.imc.org Sun May 8 13:21:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01331 for ; Sun, 8 May 2005 13:21: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 j48HEFaM015446; Sun, 8 May 2005 10:14: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 j48HEFdR015445; Sun, 8 May 2005 10:14: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48HED7V015436 for ; Sun, 8 May 2005 10:14:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1784259wra for ; Sun, 08 May 2005 10:14:08 -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=l3/v0aGE+cq35Ri5V9CZpGtD8eR8rlaPil593cD53fawScWsn2EPsw8GV+piJOTVuyGqOANp7HSXxAPyVugxZyOHTtoboqtlU73tvdwL0mzlmPxTJSrKbWhqE1lj3LhexOaSNQcCuyw1S88i48x5UTQF5WnbJEfqzfTrjWOKIok= Received: by 10.54.18.12 with SMTP id 12mr1586057wrr; Sun, 08 May 2005 10:14:08 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sun, 8 May 2005 10:14:08 -0700 (PDT) Message-ID: <68fba5c50505081014491a6fb6@mail.gmail.com> Date: Sun, 8 May 2005 13:14:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: the "atom:copyright" element Cc: Eric Scheid , atom-syntax In-Reply-To: <13A65A98-B66F-491A-92B0-9952ACE4E47A@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <13A65A98-B66F-491A-92B0-9952ACE4E47A@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j48HEE7V015438 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/8/05, Graham wrote: > How about an atom:footnote element? The biggest flaw in atom:rights > and atom:copyright is the absence of any hint for either publishers > or consumers as to how it's meant to be displayed. That's a feature. I don't see any point in arguing over "rights" vs. "copyright". It's just a text blob, so "rights" is fine. The URI is a horrid idea, though. We have a SHOULD NOT against machine readable licensing information for a reason. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 8 13:38:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02866 for ; Sun, 8 May 2005 13:38: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 j48HULSX016834; Sun, 8 May 2005 10:30: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 j48HULkf016833; Sun, 8 May 2005 10:30:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48HUKpQ016826 for ; Sun, 8 May 2005 10:30:21 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j48HUJeB002581; Sun, 8 May 2005 13:30:20 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCR11845; Sun, 8 May 2005 13:30:18 -0400 (EDT) Message-Id: <200505081730.DCR11845@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robin Cover'" , "'Atom WG'" Subject: RE: the "atom:copyright" element Date: Sun, 8 May 2005 13:30: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.2900.2180 In-Reply-To: Thread-Index: AcVTUqpU+ZL25Hi5RmKoHYdpuVO9XQAnDX8g Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit First, let me say that I am a *very* strong supporter of intellectual property rights... I have always made my income by "selling" my intellectual property and I consider the anti-IPR proponents and "Free Software" evangelists to be no better than thieves or communists... Also, I am listed as sole inventor on four patents dealing with DRM and I have a number of pending applications in the works today... Having said that: If writers and publishers are provided with mechanisms to attach "rights" or DRM-like information to Atom entries or feeds, we are likely to discover that they will mistakenly assume that software will actually take some note of their statements and use those statements while processing entries. I believe, however, that it is exceptionally unlikely that Atom processors will, in fact, process such rights statements. There are many reasons for this and I've outlined them in numerous posts in the past. The most important are: 1) There are no useful, open and unencumbered standards for expressing limitations to rights in a machine readable fashion. (Note: CC does *not* support "limiting" rights.) 2) The DRM space is carpeted with patents and it is unlikely that people will find an unencumbered DRM method for at least another 10 years or so. 3) Authors and publishers are notoriously bad at understanding the legal implications of what they are saying concerning IPR and will often limit rights more than they expect. 4) The cost of upgrading every Atom processor to handle rights "properly" and without legal risk will make it virtually impossible for people to build the kind of quick-and-dirty processors that exist today. (i.e. before you could release your latest PHP-hack, you'd have to get legal review...) 5) We'll make it legally dangerous to build software that *reads* Atom feeds. Thus, it will only safe to write software that creates Atom feeds. The result will be reduced innovation in the space and potential domination by a small number of "feed readers" who are able to demonstrate legal compliance. 6) We're likely to "pollute the stream" by creating a babel of rights languages and legal traps that will choke off the Blogosphere. 7) We risk a situation where some aggregator will obtain preferred access to an encumbered DRM technology and then evangelize its use among authors and publishers. The result might be that all feed readers who don't use the method are forced to either go out of business to avoid the legal attacks of irate users or they will be forced to pay license fees to the patent holders. This would not be difficult to orchestrate... We should studiously avoid encouraging people to believe that software management of rights is possible in the open internet until some time in the future when someone identifies a formal standard which is demonstrated to be unencumbered by patents. If people really insist on providing more encouragement to the "rights management" folk in the Atom spec, then let us *please* include something like the following in the specification in order to discourage people from believing that processors will actually head the content of their DRM statements: "Publishers MUST NOT expect that processors of atom feeds or entries will, in fact, modify their behavior based on any content provided in or linked to by this element." bob wyman From owner-atom-syntax@mail.imc.org Sun May 8 14:04:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05334 for ; Sun, 8 May 2005 14:04: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 j48HtBDB018294; Sun, 8 May 2005 10:55: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 j48HtBFx018293; Sun, 8 May 2005 10:55: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48Ht9vo018284 for ; Sun, 8 May 2005 10:55:11 -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, 9 May 2005 03:55:05 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 09 May 2005 03:54:56 +1000 Subject: Re: the "atom:copyright" element From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200505081730.DCR11845@ms8.netsolmail.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 9/5/05 3:30 AM, "Bob Wyman" wrote: > If people really insist on providing more encouragement to the > "rights management" folk in the Atom spec, then let us *please* include > something like the following in the specification in order to discourage > people from believing that processors will actually head the content of > their DRM statements: > > "Publishers MUST NOT expect that processors of atom feeds or entries > will, in fact, modify their behavior based on any content provided in or > linked to by this element." +1 From owner-atom-syntax@mail.imc.org Sun May 8 14:04:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05367 for ; Sun, 8 May 2005 14:04: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 j48HvmZ9018489; Sun, 8 May 2005 10:57: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 j48HvmOg018486; Sun, 8 May 2005 10:57:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48HvlBt018475 for ; Sun, 8 May 2005 10:57:47 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j48HvAvA020365; Sun, 8 May 2005 18:57:16 +0100 (BST) In-Reply-To: <68fba5c50505081014491a6fb6@mail.gmail.com> References: <13A65A98-B66F-491A-92B0-9952ACE4E47A@mac.com> <68fba5c50505081014491a6fb6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D0BF625-AABD-4EF1-AAE3-D64CFD16054B@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: the "atom:copyright" element Date: Sun, 8 May 2005 18:57:09 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 6:14 pm, Robert Sayre wrote: > That's a feature. The thing is, I have no idea where to put the atom:copyright content. It might be a short "(C)2005 Robert Sayre" like you see at the bottom of every web page, or it might be a shouty "FOR PRIVATE USE ONLY" thing intended to be displayed prominently, or it might be wordy licensing text, etc etc. As a publisher, I wouldn't know what to put in there other than by seeing what kind of things other people are putting, which kind of undermines having an Atom spec. Some clarification in this area is needed. > The URI is a > horrid idea, though. We have a SHOULD NOT against machine readable > licensing information for a reason. Agreed, a URI is essentially machine readable (if it links to a well- known address) and therefore a bad idea. Graham From owner-atom-syntax@mail.imc.org Sun May 8 14:05:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05504 for ; Sun, 8 May 2005 14: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 j48HtjAF018332; Sun, 8 May 2005 10:55: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 j48HtjJv018331; Sun, 8 May 2005 10:55:45 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48HthZa018321 for ; Sun, 8 May 2005 10:55:44 -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 1DUq0E-0000LP-00; Sun, 08 May 2005 18:55:42 +0100 Date: Sun, 8 May 2005 18:55:42 +0100 From: James Aylett To: Atom WG Subject: Re: the "atom:copyright" element Message-ID: <20050508175542.GG11887@tartarus.org> Mail-Followup-To: James Aylett , Atom WG References: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 08, 2005 at 09:08:43AM -0700, Tim Bray wrote: > Speaking as a publisher, Robin's proposal [atom:rights not > atom:copyright] meets my needs better then what we have now. I'm +1 on atom:rights instead of atom:copyright. atom:copyright strikes me as very limited in scope, and I agree that actually I don't care terribly much about asserting copyright ownership, but do care about asserting usage rights. For instance, in one situation I have to deal with on a semi-regular basis, it is impossible to state what the copyright ownership of some content is. (It's a complex multi-author situation with lots of implicit and historical relationships, but very few formal contracts.) However the use rights are accepted by all parties, so making statements about copyright ownership isn't worthwhile. And at the end of the day, as one of the parties with vested interest in the content, I only care about what other people are allowed to do with it. [Rights statement by URI reference] > Once again, speaking as a publisher who's not a lawyer, I find it very > helpful to use widely-shared rights statements by reference - in my > case, Creative Commons. So having a standardized URI to point to > whatever I'm using would be a value-add for me. I'm -1 on getting this into Atom core. The utility of creative commons can be satisfied by using type='xhtml' and putting appropriate anchors in the text. However the Atom feed itself should, IMHO, contain a concise statement that is as complete as practical. (This doesn't mean you'll cover every possible case, but it does mean that you shouldn't rely on dereferencing a URI for important points). Saying "I'm using CC 'Attribution, No Derivatives, Non-Commercial'" and pointing to the CC URI is fine, but saying "follow this URI for rights info" and nothing else isn't. I'm concerned that making an explicit URI part of the right elements would encourage people to shift the balance the wrong way here. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun May 8 14:54:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12889 for ; Sun, 8 May 2005 14:54: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 j48IlVlh021696; Sun, 8 May 2005 11:47: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 j48IlV52021695; Sun, 8 May 2005 11:47:31 -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 j48IlTSU021649 for ; Sun, 8 May 2005 11:47:29 -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 j48IlTi7005512 for ; Sun, 8 May 2005 12:47:29 -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 <0IG600HMZPJ4EP@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 08 May 2005 12:47:29 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG6002JBPJ3UG@mail.sun.net> for atom-syntax@imc.org; Sun, 08 May 2005 12:47:28 -0600 (MDT) Date: Sun, 08 May 2005 11:48:35 -0700 From: Tim Bray Subject: Re: the "atom:copyright" element In-reply-to: <200505081730.DCR11845@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Robin Cover'" , "'Atom WG'" Message-id: <9355e4355a9c754a0915d04b722fa4c5@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200505081730.DCR11845@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 8, 2005, at 10:30 AM, Bob Wyman wrote: > First, let me say that I am a *very* strong supporter of > intellectual property rights... I have always made my income by > "selling" my > intellectual property and I consider the anti-IPR proponents and "Free > Software" evangelists to be no better than thieves or communists... Hey Bob, please refrain from throwing gasoline around near open flames. Thank you. -Tim From owner-atom-syntax@mail.imc.org Sun May 8 15:08:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14459 for ; Sun, 8 May 2005 15:08: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 j48Iqef1022245; Sun, 8 May 2005 11:52: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 j48Iqexp022244; Sun, 8 May 2005 11:52:40 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j48IqeHK022238 for ; Sun, 8 May 2005 11:52:40 -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 1DUqtL-0001mR-00; Sun, 08 May 2005 19:52:39 +0100 Date: Sun, 8 May 2005 19:52:39 +0100 From: James Aylett To: atom-syntax Subject: Re: the "atom:copyright" element Message-ID: <20050508185239.GJ11887@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <13A65A98-B66F-491A-92B0-9952ACE4E47A@mac.com> <68fba5c50505081014491a6fb6@mail.gmail.com> <4D0BF625-AABD-4EF1-AAE3-D64CFD16054B@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D0BF625-AABD-4EF1-AAE3-D64CFD16054B@mac.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 08, 2005 at 06:57:09PM +0100, Graham wrote: > >That's a feature. > > The thing is, I have no idea where to put the atom:copyright content. > It might be a short "(C)2005 Robert Sayre" like you see at the bottom > of every web page, or it might be a shouty "FOR PRIVATE USE ONLY" > thing intended to be displayed prominently, or it might be wordy > licensing text, etc etc. As a publisher, I wouldn't know what to put > in there other than by seeing what kind of things other people are > putting, which kind of undermines having an Atom spec. Some > clarification in this area is needed. My feeling is that we can't impose significant constraints on what the clients do with the data. Something like "Atom consumers SHOULD include a way to display the rights statements; publishers MUST NOT assume that such a display will be given prominence." (The terminology is probably wrong here.) What this means to client implementors is that, beyond providing a way for end users to get at the rights statements, they don't have to bend their interface or program design towards the rights issue. Since we're not trying to come up with any kind of mandatory rights declaration, this strikes me as the right balance. In my view, a shouty "FOR PRIVATE USE ONLY" would be better placed in the content itself, at the beginning. While this doesn't make sense logically, it seems the only viable tradeoff that has any real utility. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun May 8 15:47:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23317 for ; Sun, 8 May 2005 15:47: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 j48Jck7L026298; Sun, 8 May 2005 12:38: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 j48Jck2x026297; Sun, 8 May 2005 12:38:46 -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 j48Jcjvl026290 for ; Sun, 8 May 2005 12:38:46 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 89194 invoked by uid 17064); 8 May 2005 19:38:45 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.0.200]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 May 2005 19:38:45 -0000 In-Reply-To: <30AD6514-6614-4159-9624-1A2238C79EA4@mac.com> References: <93ED8DDD-091A-471E-8BB5-2EA802625917@bblfish.net> <73103F7C-8DA1-4E2F-B5F2-FAB037DFCCFD@jtauber.com> <30AD6514-6614-4159-9624-1A2238C79EA4@mac.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A912D04-3082-4E38-8031-21D94BDE02DA@bblfish.net> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: entry definition Date: Sun, 8 May 2005 21:38:43 +0200 To: Graham X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 16:35, Graham wrote: > On 7 May 2005, at 1:35 pm, Henry Story wrote: >> My definition is making me wonder whether I should not in fact >> accept that >> link alternate is a MUST. > > Not really. There's no reason why the resource an Atom entry > describes has to be visible online anywhere else. yes. I suggested that perhaps one could think of the atom entry as being about itself in that case. Perhaps that is circular. But perhaps not. Think of an entry id such as http://test.net/blog/ entry1 This could have two representations: -an atom entry representation -a simple html representation One could think of the atom entry as being about the representation that would be returned by fetching the same resource with a text/html mime type > >>>> An Atom Entry is a resource (identified by atom:id) whose >>>> representations >>>> (atom:entry) describe the state of a web resource at a time >>>> (the link alternate) >>>> > > But in theory there's a one-to-one relationship between atom:id and > the resource being described, and not between it and the link > alternate (eg Alternate versions of several entries may all appear > on the same webpage). This makes more sense to me: > > An Atom Entry is a resource whose representations (atom:entry) > describe the state > of a resource (identified by atom:id) at a time. That is true by definition of the atom:entry representations being representations of the atom:id resource. Representations of a resource are always descriptions of the resource they are representations of. That's the whole point of the resource/ representation distinction. So we agree that atom:entry representations are representations of the atom:id resource. But what I thought interests us (humans) about these representations is that they contain information about the state of some other resource(s) (the link alternate). The entry is a collection of metadata (where the content can also be metadata), about the link alternate. But perhaps I am wrong here. Perhaps an entry is just metadata (about the atom:content?). And the time stamp atom:updated is the time at which all that metadata was changed (and so thought to be correct). > [One or more alternate representations > of that resource may also be available (link alternate)] > > The part in square brackets isn't really part of the definition of > an entry. The "at a time" not having an associated element bugs me. > It's too late now, but we really should have had a "When was this > snapshot taken?" date element. I think there is in fact such a time element. - If the atom:id is a simple http url and can be dereferenced then the time of the snapshot would be the time you fetched the representation. - if the atom:id is a undereferenceable uri such as uri:urn:... then it usually will come in another packet, eg a feed, which will have been fetched from the web. One could use that time stamp, if one fetches it oneself, or even better, one could use the atom:updated field of the feed. I wonder if this exercise has been much help now. Henry > Graham From owner-atom-syntax@mail.imc.org Sun May 8 16:04:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26037 for ; Sun, 8 May 2005 16:04: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 j48JqMHk027056; Sun, 8 May 2005 12:52: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 j48JqM20027055; Sun, 8 May 2005 12:52:22 -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 j48JqLMO027046 for ; Sun, 8 May 2005 12:52:21 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:57225 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228706AbVEHTwT (ORCPT ); Sun, 8 May 2005 22:52:19 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3e924e79fe43635bfc90c9fa949f4fc1@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: the "atom:copyright" element Date: Sun, 8 May 2005 22:51:58 +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 May 8, 2005, at 19:45, Eric Scheid wrote: > On 9/5/05 12:18 AM, "Graham" wrote: > >> What other rights can be associated with content? Habeas Corpus? The >> right to bear arms? > > trademarks? If your lawyer tells you that you need to recite some legalese about trademarks, wouldn't (s)he tell you to put the legalese where people will see it with the trademarks--ie. in the content? > moral rights (not just attribution)? Can you give an example of a jurisdiction where it is useful to declare moral rights in a way other than indicating the author? Do you have a jurisdiction in mind where the moral rights can be vested in an entity other than the author who is a natural person? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Sun May 8 16:22:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27629 for ; Sun, 8 May 2005 16:22: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 j48KExrY028386; Sun, 8 May 2005 13: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 j48KEx46028385; Sun, 8 May 2005 13:14:59 -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 j48KEx7r028379 for ; Sun, 8 May 2005 13:14:59 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 2136 invoked by uid 17064); 8 May 2005 20:14:58 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.0.200]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 May 2005 20:14:58 -0000 In-Reply-To: <1115581435.8972.2.camel@localhost.localdomain> References: <1114155696.8206.14.camel@localhost.localdomain> <1d859c31e9473fc4859de440384e79f9@bblfish.net> <1114358056.9110.54.camel@localhost.localdomain> <5f456dba9e74e80a341a6f169a1ab2e8@bblfish.net> <1115581435.8972.2.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Blogged and RDF Date: Sun, 8 May 2005 22:14:56 +0200 To: Reto Bachmann-Gmuer X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 21:43, Reto Bachmann-Gmuer wrote: > back home and looking at the code: could you give me a hint on how to > get the instances of AtomContent given a > com.sun.labs.tools.blog.Blog or > org.openrdf.model.Graph (I was looking at the SesameRDFFactory). Well you can get all instances of a particular class in the database by using the SesameRDFFactory.getAllObjects(AtomContent.class) This gets set up in the Blog class. Currently I find it is best to make sure all the classes are set up in the database with a call similar to Blog.initFactory(). a good example is the Blog.getEntries() method. There is still a lot of clean up to do in this SesameRDFFactory class. I have let it grow up till now so that it would fit my needs. But I have some good ideas on how to clean it up. As you see I have a whole bunch of implementations of my interfaces such as AContent, which I use to create objects and testing them for coherence before adding them to the database. Clearly one could just as well create them as dynamic proxies. But when I started writing this I was not sure if that would give me all I needed. I don't believe anymore that one should return classes with more interfaces implemented that what the class returns. I think instead that there should perhaps be a RDFFActory cast() method that returns an object with extra interfaces implemented. Though I am still not sure about this. Henry > thanks! > reto From owner-atom-syntax@mail.imc.org Sun May 8 16:26:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28150 for ; Sun, 8 May 2005 16:26: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 j48KKEDL028663; Sun, 8 May 2005 13:20: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 j48KKEcu028662; Sun, 8 May 2005 13:20: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 j48KKEMf028656 for ; Sun, 8 May 2005 13:20:14 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 3974 invoked by uid 17064); 8 May 2005 20:20:14 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.0.200]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 May 2005 20:20:14 -0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: References: <1114155696.8206.14.camel@localhost.localdomain> <1d859c31e9473fc4859de440384e79f9@bblfish.net> <1114358056.9110.54.camel@localhost.localdomain> <5f456dba9e74e80a341a6f169a1ab2e8@bblfish.net> <1115581435.8972.2.camel@localhost.localdomain> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <101AB8FE-343B-4B1C-88A0-3B694D766C60@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Blogged and RDF Date: Sun, 8 May 2005 22:20:12 +0200 To: atom-syntax Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry I sent this to the wrong list. Time to go to bed clearly... Henry On 8 May 2005, at 22:14, Henry Story wrote: > > On 8 May 2005, at 21:43, Reto Bachmann-Gmuer wrote: > >> back home and looking at the code: could you give me a hint on how to >> get the instances of AtomContent given a >> com.sun.labs.tools.blog.Blog or >> org.openrdf.model.Graph (I was looking at the SesameRDFFactory). >> > > Well you can get all instances of a particular class in the > database by using the > SesameRDFFactory.getAllObjects(AtomContent.class) > From owner-atom-syntax@mail.imc.org Sun May 8 16:41:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29321 for ; Sun, 8 May 2005 16:41: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 j48KY2ce029698; Sun, 8 May 2005 13:34: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 j48KY2It029697; Sun, 8 May 2005 13:34:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j48KY1s7029689 for ; Sun, 8 May 2005 13:34:01 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 25021 invoked by uid 500); 8 May 2005 21:08:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 May 2005 21:08:11 -0000 Date: Sun, 8 May 2005 17:08:11 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Bob Wyman cc: "'Atom WG'" Subject: RE: the "atom:copyright" element In-Reply-To: <200505081730.DCR11845@ms8.netsolmail.com> Message-ID: 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 Sun, 8 May 2005, Bob Wyman wrote: +1. In spirit, I think I agree with what Bob says below. My mistake, in trying to agree with Bob's statement that DRM "is a snake pit" [1] lead me to overreach and say unnecessary things about DRM. I also support the foundation of law with respect to IP, and even if I disagree with some particulars, I respect its force. [1] http://www.imc.org/atom-syntax/mail-archive/msg13896.html Clarifications and qualifications appear inline: > > First, let me say that I am a *very* strong supporter of > intellectual property rights... I have always made my income by "selling" my > intellectual property and I consider the anti-IPR proponents and "Free > Software" evangelists to be no better than thieves or communists... Also, I > am listed as sole inventor on four patents dealing with DRM and I have a > number of pending applications in the works today... Having said that: Personally, I would wear none of the labels "anti-IPR proponent", "thief", or "communist" agreeably; even if I allow that communism is to be allowed as an experiment, the experiment seems largely to have failed. But: enough of this! and Bob is to be forgiven for responding to some words which I should not have uttered. I apologize, Bob. > > If writers and publishers are provided with mechanisms to attach > "rights" or DRM-like information to Atom entries or feeds, we are likely to > discover that they will mistakenly assume that software will actually take > some note of their statements and use those statements while processing > entries. I believe, however, that it is exceptionally unlikely that Atom > processors will, in fact, process such rights statements. I agree that Atom processors will not (properly) process rights statements, whether the term 'atom:copright' or the term 'atom:rights' is used. Furthermore, I fail to see how Atom processors reasonably could be enjoined to properly process rights statement if the assumption be that "properly process" means compliance with legal norm in various jurisdictions. No way: it's never been done before, to my knowledge, even in commercial DRM software. I therefore concur with Bob that the Atom spec should include some statement of the kind he proposes: "Publishers MUST NOT expect that processors of atom feeds or entries will, in fact, modify their behavior based on any content provided in or linked to by this element." I agree with this no matter whether the name of an/the element (attribute) be "copyright" or "rights" or something similar. > There are many > reasons for this and I've outlined them in numerous posts in the past. The > most important are: > 1) There are no useful, open and unencumbered standards for > expressing limitations to rights in a machine readable fashion. (Note: CC > does *not* support "limiting" rights.) Granting that CC is in no way a standard, and that its chief role is not to express prohibitions against use (otherwise granted as right), I probably agree, if "unencumbered" means "nowhere on the radar screen of any pure-play DRM company in search of possible patent infringement." Therefore, I advocated no use of any such (putative) standard. > 2) The DRM space is carpeted with patents and it is unlikely that > people will find an unencumbered DRM method for at least another 10 years or > so. Very possible, and for this very reason, some LARGE corporate bodies are seeking to deploy access/security/rights solutions using unencumbered specifications like XACML and SAML (and others) in place of the "DRM methods" where minefields hide 20 patents per square inch. > 3) Authors and publishers are notoriously bad at understanding the > legal implications of what they are saying concerning IPR and will often > limit rights more than they expect. Thank you! I agree. Many people will not understand what is meant, in the large, if some explicitly declares (rather than leaves implicit) Copyright (c) 2005 John Q. Public Creative Commons, now being internationalized to respect different legal conventions, was designed to counter *precisely* the problem Bob identifies: that people (using 'copyright' statements) indeed "limit rights more than they expect." And Creative Commons strongly disavows any interest in DRM: its goal is to encourage permissions, not rights limitations. This is one of the reasons, though not the chief reason, why I would not approve of a specification that provided the element and **no other markup element** as the sole authorized/structured/labeled means for an author to declare that his/her work "may be used freely". > 4) The cost of upgrading every Atom processor to handle rights > "properly" and without legal risk will make it virtually impossible for > people to build the kind of quick-and-dirty processors that exist today. > (i.e. before you could release your latest PHP-hack, you'd have to get legal > review...) Agree: I cannot imaging Atom processors being equipped to properly handle rights "without legal risk"; that includes processing of content in the element as well as content in any similar element like . > 5) We'll make it legally dangerous to build software that *reads* > Atom feeds. Thus, it will only safe to write software that creates Atom > feeds. The result will be reduced innovation in the space and potential > domination by a small number of "feed readers" who are able to demonstrate > legal compliance. I'm not sure what Bob fears as being legally dangerous: legal danger comes into play, as far as I can see, more from than from , if any legal danger is material. An explicit statement in the Atom spec indicating that "processors are not required (SHOULD NOT, MUST NOT be required) to read and act upon possible claims in the xxxx(copy(rights)) element" should be adequate. > 6) We're likely to "pollute the stream" by creating a babel of > rights languages and legal traps that will choke off the Blogosphere. In my opinion, the Babel will begin if the Atom spec is delivered without any clear provision for users to clearly express their intentions and preferences with respect to (re-use) of Atom documents on the web. Giving them an appropriately-labeled element and a URI reference ("for further information") is a reasonable beginning. > 7) We risk a situation where some aggregator will obtain preferred > access to an encumbered DRM technology and then evangelize its use among > authors and publishers. The result might be that all feed readers who don't > use the method are forced to either go out of business to avoid the legal > attacks of irate users or they will be forced to pay license fees to the > patent holders. This would not be difficult to orchestrate... I don't understand the ingredients which make this risk palpable, but if it's a real threat, it's a threat no matter what the Atom spec prescribes and proscribes. Generic-label markup elements will not create this risk. > We should studiously avoid encouraging people to believe that > software management of rights is possible in the open internet until some > time in the future when someone identifies a formal standard which is > demonstrated to be unencumbered by patents. Agree 110%. And for this reason, among others, the Atom spec should be clear that it does not intend to support "software management of rights." On other hand, I believe that the right to express, in English or in any natural language, or in equivalent straight-forward markup notation, one's preferences and intents about the use of digital content -- has to be a foundational human right. If we believe it has become legally risky to declare our intent and our wish, we have forfeited our right to live in a free society. > If people really insist on providing more encouragement to the > "rights management" folk in the Atom spec, then let us *please* include > something like the following in the specification in order to discourage > people from believing that processors will actually head the content of > their DRM statements: > > "Publishers MUST NOT expect that processors of atom feeds or entries > will, in fact, modify their behavior based on any content provided in or > linked to by this element." I've seen no evidence of "rights management" folk near the Atom spec -- and I certainly do not qualify. I agree that some kind of statement like the above should be used to clarify expectations about any kind of (copy)rights expression used in Atom documents. Cheers, Robin > > bob wyman > > > -- From owner-atom-syntax@mail.imc.org Sun May 8 23:22:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29888 for ; Sun, 8 May 2005 23:22: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 j493F01g066760; Sun, 8 May 2005 20:15: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 j493F0qh066759; Sun, 8 May 2005 20:15: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j493ExuP066749 for ; Sun, 8 May 2005 20:14:59 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so2467838wri for ; Sun, 08 May 2005 20:14:54 -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=dsJeEVVysnZ0xvrWrY35bjOnk26VY+aeK+SEm3MCQGc+hHltKFKXQD1tkxhBwwWLt+uph3H3xNqCjvxTwu55iicD+vSUHOXOvJd7VW2poBTLqrc0oU8Ydorpw8yLlt+FTjj2jTXbXJda86GKXUcoc+Dib8qmMmJ3C0bx6BQjq10= Received: by 10.54.45.20 with SMTP id s20mr2258722wrs; Sun, 08 May 2005 20:14:53 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Sun, 8 May 2005 20:14:53 -0700 (PDT) Message-ID: <14be96d305050820146d52a7f0@mail.gmail.com> Date: Sun, 8 May 2005 22:14:53 -0500 From: Mark Pilgrim Reply-To: Mark Pilgrim To: atom-syntax@imc.org Subject: Re: the "atom:copyright" element In-Reply-To: <200505081730.DCR11845@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505081730.DCR11845@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j493ExuP066753 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/8/05, Bob Wyman wrote: > First, let me say that I am a *very* strong supporter of > intellectual property rights... I have always made my income by "selling" my > intellectual property and I consider the anti-IPR proponents and "Free > Software" evangelists to be no better than thieves or communists... I knew from the moment I met you that you were destined to become a corollary to Godwin's Law... > Also, I > am listed as sole inventor on four patents dealing with DRM and I have a > number of pending applications in the works today... I don't suppose any of those would have anything to do with syndication, would they? Sing it with me now: "We all live in a Wyman submarine, Wyman submarine, Wyman submarine (patent)..." -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Sun May 8 23:43:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01551 for ; Sun, 8 May 2005 23:43: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 j493Ype4067974; Sun, 8 May 2005 20:34: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 j493YpZB067973; Sun, 8 May 2005 20:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j493Ypvd067967 for ; Sun, 8 May 2005 20:34:51 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id A3BB616EE0; Sun, 8 May 2005 22:35:01 -0500 (CDT) Date: Sun, 8 May 2005 22:35:01 -0500 From: David Nesting To: Graham Cc: atom-syntax Subject: Re: the "atom:copyright" element Message-ID: <20050509033501.GJ2161@home.fastolfe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 08, 2005 at 03:18:23PM +0100, Graham wrote: > > What other rights can be associated with content? I intend on utilizing and publishing feeds internal to my company. While the information in the feed may be considered "copyrighted", it's really my company's information classification that's the overriding piece of information that I need to attach to the feed (and/or the entries, individually). In other words, how do I attach a "proprietary" label to a feed or one of its entries? (Keeping in mind that I may have a "proprietary" summary for a resource that itself is more restrictive--say, "secret".) I intended to use the copyright tag for that, because its semantics seemed closest to what I need. But now that someone else brought the issue up, I figured I'd offer my opinion. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Mon May 9 03:02:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08032 for ; Mon, 9 May 2005 03:02: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 j496jZiX016373; Sun, 8 May 2005 23: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 j496jZgc016372; Sun, 8 May 2005 23:45:35 -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 j496jWJR016318 for ; Sun, 8 May 2005 23:45:33 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j496idm22277; Mon, 9 May 2005 15:44:40 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id f1596b1c_c055_11d9_9392_0030482533a1_17502; Mon, 09 May 2005 15:45:33 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0055BC; 9 May 05 15:47:07 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 9 May 05 15:46:54 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0055B8; 9 May 05 15:46:46 +0900 Message-Id: <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 08 May 2005 15:38:45 +0900 To: Henri Sivonen From: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: iesg@ietf.org, atom-syntax@imc.org, Mark Nottingham , Robert Sayre , Thomas Broyer , Alexey Melnikov In-Reply-To: References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> 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 17:29 05/05/07, Henri Sivonen wrote: > >On May 4, 2005, at 04:39, Martin Duerst wrote: > >> For free-flowing text, however, the line breaks in the source and those in >> the display are not (necessarily) the same, and so linebreaks have to be >> changed to spaces for Western languages, but to nothing for Chinese/Japanese >> (and most possibly to a zero-width non-breaking space for Thai), and the spec >> has to say something about this. > >Why would you put line breaks in the CJK source, then? Isn't the "problem" solved with the least heuristics by the producer not putting breaks there? People in China, Japan, and so on (Korean uses spaces, so it's not CJK) tend to use similar tools to those in the western world. Tools for editing XML, e.g., usually don't make it easy to edit very long lines because they assume that such long lines can be broken. So it's not as easy as it looks for the producer. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon May 9 04:06:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13033 for ; Mon, 9 May 2005 04:06: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 j497vskM044326; Mon, 9 May 2005 00:57: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 j497vsN6044325; Mon, 9 May 2005 00:57:54 -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 j497vrqr044310 for ; Mon, 9 May 2005 00:57:54 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:60233 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228798AbVEIH5w (ORCPT ); Mon, 9 May 2005 10:57:52 +0300 In-Reply-To: <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8401c34f4ae789d7aa11f14c22db1c10@iki.fi> Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, atom-syntax@imc.org, Mark Nottingham , Robert Sayre , Thomas Broyer , Alexey Melnikov From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Mon, 9 May 2005 10:57:24 +0300 To: Martin Duerst 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 May 8, 2005, at 09:38, Martin Duerst wrote: >> Why would you put line breaks in the CJK source, then? Isn't the >> "problem" solved with the least heuristics by the producer not >> putting breaks there? > > People in China, Japan, and so on (Korean uses spaces, so it's not CJK) > tend to use similar tools to those in the western world. Tools for > editing XML, e.g., usually don't make it easy to edit very long lines > because they assume that such long lines can be broken. So it's not > as easy as it looks for the producer. If the XML editing tools are broken, they should be fixed instead of requiring consumers to perform context-sensitive DWIM. Besides, Atom feeds are typically produced programmatically instead of editing manually, so I think the point about editors is moot. The content in Atom feeds may be manually edited, but putting stray line feeds in XHTML is not safe, so producers need to take care of not including stray line feeds anyway. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Mon May 9 08:32:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06025 for ; Mon, 9 May 2005 08:32: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 j49CJhrU042393; Mon, 9 May 2005 05:19: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 j49CJhgl042392; Mon, 9 May 2005 05:19:43 -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 j49CJgp9042382 for ; Mon, 9 May 2005 05:19:42 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j49CKIY1011774; Mon, 9 May 2005 08:20:21 -0400 Message-ID: <427F555A.3000501@intertwingly.net> Date: Mon, 09 May 2005 08:19:38 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceOptionalSummary References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> In-Reply-To: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.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 Antone Roundy wrote: > > +1. > > ...oh, and the wording I just suggested for part of > PaceTextShouldBeProvided would depend on this also being accepted. With deep regret, I'm going to express my -1 on PaceOptionalSummary. Not because I object to the text expressed in the proposal section. In fact, I clearly do not as I lifted large sections of it to be placed into PaceTextShouldBeProvided. No, it is because the author of PaceOptionalSummary has made it clear that he interprets the two paces to be incompatible, so each and every +1 for PaceOptionalSummary is a vote against PaceTextShouldNotBeProvided. Despite wording that accompanied several of these +1's, like the wording describe above. I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Despite this, I have attempted to see if there was some common ground to be found. I drafted up a Pace, and offered a few suggestions. It has since become clear to me that PaceOptionalSummary is being pursued in a winner take all manner. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. One thing I would like those who advocate PaceOptionalSummary to the exclusion of all other Paces on the subject to consider... what happens if the chairs determine that consensus can't be found on either of these paces? Look at the current wording of draft-08. Is that what you really want? We can do better. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 9 08:50:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07504 for ; Mon, 9 May 2005 08:50: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 j49CcTW2049366; Mon, 9 May 2005 05:38: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 j49CcTIR049365; Mon, 9 May 2005 05:38:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49CcSkk049327 for ; Mon, 9 May 2005 05:38:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j49CbZUt022879; Mon, 9 May 2005 13:37:41 +0100 (BST) In-Reply-To: <427F555A.3000501@intertwingly.net> References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalSummary Date: Mon, 9 May 2005 13:37:33 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 9 May 2005, at 1:19 pm, Sam Ruby wrote: > I also feel the need to express deep dismay at the way that author of > PaceOptionalSummary has been pursuing a scorched earth approach > whereby > everybody who expresses an opinion to the contrary is viciously > attacked > for doing so. I believe that this has significantly hampered the > ability of the work group to hold a reasonable discourse on the > subject. Plus fucking one. > As such, I see no other path than to offer my -1 on the Pace. Face > down, arms and legs outstretched, in the middle of the road. -1 also. Graham From owner-atom-syntax@mail.imc.org Mon May 9 09:35:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12148 for ; Mon, 9 May 2005 09:35: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 j49DNm98062161; Mon, 9 May 2005 06:23: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 j49DNmtU062160; Mon, 9 May 2005 06:23:48 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49DNkqc062151 for ; Mon, 9 May 2005 06:23:46 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.32.176]) by smtp.cegetel.net (Postfix) with ESMTP id 0F7D01A5C72; Mon, 9 May 2005 15:23:28 +0200 (CEST) Message-ID: <427F6496.4020604@cegetel.net> Date: Mon, 09 May 2005 15:24:38 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: "A. Pagaltzis" Cc: atom-syntax@imc.org Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <20050505140909.GA14882@klangraum> In-Reply-To: <20050505140909.GA14882@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit A. Pagaltzis wrote: > * Thomas Broyer [2005-05-03 19:35]: > >>This means type="text" content is a single paragraph of text. >>If you need paragraphs, lists or any other "structural >>formatting", you have to use type="html" or type="xhtml" with >>the appropriate content. > > > Or type="text/plain", I’d assume? If you're talking about atom:content, not for Text Constructs. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 9 09:43:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13125 for ; Mon, 9 May 2005 09:43: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 j49DUCp0062673; Mon, 9 May 2005 06:30: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 j49DUCw8062672; Mon, 9 May 2005 06:30:12 -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 j49DUBlQ062662 for ; Mon, 9 May 2005 06:30:11 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 1360 messnum 6678394 invoked from network[83.70.217.193/unknown]); 9 May 2005 13:30:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 1360) with SMTP; 9 May 2005 13:30:05 -0000 Message-ID: <427F65DA.1050106@dehora.net> Date: Mon, 09 May 2005 14:30: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@imc.org Subject: Re: PaceOptionalSummary References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> In-Reply-To: <427F555A.3000501@intertwingly.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 Sam Ruby wrote: > > Antone Roundy wrote: > >> >> +1. >> >> ...oh, and the wording I just suggested for part of >> PaceTextShouldBeProvided would depend on this also being accepted. > > > With deep regret, I'm going to express my -1 on PaceOptionalSummary. > Not because I object to the text expressed in the proposal section. > In fact, I clearly do not as I lifted large sections of it to be placed > into PaceTextShouldBeProvided. > > No, it is because the author of PaceOptionalSummary has made it clear > that he interprets the two paces to be incompatible, so each and every > +1 for PaceOptionalSummary is a vote against > PaceTextShouldNotBeProvided. I don't think the last clause follows. > Despite this, I have attempted to see if there was some common ground to > be found. I drafted up a Pace, and offered a few suggestions. It has > since become clear to me that PaceOptionalSummary is being pursued in a > winner take all manner. > > As such, I see no other path than to offer my -1 on the Pace. Face > down, arms and legs outstretched, in the middle of the road. Tim asked last week for an explanation as to why the two paces conflict. I provided this: http://www.imc.org/atom-syntax/mail-archive/msg14863.html I see PaceTextShouldBeProvided as contradictory to PaceOptionalSummary. It calls out title-only feeds as unfortunate and I assume from that, we are meant to infer a bad practice. You came back to me and pointed out that the rationale is not the spec text; I agreed and said the rationale is flawed. That's where is was left. I think, more or less, that PaceTextShouldBeProvided only exists because PaceOptionalSummary has not been successfully dismissed. I have no idea why title-only feeds are unfortunate, are an interoperability problem, or an accessibility problem. In fact I felt we had put the accessibility issue to bed weeks ago, but it popped up again in the PaceTextShouldBeProvided's rationale. > One thing I would like those who advocate PaceOptionalSummary to the > exclusion of all other Paces on the subject to consider... what happens > if the chairs determine that consensus can't be found on either of these > paces? Look at the current wording of draft-08. Is that what you > really want? If the chairs count it up, I think they could find consensus. I think they could have done that a fortnight ago. Or last week. I agree with Robert's paraphrasing, that we are drowning in +1s. And I fail to understand why this has been dragged out so long. There are a few strongly voiced objections, but is that sufficient reason to grind this one out? > We can do better. I started out 0 and moved to +1 based on the arguments I saw presented for and against PaceOptionalSummary and my own thinking. I'm -1 on PaceTextShouldBeProvided, and have explained why. I honestly don't know how I can do any better on this. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 09:46:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13283 for ; Mon, 9 May 2005 09:46: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 j49DXoAj062856; Mon, 9 May 2005 06:33: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 j49DXoUR062855; Mon, 9 May 2005 06:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49DXmm6062848 for ; Mon, 9 May 2005 06:33:48 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C0AE8E0063; Mon, 9 May 2005 09:33:42 -0400 (EDT) To: Martin Duerst Cc: Henri Sivonen , iesg@ietf.org, Thomas Broyer , Alexey Melnikov , atom-syntax@imc.org, Mark Nottingham , Robert Sayre Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> From: Sam Hartman Date: Mon, 09 May 2005 09:33:42 -0400 In-Reply-To: <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> (Martin Duerst's message of "Sun, 08 May 2005 15:38:45 +0900") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Martin" == Martin Duerst writes: Martin> At 17:29 05/05/07, Henri Sivonen wrote: >> On May 4, 2005, at 04:39, Martin Duerst wrote: >>> For free-flowing text, however, the line breaks in the source >>> and those in the display are not (necessarily) the same, and >>> so linebreaks have to be changed to spaces for Western >>> languages, but to nothing for Chinese/Japanese (and most >>> possibly to a zero-width non-breaking space for Thai), and the >>> spec has to say something about this. >> Why would you put line breaks in the CJK source, then? Isn't >> the Martin> "problem" solved with the least heuristics by the producer Martin> not putting breaks there? Martin> People in China, Japan, and so on (Korean uses spaces, so Martin> it's not CJK) tend to use similar tools to those in the Martin> western world. Tools for editing XML, e.g., usually don't Martin> make it easy to edit very long lines because they assume Martin> that such long lines can be broken. So it's not as easy as Martin> it looks for the producer. My personal opinion as someone who is very shortly going to have to evaluate the atom specification is that you've identified an issue (space and line breaking) for some languages that should be considered. Your proposed solution seems highly undesirable in that it requires us to understand the language of the text being displayed. In the past we've had all sorts of problems doing that. Your proposed solution also seems quite complicated. It may well be that the solutions to this problem are worse than the problem itself. However I think it is important to specifically understand that is the case rather than failing to solve the problem because we failed to understand it. At least based on the discussion the IESG has been copied on, it doesn't sound like the working group has fully considered this issue. The responses have more of the character of those found from people trying to brush aside an issue than of people who have carefully considered something and concluded there is nothing to be done. Moreover, thisn issue cannot be unique to atom: it must effect many XML based protocols both within the IETF and within other standards organizations. It may be that the right people haven'tspoken up or that the right part of the discussion hasn't been copied to the IESG. I'd sort of expect the apps ADs and atompub chairs to be familiar with these issues but so far have not seen them chime in. Anyway as someone evaluating atompub's output it would be very useful if the working group responded to this last call comment. IN my mind a response would start with a researched description of the issue: either confirm that Chinese and Japanese and Thai tools work as described or explain how they actually work. Then describe what other standards have done about this problem. Finally describe what atompub has done about the problem and why. I'm not asking for a lot of text; probably something about as long as this message. Such a response would make evaluating this issue much easier when the document comes before the IESG. From owner-atom-syntax@mail.imc.org Mon May 9 10:24:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18456 for ; Mon, 9 May 2005 10:24: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 j49EC7Yr065537; Mon, 9 May 2005 07:12: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 j49EC7qn065536; Mon, 9 May 2005 07:12:07 -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 j49EC5f0065523 for ; Mon, 9 May 2005 07:12:06 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 47535 messnum 6388142 invoked from network[83.70.217.193/unknown]); 9 May 2005 14:11:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 47535) with SMTP; 9 May 2005 14:11:59 -0000 Message-ID: <427F6FAC.1010407@dehora.net> Date: Mon, 09 May 2005 15:11:56 +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: PaceNoAlternateForFeed 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.intertwingly.net/wiki/pie/PaceNoAlternateForFeed == Abstract == Allow publishers to indicate when they have no alternate link for a feed. Author: BillDehora == Status == Open Incept: 2005-05-09 Written against: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt == Rationale == Not all publishers have a suitable alternate link for a feed. Example cases include subversion repositories [1], and mail archives [2]. == Proposal == In section 4.1.1 change the tenth bullet point {{{ o atom:feed elements MUST contain at least one atom:link element with a relation of "alternate". }}} to {{{ o atom:feed elements MUST contain either and cannot contain both - one or more atom:link elements with a relation of "alternate". - one and only one atom:link element with a relation of "no-alternate". }}} == Impacts == * PaceFeedIdOrAlternate: none, that pace is withdrawn. * PaceFeedIdOrSelf: that pace suggests pointing to self in the absence of an atom:link[@rel='alternate'] or an atom:id. This pace suggests allowing the publisher to state there is no alternate. == Notes == Fragment example derived from 1.1 example 2 in draft-08 {{{ dive into mark A <em>lot</em> of effort went into making this effortless 2005-04-02T12:29:29Z tag:example.org,2003:3 Copyright (c) 2003, Mark Pilgrim }}} * The author is not attached to the token 'no-alternate'. Any other token is fine once we agree that it states the publisher is saying there is no alternate link for this feed. * The author is fine with a SHOULD provide rather than MUST provide. * Whether atom:feed/atom:id MUST be present in the absence of an alternate be present can be argued about separately from whether there is no alternate. see PaceFeedIdOrSelf. cheers Bill [1] http://www.imc.org/atom-syntax/mail-archive/msg13995.html [2] http://www.imc.org/atom-syntax/mail-archive/msg13978.html From owner-atom-syntax@mail.imc.org Mon May 9 10:44:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20727 for ; Mon, 9 May 2005 10:44: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 j49EavOS066931; Mon, 9 May 2005 07:36: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 j49EavUT066930; Mon, 9 May 2005 07:36:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49EauiK066918 for ; Mon, 9 May 2005 07:36:56 -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 <200505091436490140085pkue>; Mon, 9 May 2005 14:36:49 +0000 Date: Mon, 9 May 2005 08:36:46 -0600 Subject: Re: PaceNoAlternateForFeed Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <427F6FAC.1010407@dehora.net> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49EauiK066925 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, May 9, 2005, at 08:11 AM, Bill de hra wrote: > * PaceFeedIdOrSelf: that pace suggests pointing to self in the > absence of an atom:link[@rel='alternate'] or an atom:id. This pace > suggests allowing the publisher to state there is no alternate. > Not quite right--that pace requires pointing to self in the absence of an atom:id. Whether or not atom:link[@rel='alternate'] exists is irrelevant to that requirement. From owner-atom-syntax@mail.imc.org Mon May 9 10:48:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21240 for ; Mon, 9 May 2005 10:48: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 j49EcrAt067017; Mon, 9 May 2005 07:38: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 j49Ecqur067016; Mon, 9 May 2005 07:38:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49EcqfM067007 for ; Mon, 9 May 2005 07:38:52 -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 (rwcrmhc11) with SMTP id <20050509143846013004of1fe>; Mon, 9 May 2005 14:38:46 +0000 Date: Mon, 9 May 2005 08:38:44 -0600 Subject: Re: the "atom:copyright" element 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: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> Message-Id: <0B66B9A9-C098-11D9-90F9-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, May 8, 2005, at 10:08 AM, Tim Bray wrote: > On May 7, 2005, at 3:29 PM, Robin Cover wrote: >> The publication of a new Implementation Guideline by the >> Open Archives Initiative (OAI) compels me to suggest once >> again [1], as Norm Walsh [2], Bob Wyman [3], and others have >> done before, that the name 'atom:rights' would be better >> than the (current) element name 'atom:copyright'. > > +1 +1 from me too. From owner-atom-syntax@mail.imc.org Mon May 9 10:55:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21789 for ; Mon, 9 May 2005 10:55: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 j49Em1oZ068024; Mon, 9 May 2005 07:48: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 j49Em1HF068023; Mon, 9 May 2005 07:48:01 -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 j49Em0sL068014 for ; Mon, 9 May 2005 07:48:00 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 55976 messnum 5770298 invoked from network[83.70.217.193/unknown]); 9 May 2005 14:47:54 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 55976) with SMTP; 9 May 2005 14:47:54 -0000 Message-ID: <427F7817.1030803@dehora.net> Date: Mon, 09 May 2005 15:47:51 +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: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceNoAlternateForFeed References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Antone Roundy wrote: > > On Monday, May 9, 2005, at 08:11 AM, Bill de hra wrote: > >> * PaceFeedIdOrSelf: that pace suggests pointing to self in the >> absence of an atom:link[@rel='alternate'] or an atom:id. This pace >> suggests allowing the publisher to state there is no alternate. >> > Not quite right--that pace requires pointing to self in the absence of > an atom:id. Whether or not atom:link[@rel='alternate'] exists is > irrelevant to that requirement. Do you want to edit the pace text to make it right? cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 11:00:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22967 for ; Mon, 9 May 2005 11:00: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 j49EpApu068190; Mon, 9 May 2005 07:51: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 j49EpA63068189; Mon, 9 May 2005 07:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49EpAEx068178 for ; Mon, 9 May 2005 07:51:10 -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 (rwcrmhc13) with SMTP id <200505091450590150073dvne>; Mon, 9 May 2005 14:51:04 +0000 Date: Mon, 9 May 2005 08:50:56 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceFeedIdOrSelf From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit 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 The pace adds this under atom:feed: atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of "self". That could just as well be: atom:feed elements that contain no child atom:link element with a relation of "self" MUST contain an atom:id element. Each subtly implies a preference for one or the other. I prefer the second--a preference for an element that can't be spoofed (or where spoofing can easily be detected). If that's missing (as in cases like SMTP delivery that have been noted, where the feed isn't retrievable from a specific URI), then atom:id must be added to provide a way to identify the feed. I didn't change the Pace, since such a change could conceivably change the opinions of people who've expressed an opinion on it already. But I would be interested to know whether people think this would be an improvement, make it worse, or if either is just as well. As for 'atom:feed elements SHOULD contain at least one atom:link element with a relation of "alternate".', I don't care particularly whether this is SHOULD or MAY, just not MUST. So if another Pace makes this a MAY, I as the author of PaceFeedIdOrSelf, would not consider it to conflict (on that point, at least) with PaceFeedIdOrSelf. From owner-atom-syntax@mail.imc.org Mon May 9 11:04:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23472 for ; Mon, 9 May 2005 11:04: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 j49Euadd068485; Mon, 9 May 2005 07:56: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 j49EuacK068484; Mon, 9 May 2005 07:56: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49EuYhn068470 for ; Mon, 9 May 2005 07:56:35 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 09 May 2005 14:56:28 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.5.201.10] by mail.gmx.net (mp006) with SMTP; 09 May 2005 16:56:28 +0200 X-Authenticated: #1915285 Message-ID: <427F7A1A.4060300@gmx.de> Date: Mon, 09 May 2005 16:56:26 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> In-Reply-To: <427F6FAC.1010407@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > ... > {{{ > o atom:feed elements MUST contain either and cannot contain both > - one or more atom:link elements with a relation of "alternate". > - one and only one atom:link element with a relation of > "no-alternate". > }}} > ... > > ... Is this meant to be a serious proposal? Why can't ve just leave a protocol element out if we don't have information for it??? Best regards, Julian From owner-atom-syntax@mail.imc.org Mon May 9 11:07:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23885 for ; Mon, 9 May 2005 11: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 j49EwL1X069273; Mon, 9 May 2005 07:58: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 j49EwL0I069272; Mon, 9 May 2005 07:58: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49EwKX3069263 for ; Mon, 9 May 2005 07:58:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2238509wra for ; Mon, 09 May 2005 07:58:14 -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=Ng9Fh9Haj5tgoBQgxVkBkcflS6BHXB2O2vjTp4r8fa45J6/o4Z44yfG2GKGZc2g57/d2txEayc095SomzkvkhxH3yHa9nkpXyiwk2fRs8rUXcrPbNyZ/7tK5DtzHwW4W4HpGRakXBLiLMx0FEQPoj1L6D6oh6Dgq9tGBCt5JapA= Received: by 10.54.73.2 with SMTP id v2mr2686085wra; Mon, 09 May 2005 07:58:14 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 9 May 2005 07:58:09 -0700 (PDT) Message-ID: <68fba5c505050907582805627c@mail.gmail.com> Date: Mon, 9 May 2005 10:58:09 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOptionalSummary Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <427F555A.3000501@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49EwKX3069267 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Sam Ruby wrote: > I also feel the need to express deep dismay at the way that author of > PaceOptionalSummary has been pursuing a scorched earth approach whereby > everybody who expresses an opinion to the contrary is viciously attacked > for doing so. I believe that this has significantly hampered the > ability of the work group to hold a reasonable discourse on the subject. I believe the secretary significantly hampered discourse on this subject for *months*, by claiming the issue had consensus and was closed. How did that estimate of consensus pan out? > One thing I would like those who advocate PaceOptionalSummary to the > exclusion of all other Paces on the subject to consider... what happens > if the chairs determine that consensus can't be found on either of these > paces? Look at the current wording of draft-08. Is that what you > really want? That's not what will happen. You see, there was only *one* supporter of that wording. The WG has spoken very clearly. I'm not sure why this is dragging out. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 11:20:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25530 for ; Mon, 9 May 2005 11:20: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 j49FDBjI071120; Mon, 9 May 2005 08:13: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 j49FDBEI071119; Mon, 9 May 2005 08:13:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FDADe071100 for ; Mon, 9 May 2005 08:13:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 70983 messnum 2875370 invoked from network[83.70.217.193/unknown]); 9 May 2005 15:13:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail09.svc.cra.dublin.eircom.net (qp 70983) with SMTP; 9 May 2005 15:13:04 -0000 Message-ID: <427F7DFD.6070807@dehora.net> Date: Mon, 09 May 2005 16:13: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: Atom Syntax Subject: Re: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> In-Reply-To: <427F7A1A.4060300@gmx.de> 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 Julian Reschke wrote: > Is this meant to be a serious proposal? It's a serious proposal. Why would you think otherwise? > Why can't ve just leave a > protocol element out if we don't have information for it??? Because it allows someone to assert there is no alternate link for their feed. That's different from leaving an alternate link out. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 11:23:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25770 for ; Mon, 9 May 2005 11:23: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 j49FEaV5071216; Mon, 9 May 2005 08:14: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 j49FEaj4071214; Mon, 9 May 2005 08:14:36 -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 j49FEZXm071203 for ; Mon, 9 May 2005 08:14:36 -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 <2005050915142901200sno7ke>; Mon, 9 May 2005 15:14:30 +0000 Date: Mon, 9 May 2005 09:14:27 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceRenameImageToLogo From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <09155581-C09D-11D9-90F9-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 Not having generated any response by suggesting this without a Pace, I've written a Pace. If a miracle happens and no one denounces this idea as certain to destroy the Atom format (or otherwise gives it a -1), but no one but me gives it a +1, would that be enough to call it the consensus opinion of those who care? http://www.intertwingly.net/wiki/pie/PaceRenameImageToLogo == Abstract == What the "atom:image" element describes is a logo for the feed--let's call it "atom:logo". == Status == New == Rationale == Calling this element "image" provides no benefits over calling it "logo", but does have potential drawbacks: Section 4.2.8 of draft-ietf-atompub-format-08.txt states: The "atom:image" element's content is an IRI reference [RFC3987] which identifies an image which provides visual identification for a feed. The word "logo" more precisely matches this description than the more general term "image". Using the name "image" could lead to confusion if an extension element is introduced for, for example, associating an image with an entry. == Proposal == Change the name of the "atom:image" element to "atom:logo". From owner-atom-syntax@mail.imc.org Mon May 9 11:34:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27043 for ; Mon, 9 May 2005 11:34: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 j49FRs64072337; Mon, 9 May 2005 08:27: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 j49FRsLm072336; Mon, 9 May 2005 08:27:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from 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 j49FRq2j072330 for ; Mon, 9 May 2005 08:27:53 -0700 (PDT) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000103443.msg for ; Mon, 09 May 2005 17:25:23 +0200 In-Reply-To: <427F7DFD.6070807@dehora.net> References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7d1159534bdee6d4c6cf6308167a1c71@greenbytes.de> Cc: Atom Syntax From: Stefan Eissing Subject: Re: PaceNoAlternateForFeed Date: Mon, 9 May 2005 17:27:30 +0200 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.622) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Mon, 09 May 2005 17:25:23 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: atom-syntax@imc.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49FRr2j072331 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Am 09.05.2005 um 17:13 schrieb Bill de hra: >> Why can't ve just leave a protocol element out if we don't have >> information for it??? > > Because it allows someone to assert there is no alternate link for > their feed. That's different from leaving an alternate link out. Does not compute. How is that different for a feed reader? If you say that there is no alternate link for your feed and I make your very feed available through "my" server, does your feed have an alternate link or not? //Stefan From owner-atom-syntax@mail.imc.org Mon May 9 12:00:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29811 for ; Mon, 9 May 2005 12:00: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 j49FoHsX073993; Mon, 9 May 2005 08:50: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 j49FoHeN073992; Mon, 9 May 2005 08:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FoG3I073974 for ; Mon, 9 May 2005 08:50:16 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 61889 messnum 5385505 invoked from network[83.70.217.193/unknown]); 9 May 2005 15:50:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail08.svc.cra.dublin.eircom.net (qp 61889) with SMTP; 9 May 2005 15:50:10 -0000 Message-ID: <427F86AF.1070509@dehora.net> Date: Mon, 09 May 2005 16:50: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 Syntax Subject: Re: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <7d1159534bdee6d4c6cf6308167a1c71@greenbytes.de> In-Reply-To: <7d1159534bdee6d4c6cf6308167a1c71@greenbytes.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Stefan Eissing wrote: > > > Am 09.05.2005 um 17:13 schrieb Bill de hra: > >>> Why can't ve just leave a protocol element out if we don't have >>> information for it??? >> >> >> Because it allows someone to assert there is no alternate link for >> their feed. That's different from leaving an alternate link out. > > > Does not compute. How is that different for a feed reader? Why does it need to be different for a feed reader? > If you say that there is no alternate link for your feed and I make your > very feed available through "my" server, does your feed have an > alternate link or not? We could just as easily argue about all the possible such URLs that might be the case but aren't listed as alternates. Are they alternate links? What about an alternate link I added for the sake of spec, because I have no alternate. Is that an alternate link? Such counterfactuals are fun, but have no bearing here. Currently you MUST provide an alternate feed link. People are saying they don't always have one to provide, which encourages garbage out. That satisfying a spec constraint for its own sake. This addition allows someone to say there is no alternate for this link. It's less ambiguous than not providing an alternate and more useful than providing junk links. Not present is not the same as not the case. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 12:11:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01130 for ; Mon, 9 May 2005 12:11: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 j49G209N074897; Mon, 9 May 2005 09:02: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 j49G20RJ074896; Mon, 9 May 2005 09:02: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 j49G1xVx074875 for ; Mon, 9 May 2005 09:01:59 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 09 May 2005 16:01:52 -0000 Received: from p508FB3F0.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.179.240] by mail.gmx.net (mp005) with SMTP; 09 May 2005 18:01:52 +0200 X-Authenticated: #1915285 Message-ID: <427F8962.9020506@gmx.de> Date: Mon, 09 May 2005 18:01:38 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <7d1159534bdee6d4c6cf6308167a1c71@greenbytes.de> <427F86AF.1070509@dehora.net> In-Reply-To: <427F86AF.1070509@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > ... > Currently you MUST provide an alternate feed link. People are saying > they don't always have one to provide, which encourages garbage out. > That satisfying a spec constraint for its own sake. This addition allows > someone to say there is no alternate for this link. It's less ambiguous > than not providing an alternate and more useful than providing junk > links. Not present is not the same as not the case. > ... How is it "less ambiguous" if the spec states that the absence of the link means that there is no alternate information? Best regards, Julian From owner-atom-syntax@mail.imc.org Mon May 9 12:12:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01249 for ; Mon, 9 May 2005 12:12: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 j49Fxq5V074748; Mon, 9 May 2005 08:59: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 j49FxqaR074747; Mon, 9 May 2005 08:59:52 -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 j49FxnY5074739; Mon, 9 May 2005 08:59:50 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <09155581-C09D-11D9-90F9-003065EA6144@geckotribe.com> References: <09155581-C09D-11D9-90F9-003065EA6144@geckotribe.com> Date: Mon, 9 May 2005 08:59:47 -0700 To: Antone Roundy , atom-syntax@imc.org From: Paul Hoffman Subject: Re: PaceRenameImageToLogo 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 9:14 AM -0600 5/9/05, Antone Roundy wrote: >If a miracle happens and no one denounces this idea as certain to >destroy the Atom format (or otherwise gives it a -1), but no one but >me gives it a +1, would that be enough to call it the consensus >opinion of those who care? No. Consensus means that many active people think it is a good idea. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon May 9 12:26:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02479 for ; Mon, 9 May 2005 12:26: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 j49GHQBV076210; Mon, 9 May 2005 09:17: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 j49GHQ2m076209; Mon, 9 May 2005 09:17: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49GHOO9076199 for ; Mon, 9 May 2005 09:17:25 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2298412wra for ; Mon, 09 May 2005 09:17:18 -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=p8plDbmJra3qkbonFRnccqFFhK3RMZkgDtlYxaMfdX/DSrwN9D80SHkZKG/SGa3gWUKBciCArsurPK32Qv7A6ETf0xhP8Av/MeWGfjCHmjaZQ7f2FvT05OWJsB4BNse8HunVcBeFbTrFaJQfmp2Qtvrc2Tt4eaEcFa6i46ry3rI= Received: by 10.54.79.8 with SMTP id c8mr120401wrb; Mon, 09 May 2005 09:17:18 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 9 May 2005 09:16:29 -0700 (PDT) Message-ID: <68fba5c5050509091656591367@mail.gmail.com> Date: Mon, 9 May 2005 12:16:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceTextShouldBeProvided Cc: Atom Syntax In-Reply-To: <427B8134.4020000@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427B8134.4020000@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49GHQO9076204 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, Bill de hra wrote: > > -1. > > I agree with Robert; it conflicts with PaceOptionalSummary and I doubt > it would exist if PaceOptionalSummary had not make the cut. -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 12:31:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03048 for ; Mon, 9 May 2005 12:31: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 j49GMaeu076505; Mon, 9 May 2005 09:22: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 j49GMaBe076504; Mon, 9 May 2005 09:22:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49GMZXr076498 for ; Mon, 9 May 2005 09:22:36 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j49GMXgv015556 for ; Mon, 9 May 2005 12:22:35 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCV46138 (AUTH bob@wyman.us); Mon, 9 May 2005 12:22:26 -0400 (EDT) Message-Id: <200505091622.DCV46138@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: Which is the preferred feed? Date: Mon, 9 May 2005 12:22:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C55491.C27E37D0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVUs0fpajyA89cUQhWa0LxDXlKiQg== 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_0019_01C55491.C27E37D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. However, many of today's intermediaries require that program participants manage a "base" feed on their own sites that is later copied to the intermediary. This is the approach taken by FeedBurner among others. Whether or not the intermediaries require that a feed be maintained on the site, this is usually required if only because there will be people who are reading the feed and there is no means to notify them, within the feed, that a new "preferred" source of the feeds is available. For instance, the Typepad site blog.deeje.tv has two feeds generated by Typepad: http://blog.deeje.tv/musings/atom.xml http://blog.deeje.tv/musings/index.rdf and it has a feed generated by FeedBurner: http://feeds.feedburner.com/deeje/musings Now, my assumption is that the owner of blog.deeje.tv probably would prefer that people read his FeedBurner feed rather than the TypePad feeds. Evidence of this can be seen in that the autodiscovery links on the page point to the FeedBurner feeds. However, while the links currently point to FeedBurner, they have not always pointed there. At some point in the past, the owner of this blog decided to prefer the FeedBurner service over Typepad for feed services. At some point in the future, the same owner might wish to drop the FeedBurner service in favor of some other service - or perhaps just go back to Typepad normal feeds. The problem, of course, is that there is no existing mechanism by which these changes in preferred feeds can be indicated in either an Atom or RSS file. The result is that any software system that started reading the Atom or RDF feeds provided by Typepad before this blog started using FeedBurner will continue to read the Typepad feeds in the future. Similarly, any system currently reading the FeedBurner feeds is likely to continue reading those feeds in the future. One could argue that feed reading software should, on some regular schedule, re-scan the "alternate" site for a feed to see if the autodiscovery links have changed. However, this is a pretty crude solution. It would be much, much better to allow a feed to contain data that explicitly identifies a "preferred" alternative source. Supporting a means to identify a "preferred" alternative source would greatly improve the mobility of feeds across the network and would avoid the current problem of potentially pinning someone down to a feed delivery service simply because of historical accident. If I want to move my feeds from Typepad to FeedBurner, I should be able to without having to worry about leaving behind everyone who had ever started reading my Typepad feeds. Similarly, if I later decide that I want to move off FeedBurner, there should be a way to point people to the location of my preferred feeds. bob wyman ------=_NextPart_000_0019_01C55491.C27E37D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some sites are beginning to = serve their feeds via intermediaries like FeedBurner. They are doing this, in = part, to make it easier for them to get better statistics on their use of the = feeds, to off-load bandwidth requirements, or to take advantage of the = advertising insertion and management programs of the = intermediaries.

However, many of = today’s intermediaries require that program participants manage a = “base” feed on their own sites that is later copied to the intermediary. This = is the approach taken by FeedBurner among others. Whether or not the = intermediaries require that a feed be maintained on the site, this is usually required = if only because there will be people who are reading the feed and there is no = means to notify them, within the feed, that a new “preferred” source = of the feeds is available.

For instance, the Typepad = site blog.deeje.tv has two feeds generated by = Typepad:

 

http://blog.deeje.tv/musin= gs/atom.xml

http://blog.deeje.tv/musi= ngs/index.rdf

 

and it has a feed generated = by FeedBurner:

 

http://feeds.feedburne= r.com/deeje/musings

 

Now, my assumption is that = the owner of blog.deeje.tv probably would prefer that people read his FeedBurner = feed rather than the TypePad feeds. Evidence of this can be seen in that the autodiscovery links on the page point to the FeedBurner feeds. However, = while the links currently point to FeedBurner, they have not always pointed = there… At some point in the past, the owner of this blog decided to prefer the FeedBurner service over Typepad for feed services. At some point in the = future, the same owner might wish to drop the FeedBurner service in favor of = some other service – or perhaps just go back to Typepad normal = feeds.

The problem, of course, is = that there is no existing mechanism by which these changes in preferred feeds = can be indicated in either an Atom or RSS file. The result is that any software = system that started reading the Atom or RDF feeds provided by Typepad before = this blog started using FeedBurner will continue to read the Typepad feeds in the = future. Similarly, any system currently reading the FeedBurner feeds is likely = to continue reading those feeds in the future.

One could argue that feed = reading software should, on some regular schedule, re-scan the “alternate” = site for a feed to see if the autodiscovery links have changed. However, this is = a pretty crude solution… It would be much, much better to allow a feed to = contain data that explicitly identifies a “preferred” alternative = source.

Supporting a means to = identify a “preferred” alternative source would greatly improve the mobility of feeds across = the network and would avoid the current problem of potentially pinning = someone down to a feed delivery service simply because of historical accident. If I = want to move my feeds from Typepad to FeedBurner, I should be able to without = having to worry about leaving behind everyone who had ever started reading my = Typepad feeds. Similarly, if I later decide that I want to move off FeedBurner, = there should be a way to point people to the location of my preferred = feeds.

 

bob = wyman

 

 

 

 

------=_NextPart_000_0019_01C55491.C27E37D0-- From owner-atom-syntax@mail.imc.org Mon May 9 12:36:33 2005 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 ; Mon, 9 May 2005 12:36: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 j49GS0CT077029; Mon, 9 May 2005 09:28: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 j49GS0aM077028; Mon, 9 May 2005 09:28:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49GRx4Z077003 for ; Mon, 9 May 2005 09:27:59 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 28232 invoked by uid 10); 9 May 2005 16:27:53 -0000 Received: (vexira-qq 28224-F5FFB1AD invoked from network) 09 May 2005 18:27:53 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 May 2005 16:27:53 -0000 Message-ID: <427F8F89.1060107@annevankesteren.nl> Date: Mon, 09 May 2005 18:27:53 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: Which is the preferred feed? References: <200505091622.DCV46138@ms8.netsolmail.com> In-Reply-To: <200505091622.DCV46138@ms8.netsolmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Some sites are beginning to serve their feeds via intermediaries like > FeedBurner. They are doing this, in part, to make it easier for them to get > better statistics on their use of the feeds, to off-load bandwidth > requirements, or to take advantage of the advertising insertion and > management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 9 12:43:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04113 for ; Mon, 9 May 2005 12:43: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 j49GZ8fs077949; Mon, 9 May 2005 09:35: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 j49GZ8ex077948; Mon, 9 May 2005 09:35:08 -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 j49GZ7l3077929 for ; Mon, 9 May 2005 09:35:08 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 38861 messnum 5245996 invoked from network[83.70.217.193/unknown]); 9 May 2005 16:35:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail02.svc.cra.dublin.eircom.net (qp 38861) with SMTP; 9 May 2005 16:35:01 -0000 Message-ID: <427F9132.5040403@dehora.net> Date: Mon, 09 May 2005 17:34: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: Atom Syntax Subject: Re: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <7d1159534bdee6d4c6cf6308167a1c71@greenbytes.de> <427F86AF.1070509@dehora.net> <427F8962.9020506@gmx.de> In-Reply-To: <427F8962.9020506@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Julian Reschke wrote: > Bill de hra wrote: > >> ... >> Currently you MUST provide an alternate feed link. People are saying >> they don't always have one to provide, which encourages garbage out. >> That satisfying a spec constraint for its own sake. This addition >> allows someone to say there is no alternate for this link. It's less >> ambiguous than not providing an alternate and more useful than >> providing junk links. Not present is not the same as not the case. >> ... > > > How is it "less ambiguous" if the spec states that the absence of the > link means that there is no alternate information? It doesn't state that. But that would be logically the same to me. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 12:54:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04957 for ; Mon, 9 May 2005 12:54: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 j49Gkih4079104; Mon, 9 May 2005 09:46: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 j49Gkifm079103; Mon, 9 May 2005 09:46:44 -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 j49Gkh9e079092 for ; Mon, 9 May 2005 09:46:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2320160wra for ; Mon, 09 May 2005 09:46:38 -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=LvOhrxlRjooCHEyCIhLdMJUvBg2X//swlSYdJF7jMSPQY5hNjb9QS2CnicrfCEPBBvKLedD1hou6X3dctMEFfL2kwimq90iEqcA36+Dqw+714XUmqckmbxoPsXrCWogeip7i0LpKfkCWql8qktYrktf1xOEC7s7U2RgaerQxM4E= Received: by 10.54.70.8 with SMTP id s8mr2732470wra; Mon, 09 May 2005 09:46:38 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 9 May 2005 09:43:51 -0700 (PDT) Message-ID: <68fba5c505050909434e9f7a10@mail.gmail.com> Date: Mon, 9 May 2005 12:43:51 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Martin Duerst Subject: Re: PaceOptionalFeedLink Cc: Sam Ruby , Tim Bray , Atom Syntax In-Reply-To: <6.0.0.20.2.20050506184319.067140f0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427ADB61.7010805@intertwingly.net> <6.0.0.20.2.20050506184319.067140f0@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49Gki9e079098 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/6/05, Martin Duerst wrote: > > At 11:50 05/05/06, Sam Ruby wrote: > > > >Tim Bray wrote: > >> +1 > >> There are people who want to publish feeds without rel="alternate" > links. I'm against telling people they can't do something they want to do > without strong reasons, as in loss of interoperability. I don't see the > reasons here as strong enough. -Tim +1 as well. In this case, the problems faced by producers seem to outweigh those faced by consumers. The link doesn't seem to be helpful as an identifier, so that's orthogonal. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 13:01:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05594 for ; Mon, 9 May 2005 13: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 j49GrM2Z079501; Mon, 9 May 2005 09:53: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 j49GrMN9079500; Mon, 9 May 2005 09:53:22 -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 j49GrLgP079474 for ; Mon, 9 May 2005 09:53:21 -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 <2005050916531501200sl640e>; Mon, 9 May 2005 16:53:15 +0000 Date: Mon, 9 May 2005 10:53:14 -0600 Subject: Re: Which is the preferred feed? 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: <427F8F89.1060107@annevankesteren.nl> 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, May 9, 2005, at 10:27 AM, Anne van Kesteren wrote: > Bob Wyman wrote: >> Some sites are beginning to serve their feeds via intermediaries like >> FeedBurner. They are doing this, in part, to make it easier for them >> to get >> better statistics on their use of the feeds, to off-load bandwidth >> requirements, or to take advantage of the advertising insertion and >> management programs of the intermediaries. > > Sites could also use a HTTP 302 link on their own site that points to > FeedBurner in the end. When FeedBurner dies or when they no longer > have desire to use the service, they switch the location of the > temporary redirect and all is fine. This method would have a few weaknesses: 1) From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10: 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. 2) Not everyone is going to be able to send a 302. A 301 would solve the first problem, but replace it with a worse one--there would be no way to indicate a new location to people once they were subscribed to the FeedBurner feed if it were to move again. One solution that might work would be to set the "self" link to the preferred address. That wouldn't provide a way to indicate a preferred format though, if that's part of what's desired. If all formats are being served from the same address using content negotiation, then that doesn't matter. And if they're being served from different addresses, then each feed can point it's "self" link to the preferred address for that format. Are there any issues that couldn't be solved by that method? From owner-atom-syntax@mail.imc.org Mon May 9 13:17:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08078 for ; Mon, 9 May 2005 13:17: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 j49H7ZT0080385; Mon, 9 May 2005 10:07: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 j49H7ZU9080384; Mon, 9 May 2005 10:07:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49H7YLW080370 for ; Mon, 9 May 2005 10:07:34 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 30979 invoked by uid 10); 9 May 2005 17:07:28 -0000 Received: (vexira-qq 30971-798D3E5C invoked from network) 09 May 2005 19:07:28 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 May 2005 17:07:28 -0000 Message-ID: <427F98D0.60307@annevankesteren.nl> Date: Mon, 09 May 2005 19:07:28 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Which is the preferred feed? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > 302 would result in feed readers (that follow the HTTP spec) continuing > to hit the publisher's site every time they checked the feed, and then > going to FeedBurner. As it would not be a very large hit of say, 25 to 50 KiB; I guess people can live with that. > 2) Not everyone is going to be able to send a 302. Not everyone is going to be able to send 410 either. Not everyone is going to be able to say that the MIME type is application/atom+xml (yes, I'm aware about the deal with Apache and Microsoft). Et cetera. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 9 13:19:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08348 for ; Mon, 9 May 2005 13:19: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 j49H2H8E080071; Mon, 9 May 2005 10:02: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 j49H2Hna080070; Mon, 9 May 2005 10:02:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49H2Gp2080055 for ; Mon, 9 May 2005 10:02:17 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j49H0U5x027649; Mon, 9 May 2005 18:00:38 +0100 (BST) In-Reply-To: <200505091622.DCV46138@ms8.netsolmail.com> References: <200505091622.DCV46138@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Cc: atom-syntax From: Graham Subject: Re: Which is the preferred feed? Date: Mon, 9 May 2005 18:00:32 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49H2Hp2080065 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 9 May 2005, at 5:22 pm, Bob Wyman wrote: > However, many of todays intermediaries require that program > participants manage a base feed on their own sites that is later > copied to the intermediary. This is the approach taken by > FeedBurner among others. Whether or not the intermediaries require > that a feed be maintained on the site, this is usually required if > only because there will be people who are reading the feed and > there is no means to notify them, within the feed, that a new > preferred source of the feeds is available. Why can't they use an HTTP redirect like everyone else? They can then publish the base feed from a private address. Graham From owner-atom-syntax@mail.imc.org Mon May 9 13:30:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09438 for ; Mon, 9 May 2005 13:30: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 j49HKs7F081758; Mon, 9 May 2005 10:20: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 j49HKsIY081757; Mon, 9 May 2005 10:20:54 -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 j49HKsbp081751 for ; Mon, 9 May 2005 10:20:54 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 87842 invoked by uid 17064); 9 May 2005 17:20:53 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.8.212]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 9 May 2005 17:20:53 -0000 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax Syntax From: Henry Story Subject: PaceDuplicateIds and archive formats Date: Mon, 9 May 2005 19:20:51 +0200 X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have just had a wicked thought regarding PaceDuplicateIds. One of the main motives, as I understand it, against PaceDuplicateIds is that this does not allow one to know what the current state of the Entry is. I don't think that not allowing duplicate entries with the same id is the solution to the problem. The best solution to the problem is simply not to put any content at all in feed, but to point to a web resource that does. Since you can always only retrieve a web resource in the present, you can only get the latest of such an entry. Furthermore this would be a lot more restful, and dramatically reduce the size of downloads, using all the resources of the web, caches and all, the way they are meant to be used. A feed would then look something like this: Example Feed 2003-12-13T18:30:02Z John Doe urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 2003-12-13T18:30:02Z urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b 2003-12-13T18:30:02Z The more content appears in an entry found in a feed, the more it turns into an archive format. Perhaps this is where some of the disagreements or misunderstandings are stemming from. Henry Story http://bblfish.net/blog/ From owner-atom-syntax@mail.imc.org Mon May 9 13:33:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09825 for ; Mon, 9 May 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 j49HP8HV082122; Mon, 9 May 2005 10:25: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 j49HP8vA082118; Mon, 9 May 2005 10:25:08 -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 j49HP3W5082109 for ; Mon, 9 May 2005 10:25:03 -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 j49HP3i7011315 for ; Mon, 9 May 2005 11:25:03 -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 <0IG800168GDQH8@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 09 May 2005 11:25:03 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG800AM7GDPTI@mail.sun.net> for atom-syntax@imc.org; Mon, 09 May 2005 11:25:02 -0600 (MDT) Date: Mon, 09 May 2005 10:26:10 -0700 From: Tim Bray Subject: Re: PaceNoAlternateForFeed In-reply-to: <427F7DFD.6070807@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom Syntax Message-id: <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49HP3W5082110 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 9, 2005, at 8:13 AM, Bill de hra wrote: >> Why can't ve just leave a protocol element out if we don't have >> information for it??? > > Because it allows someone to assert there is no alternate link for > their feed. That's different from leaving an alternate link out. What observable difference in the behavior of software would be affected by this difference? It's not obvious to me that there's a meaningful difference. -Tim From owner-atom-syntax@mail.imc.org Mon May 9 13:36:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10078 for ; Mon, 9 May 2005 13:36: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 j49HTjdt082479; Mon, 9 May 2005 10:29: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 j49HTjKl082478; Mon, 9 May 2005 10:29:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49HTjx5082472 for ; Mon, 9 May 2005 10:29:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j49HTeqv011934; Mon, 9 May 2005 13:29:42 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DCV77807 (AUTH bob@wyman.us); Mon, 9 May 2005 13:29:39 -0400 (EDT) Message-Id: <200505091729.DCV77807@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Anne van Kesteren'" , Cc: Subject: RE: Which is the preferred feed? Date: Mon, 9 May 2005 13:29:38 -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.1441 Thread-Index: AcVUtBhkP25C2p/bRRetgCP/Ik83IgAAtZPw In-Reply-To: <427F8F89.1060107@annevankesteren.nl> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > Sites could also use a HTTP 302 link on their own site that points > to FeedBurner in the end. When FeedBurner dies or when they no longer > have desire to use the service, they switch the location of the > temporary redirect and all is fine. While 302 is an obvious technical solution, it just doesn't do the job. HTTP's 302 is just a bit too absolute... For instance, if I'm trying to push people from my Atom 0.3 feed to my Atom V1.0 feed, it is likely that there will be many readers who don't know how to process Atom V1.0 correctly -- at least initially. They should be free to fallback to the Atom 0.3 feed until they learn the new format. Similarly, if I have readers who use one of the MAC based readers that only read RSS, it becomes problematic to force them to read my Atom V1.0 feeds... It should also be noted that the ability to change HTTP response codes is not something which is typically provided to many bloggers today. I'm aware of no blog hosting services that allow for "customer-requested 302" status values. Even on the one-user systems, I think its pretty hard for normal folk to figure out how to make the modifications needed to return a 302 for some files. We should also realize that business issues are likely to make it difficult for people to use 302-based solutions. For instance, a site that provided intermediary feed serving might not wish to make it easy for people to migrate their feeds away from their service. They might *like* the idea that switching costs are very high... Thus, they might simply refuse (on some technical grounds) to allow users who are moving to a new service to get 302-forwarding on their feeds. On the other hand, if the Atom format itself contained a means of redirecting to preferred feeds, and if the spec said that such data "MUST NOT" be removed when a feed is copied, etc., then one could essentially force vendors to support feed mobility. (Yes, there would be loop-holes) Normally, I wouldn't argue for replicating an HTTP feature inside the feeds, however, I think that what I'm talking about here is not really what 302 was intended to provide. In any case, this may be looked at as a layering issue. 302 provides hard redirection at the HTTP level, a "preferred" feed indicator provides soft-redirection at the application level. Implementation of similar services in multiple layers of the stack is a reasonable thing to do as long as the semantics vary at least slightly between the layers and the reasons for the variances are related to the nature of the layers. bob wyman From owner-atom-syntax@mail.imc.org Mon May 9 13:39:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10454 for ; Mon, 9 May 2005 13: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 j49HVtGW082688; Mon, 9 May 2005 10:31: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 j49HVtG4082687; Mon, 9 May 2005 10:31:55 -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 j49HVssp082678 for ; Mon, 9 May 2005 10:31:54 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2348657wra for ; Mon, 09 May 2005 10:31:48 -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=BXZeJOtw0ok4OEVJu8d64Lzkxk6SWnR2u/WePYAEczE+au6s8aA8pgTfaoLi5fMuVM5HsBM59IMfI24zIH1NDH/p4m1TW5DXM45QferVPwyyYYraz1p3gUVe3uXObbkNRYC1Z1k/JUGu98zKtKiUt0i9AVpth/psEGdj2yJhLyY= Received: by 10.54.30.40 with SMTP id d40mr2754205wrd; Mon, 09 May 2005 10:31:48 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 10:31:47 -0700 (PDT) Message-ID: <68fba5c5050509103155337401@mail.gmail.com> Date: Mon, 9 May 2005 13:31:48 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: On SHOULD 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 j49HVssp082682 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Off-list, I've been told some it would help to explain my view that PaceTextShouldBeProvided and PaceOptionalSummary are incompatible. --------------------------------------- First, remember that PaceOptionalSummary does one thing--make content/summary optional. This means that Atom Processors MUST be prepared to interoperate with title-only feeds. It doesn't mean an _application_ has to accept them. It does mean that application authors can't claim it breaks their Atom machinery. We don't care what applications do after something is parsed. They can turn everything purple and display it with polar coordinates. Let's start with the current draft's requirements: 1 of atom:content or atom:summary MUST be present. That's clear. It means that say, Jakarta FeedParser, could halt and catch fire if it encountered an atom:entry missing both elements. PaceOptionalSummary dismissed the requirement entirely, as its only action. Jakarta FeedParser would have to be prepared to deal with title-only feeds. --------------------------------------- Here's where SHOULD comes in. We're lucky that we have an example of what happens when a SHOULD is violated. I'm sure most of you saw the nasty arguments, accusations, and all-around busted software that happen this week with Google Web Accelerator and Ruby On Rails.[0] Ugly, right? This WG should be proud that we've kept the SHOULDs to a minimum. PaceTextShouldBeProvided proposes a number of (IMO) misguided a requirements in effort to reverse the effect of PaceOptionalSummary. It proposes that "" is threat to interop while " " is not. It makes similar claims for a number of other situations. It does reasonably propose that application-specific atom:content SHOULD have an accompanying summary. Lastly, it makes this requirement: 1 of atom:content or atom:summary SHOULD be present. It means that say, Jakarta FeedParser, could halt and catch fire if it encountered an atom:entry missing both elements and remain conformant. It does allow for the possibility of a parser that can handle it. That's not what PaceOptionalSummary proposed. The discussion has heard from application authors and publishers who value the ability to choose title-only feeds. That choice *does not* cause breakage, as every existing format and processor demonstrate. PaceTextShouldBeProvided loses the running code argument by an even wider margin than it loses elsewhere. Robert Sayre [0] http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html From owner-atom-syntax@mail.imc.org Mon May 9 13:57:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11847 for ; Mon, 9 May 2005 13:57: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 j49Hn3uZ084009; Mon, 9 May 2005 10:49: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 j49Hn3VK084008; Mon, 9 May 2005 10:49:03 -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 j49Hn2oU083981 for ; Mon, 9 May 2005 10:49:02 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 52924 messnum 6386019 invoked from network[83.70.217.193/unknown]); 9 May 2005 17:48:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 52924) with SMTP; 9 May 2005 17:48:56 -0000 Message-ID: <427FA284.5000007@dehora.net> Date: Mon, 09 May 2005 18:48: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: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> In-Reply-To: <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > On May 9, 2005, at 8:13 AM, Bill de hra wrote: > >>> Why can't ve just leave a protocol element out if we don't have >>> information for it??? >> >> >> Because it allows someone to assert there is no alternate link for >> their feed. That's different from leaving an alternate link out. > > > What observable difference in the behavior of software would be affected > by this difference? It's not obvious to me that there's a meaningful > difference. -Tim The difference is in what can be concluded from the data, ie it's a 3-valued logic problem. Does the absence mean there's no alternate? Does it mean don't unknown? Do we need to care? I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 13:57:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11865 for ; Mon, 9 May 2005 13:57: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 j49HocoM084067; Mon, 9 May 2005 10:50: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 j49HocSW084066; Mon, 9 May 2005 10:50:38 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49HobiG084059 for ; Mon, 9 May 2005 10:50:37 -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); Tue, 10 May 2005 03:50:37 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 03:50:13 +1000 Subject: Re: PaceFeedIdOrSelf 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 10/5/05 12:50 AM, "Antone Roundy" wrote: > I didn't change the Pace, since such a change could conceivably change > the opinions of people who've expressed an opinion on it already. But > I would be interested to know whether people think this would be an > improvement, make it worse, or if either is just as well. +1, an improvement e. From owner-atom-syntax@mail.imc.org Mon May 9 14:19:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13980 for ; Mon, 9 May 2005 14:19: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 j49I5g8P084998; Mon, 9 May 2005 11: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 j49I5g2A084997; Mon, 9 May 2005 11:05: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49I5bul084959 for ; Mon, 9 May 2005 11:05:39 -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); Tue, 10 May 2005 04:05:29 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 03:51:38 +1000 Subject: Re: PaceRenameImageToLogo From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <09155581-C09D-11D9-90F9-003065EA6144@geckotribe.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/5/05 1:14 AM, "Antone Roundy" wrote: > http://www.intertwingly.net/wiki/pie/PaceRenameImageToLogo +1 From owner-atom-syntax@mail.imc.org Mon May 9 16:52:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10154 for ; Mon, 9 May 2005 16:52: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 j49KheYK000350; Mon, 9 May 2005 13:43: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 j49KhehB000349; Mon, 9 May 2005 13:43: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49KhdKJ000340 for ; Mon, 9 May 2005 13:43:39 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2461698wra for ; Mon, 09 May 2005 13:43:33 -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=TyPnk/DyCPwkPvXXBq6hIb0CZm6ljAbsI/vpD61zr3pKjVaZ63dnSMUqbXDyhsz12dTg8jFgg31R4JfyyFSBFrSx5oSyg2bX1Q8E7OXhi4rtGkXJwoqIRDwXlKRdZhjRhA98gk7jtddhlQrpkqUt+Af/HGo9h8rWri80FCwC4f4= Received: by 10.54.31.57 with SMTP id e57mr22657wre; Mon, 09 May 2005 13:43:31 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 13:43:30 -0700 (PDT) Message-ID: <68fba5c5050509134359c7055a@mail.gmail.com> Date: Mon, 9 May 2005 16:43:30 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby , Graham Subject: Fwd: PaceOptionalSummary Cc: Atom Syntax In-Reply-To: <427F65DA.1050106@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> <427F65DA.1050106@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49KhdKJ000344 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Guys! Did you see this email? Did you notice all the questions about the technical basis of your position? Maybe you should answer them. Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different? Robert Sayre On 5/9/05, Bill de hra wrote: > I think, more or less, that PaceTextShouldBeProvided only exists because > PaceOptionalSummary has not been successfully dismissed. I have no idea > why title-only feeds are unfortunate, are an interoperability problem, > or an accessibility problem. In fact I felt we had put the accessibility > issue to bed weeks ago, but it popped up again in the > PaceTextShouldBeProvided's rationale. > > > > One thing I would like those who advocate PaceOptionalSummary to the > > exclusion of all other Paces on the subject to consider... what happens > > if the chairs determine that consensus can't be found on either of these > > paces? Look at the current wording of draft-08. Is that what you > > really want? > > If the chairs count it up, I think they could find consensus. I think > they could have done that a fortnight ago. Or last week. I agree with > Robert's paraphrasing, that we are drowning in +1s. And I fail to > understand why this has been dragged out so long. There are a few > strongly voiced objections, but is that sufficient reason to grind this > one out? > > > We can do better. > > I started out 0 and moved to +1 based on the arguments I saw presented > for and against PaceOptionalSummary and my own thinking. I'm -1 on > PaceTextShouldBeProvided, and have explained why. I honestly don't know > how I can do any better on this. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Mon May 9 17:14:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12260 for ; Mon, 9 May 2005 17:14: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 j49L4wMh001807; Mon, 9 May 2005 14:04: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 j49L4w7P001806; Mon, 9 May 2005 14:04:58 -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 j49L4vWF001791 for ; Mon, 9 May 2005 14:04:57 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2474245wra for ; Mon, 09 May 2005 14:04:51 -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=tFqo+u0Vl6kyUuvT0VYHfVqWdyAaWiSj0/SMYdZZtHokcIOpVgdB6gXG9SVgOJsF84LldqTx79vIox8Dddm0pBmMxwdZewG3XTFfCS0NsIAf5qEuq1uqCGd684xQBvT0Mu3pdBOzCJbhKL4i6zZdl6LyzhSPl3oZSyf7jAJnVCk= Received: by 10.54.41.39 with SMTP id o39mr31109wro; Mon, 09 May 2005 14:04:51 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 14:04:51 -0700 (PDT) Message-ID: <68fba5c50505091404161e84ee@mail.gmail.com> Date: Mon, 9 May 2005 17:04:51 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: atom-syntax@imc.org, Mark Nottingham , Robert Sayre In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49L4vWF001800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Sam Hartman wrote: > At least based on the discussion the IESG has been copied on, it > doesn't sound like the working group has fully considered this issue. > The responses have more of the character of those found from people > trying to brush aside an issue than of people who have carefully > considered something and concluded there is nothing to be done. > > Moreover, thisn issue cannot be unique to atom: it must effect many > XML based protocols both within the IETF and within other standards > organizations. Martin, I agree with Sam on both points. Can you give us an example of an XML format that successfully deals with your issue? Does XHTML differ from Atom? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 17:33:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14259 for ; Mon, 9 May 2005 17:33: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 j49LQ75M003236; Mon, 9 May 2005 14:26: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 j49LQ7oi003235; Mon, 9 May 2005 14:26:07 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49LQ6cD003213 for ; Mon, 9 May 2005 14:26:06 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.32.176]) by smtp.cegetel.net (Postfix) with ESMTP id 4E2321A4B47 for ; Mon, 9 May 2005 23:25:47 +0200 (CEST) Message-ID: <427FD584.5080407@cegetel.net> Date: Mon, 09 May 2005 23:26:28 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: the "atom:copyright" element References: <0B66B9A9-C098-11D9-90F9-003065EA6144@geckotribe.com> In-Reply-To: <0B66B9A9-C098-11D9-90F9-003065EA6144@geckotribe.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 Antone Roundy wrote: > > On Sunday, May 8, 2005, at 10:08 AM, Tim Bray wrote: > >> On May 7, 2005, at 3:29 PM, Robin Cover wrote: >> >>> The publication of a new Implementation Guideline by the >>> Open Archives Initiative (OAI) compels me to suggest once >>> again [1], as Norm Walsh [2], Bob Wyman [3], and others have >>> done before, that the name 'atom:rights' would be better >>> than the (current) element name 'atom:copyright'. >> >> >> +1 > > > +1 from me too. > +1 as well. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 9 17:39:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14731 for ; Mon, 9 May 2005 17:39: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 j49LXiL9004008; Mon, 9 May 2005 14:33: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 j49LXi6V004007; Mon, 9 May 2005 14:33:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49LXhvq003998 for ; Mon, 9 May 2005 14:33:44 -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 (rwcrmhc11) with SMTP id <2005050921333701300hf29ie>; Mon, 9 May 2005 21:33:37 +0000 Date: Mon, 9 May 2005 15:33:36 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <68fba5c5050509134359c7055a@mail.gmail.com> Message-Id: <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49LXivq004002 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Monday, May 9, 2005, at 02:43 PM, Robert Sayre wrote: > Did you see this email? Did you notice all the questions about the > technical basis of your position? Maybe you should answer them. > > Also, I'm having trouble reconciling your road lying with the > assertion that the two proposals are compatible. How can they be if > their outcomes are so different? The change to the spec text proposed by PaceOptionalSummary would also be made by PaceTextShouldBeProvided. In that way, they are compatible. The intents of the authors in writing them was different. In that way, they are incompatible. The intents of people who gave them +1 are not 100% clear. My interpretation is that if someone gave PaceOptionalSummary a +1, but not PaceTextShouldBeProvided, then their intent is close to the author of PaceOptionalSummary. If they gave both a +1, then either they could live with either MAY or SHOULD in the proposed change to section 4.1.2, or their intent is close to the author of PaceTextShouldBeProvided (and they consider the two basically compatible for the reason noted above--ie. looking at the proposed changes to the spec, and not worrying about the authors' intents). I'm in the former group--okay with either MAY or SHOULD. I'd lean more toward SHOULD if we were to come up with a good way to say "if there's content, but it's not in atom:content in one of our three special formats, then there SHOULD be a summary"--in other words, if one of the following applies: * atom:content/@type is a MIME type rather than "text", "html" or "xhtml" * there is no atom:content, and some extension element holds the core content of the entry Note that I don't list "no atom:content and no extension element holding the content"...that's where I lean towards MAY, because to me, the biggest reason for strongly encouraging the use of atom:summary is accessibility. If there's no atom:content or substitute element, then nobody is less able to access the content of the entry than anyone else, because there is no "content" outside of the metadata elements. The problem with the above is that bullet point #2 isn't checkable without agreement on what constitutes a core-content-holding-extension-element. I don't even want to try to come up with language to describe that--I've participated in this group too long to be that foolish. > On 5/9/05, Bill de hra wrote: >> I think, more or less, that PaceTextShouldBeProvided only exists >> because >> PaceOptionalSummary has not been successfully dismissed. I have no >> idea >> why title-only feeds are unfortunate, are an interoperability problem, >> or an accessibility problem. In fact I felt we had put the >> accessibility >> issue to bed weeks ago, but it popped up again in the >> PaceTextShouldBeProvided's rationale. I have no problem with title only feeds. I myself would be far less likely to subscribe to them--or at least they'd have to have extraordinarily well-written, informative titles for me to subscribe to them in just about all cases--but there are certainly valid uses for them. From owner-atom-syntax@mail.imc.org Mon May 9 18:17:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18674 for ; Mon, 9 May 2005 18:17: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 j49M9tXD006829; Mon, 9 May 2005 15:09: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 j49M9tsY006828; Mon, 9 May 2005 15:09:55 -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 j49M9seG006814 for ; Mon, 9 May 2005 15:09:54 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so3096073wri for ; Mon, 09 May 2005 15:09:48 -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=VJ32WyCVW7pSHraylY31I8ncMfGVKxCWQCZEQdXgSATO962hz3mboABmVevx2dQULtg+TdZSAE/G6tqlWgLsAG/wVaR1OREs2vUWb+X2FZp5ObXCVtHbBxMzC54TIEqEGhS/2o7Szj0zjPWHz1GnbvNOzgDehQ/IYpGh3V76DEU= Received: by 10.54.139.7 with SMTP id m7mr57727wrd; Mon, 09 May 2005 15:08:48 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Mon, 9 May 2005 15:08:48 -0700 (PDT) Message-ID: <540e373205050915086344bae4@mail.gmail.com> Date: Mon, 9 May 2005 17:08:48 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: PaceOptionalSummary In-Reply-To: <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49M9seG006822 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Mon May 9 18:23:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19365 for ; Mon, 9 May 2005 18:23: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 j49MG5hU007476; Mon, 9 May 2005 15:16: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 j49MG5vZ007475; Mon, 9 May 2005 15:16: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49MG56B007460 for ; Mon, 9 May 2005 15:16:05 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2507257wra for ; Mon, 09 May 2005 15:15: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=SGTsTw6+ZeU8zALLzBe7odKbjKrJR8LxbxX3ADRQr5K3JDJs4U9lhobOnGKTbQzFTu55DLtf7ZHiusD6XnSrJmWKh+YdgVl+gSC7dhR7ao824/iyz4zsn7RZZVdLjvDO4hol1qcBbWI+QjmdUw5AUz5OBrNpBuqAI9VrPsOZ8tc= Received: by 10.54.110.12 with SMTP id i12mr59469wrc; Mon, 09 May 2005 15:15:03 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 15:15:03 -0700 (PDT) Message-ID: <68fba5c5050509151525190e9d@mail.gmail.com> Date: Mon, 9 May 2005 18:15:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: PaceOptionalSummary Cc: atom-syntax@imc.org In-Reply-To: <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49MG56B007470 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Antone Roundy wrote: > > I have no problem with title only feeds. I myself would be far less > likely to subscribe to them--or at least they'd have to have > extraordinarily well-written, informative titles for me to subscribe to > them in just about all cases--but there are certainly valid uses for > them. Do you expect a conformant Atom Processor, such as Jakarta FeedParser, to successfully process title-only feeds? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 18:32:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20157 for ; Mon, 9 May 2005 18:32: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 j49MQiDs007907; Mon, 9 May 2005 15:26: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 j49MQiWP007906; Mon, 9 May 2005 15:26:44 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49MQhVu007897 for ; Mon, 9 May 2005 15:26:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2511435wra for ; Mon, 09 May 2005 15:26:37 -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=HS3HFCnBr4wDsetrVpXLkssNDdXsHorRVZmjC8s579tj5dXJMI0nvSdOKrZkY7kZcgFwqN9FI+FqQkbZi7gcB7GNevnaXkVQbNKin8c7Pj8u7x8/ldEl2X7xqTChpVzXnqXkQe0cTVM2kTKVgoxR6JOX82Difqeh0fiChka2vtA= Received: by 10.54.13.23 with SMTP id 23mr64055wrm; Mon, 09 May 2005 15:24:53 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 15:24:53 -0700 (PDT) Message-ID: <68fba5c505050915242ab4c20e@mail.gmail.com> Date: Mon, 9 May 2005 18:24:53 -0400 From: Robert Sayre Reply-To: Robert Sayre To: "Roger B." Subject: Re: PaceOptionalSummary Cc: atom-syntax@imc.org In-Reply-To: <540e373205050915086344bae4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49MQhVu007901 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Roger B. wrote: > > > I have no problem with title only feeds. > > I'm -1 on POS, although I wouldn't describe myself as being positioned > in the path of oncoming traffic. > > Title-only feeds have valid uses, but they're really out of scope for > a feed format that only exists because it provides a clearer, cleaner > way to deliver content. Roger, please don't see this as an attack. Here's our charter: ---------------------------------- The format must be able to represent: ... * a feed or channel of entries, with or without enclosed content ... ---------------------------------- I don't think there's a scope argument here. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 18:56:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22488 for ; Mon, 9 May 2005 18:56: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 j49Mo89o009110; Mon, 9 May 2005 15:50: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 j49Mo8Rx009109; Mon, 9 May 2005 15:50:08 -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 j49Mo0wj009101; Mon, 9 May 2005 15:50:01 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> Date: Mon, 9 May 2005 15:49:38 -0700 To: iesg@ietf.org, Atom WG From: Paul Hoffman Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 9:33 AM -0400 5/9/05, Sam Hartman wrote: >My personal opinion as someone who is very shortly going to have to >evaluate the atom specification is that you've identified an issue >(space and line breaking) for some languages that should be >considered. Your proposed solution seems highly undesirable in that >it requires us to understand the language of the text being displayed. >In the past we've had all sorts of problems doing that. Your proposed >solution also seems quite complicated. Fully agree. Please note the text in the spec we are working from: If the value is "text", the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white-space (including line-breaks), and display the text using typographic techniques such as justification and proportional fonts. FWIW, this appears twice, identically, in the spec. Martin Drst brought up CJK (well, actually CJT), saying that they don't use inter-word spacing. That's fine, but it is irrelevant to the text in the draft. If some text comes through with no spaces, there is no white space to collapse. His argument that some XML editors make long lines of text difficult to edit is clearly *way* out of scope for Atom, or any other XML-using protocol for that matter. >It may well be that the solutions to this problem are worse than the >problem itself. However I think it is important to specifically >understand that is the case rather than failing to solve the problem >because we failed to understand it. The "case" is that text that is supposed to be read by humans comes in many forms, with different line lengths, and so on. The paragraph from the spec says that Atom processors may alter these so that they can be presented better for the reader. Of course, they may also alter it to make it less readable, as many mail user agents do (). Regardless, this says that the Atom processor is free to present things in text constructs in any fashion it deems suitable. This is particularly important for making Atom content accessible; for example, the Atom processor can use this rule to present text content by reading it aloud, by putting it on a screen greatly magnified one character at a time, and so on. >At least based on the discussion the IESG has been copied on, it >doesn't sound like the working group has fully considered this issue. >The responses have more of the character of those found from people >trying to brush aside an issue than of people who have carefully >considered something and concluded there is nothing to be done. Sorry, but that's unfair. Alexy asked "Ok, maybe it is just me, but what does it mean to "collapse white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a single space?" Martin's response was orthogonal: "Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words." The rest of the thread wandered into the weeds because it was hard to figure out what was being discussed. >Moreover, thisn issue cannot be unique to atom: it must effect many >XML based protocols both within the IETF and within other standards >organizations. Any protocol that has XML that includes human-readable text has this issue. Well, the processors of that XML does; the protocols themselves do not. >Anyway as someone evaluating atompub's output it would be very useful >if the working group responded to this last call comment. IN my mind >a response would start with a researched description of the issue: >either confirm that Chinese and Japanese and Thai tools work as >described or explain how they actually work. Then describe what other >standards have done about this problem. Finally describe what atompub >has done about the problem and why. > >I'm not asking for a lot of text; probably something about as long as >this message. I believe that it can be a lot shorter: given the rationale above, it's not a problem for Atompub or any other XML-using protocol. For that matter, it's not really and XML problem at all: it affects text formats like HTML and RFC 2822 as well. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon May 9 19:17:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25696 for ; Mon, 9 May 2005 19: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 j49N82sn010211; Mon, 9 May 2005 16:08: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 j49N82wJ010210; Mon, 9 May 2005 16:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49N80QT010151 for ; Mon, 9 May 2005 16:08:01 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j49N5NJD000307; Tue, 10 May 2005 00:05:44 +0100 (BST) In-Reply-To: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> References: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27F7A1C0-C72D-4274-AAA8-B26C45F13EF1@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceFeedIdOrSelf Date: Tue, 10 May 2005 00:05:22 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote: > And add this bullet point: > > * atom:feed elements that contain no child atom:id element MUST > contain an atom:link element with a relation of "self". rel="self" is in no way a substitute for an identifier and shouldn't be presented as such, the way this text does. If the intent is to require an identifier, we should just require atom:id. -1 Graham From owner-atom-syntax@mail.imc.org Mon May 9 19:18:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25841 for ; Mon, 9 May 2005 19:18: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 j49NCSfs010429; Mon, 9 May 2005 16:12: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 j49NCSTI010428; Mon, 9 May 2005 16:12:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NCQgT010418 for ; Mon, 9 May 2005 16:12:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j49NAZ8O001630; Tue, 10 May 2005 00:10:35 +0100 (BST) In-Reply-To: <427FA284.5000007@dehora.net> References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> <427FA284.5000007@dehora.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: atom-syntax From: Graham Subject: Re: PaceNoAlternateForFeed Date: Tue, 10 May 2005 00:10:33 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49NCRgT010422 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 9 May 2005, at 6:48 pm, Bill de hra wrote: > I think this exercise is *critical* for any piece of markup that is > going to move from mandatory to optional. Either way, we should pin > down spec language around the optionality of alternate feed links, > or consciously decide we're not going to pin it down. So you wouldn't support a proposal that removed a required element without explaining what it's absence meant (eg PaceAtomSummary), because you'd prefer one that leaves it much less ambiguous (eg PaceTextShouldBeProvided, which strongly encourages publishers to only omit atom:summary when none exists)? > The difference is in what can be concluded from the data, ie it's a > 3-valued logic problem. Does the absence mean there's no > alternate? Does it mean don't unknown? Do we need to care? Answer Tim's question: "What observable difference in the behavior of software would be affected by this difference?" Graham From owner-atom-syntax@mail.imc.org Mon May 9 19:40:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27738 for ; Mon, 9 May 2005 19: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 j49NWoIA011655; Mon, 9 May 2005 16:32: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 j49NWo11011654; Mon, 9 May 2005 16:32:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NWnqe011648 for ; Mon, 9 May 2005 16:32:49 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from nameko.campusclub.princeton.edu ([140.180.135.3] helo=[192.168.0.223]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DVHjx-0006vW-Kx for atom-syntax@imc.org; Mon, 09 May 2005 19:32:45 -0400 Message-ID: <427FF31E.1060504@inkedblade.net> Date: Mon, 09 May 2005 19:32:46 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <605EF059B8737EC84E00239B@Wunders-Computer.local> <70478bc828782710dbb5b0bdb053626c@iki.fi> In-Reply-To: <70478bc828782710dbb5b0bdb053626c@iki.fi> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > On May 8, 2005, at 06:30, Walter Underwood wrote: > >> White space is not particularly meaningful in some of these languages, >> so we cannot expect them to suddenly pay attention to that just so >> they can use Atom. > > Why not? We expect them not no insert other random characters there. > What do the same producers do with XHTML? Opera 7.53 and Safari 1.3 > render a space between the second and third Kanji in > http://hsivonen.iki.fi/test/cjk-whitespace.xhtml See also Ishida's tests: http://www.w3.org/International/tests/results/white-space-ideograph Special handling of white-space in CJK context is accounted for in the CSS2.1 spec (and will be described in more detail in CSS3 Text). >> There will be plenty of content from other formats >> with this linguistically meaningless white space. > > Why not just get rid of it in the producer end like you have to get rid > of form feeds? Because form feeds are normally not used in source code files whereas line breaks and indendation often are? ~fantasai From owner-atom-syntax@mail.imc.org Mon May 9 19:55:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28901 for ; Mon, 9 May 2005 19:55: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 j49NlAgS012213; Mon, 9 May 2005 16:47: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 j49NlAx7012212; Mon, 9 May 2005 16:47:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49Nl9v5012204 for ; Mon, 9 May 2005 16:47:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 79679 messnum 2874892 invoked from network[83.70.217.193/unknown]); 9 May 2005 23:47:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail09.svc.cra.dublin.eircom.net (qp 79679) with SMTP; 9 May 2005 23:47:03 -0000 Message-ID: <427FF673.2070203@dehora.net> Date: Tue, 10 May 2005 00:46:59 +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: PaceNoAlternateForFeed References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> <427FA284.5000007@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham wrote: > On 9 May 2005, at 6:48 pm, Bill de hra wrote: > >> I think this exercise is *critical* for any piece of markup that is >> going to move from mandatory to optional. Either way, we should pin >> down spec language around the optionality of alternate feed links, or >> consciously decide we're not going to pin it down. > > > So you wouldn't support a proposal that removed a required element > without explaining what it's absence meant (eg PaceAtomSummary), > because you'd prefer one that leaves it much less ambiguous (eg > PaceTextShouldBeProvided, which strongly encourages publishers to only > omit atom:summary when none exists)? I'm not surprised at this line of thought since there is also another dicussion going on around optional summaries. You're jumping the gun though and/or possibly trying to pin me into some kind of non-existent corner - fair enough. What I would like is that we at least discuss the consequences of making non-optional things optional on the data beynd some people can't supply meaningful alternates - I happen to be one of those people btw, if I haven't said it already. And some consistency of debate around loosening constraints is good I think. Finally, there is an important distinction between the two cases (optional alternates and optional summaries). >> The difference is in what can be concluded from the data, ie it's a >> 3-valued logic problem. Does the absence mean there's no alternate? >> Does it mean don't unknown? Do we need to care? > > > Answer Tim's question: "What observable difference in the behavior of > software would be affected by this difference?" I can have nullable columns in my database depending on what we decide to do here. That affects the behaviour of my SQL queries and depending. I can can constrain the search for alternates in a nypertext graph if I know the author is saying there is no alternate. That affects (massively in some cases) the behaviour of an RDF query backend among other things. similar arguments can be made for search systems that are working off raw indexes. I can send the message "there is no alternate for this feed" or "no alternate was provided for this feed" or "no alternate was found for this feed" depending on what we decide to do here. Is that enough? Do you see that the point of this pace is to shine some light on what we're doing here? Btw, I'm 0 on PaceNoAlternateForFeed - like I said, I have feeds that have no real alternates. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 9 19:55:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28939 for ; Mon, 9 May 2005 19:55: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 j49Nmevd012254; Mon, 9 May 2005 16:48: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 j49Nmer7012253; Mon, 9 May 2005 16:48: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49Nmddc012247 for ; Mon, 9 May 2005 16:48:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2545543wra for ; Mon, 09 May 2005 16:48:34 -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=U8R//p4XeaSMG8iBBRUGZEYWgRoPbUiNzqy3fJO5S7Jzs369b0n4YrCkbP098liLcXRNNoIgnfJk7YFHmNXl7jwhZ56AnsxmOGFOJ6zpEmC2CbN0Kx350Ogregq7i3F0yNqTtWKgug0g0zBkmEPQ4hZ/DddO9Uhl37xtkUkS0zc= Received: by 10.54.16.68 with SMTP id 68mr103158wrp; Mon, 09 May 2005 16:48:34 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 16:48:34 -0700 (PDT) Message-ID: <68fba5c50505091648740fcccd@mail.gmail.com> Date: Mon, 9 May 2005 19:48:34 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceNoAlternateForFeed Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> <427FA284.5000007@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49Nmedc012248 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Graham wrote: > > On 9 May 2005, at 6:48 pm, Bill de hra wrote: > > > I think this exercise is *critical* for any piece of markup that is > > going to move from mandatory to optional. Either way, we should pin > > down spec language around the optionality of alternate feed links, > > or consciously decide we're not going to pin it down. > > So you wouldn't support a proposal that removed a required element > without explaining what it's absence meant (eg PaceAtomSummary), No, he consciously decided it wasn't worth pinning down, because there's no interop to be gained. Party foul for bringing this issue up in yet another thread, BTW. > because you'd prefer one that leaves it much less ambiguous (eg > PaceTextShouldBeProvided, which strongly encourages publishers to > only omit atom:summary when none exists)? I've read PaceTextShouldBeProvided, and I don't understand its rationale, but I can tell you there is absolutely nothing in the proposal section "which strongly encourages publishers to only omit atom:summary when none exists". All it says is that things might break if you don't include a summary or include empty text constructs. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 21:16:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05280 for ; Mon, 9 May 2005 21:16: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 j4A17nmS017195; Mon, 9 May 2005 18: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 j4A17nTV017194; Mon, 9 May 2005 18:07: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A17l3i017187 for ; Mon, 9 May 2005 18:07:48 -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); Tue, 10 May 2005 11:07:47 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 11:07:30 +1000 Subject: Re: the "atom:copyright" element From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <427FD584.5080407@cegetel.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 >>>> The publication of a new Implementation Guideline by the >>>> Open Archives Initiative (OAI) compels me to suggest once >>>> again [1], as Norm Walsh [2], Bob Wyman [3], and others have >>>> done before, that the name 'atom:rights' would be better >>>> than the (current) element name 'atom:copyright'. +1 From owner-atom-syntax@mail.imc.org Mon May 9 21:20:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05594 for ; Mon, 9 May 2005 21: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 j4A1DDYr017544; Mon, 9 May 2005 18:13: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 j4A1DDF5017543; Mon, 9 May 2005 18:13:13 -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 j4A1D6rQ017500 for ; Mon, 9 May 2005 18:13:12 -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 <20050510011301014003pd15e>; Tue, 10 May 2005 01:13:01 +0000 Date: Mon, 9 May 2005 19:12:59 -0600 Subject: Re: PaceFeedIdOrSelf 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: <27F7A1C0-C72D-4274-AAA8-B26C45F13EF1@mac.com> 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, May 9, 2005, at 05:05 PM, Graham wrote: > On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote: >> And add this bullet point: >> >> * atom:feed elements that contain no child atom:id element MUST >> contain an atom:link element with a relation of "self". > > rel="self" is in no way a substitute for an identifier Why not? Unless you can explain how multiple different feeds can be obtained via one URI (other than content negotiation to determine the format of the feed or some ridiculous abuse of standards), I disagree completely. @rel="self" does precisely identify a feed--the feed pointed to by @href--and while it may be less permanent than atom:id in some cases, it should be sufficiently stable in most cases, and is less spoofable than atom:id, which in my book makes it a better identifier. From owner-atom-syntax@mail.imc.org Mon May 9 21:33:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06242 for ; Mon, 9 May 2005 21:33: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 j4A1QZQs018398; Mon, 9 May 2005 18:26: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 j4A1QZMp018397; Mon, 9 May 2005 18:26:35 -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 j4A1QXCO018389 for ; Mon, 9 May 2005 18:26:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2584524wra for ; Mon, 09 May 2005 18:26: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:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ECzjJanEuTqfB9v3W6SF7MXVnVgCvpganZoqns75aa6pUb18nKwmGpfGo1gJ8h/cuOVrDME/E+vtKQIMldYurnhoy8QskQkk/OtW/n3BZmklfFQ1AfltbkX+14tv1nbIFegZ8JPu/rBCadWdlvkaXkiVGgz54Pez4xvDwaMqJAo= Received: by 10.54.37.21 with SMTP id k21mr154719wrk; Mon, 09 May 2005 18:26:28 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 18:26:28 -0700 (PDT) Message-ID: <68fba5c5050509182672aed344@mail.gmail.com> Date: Mon, 9 May 2005 21:26:28 -0400 From: Robert Sayre Reply-To: Robert Sayre Subject: Re: the "atom:copyright" element Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <427FD584.5080407@cegetel.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4A1QZCO018392 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit +1 to atom:rights without a URI attribute. Leave it a text blob. On 5/9/05, Eric Scheid wrote: > > >>>> The publication of a new Implementation Guideline by the > >>>> Open Archives Initiative (OAI) compels me to suggest once > >>>> again [1], as Norm Walsh [2], Bob Wyman [3], and others have > >>>> done before, that the name 'atom:rights' would be better > >>>> than the (current) element name 'atom:copyright'. > > +1 > > From owner-atom-syntax@mail.imc.org Mon May 9 21:39:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06792 for ; Mon, 9 May 2005 21:39: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 j4A1VULp018613; Mon, 9 May 2005 18:31: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 j4A1VUid018612; Mon, 9 May 2005 18:31:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1VToo018606 for ; Mon, 9 May 2005 18:31:30 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id 16ADC16EDD; Mon, 9 May 2005 20:31:42 -0500 (CDT) Date: Mon, 9 May 2005 20:31:42 -0500 From: David Nesting To: Graham Cc: Bill de =?iso-8859-1?Q?h=D3ra?= , atom-syntax Subject: Re: PaceNoAlternateForFeed Message-ID: <20050510013141.GQ2161@home.fastolfe.net> References: <427F6FAC.1010407@dehora.net> <427F7A1A.4060300@gmx.de> <427F7DFD.6070807@dehora.net> <11e5b7b208fbe54910fd75ec4ec11ffb@sun.com> <427FA284.5000007@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 10, 2005 at 12:10:33AM +0100, Graham wrote: > > So you wouldn't support a proposal that removed a required element > without explaining what it's absence meant (eg PaceAtomSummary), > because you'd prefer one that leaves it much less ambiguous (eg > PaceTextShouldBeProvided, which strongly encourages publishers to > only omit atom:summary when none exists)? There's a difference between atom:summary and atom:link. The first is a product of the RESOURCE the entry is pointing to. The lack of a summary in the entry does not necessarily imply that the RESOURCE has no summary, only that no summary exists in this entry. The presence of an empty summary is a statement that the summary "exists", but is empty. The second is a product of the FEED: here's a link that has something to do with the feed itself. The feed is the sole authority on things (meta data) related to the feed. The absence of an alternate link and the presence of an "empty" link are BOTH statements that no alternate link exists. One can not reasonably infer that the lack of a link is somehow the feed being uncommunicative about its own state. There is insufficient difference between the two to mean anything significant to software/readers. It seems most reasonable to me to simply allow the lack of a where it's reasonable for there to be no link. The presence of a "no link" provides no additional information than the omission would. This is not the same as the summary, where the feed may not be the authority on the resource it's pointing to. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Mon May 9 21:44:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07122 for ; Mon, 9 May 2005 21:44: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 j4A1a3BI018796; Mon, 9 May 2005 18:36: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 j4A1a3xX018795; Mon, 9 May 2005 18:36:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1a3SQ018789 for ; Mon, 9 May 2005 18:36:03 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id D8B9216EE0; Mon, 9 May 2005 20:36:15 -0500 (CDT) Date: Mon, 9 May 2005 20:36:15 -0500 From: David Nesting To: Graham Cc: Antone Roundy , atom-syntax Subject: Re: PaceFeedIdOrSelf Message-ID: <20050510013615.GR2161@home.fastolfe.net> References: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> <27F7A1C0-C72D-4274-AAA8-B26C45F13EF1@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27F7A1C0-C72D-4274-AAA8-B26C45F13EF1@mac.com> User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 10, 2005 at 12:05:22AM +0100, Graham wrote: > > rel="self" is in no way a substitute for an identifier and shouldn't Has anyone considered merging these into one (required) element? The ID can be a URI. The URI need not be resolvable. If the URI is a URL, it SHOULD (MUST?) point to the feed's location. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Mon May 9 21:53:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07914 for ; Mon, 9 May 2005 21:53: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 j4A1hM4q019142; Mon, 9 May 2005 18:43: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 j4A1hLPL019141; Mon, 9 May 2005 18:43:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1hL5g019134 for ; Mon, 9 May 2005 18:43:21 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id 81C3216EE0; Mon, 9 May 2005 20:43:32 -0500 (CDT) Date: Mon, 9 May 2005 20:43:32 -0500 From: David Nesting To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Which is the preferred feed? Message-ID: <20050510014332.GS2161@home.fastolfe.net> References: <427F8F89.1060107@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 09, 2005 at 10:53:14AM -0600, Antone Roundy wrote: > > 302 would result in feed readers (that follow the HTTP spec) continuing > to hit the publisher's site every time they checked the feed, and then > going to FeedBurner. I'm not sure how user agents would handle it, but one could always attach some caching headers to that 302 response to indicate that the 302 is semi-permanent. In theory, user agents could hold on to that 302 response for a little while and follow the "cached" redirection. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Mon May 9 22:00:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08229 for ; Mon, 9 May 2005 22:00: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 j4A1r7HL020928; Mon, 9 May 2005 18:53: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 j4A1r7Js020927; Mon, 9 May 2005 18:53: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1r5M5020921 for ; Mon, 9 May 2005 18:53: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); Tue, 10 May 2005 11:53:08 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 11:52:55 +1000 Subject: Re: PaceFeedIdOrSelf 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 10/5/05 11:12 AM, "Antone Roundy" wrote: >> rel="self" is in no way a substitute for an identifier > > Why not? the uri can change. e. From owner-atom-syntax@mail.imc.org Mon May 9 22:01:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08284 for ; Mon, 9 May 2005 22: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 j4A1qxsF020916; Mon, 9 May 2005 18:52: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 j4A1qx3v020915; Mon, 9 May 2005 18:52:59 -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 j4A1qvX8020907 for ; Mon, 9 May 2005 18:52:58 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2595611wra for ; Mon, 09 May 2005 18:52:52 -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=DrhH4+mzqYT2Ja+XEGvW8qErOTtqgIG2iapG3f7ZAm+wM0X1+qmeKmfkQhFp+5EPjjUPRixSpvYU1hCTIEtVoNgS7rVWUiszShxq5BoXW/6mDfiPzlq1O28xJIjFVf0oz5HbG/z17X5llACAosiciXhbIfZMhdQgPlQTyr9Itls= Received: by 10.54.7.16 with SMTP id 16mr165835wrg; Mon, 09 May 2005 18:52:51 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 18:52:51 -0700 (PDT) Message-ID: <68fba5c50505091852aee94ab@mail.gmail.com> Date: Mon, 9 May 2005 21:52:51 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: extensions -- Atom NS and unprefixed attributes 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 j4A1qwX8020910 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 22:07:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08606 for ; Mon, 9 May 2005 22:07: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 j4A1xwJe021279; Mon, 9 May 2005 18:59: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 j4A1xwMH021278; Mon, 9 May 2005 18:59:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1xuon021272 for ; Mon, 9 May 2005 18:59:57 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id A968016EDD; Mon, 9 May 2005 21:00:08 -0500 (CDT) Date: Mon, 9 May 2005 21:00:08 -0500 From: David Nesting To: Eric Scheid Cc: Atom Syntax Subject: Re: PaceFeedIdOrSelf Message-ID: <20050510020008.GT2161@home.fastolfe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 10, 2005 at 11:52:55AM +1000, Eric Scheid wrote: > > Why not? > > the uri can change. "URIs don't change; People change them."[1] But yah, things are never that simple. Consequently, ignore my other e-mail in this thread. (And sorry if this is all a re-hash.) David [1] http://www.w3.org/Provider/Style/URI.html -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Mon May 9 22:08:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08628 for ; Mon, 9 May 2005 22:08: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 j4A1x0V4021233; Mon, 9 May 2005 18:59: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 j4A1x0vq021232; Mon, 9 May 2005 18:59:00 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A1ww7M021223 for ; Mon, 9 May 2005 18:58:59 -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); Tue, 10 May 2005 11:59:00 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 11:58:46 +1000 Subject: Re: PaceFeedIdOrSelf From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050510013615.GR2161@home.fastolfe.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 10/5/05 11:36 AM, "David Nesting" wrote: >> rel="self" is in no way a substitute for an identifier and shouldn't > > Has anyone considered merging these into one (required) element? The ID > can be a URI. The URI need not be resolvable. If the URI is a URL, > it SHOULD (MUST?) point to the feed's location. in the spec the atom:id *is* a URI. introducing "SHOULD/MUST point to the feed's location" would put pressure on the value of atom:id being changed if the feed is re-located (eg. to FeedBurner). Not a good thing. e. From owner-atom-syntax@mail.imc.org Mon May 9 22:30:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09947 for ; Mon, 9 May 2005 22: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 j4A2LTcv023784; Mon, 9 May 2005 19:21: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 j4A2LT7j023783; Mon, 9 May 2005 19:21:29 -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 j4A2LSeM023774 for ; Mon, 9 May 2005 19:21:28 -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 j4A2LNjO025817 for ; Mon, 9 May 2005 20:21:28 -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 <0IG9009JO57MCN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 09 May 2005 20:21:22 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG9000GK57L8A@mail.sun.net> for atom-syntax@imc.org; Mon, 09 May 2005 20:21:22 -0600 (MDT) Date: Mon, 09 May 2005 19:22:30 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <68fba5c50505091852aee94ab@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 9, 2005, at 6:52 PM, Robert Sayre wrote: > > I think we should be clearer that new elements in the Atom namespace > and unprefixed attributes with parent elements in the Atom namespace > can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim From owner-atom-syntax@mail.imc.org Mon May 9 22:30:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09958 for ; Mon, 9 May 2005 22:30: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 j4A2NQOI023904; Mon, 9 May 2005 19:23: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 j4A2NQI0023903; Mon, 9 May 2005 19:23:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A2NQDG023883 for ; Mon, 9 May 2005 19:23:26 -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 (rwcrmhc11) with SMTP id <2005051002231401300hk86ee>; Tue, 10 May 2005 02:23:14 +0000 Date: Mon, 9 May 2005 20:23:12 -0600 Subject: Re: PaceFeedIdOrSelf 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: <756BB204-C0FA-11D9-90F9-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, May 9, 2005, at 07:52 PM, Eric Scheid wrote: >>> rel="self" is in no way a substitute for an identifier >> Why not? > the uri can change. > Yes, I acknowledged that a little after "why not?". So we have a tradeoff--greater permanence vs. greater resistance to spoofing. In my opinion, protection against spoofing is more valuable, in part because I expect most feed URIs to be stable enough that their changing won't be a significant issue. Also because things like the volume of SPAM that gets sent to me convince me that people WILL exploit atom:id's spoofability to DOS others' entries. I'm open to experience and reasoning to the contrary, but at this point, that's my position. From owner-atom-syntax@mail.imc.org Mon May 9 22:36:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10391 for ; Mon, 9 May 2005 22:36: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 j4A2SqB1024646; Mon, 9 May 2005 19:28: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 j4A2SqWo024645; Mon, 9 May 2005 19:28:52 -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 j4A2Spiq024637 for ; Mon, 9 May 2005 19:28:51 -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 j4A2SpjO000022 for ; Mon, 9 May 2005 20:28:51 -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 <0IG9008XY5K2IG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 09 May 2005 20:28:51 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IG9000H05K28A@mail.sun.net> for atom-syntax@imc.org; Mon, 09 May 2005 20:28:50 -0600 (MDT) Date: Mon, 09 May 2005 19:29:58 -0700 From: Tim Bray Subject: Atom 1.0? To: Atom Syntax Message-id: <4291d2e71f8d649e88d30fd250e83936@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 Question: how do we refer to the product of this WG once it has an RFC number? We definitely need some quick, snappy label to refer to that version to distinguish it from Atom 0.3, which is widely enough deployed that it'll be with us for a while. Per WG consensus, an Atom doc has no version stamp. So there'll be no actual spec-based reason to call our product "Atom 1.0". But, we could just go ahead and do it anyhow. Anyone have a better idea? --Tim From owner-atom-syntax@mail.imc.org Mon May 9 22:42:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10714 for ; Mon, 9 May 2005 22:42: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 j4A2Yx4B025104; Mon, 9 May 2005 19:34: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 j4A2YxWg025103; Mon, 9 May 2005 19:34:59 -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 j4A2YwO3025090 for ; Mon, 9 May 2005 19:34:59 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2613753wra for ; Mon, 09 May 2005 19:34:53 -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=rvMNvln/nPc6Bz2f39+9Z8AkqcNgA0xNPwQ5hoFnICsTBBWafoWfowzvvI77xgIzCYd+2lgTZ+u7LMPbeGQTsr6z14dOpyaUwiqXSxsbfFtKM80hrABFyqVYehCyH9vTKg+zb+KA2W6RHWD/lzzIlGO67nWMpfgGzPsm2HSIWyE= Received: by 10.54.41.39 with SMTP id o39mr188510wro; Mon, 09 May 2005 19:34:53 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 19:34:53 -0700 (PDT) Message-ID: <68fba5c5050509193458810ff5@mail.gmail.com> Date: Mon, 9 May 2005 22:34:53 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4A2YxO3025097 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Tim Bray wrote: > I wonder if there's some standard IETF practice when you define a > language as regards future change control? > > Generally -1. This spec defines what Atom 1.0 is, why try to > micro-manage the future? Fair enough. But can just anyone add stuff to the Atom namespace? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 22:46:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10945 for ; Mon, 9 May 2005 22:46: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 j4A2cNC8025491; Mon, 9 May 2005 19:38: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 j4A2cNQD025490; Mon, 9 May 2005 19:38:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A2cMZO025477 for ; Mon, 9 May 2005 19:38:22 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.1.8] (trillian.student.umd.edu [129.2.249.178]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j4A2cFpb029514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 9 May 2005 22:38:16 -0400 (EDT) Message-ID: <42801E91.2040704@atrus.org> Date: Mon, 09 May 2005 22:38:09 -0400 From: Nikolas Coukouma User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Autodiscovery paces 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 written a couple of paces based on the autodiscovery discussion. I'd like the group to stay focused on the syndication format issues, but didn't want the proposals to be lost. http://www.intertwingly.net/wiki/pie/PaceAnchorSupport http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue -Nikolas Coukouma From owner-atom-syntax@mail.imc.org Mon May 9 23:02:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11570 for ; Mon, 9 May 2005 23:02: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 j4A2v7MW026795; Mon, 9 May 2005 19:57: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 j4A2v7ue026794; Mon, 9 May 2005 19:57:07 -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 j4A2v3Qx026786; Mon, 9 May 2005 19:57:04 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <68fba5c50505091852aee94ab@mail.gmail.com> Date: Mon, 9 May 2005 19:57:00 -0700 To: Tim Bray , Robert Sayre From: Paul Hoffman Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax 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:22 PM -0700 5/9/05, Tim Bray wrote: >On May 9, 2005, at 6:52 PM, Robert Sayre wrote: > >> >>I think we should be clearer that new elements in the Atom namespace >>and unprefixed attributes with parent elements in the Atom namespace >>can only be added by IETF consensus. Thoughts? > >I wonder if there's some standard IETF practice when you define a >language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. >Generally -1. This spec defines what Atom 1.0 is, why try to >micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: >Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon May 9 23:03:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11678 for ; Mon, 9 May 2005 23:03: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 j4A2tsVP026744; Mon, 9 May 2005 19: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 j4A2tsk6026743; Mon, 9 May 2005 19:55:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gridzones.com (mail.judysbookteam.com [69.90.133.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A2tsjv026737 for ; Mon, 9 May 2005 19:55:54 -0700 (PDT) (envelope-from jrodenburg@judysbookteam.com) Received: from [216.39.146.174] (account jrodenburg@judysbookteam.com HELO [127.0.0.1]) by gridzones.com (CommuniGate Pro SMTP 4.2.9) with ESMTP id 340107 for atom-syntax@imc.org; Mon, 09 May 2005 19:55:54 -0700 Message-ID: <4280224A.5050701@judysbookteam.com> Date: Mon, 09 May 2005 19:54:02 -0700 From: Jeff Rodenburg Organization: Judy's Book, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom Syntax Subject: Re: Atom 1.0? References: <4291d2e71f8d649e88d30fd250e83936@sun.com> In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@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: > > Question: how do we refer to the product of this WG once it has an RFC > number? > > We definitely need some quick, snappy label to refer to that version > to distinguish it from Atom 0.3, which is widely enough deployed that > it'll be with us for a while. Per WG consensus, an Atom doc has no > version stamp. So there'll be no actual spec-based reason to call our > product "Atom 1.0". But, we could just go ahead and do it anyhow. > > Anyone have a better idea? --Tim > First time commenting on the list, be gentle. :-) +1 on Tim's suggestion to use "Atom 1.0". "Atom 0.3" more or less dictates that future version numbers will be referenced in practical usage, so the 1.0 name seems natural. Additionally, it would be unfortunate to be lumped in with RSS in terms of selecting terminology related to versions of the specification (2.0 before 1.0?) These are superficial reasons, but my belief is that this specification will introduce a lot of publishers to the world of syndication. A good name will go a long way to pushing adoption of the specification. Thanks, Jeff Rodenburg From owner-atom-syntax@mail.imc.org Mon May 9 23:08:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11865 for ; Mon, 9 May 2005 23: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 j4A31JjO027015; Mon, 9 May 2005 20:01: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 j4A31Jpx027014; Mon, 9 May 2005 20:01: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A31ICK026992 for ; Mon, 9 May 2005 20:01:18 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2625063wra for ; Mon, 09 May 2005 20:01: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=PHhypErqPIlio6xQ+PQyMl1Hh00PFbnpFI2qPsBAUnNufBpOTK3mEX6t70xwmk4nyf3Yir1Rvmx8NlxdYIcCeKyGIvBb9wDw2lhC7b/s1b2tTdx0pTOmWP3guw9st9gbiwbLL50O9sNvxMkSTLQjVXyWYsFruV7G1BjkhTSvaYs= Received: by 10.54.83.11 with SMTP id g11mr200822wrb; Mon, 09 May 2005 20:01:12 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 20:01:12 -0700 (PDT) Message-ID: <68fba5c50505092001339ea585@mail.gmail.com> Date: Mon, 9 May 2005 23:01:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4A31ICK027004 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Paul Hoffman wrote: > >Fair enough. But can just anyone add stuff to the Atom namespace? > > If the IESG lets them, yes. > > We gotta trust the IESG after the WG shuts down. Fortunately, they > have earned that trust over time. I am fine with that. I am concerned that the current draft fails to differentiate between "foreign markup" and "markup that requires IESG approval". Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 9 23:47:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14041 for ; Mon, 9 May 2005 23:47: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 j4A3c8eF031483; Mon, 9 May 2005 20:38: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 j4A3c83o031482; Mon, 9 May 2005 20:38:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A3c7Qe031472 for ; Mon, 9 May 2005 20:38:07 -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 <2005051003380101400ehbdre>; Tue, 10 May 2005 03:38:02 +0000 Date: Mon, 9 May 2005 21:37:59 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: Atom 1.0? From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit 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 Tim Bray wrote: > Question: how do we refer to the product of this WG once it has an RFC > number? > > We definitely need some quick, snappy label to refer to that version > to distinguish it from Atom 0.3, which is widely enough deployed that > it'll be with us for a while. Per WG consensus, an Atom doc has no > version stamp. So there'll be no actual spec-based reason to call our > product "Atom 1.0". But, we could just go ahead and do it anyhow. > > Anyone have a better idea? --Tim Let's see: "Atom NT", "Atom ME", "Atom XP", "Atom 05"... Just kidding. How about "AtomRSS X 1.0 Lynx" or "iAtom"? Yeah, yeah, ha ha. Atom++? Atom Ion? "an electrically charged particle"...fits the tone of the discussion here. "Atom Isotope" would avoid that connotation. "Atom H" ("H" = "hydrogen", this first element in the periodic table). "Atom Xe" might work if it were only for archives (Xe = "xenon", an inert gas). "Atom Ra" might be good for referring back to some of the earlier drafts ("Ra" = "radium"...unstable). "Atom Cs" ("Cs" = Caesium...we've finally "caesed" arguing and finalized the spec). "Atom Ba" ("Ba" = "barium"...we can't bear to continue working on the spec...nor to read anymore such jokes? Okay, I'll quit.) Seriously though, if we just call it "Atom", no one will know whether we're talking about 0.3 or the-format-formerly-known-as-Atom-0.3-before-it-was-finalized, so I think we've got to tack something on to it. It can either be a number, a descriptive name, or a non-descriptive name. A non-descriptive name might require too much explanation, even if it sounded cool. A descriptive name? Might be hard to come up with and/or be too long: "Atom: first standardized edition?" "Atom 1.0" is certainly the easiest way to get the point across. But yeah, it's an odd choice in a way. From owner-atom-syntax@mail.imc.org Mon May 9 23:54:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14454 for ; Mon, 9 May 2005 23:54: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 j4A3mDLo032027; Mon, 9 May 2005 20:48: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 j4A3mDot032026; Mon, 9 May 2005 20:48: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A3mCq6032016 for ; Mon, 9 May 2005 20:48:12 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2647749wra for ; Mon, 09 May 2005 20:48:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uO5l8lCZsHKvLm5GtP99Zu9rItYIorac4OglojzDmZGDsO+vKtn90PXCw8eveUwkRmyAS7Hh0XylNRuRI4YAgkUDgBbv4Mtjtb+RMCKDmzC+EIYl1kA4fswJKHER/ubGurZ4E9H0fVvzfey23gIe1m1Vc8Y9OxomMwBpHjZ/lcE= Received: by 10.54.37.18 with SMTP id k18mr226668wrk; Mon, 09 May 2005 20:48:07 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Mon, 9 May 2005 20:48:07 -0700 (PDT) Message-ID: <68fba5c5050509204842f42f18@mail.gmail.com> Date: Mon, 9 May 2005 23:48:07 -0400 From: Robert Sayre Reply-To: Robert Sayre Subject: Re: Atom 1.0? Cc: atom-syntax@imc.org 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 j4A3mCq6032021 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Antone Roundy wrote: > > Tim Bray wrote: > > Question: how do we refer to the product of this WG once it has an RFC > > number? > > > > We definitely need some quick, snappy label to refer to that version > > to distinguish it from Atom 0.3, which is widely enough deployed that > > it'll be with us for a while. Per WG consensus, an Atom doc has no > > version stamp. So there'll be no actual spec-based reason to call our > > product "Atom 1.0". But, we could just go ahead and do it anyhow. > > > > Anyone have a better idea? --Tim I like "Atom". > Foghorn? Liger? Atom 2005 MX Killer Whale? > From owner-atom-syntax@mail.imc.org Tue May 10 00:18:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15978 for ; Tue, 10 May 2005 00:18: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 j4A49Dbt033979; Mon, 9 May 2005 21: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 j4A49DbR033978; Mon, 9 May 2005 21:09:13 -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 j4A49CPd033968 for ; Mon, 9 May 2005 21:09:13 -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 0033DB1 for ; Mon, 9 May 2005 21:09:04 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4A48wng000997 for ; Mon, 9 May 2005 21:09:04 -0700 (PDT) Date: Mon, 09 May 2005 21:09:27 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Atom 1.0? Message-ID: <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@sun.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> X-Mailer: Mulberry/4.0.0b1 (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 May 9, 2005 7:29:58 PM -0700 Tim Bray wrote: > > Anyone have a better idea? --Tim Hey, let's vote on a *new* name. I'm +1 on "Naked News", because it delivers the news without chrome and crap. Or maybe that is what you get when Atom (Adam?) goes public. Or because sex sells. Seriously, I don't mind "Atom 1.0" as long as the next version is "Atom 2.0". Please don't increment the right-of-the-dot part forever, because I just had to fix some software that made the (reasonable) assumption that 5.10==5.1, even though "5.10" is really Solaris 10. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue May 10 00:50:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18012 for ; Tue, 10 May 2005 00:50: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 j4A4iZCr037303; Mon, 9 May 2005 21:44: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 j4A4iZqm037302; Mon, 9 May 2005 21:44:35 -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 j4A4iZSU037287 for ; Mon, 9 May 2005 21:44:35 -0700 (PDT) (envelope-from freeformgoodness@comcast.net) Received: from [192.168.2.46] (bgp992248bgs.mlvind01.mi.comcast.net[68.43.25.82]) by comcast.net (rwcrmhc12) with SMTP id <20050510044429014003gp3qe>; Tue, 10 May 2005 04:44:30 +0000 Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@sun.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86EA08DB-2A8D-453F-99F2-67194B96B245@comcast.net> Content-Transfer-Encoding: 7bit From: Dave Walker Subject: Re: Atom 1.0? Date: Tue, 10 May 2005 00:44:28 -0400 To: Atom Syntax X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On May 9, 2005, at 10:29 PM, Tim Bray wrote: > So there'll be no actual spec-based reason to call our product > "Atom 1.0". But, we could just go ahead and do it anyhow. +1 : it's The Simplest Thing That Could Possibly Work. -d.w. From owner-atom-syntax@mail.imc.org Tue May 10 02:30:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18963 for ; Tue, 10 May 2005 02:30: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 j4A6HUTP071906; Mon, 9 May 2005 23:17: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 j4A6HUt7071905; Mon, 9 May 2005 23:17:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from imo-m17.mx.aol.com (imo-m17.mx.aol.com [64.12.138.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6HTdX071874 for ; Mon, 9 May 2005 23:17:29 -0700 (PDT) (envelope-from Svgdeveloper@aol.com) Received: from Svgdeveloper@aol.com by imo-m17.mx.aol.com (mail_out_v38_r1.7.) id 7.e0.133288ed (2519) for ; Tue, 10 May 2005 02:17:21 -0400 (EDT) From: Svgdeveloper@aol.com Message-ID: Date: Tue, 10 May 2005 02:17:21 EDT Subject: Re: Atom 1.0? To: atom-syntax@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_e0.133288ed.2fb1abf1_boundary" X-Mailer: 8.0 for Windows sub 670 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --part1_e0.133288ed.2fb1abf1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 10/05/2005 03:29:16 GMT Daylight Time, Tim.Bray@Sun.COM writes: > Question: how do we refer to the product of this WG once it has an RFC > number? > > We definitely need some quick, snappy label to refer to that version to > distinguish it from Atom 0.3, which is widely enough deployed that > it'll be with us for a while. Per WG consensus, an Atom doc has no > version stamp. So there'll be no actual spec-based reason to call our > product "Atom 1.0". But, we could just go ahead and do it anyhow. > > Anyone have a better idea? --Tim "Atom 1.0" was the term we (Danny Ayers and I) used to refer forward to the just-about-to-be version of Atom in Beginning RSS & Atom Programming. And "Atom 0.3" was the term used to refer to the existing version. Given the existence of that version, and assuming that the intention is still to use the term "Atom" at all (I assume it is) then a version number is essential in my opinion to distinguish the pukka stuff from Atom 0.3. So "Atom 1.0" would get my vote. BTW where did the "WB consensus" of avoiding a version number come from? At first sight that seems a daft idea. It also conveys a hint of immodesty and a lack of foresight as if the WG hadn't envisaged that its work could ever be improved upon, that nobody would ever want to change it. Totally unrealistic in my view. Andrew Watt --part1_e0.133288ed.2fb1abf1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 10/05/2005 03:29= :16 GMT Daylight Time, Tim.Bray@Sun.COM writes:

Question: how do we refer to th= e product of this WG once it has an RFC
number?

We definitely need some quick, snappy label to refer to that version to
distinguish it from Atom 0.3, which is widely enough deployed that
it'll be with us for a while.  Per WG consensus, an Atom doc has no version stamp.  So there'll be no actual spec-based reason to call our=20=
product "Atom 1.0".  But, we could just go ahead and do it anyhow.

Anyone have a better idea? --Tim


"Atom 1.0" was the term we (Danny Ayers and I) used to refer forward to the=20= just-about-to-be version of Atom in Beginning RSS & Atom Programming.
And "Atom 0.3" was the term used to refer to the existing version. Given the= existence of that version, and assuming that the intention is still to use=20= the term "Atom" at all (I assume it is) then a version number is essential i= n my opinion to distinguish the pukka stuff from Atom 0.3.

So "Atom 1.0" would get my vote.

BTW where did the "WB consensus" of avoiding a version number come from? At=20= first sight that seems a daft idea. It also conveys a hint of immodesty and=20= a lack of foresight as if the WG hadn't envisaged that its work could ever b= e improved upon, that nobody would ever want to change it. Totally unrealist= ic in my view.

Andrew Watt --part1_e0.133288ed.2fb1abf1_boundary-- From owner-atom-syntax@mail.imc.org Tue May 10 03:27:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23738 for ; Tue, 10 May 2005 03:27: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 j4A7HEVc095837; Tue, 10 May 2005 00:17: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 j4A7HEKs095836; Tue, 10 May 2005 00:17: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 j4A7HDOX095826 for ; Tue, 10 May 2005 00:17:13 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 51425 invoked by uid 17064); 10 May 2005 07:17:13 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.13.195]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 10 May 2005 07:17:13 -0000 In-Reply-To: <756BB204-C0FA-11D9-90F9-003065EA6144@geckotribe.com> References: <756BB204-C0FA-11D9-90F9-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceFeedIdOrSelf Date: Tue, 10 May 2005 09:17:10 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 04:23, Antone Roundy wrote: > On Monday, May 9, 2005, at 07:52 PM, Eric Scheid wrote: > >>>> rel="self" is in no way a substitute for an identifier >>>> >>> Why not? >>> >> the uri can change. >> >> > Yes, I acknowledged that a little after "why not?". So we have a > tradeoff--greater permanence vs. greater resistance to spoofing. > In my opinion, protection against spoofing is more valuable, in > part because I expect most feed URIs to be stable enough that their > changing won't be a significant issue. Also because things like > the volume of SPAM that gets sent to me convince me that people > WILL exploit atom:id's spoofability to DOS others' entries. I'm > open to experience and reasoning to the contrary, but at this > point, that's my position. I am starting agree a little hesitantly with that position. For either a feed or an entry there has to be a url that is used to DELETE, PUT, or GET it. These actions being available automatically give clients a handle on the identity of the resource. If the id is just a string to be shoved around with no means of verifying it in this way, making it possible to be spoofed, then all trust in it will vanish and inevitably the role of identity will go to whatever enables actions such as DELETE, PUT and GET. Now perhaps in a p2p world it makes sense to GET a url such as and so that our language is just being open to new protocols. (Can a P2P network allows PUTs and DELETE on such a url?) I say I am agreeing hesitantly, because the idea of having an id that would allow one to move one's feed or entry from one server to another seems very appealing. But perhaps there will be other methods of noting such a move that will be more effective. One such way would be for the old moved url to send http redirects to the new one. One could also choose one's blog service provider by asking for a contract where they agree to provide such a redirect on all one's entries in case one wishes to move. Henry From owner-atom-syntax@mail.imc.org Tue May 10 05:37:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02205 for ; Tue, 10 May 2005 05: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 j4A9SuHM040602; Tue, 10 May 2005 02:28: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 j4A9Su5N040601; Tue, 10 May 2005 02:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A9Ssau040556 for ; Tue, 10 May 2005 02:28:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4A9RIpc008138; Tue, 10 May 2005 10:27:29 +0100 (BST) In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@sun.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom 1.0? Date: Tue, 10 May 2005 10:27:11 +0100 To: Tim Bray X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 3:29 am, Tim Bray wrote: > Question: how do we refer to the product of this WG once it has an > RFC number? > > We definitely need some quick, snappy label to refer to that > version to distinguish it from Atom 0.3, which is widely enough > deployed that it'll be with us for a while. Per WG consensus, an > Atom doc has no version stamp. So there'll be no actual spec-based > reason to call our product "Atom 1.0". But, we could just go ahead > and do it anyhow. > > Anyone have a better idea? --Tim Just "Atom", no version number. No one refers to HTTP or SMTP or POP or XML by their version numbers unless they have to. Including the version number makes it sound like their are other versions that matter, and for the moment, they're aren't. Which sounds better? "Atom 1.0 released" "Atom is finished" Graham From owner-atom-syntax@mail.imc.org Tue May 10 06:18:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05078 for ; Tue, 10 May 2005 06:18: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 j4AA846q054947; Tue, 10 May 2005 03: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 j4AA84U1054946; Tue, 10 May 2005 03:08: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AA82IE054867 for ; Tue, 10 May 2005 03:08:03 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 10 May 2005 10:07:56 -0000 Received: from xdsl-213-196-245-118.netcologne.de (EHLO klangraum) [213.196.245.118] by mail.gmx.net (mp027) with SMTP; 10 May 2005 12:07:56 +0200 X-Authenticated: #163624 Date: Tue, 10 May 2005 12:11:16 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Atom 1.0? Message-ID: <20050510101116.GA23544@klangraum> Mail-Followup-To: Atom Syntax References: <4291d2e71f8d649e88d30fd250e83936@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@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: * Tim Bray [2005-05-10 04:40]: > We definitely need some quick, snappy label to refer to that > version to distinguish it from Atom 0.3 > there'll be no actual spec-based reason to call our product > "Atom 1.0". But, we could just go ahead and do it anyhow. +1 for "Atom 1.0" since a lot of people have already used that, and given the provenance of "Atom 0.3". But it should remain colloquial usage. I would argue that another, probably equally colloquial term should be introduced meanwhile, so that in the long term, the "1.0" disappears from common usage. That would probably work best if this new term includes an otherwise redundant qualifier that people will eventually discard. I am thinking "IETF Atom" might just fit the bill. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 10 06:38:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06416 for ; Tue, 10 May 2005 06:38: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 j4A9ihFI046145; Tue, 10 May 2005 02:44: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 j4A9ihfA046144; Tue, 10 May 2005 02:44:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A9ign9046082 for ; Tue, 10 May 2005 02:44:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4A9feZo016903; Tue, 10 May 2005 10:41:41 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51486089-0870-483E-B029-738E3BEA8CAF@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceFeedIdOrSelf Date: Tue, 10 May 2005 10:41:37 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 2:12 am, Antone Roundy wrote: > Why not? Because: a) It's not possible to compare an atom:id with a rel=self link. It's perfectly possible for the URI in atom:id to be the same as the rel=self in a different feed (unlikely, but possible). It's also possible for the same feed to switch from having an atom:id with one value, to having a rel=self with the a different value. b) rel=self can change c) rel=self offers no guarantee of uniqueness > Unless you can explain how multiple different feeds can be obtained > via one URI As I explained on a thread last week, rel=self doesn't necessarily correspond with the address the feed is being served from. Stop making this mistake. Graham From owner-atom-syntax@mail.imc.org Tue May 10 07:05:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12873 for ; Tue, 10 May 2005 07:05: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 j49Nsi8n012489; Mon, 9 May 2005 16:54: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 j49Nsi1B012488; Mon, 9 May 2005 16:54:44 -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 j49Nshx9012477 for ; Mon, 9 May 2005 16:54:43 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so3144877wri for ; Mon, 09 May 2005 16:54:38 -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=E9Hqe3w331JjNNSYbcbdH7SzodWavegkKAmjZjLG80sF/sK4sbcxSPrCi9pPfUjtjgpLoVQB2LirzpZRnezJMuB4QqR1jzOdhm84Zaenuwz2T3Qg1miIKraEH4FgJ88dli7mq6oqjyJXJufWkp8RxlnwXrsiZbYn23dK7lsE1s4= Received: by 10.54.54.35 with SMTP id c35mr107928wra; Mon, 09 May 2005 16:54:38 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Mon, 9 May 2005 16:54:38 -0700 (PDT) Message-ID: <540e373205050916547989ae97@mail.gmail.com> Date: Mon, 9 May 2005 18:54:38 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: PaceOptionalSummary In-Reply-To: <68fba5c505050915242ab4c20e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49Nshx9012483 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Roger, please don't see this as an attack. Robert: I would have to be one seriously touchy prick to see that as an attack. Don't sweat it. > I don't think there's a scope argument here. That's what I get for using a loaded term. My apologies. Again, I think title-only feeds are reasonable. And in a letter-of-the-poorly-phrased-charter sense, they're definitely in scope. But from a broader "why are we bothering with this?" perspective, I think they're a bit off the map. If I create a minimal Atom feed containing a title/link/summary combo, I will get pretty uniform results across 95% of the aggregators out there. That's our baseline, the default expectation. If I create a minimal feed with just title and link, on the other hand, I'm going to get substantially different results from app to app. That's no sin, nor is it the end of the world. But it's the kind of thing that publishers need to understand going in. Does that require a SHOULD in the spec? Perhaps not. Maybe it just needs a big, bold paragraph in an implementation guide. But it feels like a SHOULD to me. Every title-only feed is a support request waiting to happen, as new users stare at their screens and wonder why the feed is "broken". And I'm not convinced that aggregator developers should be the primary heat-takers in such situations... if you're producing titles-only feeds, you need to know what you're doing, and you need to be educating users prior to subscription. For what it's worth, no one needs to feel compelled to address this post. I'm not trying to hold up the process. I'm just not sure I've adequately explained my thinking up to now, and wanted to give it another shot. The end. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Tue May 10 07:53:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17853 for ; Tue, 10 May 2005 07:53: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 j4ABdIE4087634; Tue, 10 May 2005 04:39: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 j4ABdIYN087633; Tue, 10 May 2005 04:39:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ABdHhe087592 for ; Tue, 10 May 2005 04:39:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4ABc0O0028167; Tue, 10 May 2005 12:38:05 +0100 (BST) In-Reply-To: <540e373205050916547989ae97@mail.gmail.com> References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalSummary Date: Tue, 10 May 2005 12:37:58 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Don't worry about how it might be worded for now, just the principal. Graham From owner-atom-syntax@mail.imc.org Tue May 10 07:56:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18120 for ; Tue, 10 May 2005 07:56: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 j4ABlWGv090651; Tue, 10 May 2005 04:47: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 j4ABlW2D090650; Tue, 10 May 2005 04:47:32 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ABlR10090573 for ; Tue, 10 May 2005 04:47: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); Tue, 10 May 2005 21:47:27 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 10 May 2005 21:45:08 +1000 Subject: Re: Atom 1.0? 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 10/5/05 7:27 PM, "Graham" wrote: > Which sounds better? > "Atom 1.0 released" > "Atom is finished" "Atom is ready" e. From owner-atom-syntax@mail.imc.org Tue May 10 09:06:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24061 for ; Tue, 10 May 2005 09:06: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 j4ACwFT7016719; Tue, 10 May 2005 05:58: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 j4ACwFpN016715; Tue, 10 May 2005 05:58:15 -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 j4ACwDXX016660; Tue, 10 May 2005 05:58:14 -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; Tue, 10 May 2005 08:58:07 -0400 id 002F00C9.4280AFDF.000060E4 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Paul Hoffman'" , iesg@ietf.org, "'Atom WG'" Subject: RE: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 10 May 2005 08:57:47 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ACwEXX016705 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > >I'm not asking for a lot of text; probably something about as long as > >this message. > > I believe that it can be a lot shorter: given the rationale above, > it's not a problem for Atompub or any other XML-using protocol. For > that matter, it's not really and XML problem at all: it affects text > formats like HTML and RFC 2822 as well. I have to agree with Paul. I don't believe that the issue of white space in the syndicated content is really an Atompub issue. It might be an issue for the content creator. It might be an issue for the reader. As long as the pipe between the two passes the content as submitted, though, the pipe has done its job. -Scott- From owner-atom-syntax@mail.imc.org Tue May 10 09:20:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24920 for ; Tue, 10 May 2005 09:20: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 j4ADCCfU018640; Tue, 10 May 2005 06:12: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 j4ADCCl1018639; Tue, 10 May 2005 06:12: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 j4ADCBp5018621 for ; Tue, 10 May 2005 06:12:11 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4ADCu1B008648; Tue, 10 May 2005 09:12:56 -0400 Message-ID: <4280B32A.4030608@intertwingly.net> Date: Tue, 10 May 2005 09:12:10 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: PaceOptionalSummary References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> <68fba5c505050907582805627c@mail.gmail.com> In-Reply-To: <68fba5c505050907582805627c@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: > On 5/9/05, Sam Ruby wrote: > >>I also feel the need to express deep dismay at the way that author of >>PaceOptionalSummary has been pursuing a scorched earth approach whereby >>everybody who expresses an opinion to the contrary is viciously attacked >>for doing so. I believe that this has significantly hampered the >>ability of the work group to hold a reasonable discourse on the subject. > > I believe the secretary significantly hampered discourse on this > subject for *months*, by claiming the issue had consensus and was > closed. It appears that the scorched earth campaign is destined to continue unabated. It is an interesting theory, now lets explore the facts. The secretary's job is to schedule the discussion of Paces. PaceOptionalSummary was authored on 2005/04/30, and scheduled on 2005/05/05. PaceOptionalSummary was preceded by PaceCoConstraintsAreBad, which was authored on 2005/04/06. It, too, was scheduled in the very next round of paces. >>I agree with Robert; it conflicts with PaceOptionalSummary and I doubt >>> it would exist if PaceOptionalSummary had not make the cut. > > -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Alternate theory. After months of foreshadowing, PaceOptionalSummary was exquisitely timed to coincide with last call. Along with a diversionary burst of fire concerning alleged process issues. > Here's where SHOULD comes in. We're lucky that we have an example of > what happens when a SHOULD is violated. I'm sure most of you saw the > nasty arguments, accusations, and all-around busted software that > happen this week with Google Web Accelerator and Ruby On Rails.[0] > Ugly, right? This WG should be proud that we've kept the SHOULDs to a > minimum. Interesting analogy, let's see how it pans out. The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. Or they could have made idempotency a MAY, slamming the door shut not only things like Google's WebAccelerator, but also on all web crawlers. Instead, they decided to make idempotency a SHOULD, opening the door for web crawlers by putting servers on notice that in the event of a conflict, the onus is on them. - - - Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? Simply put, PaceOptionalSummary is incomplete. >> Also, I'm having trouble reconciling your road lying with the >> assertion that the two proposals are compatible. How can they be if >> their outcomes are so different? In my note yesterday morning, I made it abundantly clear what I objected to. It wasn't the text between the ==Proposal== and ==Impacts== markers. - - - The W3C got it right. And so should we. Answer the two questions above. Without hysterics like "burst into fire". What we actually are talking about here is aggregators that drop information on the floor. Should we warn producers about this? - Sam Ruby From owner-atom-syntax@mail.imc.org Tue May 10 09:32:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25852 for ; Tue, 10 May 2005 09:32: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 j4ADPNaM020235; Tue, 10 May 2005 06:25: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 j4ADPNY8020234; Tue, 10 May 2005 06:25: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4ADPLim020225 for ; Tue, 10 May 2005 06:25:22 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 10 May 2005 13:25:14 -0000 Received: from p508F9A0A.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.154.10] by mail.gmx.net (mp006) with SMTP; 10 May 2005 15:25:14 +0200 X-Authenticated: #1915285 Message-ID: <4280B638.2020204@gmx.de> Date: Tue, 10 May 2005 15:25:12 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Robert Sayre , atom-syntax@imc.org Subject: Re: PaceOptionalSummary References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> <68fba5c505050907582805627c@mail.gmail.com> <4280B32A.4030608@intertwingly.net> In-Reply-To: <4280B32A.4030608@intertwingly.net> 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 Sam Ruby wrote: > ... > The W3C could have made idempotency a MUST, which effectively would have > prevented useful things like hit counters. > ... Not true. Quoting RFC2616: "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them." > ... Best regards, Julian From owner-atom-syntax@mail.imc.org Tue May 10 09:39:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26196 for ; Tue, 10 May 2005 09:39: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 j4ADSFIL020377; Tue, 10 May 2005 06:28: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 j4ADSFk9020376; Tue, 10 May 2005 06:28: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ADSEQ0020366 for ; Tue, 10 May 2005 06:28:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2936771wra for ; Tue, 10 May 2005 06:28:08 -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=q4NHpgTZdIPkB1BG33c9LQX329ZCZZrfE2BgGWwCI3ObXaG9+hp07t5Evt1vdzE8C8HNGvRpHGJBHLLk4bBEZIF6i1DgfQ7RXCet1jtWWYybBR9UC3mlPM4wkdPICfAvuBhz0JXI/LEqH0TBxs0FRcVCB7DteTFThP1LI1u3ma8= Received: by 10.54.36.66 with SMTP id j66mr511863wrj; Tue, 10 May 2005 06:28:08 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 06:28:08 -0700 (PDT) Message-ID: <68fba5c5050510062864a7eb2e@mail.gmail.com> Date: Tue, 10 May 2005 09:28:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOptionalSummary Cc: atom-syntax@imc.org In-Reply-To: <4280B32A.4030608@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6733C8D3-BD76-11D9-AC04-003065EA6144@geckotribe.com> <427F555A.3000501@intertwingly.net> <68fba5c505050907582805627c@mail.gmail.com> <4280B32A.4030608@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ADSEQ0020371 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Sam Ruby wrote: > Back to Atom. > > If a entry in a feed does not include a title, and Firefox's Live > Bookmark support choses not to display it, who is the onus on? No one. The spec doesn't say anything about what must be displayed. > If an entry in a feed contains neither a textual content nor a summary, > and Walter's search engine choses not to index it, who is the onus on? No one. The spec doesn't say anything about what must be persisted. > Should we warn producers about this? No. These are application-specific issues. Every application is different. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 09:50:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26905 for ; Tue, 10 May 2005 09:50: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 j4ADgmEp021324; Tue, 10 May 2005 06:42: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 j4ADgm9a021323; Tue, 10 May 2005 06:42:48 -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 j4ADglFV021315 for ; Tue, 10 May 2005 06:42:47 -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 <20050510134229011000q0m0e>; Tue, 10 May 2005 13:42:39 +0000 Date: Tue, 10 May 2005 07:42:27 -0600 Subject: Re: PaceFeedIdOrSelf 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: <51486089-0870-483E-B029-738E3BEA8CAF@mac.com> Message-Id: <593C95E2-C159-11D9-A2CE-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 Tuesday, May 10, 2005, at 03:41 AM, Graham wrote: >> Unless you can explain how multiple different feeds can be obtained >> via one URI > > As I explained on a thread last week, rel=self doesn't necessarily > correspond with the address the feed is being served from. Stop making > this mistake. Let's look at the proposed text from PaceFeedLink, the proposal that added "self": atom:head elements SHOULD contain one atom:link element with a rel attribute value of "self" and SHOULD contain a href attribute with an absolute URI as its value. This URI SHOULD identify the feed and a representation exactly equivalent to the feed SHOULD be available through a HTTP GET on the URI. If the link has a "type" attribute, its value MUST conform to the Atom MIME type as described in Section 10. The atom:link element MUST otherwise conform to the definition of a Link Construct in Section 3.5. "This URI SHOULD identify the feed and a representation exactly equivalent to the feed SHOULD be available through a HTTP GET on the URI." I don't think the full meaning behind that sentence made it into the actual spec. Here's what's in the spec--in one place: 3. The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element. and elsewhere: o atom:feed elements SHOULD contain one atom:link element with a rel attribute value of "self". This URI identifies the feed and a representation equivalent to the feed. Both the proposed text and the text that made it in say that the URI (or IRI) identifies or SHOULD identify the feed. The proposal says that the feed SHOULD be available from that xRI. Was not "self" added largely/primarily to enable feed readers that didn't get the information about the IRI from which a feed was retrieved to subscribe to it? Did we not discuss standard behavior when obtaining a feed from a different IRI being automatically switching to the "self" value when accessing it in the future? See http://www.imc.org/atom-syntax/mail-archive/msg12176.html for example. From owner-atom-syntax@mail.imc.org Tue May 10 09:53:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27165 for ; Tue, 10 May 2005 09:53: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 j4ADjv9S021596; Tue, 10 May 2005 06:45: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 j4ADjv9o021595; Tue, 10 May 2005 06:45:57 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ADjvTZ021581 for ; Tue, 10 May 2005 06:45: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 (sccrmhc13) with SMTP id <2005051013455101600cel8pe>; Tue, 10 May 2005 13:45:51 +0000 Date: Tue, 10 May 2005 07:45:49 -0600 Subject: Re: PaceOptionalSummary 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 Tuesday, May 10, 2005, at 05:37 AM, Graham wrote: > Let's forget about Paces for a minute. Does anyone disagree with the > principal of recommending publishers include summaries if they have > them available, and aren't supplying atom:content? Yes. Note that I also recognize the legitimacy of publishing a feed without the summary, even if available, in some circumstances--hopefully in an alternative version of the feed (ie., hopefully there's a version of the feed with summaries or content, and a special-purpose one without). That'd lead to a SHOULD, right? From owner-atom-syntax@mail.imc.org Tue May 10 09:55:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27253 for ; Tue, 10 May 2005 09:55: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 j4ADY8fh020716; Tue, 10 May 2005 06:34: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 j4ADY8hL020715; Tue, 10 May 2005 06:34:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ADY73K020702 for ; Tue, 10 May 2005 06:34:07 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4ADVuu7001886; Tue, 10 May 2005 14:32:03 +0100 (BST) In-Reply-To: <605EF059B8737EC84E00239B@Wunders-Computer.local> References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <605EF059B8737EC84E00239B@Wunders-Computer.local> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 10 May 2005 14:31:53 +0100 To: Walter Underwood X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8 May 2005, at 4:30 am, Walter Underwood wrote: > White space is not particularly meaningful in some of these languages, > so we cannot expect them to suddenly pay attention to that just so > they can use Atom. There will be plenty of content from other formats > with this linguistically meaningless white space. So the idea is that whitespace should not appear at all in certain texts, and you'd like it to be stripped out at the consumer? There are only three possible ways for this to happen: 1) The consumer removes all whitespace, even in western texts 2) The consumer recognizes these languages and removes the whitespace automatically 3) The consumer is told what to do by an attribute (1) is obviously not plausible, but included for completeness. (2) is impractical. (3) is plausible, but may or may not end up being implemented in all consumers, making it kind of useless. I don't see how there's a better solution than texts that shouldn't be shown with whitespace not containing whitespace in the first place, which is what we have. Graham From owner-atom-syntax@mail.imc.org Tue May 10 10:26:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00878 for ; Tue, 10 May 2005 10:26: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 j4AEAJXM023344; Tue, 10 May 2005 07:10: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 j4AEAJpB023343; Tue, 10 May 2005 07:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEAIVx023335 for ; Tue, 10 May 2005 07:10:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4AE8fgc026048; Tue, 10 May 2005 15:08:47 +0100 (BST) In-Reply-To: <593C95E2-C159-11D9-A2CE-003065EA6144@geckotribe.com> References: <593C95E2-C159-11D9-A2CE-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <864C831F-8B78-48E4-B891-046FFA2A0022@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceFeedIdOrSelf Date: Tue, 10 May 2005 15:08:39 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 2:42 pm, Antone Roundy wrote: > Both the proposed text and the text that made it in say that the > URI (or IRI) identifies or SHOULD identify the feed. The proposal > says that the feed SHOULD be available from that xRI. OK, fair enough. But the other reasons I gave are far more important. > Was not "self" added largely/primarily to enable feed readers that > didn't get the information about the IRI from which a feed was > retrieved to subscribe to it? Did we not discuss standard behavior > when obtaining a feed from a different IRI being automatically > switching to the "self" value when accessing it in the future? See > http://www.imc.org/atom-syntax/mail-archive/msg12176.html for example. The model was that the browser downloaded the file, and the OS sent a system event to the feed reader asking it to open the file. If I received such a system event, I'd look for the rel="self" in the file and subscribe to that address. This all works without looking at "self" in feeds that are already subscribed to, which would be entirely separate functionality and (apart from that message) hasn't been discussed on the list, as far as I remember. Graham From owner-atom-syntax@mail.imc.org Tue May 10 10:30:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01166 for ; Tue, 10 May 2005 10:30: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 j4AEKtEM024000; Tue, 10 May 2005 07:20: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 j4AEKtQE023999; Tue, 10 May 2005 07:20:55 -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 j4AEKs2f023986 for ; Tue, 10 May 2005 07:20:55 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:49592 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228735AbVEJOUx (ORCPT ); Tue, 10 May 2005 17:20:53 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <4291d2e71f8d649e88d30fd250e83936@sun.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83d9c39f8970ba2e9e4d11b13aace0f2@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Atom 1.0? Date: Tue, 10 May 2005 17:20:44 +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 May 10, 2005, at 05:29, Tim Bray wrote: > Atom 1.0 +1 for Atom 1.0 in order to distinguish from 0.3. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue May 10 10:54:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03675 for ; Tue, 10 May 2005 10:54: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 j4AEUKQk024610; Tue, 10 May 2005 07:30: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 j4AEUKZi024609; Tue, 10 May 2005 07:30: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 j4AEUJUF024603 for ; Tue, 10 May 2005 07:30: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 j4AEUJjO026795 for ; Tue, 10 May 2005 08:30:19 -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 <0IGA00JR32YI87@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 10 May 2005 08:30:19 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGA00A2J2YHTI@mail.sun.net> for atom-syntax@imc.org; Tue, 10 May 2005 08:30:18 -0600 (MDT) Date: Tue, 10 May 2005 07:31:26 -0700 From: Tim Bray Subject: Re: PaceOptionalSummary In-reply-to: To: Graham Cc: atom-syntax , Robert Sayre Message-id: <2a430abaf83fcfab148863e39f04a8d4@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 10, 2005, at 4:37 AM, Graham wrote: > > Let's forget about Paces for a minute. Does anyone disagree with the > principal of recommending publishers include summaries if they have > them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim From owner-atom-syntax@mail.imc.org Tue May 10 10:58:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04065 for ; Tue, 10 May 2005 10:58: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 j4AEbWlK025018; Tue, 10 May 2005 07:37: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 j4AEbWTH025017; Tue, 10 May 2005 07:37: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEbVFi025007 for ; Tue, 10 May 2005 07:37:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2985935wra for ; Tue, 10 May 2005 07:37:25 -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=X24AeCvTqO5pKfW/t1fLPiyCLyeODRoHi64NCyQTLxbAgXc4Y9ASDDS7EWfC+6FihX5+3nSGVfk4hGedoB1HHHGR/RmNOCRT/TtmTXiEo/a6bm6A6YByAcHVZncJkAmFOoBMC2nT9l6tFL2+nUx+Hvrp0p7Tu7ud+jvE8fhxaIk= Received: by 10.54.16.52 with SMTP id 52mr544884wrp; Tue, 10 May 2005 07:37:25 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 07:37:25 -0700 (PDT) Message-ID: <68fba5c5050510073720d11a85@mail.gmail.com> Date: Tue, 10 May 2005 10:37:25 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: PaceOptionalSummary Cc: Graham , atom-syntax In-Reply-To: <2a430abaf83fcfab148863e39f04a8d4@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AEbVFi025011 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Tim Bray wrote: > > Yes, but I'd go further; I'd like to encourage, in general, producers > to put more than less stuff in feeds, and provide a summary whenever > they possibly can. Shouldn't we warn producers that this hurts performance in cellphones and Firefox? ;) Seriously, the benefits of providing the *right* amount of information are extensive, but it's totally inappropriate to specify it. > My only angst at this moment is whether the canonical SHOULD is the > right tool to do that. It definitely is not. Conformant Atom Processors MUST interoperate with title-only feeds. That's not a big deal, because all of them do. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 11:00:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04200 for ; Tue, 10 May 2005 11:00: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 j4AEmotS026299; Tue, 10 May 2005 07:48: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 j4AEmoGN026297; Tue, 10 May 2005 07:48:50 -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 j4AEmnFv026284 for ; Tue, 10 May 2005 07:48:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 85017 messnum 11074380 invoked from network[83.70.217.193/unknown]); 10 May 2005 14:48:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail11.svc.cra.dublin.eircom.net (qp 85017) with SMTP; 10 May 2005 14:48:43 -0000 Message-ID: <4280C9C6.60808@dehora.net> Date: Tue, 10 May 2005 15:48:39 +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: PaceOptionalSummary References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> In-Reply-To: <2a430abaf83fcfab148863e39f04a8d4@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: > > > On May 10, 2005, at 4:37 AM, Graham wrote: > >> >> Let's forget about Paces for a minute. Does anyone disagree with the >> principal of recommending publishers include summaries if they have >> them available, and aren't supplying atom:content? > > > Yes, but I'd go further; I'd like to encourage, in general, producers to > put more than less stuff in feeds, and provide a summary whenever they > possibly can. > My only angst at this moment is whether the canonical SHOULD is the > right tool to do that. -Tim MAY is the requirement level I would choose for something like a summary, which isn't a control code or interoperability hotspot. My sense of things, based on the paces and discussion I've seen, is that MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. cheers Bill From owner-atom-syntax@mail.imc.org Tue May 10 11:24:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05761 for ; Tue, 10 May 2005 11:24: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 j4AFFp5d028167; Tue, 10 May 2005 08:15: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 j4AFFpnh028166; Tue, 10 May 2005 08:15:51 -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 j4AFFole028150; Tue, 10 May 2005 08:15:50 -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 2106CB6; Tue, 10 May 2005 08:15:45 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4AFFgng007672; Tue, 10 May 2005 08:15:43 -0700 (PDT) Date: Tue, 10 May 2005 08:16:11 -0700 From: Walter Underwood To: Scott Hollenbeck , "'Paul Hoffman'" , iesg@ietf.org, "'Atom WG'" Subject: RE: Last Call: 'The Atom Syndication Format' to Proposed Standard Message-ID: <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> X-Mailer: Mulberry/4.0.0b1 (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 May 10, 2005 8:57:47 AM -0400 Scott Hollenbeck wrote: > > I have to agree with Paul. I don't believe that the issue of white space in > the syndicated content is really an Atompub issue. It might be an issue for > the content creator. It might be an issue for the reader. As long as the > pipe between the two passes the content as submitted, though, the pipe has > done its job. If publishers and subscribers have obstacles to using Atom, that sounds like a problem to me. "Everyone has this problem" is not a good reason to ignore it. Someone has to be the first to solve it, might as well be us. It is not acceptable to build formats for the "English Wide Web". That doesn't exist any more. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue May 10 11:24:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05779 for ; Tue, 10 May 2005 11:24: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 j4AFIEVt028403; Tue, 10 May 2005 08:18: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 j4AFIEC2028402; Tue, 10 May 2005 08:18: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AFIDwV028390 for ; Tue, 10 May 2005 08:18:13 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so3635554wri for ; Tue, 10 May 2005 08:18:07 -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=o4MJChoLPIQHI4iblUbdK3T4ucLlIxh6E3bDFXNTNf8gN+kd+kpTcoMc/LUZ5mnt8Q1+t+EaJWzPRk7tzxPuxC8wMF8sAgilwMVz1TaRGgOjcvnC5FkvS8z0dYCbV1jSDJLjzmKcbsfuIFfKg6CbUjzX/jpBZ574CVGHcVJ9q0E= Received: by 10.54.44.40 with SMTP id r40mr581532wrr; Tue, 10 May 2005 08:18:07 -0700 (PDT) Received: by 10.54.25.58 with HTTP; Tue, 10 May 2005 08:18:07 -0700 (PDT) Message-ID: <14be96d3050510081866b90ab3@mail.gmail.com> Date: Tue, 10 May 2005 11:18:07 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Nikolas Coukouma Subject: Re: Autodiscovery paces Cc: Atom Syntax In-Reply-To: <42801E91.2040704@atrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42801E91.2040704@atrus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AFIDwV028392 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Nikolas Coukouma wrote: > http://www.intertwingly.net/wiki/pie/PaceAnchorSupport "Autodicovery elements MAY appear in either the or the of the document." I believe this is incorrect. IIRC, elements may only appear in the , and elements may only appear in the . Other than that, +1 on PaceAnchorSupport. > http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +0. Part of my newfound personal definition of a life well-lived is to never again argue about semantics, markup, or the "correct" way to use them. This Pace will break every aggregator on the planet, but then again, so will Atom 1.0 feeds, so... +0. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Tue May 10 11:44:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07100 for ; Tue, 10 May 2005 11:44: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 j4AFWJ4E029267; Tue, 10 May 2005 08:32: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 j4AFWJmq029266; Tue, 10 May 2005 08:32:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AFWIvS029256 for ; Tue, 10 May 2005 08:32:19 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 6652 invoked by uid 10); 10 May 2005 15:32:12 -0000 Received: (vexira-qq 06646-E6E602B0 invoked from network) 10 May 2005 17:32:12 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 May 2005 15:32:12 -0000 Message-ID: <4280D3FF.9030001@annevankesteren.nl> Date: Tue, 10 May 2005 17:32:15 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nikolas Coukouma CC: Atom Syntax Subject: Re: Autodiscovery paces References: <42801E91.2040704@atrus.org> In-Reply-To: <42801E91.2040704@atrus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas Coukouma wrote: > http://www.intertwingly.net/wiki/pie/PaceAnchorSupport +1 with the same remark as Mark Pilgrim. > http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +1 if it is extended to support "alternate" as well when the feed really is the alternate version of the page. That would be a requirement for page authors. Feed readers don't have to check that and can fetch every feed with either a "feed" or "alternate" REL attribute value. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue May 10 11:47:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07250 for ; Tue, 10 May 2005 11:47: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 j4AFdbEk029774; Tue, 10 May 2005 08:39: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 j4AFdbuh029773; Tue, 10 May 2005 08:39:37 -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 j4AFdZnT029760; Tue, 10 May 2005 08:39:36 -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; Tue, 10 May 2005 11:39:35 -0400 id 002F0040.4280D5B7.00000E75 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Walter Underwood'" , "'Paul Hoffman'" , iesg@ietf.org, "'Atom WG'" Subject: RE: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 10 May 2005 11:39:15 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749CADD@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AFdanT029761 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Walter Underwood [mailto:wunder@verity.com] > Sent: Tuesday, May 10, 2005 11:16 AM > To: Scott Hollenbeck; 'Paul Hoffman'; iesg@ietf.org; 'Atom WG' > Subject: RE: Last Call: 'The Atom Syndication Format' to > Proposed Standard > > > > --On May 10, 2005 8:57:47 AM -0400 Scott Hollenbeck > wrote: > > > > I have to agree with Paul. I don't believe that the issue > of white space in > > the syndicated content is really an Atompub issue. It > might be an issue for > > the content creator. It might be an issue for the reader. > As long as the > > pipe between the two passes the content as submitted, > though, the pipe has > > done its job. > > If publishers and subscribers have obstacles to using Atom, > that sounds > like a problem to me. Why? If the "problem" is in the content creation and consumption processes, why must the conduit provide the solution? I agree that Atompub shouldn't make the problem worse, but I don't believe that it should attempt to solve endpoint problems. > "Everyone has this problem" is not a good reason to ignore it. Someone > has to be the first to solve it, might as well be us. It is > not acceptable > to build formats for the "English Wide Web". That doesn't > exist any more. Sorry, but I disagree with the "might as well be us" part. Atompub is chartered to define a syndication format and protocol, not to solve the web's i18n problems. -Scott- From owner-atom-syntax@mail.imc.org Tue May 10 11:51:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07528 for ; Tue, 10 May 2005 11:51: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 j4AFfjA2029923; Tue, 10 May 2005 08:41: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 j4AFfj6i029922; Tue, 10 May 2005 08:41: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AFfh8s029912 for ; Tue, 10 May 2005 08:41:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3028408wra for ; Tue, 10 May 2005 08:41:38 -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=cTOMz02WVmtup2lCAGBdHUHkCGuaT4nd9E6iU9wtD8w1sNkjfpaWbEczR6E41PPuJTg+J1VkWMf/lOYgU89TW8KdoLuAF2WTCXwTCYbcQYbocPD8jA6Uy6BMJiozBA1uODDMDB/JMmH0T/YAbjingkddtlUkgM5ev3tBNHLiNzs= Received: by 10.54.84.2 with SMTP id h2mr3382391wrb; Tue, 10 May 2005 08:41:38 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 08:41:38 -0700 (PDT) Message-ID: <68fba5c505051008411bac286d@mail.gmail.com> Date: Tue, 10 May 2005 11:41:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: Autodiscovery paces Cc: Nikolas Coukouma , Atom Syntax In-Reply-To: <4280D3FF.9030001@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42801E91.2040704@atrus.org> <4280D3FF.9030001@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AFfi8s029917 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue > > +1 if it is extended to support "alternate" as well when the feed really > is the alternate version of the page. That would be a requirement for > page authors. Feed readers don't have to check that and can fetch every > feed with either a "feed" or "alternate" REL attribute value. I don't understand what the "feed" relation indicates. What benefit does it have over ... ? Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 11:53:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07701 for ; Tue, 10 May 2005 11:53: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 j4AFkaX5030205; Tue, 10 May 2005 08:46: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 j4AFkZa3030204; Tue, 10 May 2005 08:46:35 -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 j4AFkZxG030191; Tue, 10 May 2005 08:46:35 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:50653 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228699AbVEJPqd (ORCPT + 1 other); Tue, 10 May 2005 18:46:33 +0300 In-Reply-To: <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.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: Scott Hollenbeck , "'Atom WG'" , "'Paul Hoffman'" , iesg@ietf.org From: Henri Sivonen Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 10 May 2005 18:46:10 +0300 To: Walter Underwood 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 May 10, 2005, at 18:16, Walter Underwood wrote: > "Everyone has this problem" is not a good reason to ignore it. Someone > has to be the first to solve it, might as well be us. It is not > acceptable > to build formats for the "English Wide Web". That doesn't exist any > more. I believe the problem should be addressed in the producer end. Not in the wire format nor at the consumer end. No one is preventing non-English text in Atom--just saying that if you don't want stuff to appear in the feed do not put the stuff there and expect the consumer to take it out. It's the usual "It hurts when I do this. -- Don't do it then." situation. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue May 10 11:55:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07812 for ; Tue, 10 May 2005 11:55: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 j4AFmHjZ030271; Tue, 10 May 2005 08:48: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 j4AFmH6x030270; Tue, 10 May 2005 08:48:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AFmGdY030260 for ; Tue, 10 May 2005 08:48:16 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 13680 invoked by uid 10); 10 May 2005 15:48:11 -0000 Received: (vexira-qq 13664-E94C2D91 invoked from network) 10 May 2005 17:48:11 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 May 2005 15:48:10 -0000 Message-ID: <4280D7BA.5050800@annevankesteren.nl> Date: Tue, 10 May 2005 17:48:10 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Nikolas Coukouma , Atom Syntax Subject: Re: Autodiscovery paces References: <42801E91.2040704@atrus.org> <4280D3FF.9030001@annevankesteren.nl> <68fba5c505051008411bac286d@mail.gmail.com> In-Reply-To: <68fba5c505051008411bac286d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >>> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue >> >> +1 if it is extended to support "alternate" as well when the feed >> really is the alternate version of the page. That would be a >> requirement for page authors. Feed readers don't have to check that >> and can fetch every feed with either a "feed" or "alternate" REL >> attribute value. > > I don't understand what the "feed" relation indicates. What benefit > does it have over > > ... > > ? That it can be used for *any* feed regardless its MIME type. Another advantage is that I can say: 'Look, an Atom feed that is well-formed', without making feed readers discover it. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue May 10 12:21:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09817 for ; Tue, 10 May 2005 12:21: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 j4AGCBgo032004; Tue, 10 May 2005 09:12: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 j4AGCBdo032003; Tue, 10 May 2005 09:12:11 -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 j4AGC97T031996 for ; Tue, 10 May 2005 09:12:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Date: Tue, 10 May 2005 09:12:09 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: Atom 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: At 9:09 PM -0700 5/9/05, Walter Underwood wrote: >Seriously, I don't mind "Atom 1.0" as long as the next version is >"Atom 2.0". +12 --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 10 12:22:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09845 for ; Tue, 10 May 2005 12:22: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 j4AGB9Zu031918; Tue, 10 May 2005 09:11: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 j4AGB9ek031917; Tue, 10 May 2005 09:11:09 -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 j4AGB5O5031909; Tue, 10 May 2005 09:11:05 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> <8C4C2A67A9099407642C25DD@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Date: Tue, 10 May 2005 09:10:07 -0700 To: iesg@ietf.org, "'Atom WG'" From: Paul Hoffman Subject: RE: Last Call: 'The Atom Syndication Format' to Proposed Standard 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 8:16 AM -0700 5/10/05, Walter Underwood wrote: >If publishers and subscribers have obstacles to using Atom, that sounds >like a problem to me. It is a problem, of course. >"Everyone has this problem" is not a good reason to ignore it. No one is ignoring it. This thread started because the format draft pointed out at least one aspect of the problem, which is more than most other RFCs do. > Someone >has to be the first to solve it, might as well be us. May I suggest that there are groups with more experience in the area than ours that would be more appropriate? In specific, since this problem affects all internationalized text, the Unicode Consortium has a much higher chance of "solving" the problem than an IETF Working Group who is focused on a syndication format. If you have a proposed solution to the problem (you didn't include one in your message to the WG), the Unicode Consortium is quite open to outside input on this type of thing. >It is not acceptable >to build formats for the "English Wide Web". That doesn't exist any more. That is both grossly insulting to those of us have spent a great deal of time trying to make the Internet internationalization-friendly, and is also grossly technically inaccurate, unless you consider every written language other than Chinese, Japanese Kanji, Burmese, Khmer, Thai, Tagalog, Lao, and Tibetan to be "English". (The folks who speak all the other languages might find you calling them "English" to be insulting too, of course.) --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 10 12:33:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13404 for ; Tue, 10 May 2005 12:33: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 j4AGPM9u033049; Tue, 10 May 2005 09:25: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 j4AGPMpL033048; Tue, 10 May 2005 09:25:22 -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 j4AGPK6N033038 for ; Tue, 10 May 2005 09:25:20 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 10 May 2005 16:25:13 -0000 Received: from xdsl-81-173-172-194.netcologne.de (EHLO klangraum) [81.173.172.194] by mail.gmx.net (mp008) with SMTP; 10 May 2005 18:25:13 +0200 X-Authenticated: #163624 Date: Tue, 10 May 2005 18:28:28 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceOptionalSummary Message-ID: <20050510162828.GA26168@klangraum> Mail-Followup-To: atom-syntax References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> <4280C9C6.60808@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4280C9C6.60808@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: 8bit * Bill de hÓra [2005-05-10 17:00]: > Perhaps that can be offset by producing text that urges the > publisher to consider emitting summaries. Maybe it’s something for the implemetor’s guide as opposed to the spec, then? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 10 12:34:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13423 for ; Tue, 10 May 2005 12:34: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 j4AGPoLl033102; Tue, 10 May 2005 09: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 j4AGPoqS033101; Tue, 10 May 2005 09:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AGPmrp033074 for ; Tue, 10 May 2005 09:25:49 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4AGOwXO010580; Tue, 10 May 2005 17:25:04 +0100 (BST) In-Reply-To: <42801E91.2040704@atrus.org> References: <42801E91.2040704@atrus.org> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F243BD0-C6E9-499E-8F64-26C5F8F0F3E6@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Autodiscovery paces Date: Tue, 10 May 2005 17:24:58 +0100 To: Nikolas Coukouma X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 3:38 am, Nikolas Coukouma wrote: > http://www.intertwingly.net/wiki/pie/PaceAnchorSupport -1 I also don't want to implement it. > http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue -1 I mainly don't see the point of changing it. Also, while "alternate" expressly says the feed corresponds in some way to the content of the current page, "feed" simply says "here is a feed of some kind", and isn't a relationship at all. Graham From owner-atom-syntax@mail.imc.org Tue May 10 12:40:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13886 for ; Tue, 10 May 2005 12:40: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 j4AGXptB034281; Tue, 10 May 2005 09:33: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 j4AGXoXh034277; Tue, 10 May 2005 09:33: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AGXmlp034164 for ; Tue, 10 May 2005 09:33:48 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3060449wra for ; Tue, 10 May 2005 09:33:42 -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=CQ/sZtceHAEaRu+zVbPPBfQ4bc+4ggtwJhh+5+xFCthW+84rNvYL6A/nNfuVErxykWQiXaNCJCaiuEBh2It38CZ2N1yzoO6DSXxTLfSbS+631J6ny84LyS4EQrEAEjF+oQYYFrkbbFc17johWJeyUmIhpFBEgg7xNgJ2ICXG6aw= Received: by 10.54.96.19 with SMTP id t19mr596270wrb; Tue, 10 May 2005 09:33:42 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 09:33:42 -0700 (PDT) Message-ID: <68fba5c5050510093356fed6a7@mail.gmail.com> Date: Tue, 10 May 2005 12:33:42 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: <4280C9C6.60808@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> <4280C9C6.60808@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AGXmlp034272 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Bill de hra wrote: > MAY won't accord sufficient moral obligation to gain consensus here. > Perhaps that can be offset by producing text that urges the publisher to > consider emitting summaries. Or, we could figure out a way to let the client ask for the amount of information it desires, rather than legislate morality. http://www.franklinmint.fm/blog/archives/000381.html After all, we're not having discussions on how many entries there should be in a feed. The amount of work on content negotiation/instance manipulation of feed resources should indicate there is no right answer to these questions. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 13:17:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21540 for ; Tue, 10 May 2005 13:17: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 j4AH8I4P038296; Tue, 10 May 2005 10:08: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 j4AH8Ik5038295; Tue, 10 May 2005 10:08: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AH82oT038273 for ; Tue, 10 May 2005 10:08:08 -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); Wed, 11 May 2005 03:07:58 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 03:07:43 +1000 Subject: Re: Autodiscovery paces From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505051008411bac286d@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 11/5/05 1:41 AM, "Robert Sayre" wrote: > I don't understand what the "feed" relation indicates. What benefit > does it have over > > ... It indicates that the @href resource is a feed in the sense that it is a source of notifications of updated content (and is the place to watch for updates the current page) to which one might wish to subscribe, and furthermore it suggests that the resource of @type="application/atom+xml" is an Atom Feed Document, and not an Atom Entry Document. Links you might *not* want to use @rel="feed" on would be... example of a broken feed archives for June 2002 Tom's feed, very interesting Without @rel="feed", a browser with autodiscovery support might well suggest those links as being worthy of subscription. (The third case iffy -- I rule it not @rel="feed" because Tom is quite unlikely to include an entry which is an alternate for this particular page). e. From owner-atom-syntax@mail.imc.org Tue May 10 13:19:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21938 for ; Tue, 10 May 2005 13:19: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 j4AH5MVs038129; Tue, 10 May 2005 10:05: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 j4AH5MwV038128; Tue, 10 May 2005 10:05:22 -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 j4AH5KhI038114 for ; Tue, 10 May 2005 10:05:21 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 65358 messnum 6388761 invoked from network[83.70.217.193/unknown]); 10 May 2005 17:05:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 65358) with SMTP; 10 May 2005 17:05:14 -0000 Message-ID: <4280E9C6.7080500@dehora.net> Date: Tue, 10 May 2005 18:05:10 +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: Atom Syntax Subject: Re: PaceOptionalSummary References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> <4280C9C6.60808@dehora.net> <20050510162828.GA26168@klangraum> In-Reply-To: <20050510162828.GA26168@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit A. Pagaltzis wrote: > * Bill de hÓra [2005-05-10 17:00]: > >>Perhaps that can be offset by producing text that urges the >>publisher to consider emitting summaries. > > > Maybe it’s something for the implemetor’s guide as opposed to the > spec, then? I raised that question already: http://www.mail-archive.com/atom-syntax@mail.imc.org/msg02809.html the WG didn't discuss it in follow-up (I think). cheers Bill From owner-atom-syntax@mail.imc.org Tue May 10 13:19:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21964 for ; Tue, 10 May 2005 13:19: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 j4AH9cWF038398; Tue, 10 May 2005 10:09: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 j4AH9cv6038397; Tue, 10 May 2005 10:09:38 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AH9ZVU038387 for ; Tue, 10 May 2005 10:09:37 -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); Wed, 11 May 2005 03:09:37 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 03:09:23 +1000 Subject: Re: PaceFeedIdOrSelf 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 10/5/05 3:50 AM, "Eric Scheid" wrote: >> I didn't change the Pace, since such a change could conceivably change >> the opinions of people who've expressed an opinion on it already. But >> I would be interested to know whether people think this would be an >> improvement, make it worse, or if either is just as well. > > +1, an improvement -1, on reflection that link[@rel='self] is no substitute for atom:id -1 to this Pace. e. From owner-atom-syntax@mail.imc.org Tue May 10 13:24:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22402 for ; Tue, 10 May 2005 13:24: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 j4AHI6cV039326; Tue, 10 May 2005 10:18: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 j4AHI6Dr039325; Tue, 10 May 2005 10:18: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AHI4m6039308 for ; Tue, 10 May 2005 10:18:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3093898wra for ; Tue, 10 May 2005 10:17: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=ncem5wrNF6sHjImoX+ZbLIUfdA5/z3H1xq1801PqOWEJX3yqO9DwkLQjB4jJgpGmsIrYU+OyHmAw5zo48Rl7KZm38NXt+QMzema2XMdX2JVbxQVY1cW2nqLd8eLUHkjHdQFDoExnbjgn4GzOhg7kG5K8SNgJ1IWHiZN/eAOdCmE= Received: by 10.54.83.11 with SMTP id g11mr613128wrb; Tue, 10 May 2005 10:17:59 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 10:17:59 -0700 (PDT) Message-ID: <68fba5c505051010174b11a3ee@mail.gmail.com> Date: Tue, 10 May 2005 13:17:59 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: Autodiscovery paces Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051008411bac286d@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AHI5m6039318 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Eric Scheid wrote: > > Without @rel="feed", a browser with autodiscovery support might well suggest > those links as being worthy of subscription. Hmm. I can see the merit in your rationale. Does it meet a need? Why not deploy it and see what happens. There's nothing in the HTML spec that says you can't make up a rel value, and you won't break anything by trying it out. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 13:49:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050 for ; Tue, 10 May 2005 13:49: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 j4AHfL5k041714; Tue, 10 May 2005 10:41: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 j4AHfLGg041713; Tue, 10 May 2005 10:41:21 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AHfFqS041704 for ; Tue, 10 May 2005 10:41:16 -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); Wed, 11 May 2005 03:41:17 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 03:41:02 +1000 Subject: Re: Autodiscovery paces From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505051010174b11a3ee@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 11/5/05 3:17 AM, "Robert Sayre" wrote: > Hmm. I can see the merit in your rationale. Does it meet a need? The need is to not confuse users. Safari under tiger now does RSS auto-discovery, which means there will be many totally-non-geek users who might well get upset if the "Subscribe to RSS" function appears to be borked. We're about to cross the chasm with RSS/Atom -- now would be a good time to make sure the folks on the other side will have a pleasant experience. Safari is however having to make do using rough heuristics instead of following a documented specification. Right now, it suggests links to "application/atom+xml" resources as being feeds, but sometime in the future that will be sub-optimal once/if folks start publishing Atom Entry Documents. I suspect it probably also suggests the following link as an RSS 1.0 feed: even if it were on this page: http://dannyayers.com/misc/about/biog.htm which (I'm guessing) would more likely to lead to a FOAF document than an RSS 1.0 document. e. From owner-atom-syntax@mail.imc.org Tue May 10 14:05:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27585 for ; Tue, 10 May 2005 14:05: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 j4AI08Jb045038; Tue, 10 May 2005 11: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 j4AI08Xr045037; Tue, 10 May 2005 11:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.myoutlookonline.com (mx1.MyOutlookOnline.com [69.25.74.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AI07eF045024 for ; Tue, 10 May 2005 11:00:07 -0700 (PDT) (envelope-from anil@sixapart.com) Received: from be022.mail.lan ([10.109.209.122]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 14:00:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Atom 1.0? Date: Tue, 10 May 2005 14:00:01 -0400 Message-ID: Thread-Topic: Atom 1.0? Thread-Index: AcVVRGoSxalAnz3CR7WFixh0MWncfwARUMJQ From: "Anil Dash" To: "Graham" , "Tim Bray" Cc: "atom-syntax" X-OriginalArrivalTime: 10 May 2005 18:00:01.0868 (UTC) FILETIME=[165898C0:01C5558A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AI07eF045032 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] On Behalf Of Graham > On 10 May 2005, at 3:29 am, Tim Bray wrote: > > > Question: how do we refer to the product of this WG once it has an > > RFC number? > Just "Atom", no version number. No one refers to HTTP or SMTP or POP > or XML by their version numbers unless they have to. Including the > version number makes it sound like their are other versions that > matter, and for the moment, they're aren't. > > Which sounds better? > "Atom 1.0 released" > "Atom is finished" > > Graham I think we should distinguish the technical conversation from the marketing/evangelism name. I'd suggest Atom 1.0 for circumstances where it's relevant (distinguishing within technical documentation) and Atom by itself everywhere else, such as on the AtomEnabled site or on sidebar buttons linking to a feed. If you see "Atom 1.0" somewhere, it should only be in contexts where someone knows what XML stands for, without having it explained. Anil __________________________________________________ Anil Dash +1 646 541 5843 From owner-atom-syntax@mail.imc.org Tue May 10 14:05:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27658 for ; Tue, 10 May 2005 14:05: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 j4AHxEsO044956; Tue, 10 May 2005 10:59: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 j4AHxEO5044955; Tue, 10 May 2005 10:59: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AHxDKL044937 for ; Tue, 10 May 2005 10:59:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3122439wra for ; Tue, 10 May 2005 10:59:07 -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=MwUqeHI1nDSsxqqgEilRPmodru6dbI29tlLnFMCd7kFLhVrE33eP1b9qYkUPqRqt0Zvc+VxngqSv3jAimunB0Ga49jD0jp4MfPrXGjnLbzfEGdoNpqHg2GYG2eAP7aM8clRvFTlHzW+pvfly0VebgnSvGlt5T9zrZeBEw+A5ESs= Received: by 10.54.96.19 with SMTP id t19mr636328wrb; Tue, 10 May 2005 10:59:07 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 10:59:07 -0700 (PDT) Message-ID: <68fba5c5050510105969bad588@mail.gmail.com> Date: Tue, 10 May 2005 13:59:07 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax Subject: Re: PaceOptionalSummary In-Reply-To: <20050510162828.GA26168@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050509134359c7055a@mail.gmail.com> <0084A4F7-C0D2-11D9-90F9-003065EA6144@geckotribe.com> <540e373205050915086344bae4@mail.gmail.com> <68fba5c505050915242ab4c20e@mail.gmail.com> <540e373205050916547989ae97@mail.gmail.com> <2a430abaf83fcfab148863e39f04a8d4@sun.com> <4280C9C6.60808@dehora.net> <20050510162828.GA26168@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AHxEKL044949 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, A. Pagaltzis wrote: > > * Bill de hra [2005-05-10 17:00]: > > Perhaps that can be offset by producing text that urges the > > publisher to consider emitting summaries. > > Maybe it's something for the implemetor's guide as opposed to the > spec, then? That's one option. If the implementor's guide were a BCP RFC, it would be easy to flag in a feed validator. The validator at feedvalidator.org spits out a pretty scary warning when it decides to warn (example: javascript in html content). Many people mistake the warnings for an error, because the little 'valid' badge is buried under the warning message and source code. A BCP RFC could be used as fodder for a less-scary looking warning. Something like "This feed may not follow established best practices". Another option would be to give title-only entries an intimidating name in the spec. Something like "Entries that lack both an atom:summary and an atom:content are termed 'Content-Free'." Or we could do both. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 14:22:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29247 for ; Tue, 10 May 2005 14:22: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 j4AIEcgA046679; Tue, 10 May 2005 11:14: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 j4AIEcrt046678; Tue, 10 May 2005 11:14:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AIEbnG046665; Tue, 10 May 2005 11:14:37 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E445BE0063; Tue, 10 May 2005 14:14:32 -0400 (EDT) To: "Scott Hollenbeck" Cc: "'Paul Hoffman'" , iesg@ietf.org, "'Atom WG'" Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> From: Sam Hartman Date: Tue, 10 May 2005 14:14:32 -0400 In-Reply-To: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> (Scott Hollenbeck's message of "Tue, 10 May 2005 08:57:47 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) 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: >>>>> "Scott" == Scott Hollenbeck writes: >> >I'm not asking for a lot of text; probably something about as >> long as >this message. >> >> I believe that it can be a lot shorter: given the rationale >> above, it's not a problem for Atompub or any other XML-using >> protocol. For that matter, it's not really and XML problem at >> all: it affects text formats like HTML and RFC 2822 as well. Scott> I have to agree with Paul. I don't believe that the issue Scott> of white space in the syndicated content is really an Scott> Atompub issue. It might be an issue for the content Scott> creator. It might be an issue for the reader. As long as Scott> the pipe between the two passes the content as submitted, Scott> though, the pipe has done its job. Except that we try to build deployable protocols. If there aren't content creation tools that can do the right thing then it becomes a deployment issue for atompub. A perfectly reasonable response would be that you've thought about and understood the problem and there are sufficient tools available that can work with your proposed pipe that you don't need to care about the issue. --Sam From owner-atom-syntax@mail.imc.org Tue May 10 14:36:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00664 for ; Tue, 10 May 2005 14:36: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 j4AIQvhc047784; Tue, 10 May 2005 11:26: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 j4AIQvxr047783; Tue, 10 May 2005 11:26:57 -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 j4AIQu4j047766; Tue, 10 May 2005 11:26:56 -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; Tue, 10 May 2005 14:26:50 -0400 id 002F0040.4280FCEA.00003CA6 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Sam Hartman'" Cc: "'Paul Hoffman'" , "'Atom WG'" , iesg@ietf.org Subject: RE: Last Call: 'The Atom Syndication Format' to Proposed Standard Date: Tue, 10 May 2005 14:26:30 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749CAE2@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > A perfectly reasonable response would be that you've thought about and > understood the problem and there are sufficient tools available that > can work with your proposed pipe that you don't need to care about the > issue. Paul described text that's in the document to describe what MAY be done. I would argue that the existing text is evidence of the thought that has gone into understanding the issue and the alleged problem. -Scott- From owner-atom-syntax@mail.imc.org Tue May 10 14:37:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00818 for ; Tue, 10 May 2005 14:37: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 j4AITInE047907; Tue, 10 May 2005 11:29: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 j4AITIh6047906; Tue, 10 May 2005 11:29:18 -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 j4AITFOR047896; Tue, 10 May 2005 11:29:15 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <046F43A8D79C794FA4733814869CDF0749CAD3@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Tue, 10 May 2005 11:29:15 -0700 To: iesg@ietf.org, "'Atom WG'" From: Paul Hoffman Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard 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:14 PM -0400 5/10/05, Sam Hartman wrote: >Except that we try to build deployable protocols. If there aren't >content creation tools that can do the right thing then it becomes a >deployment issue for atompub. True. Fortunately, there have been plenty of text editing tools that work with the "no spaces between words" languages for at least 20 years in the case of Chinese and Japanese Kanji (probably 15 years for the other languages). >A perfectly reasonable response would be that you've thought about and >understood the problem and there are sufficient tools available that >can work with your proposed pipe that you don't need to care about the >issue. I'll make that response. :-) --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 10 15:52:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07487 for ; Tue, 10 May 2005 15:52: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 j4AJg3ux053756; Tue, 10 May 2005 12:42: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 j4AJg3xJ053755; Tue, 10 May 2005 12:42: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJg2XI053738 for ; Tue, 10 May 2005 12:42:02 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3187675wra for ; Tue, 10 May 2005 12:41:57 -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=jsfzs14w0m6kS5NXTJdywFeHJMf3nRWDC/PbuWv+JPiqvDpmzYgjNjHfV8guZjPYxY+gSFDz/O0ejp/36RT860Plgjl/aPmo//QGsFi+37sAj0BJ9iFwOpi2Arj4k1sOqqFoPUeio1cElmOy4nl4W3o4uFfHWLUAHMN5uZxQ7aA= Received: by 10.54.31.57 with SMTP id e57mr679910wre; Tue, 10 May 2005 12:41:56 -0700 (PDT) Received: by 10.54.83.15 with HTTP; Tue, 10 May 2005 12:41:55 -0700 (PDT) Message-ID: <9547bc9c050510124159bf095a@mail.gmail.com> Date: Tue, 10 May 2005 12:41:55 -0700 From: Phil Ringnalda Reply-To: Phil Ringnalda To: Atom Syntax Subject: Re: Autodiscovery paces In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051010174b11a3ee@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AJg2XI053748 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Eric Scheid wrote: > > The need is to not confuse users. Safari under tiger now does RSS > auto-discovery, which means ... that it will be totally borked if Atom feeds with rel="alternate" autodiscovery turn out to be in a namespace other than the Atom 0.3 one. It occurred to me after I changed Mark's "Such notification could also be built directly into future versions of desktop web browsers." to "Such notification is also built directly into some desktop web browsers." that it's not a very good thing for Atom 1.0 that it is: I don't know about Safari and Opera, but thanks to ultra-liberal autodiscovery Firefox will be discovering Atom 1.0 feeds without knowing how to handle them no matter what, unless we beat the Firefox 1.1 clock by just the right amount. At least changing the @rel value will give more cautious autodiscoverers a fighting chance at not discovering Atom 1.0 until they know how to read it. During the changeover, rel="alternate feed" would still be risky, but a careful publisher could call their alternate feed only rel="feed" until they felt enough clients understood 1.0 to risk confusing legacy 0.3 clients. Phil Ringnalda From owner-atom-syntax@mail.imc.org Tue May 10 16:00:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08330 for ; Tue, 10 May 2005 16:00: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 j4AJuBXs054644; Tue, 10 May 2005 12:56: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 j4AJuBDe054643; Tue, 10 May 2005 12:56:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJuAdq054637 for ; Tue, 10 May 2005 12:56:11 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07665; Tue, 10 May 2005 15:56:08 -0400 (EDT) Message-Id: <200505101956.PAA07665@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-protocol-04.txt Date: Tue, 10 May 2005 15:56:08 -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 Publishing Protocol Author(s) : R. Sayre, J. Gregorio Filename : draft-ietf-atompub-protocol-04.txt Pages : 36 Date : 2005-5-10 This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (draft-ietf-atompub-format-06.txt). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.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-protocol-04.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-protocol-04.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-5-10162934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-10162934.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Tue May 10 16:03:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09292 for ; Tue, 10 May 2005 16:03: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 j4AJsnmC054546; Tue, 10 May 2005 12:54: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 j4AJsnJg054545; Tue, 10 May 2005 12:54:49 -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 j4AJsmJq054536 for ; Tue, 10 May 2005 12:54:49 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3195921wra for ; Tue, 10 May 2005 12:54:43 -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=ssT3XPwsRksxhEOyCOfl43K08joyzk0ecGkSHkBjqR4yHvD2uGPoaVgdNfyZEVhnhCYvCQPL/A/LODzq5QkgkrEg6uFkQiT3sNLOE8tl/aBLc98JVKHthjF80AiKajl3gKNlMtyyqPcao408IdyMLbAK8WEd24DTNemmELWaYVw= Received: by 10.54.96.19 with SMTP id t19mr688996wrb; Tue, 10 May 2005 12:54:43 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 12:54:43 -0700 (PDT) Message-ID: <68fba5c50505101254fb4aa24@mail.gmail.com> Date: Tue, 10 May 2005 15:54:43 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Phil Ringnalda Subject: Re: Autodiscovery paces Cc: Atom Syntax In-Reply-To: <9547bc9c050510124159bf095a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051010174b11a3ee@mail.gmail.com> <9547bc9c050510124159bf095a@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AJsnJq054540 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Phil Ringnalda wrote: > > On 5/10/05, Eric Scheid wrote: > > > > The need is to not confuse users. Safari under tiger now does RSS > > auto-discovery, which means > > ... that it will be totally borked if Atom feeds with rel="alternate" > autodiscovery turn out to be in a namespace other than the Atom 0.3 > one. Safari's RSS/Atom parser is an XQuery script. When Atom is done, you can bet they will roll out an updated script via Software Update. They'll surely have other bugs to fix, anyway.I bet they will have it done before we have an RFC number. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 16:04:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09682 for ; Tue, 10 May 2005 16:04: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 j4AJtxe4054628; Tue, 10 May 2005 12:55: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 j4AJtxSx054627; Tue, 10 May 2005 12:55:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJtw7d054621 for ; Tue, 10 May 2005 12:55:58 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07655; Tue, 10 May 2005 15:55:56 -0400 (EDT) Message-Id: <200505101955.PAA07655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt Date: Tue, 10 May 2005 15:55:56 -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 : Atom Feed Autodiscovery Author(s) : P. Ringnalda, M. Pilgrim Filename : draft-ietf-atompub-autodiscovery-01.txt Pages : 14 Date : 2005-5-10 This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the element. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-01.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-autodiscovery-01.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-autodiscovery-01.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-5-10162917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-autodiscovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-autodiscovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-10162917.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Tue May 10 16:15:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13678 for ; Tue, 10 May 2005 16:15: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 j4AK7AeK056358; Tue, 10 May 2005 13:07: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 j4AK7AZ9056357; Tue, 10 May 2005 13:07:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AK79fI056348 for ; Tue, 10 May 2005 13:07:09 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4AK5g0c018496; Tue, 10 May 2005 21:06:02 +0100 (BST) In-Reply-To: <9547bc9c050510124159bf095a@mail.gmail.com> References: <68fba5c505051010174b11a3ee@mail.gmail.com> <9547bc9c050510124159bf095a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <923D4254-1080-44DC-987F-D20C9E86387F@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Autodiscovery paces Date: Tue, 10 May 2005 21:05:39 +0100 To: Phil Ringnalda X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 8:41 pm, Phil Ringnalda wrote: > ... that it will be totally borked if Atom feeds with rel="alternate" > autodiscovery turn out to be in a namespace other than the Atom 0.3 > one. I just tried it, and it doesn't seem to care about the namespace. Anyone who gets lazy and uses "alternate" instead of "feed" for their Atom 1.0 feed would be borked anyway, so I don't really see this as a valid "pro" argument. BTW Are we seriously considering using a different rel value to every other feed format in existence, including our own, for no discernible reason? Graham From owner-atom-syntax@mail.imc.org Tue May 10 16:26:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16711 for ; Tue, 10 May 2005 16:26: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 j4AKJVMX057714; Tue, 10 May 2005 13:19: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 j4AKJV4N057712; Tue, 10 May 2005 13:19: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AKJTqR057676 for ; Tue, 10 May 2005 13:19:30 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so128062nzn for ; Tue, 10 May 2005 13:19:24 -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=ksuZMtIoA+kKjBSKx/KrtHPO7lKbSFEuydYdUnXzZt0ZxBKbmhL/O4v0rdfR1aRVbA7K6to/pBhpcrAEubuVuBfoBRd1EmiVncW03HnifKNZiCGzo9xgvXsfX8LlC8IxvxuVV3NUXar5dM7RT9EPRpU4aXfacHyASlOgDJzWPeg= Received: by 10.36.7.3 with SMTP id 3mr1734577nzg; Tue, 10 May 2005 13:19:24 -0700 (PDT) Received: by 10.36.65.13 with HTTP; Tue, 10 May 2005 13:19:24 -0700 (PDT) Message-ID: <3f1451f50505101319789825c6@mail.gmail.com> Date: Tue, 10 May 2005 16:19:24 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: atom-syntax@imc.org, Atom Protocol Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-04.txt In-Reply-To: <200505101956.PAA07665@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505101956.PAA07665@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AKJUqR057702 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit As usual, the HTML and XML versions are available here: http://bitworking.org/projects/atom/ As an indication of how much has changed from -03 to -04, there are no diffs available, the tool we use to automatically generate the diffs threw up its hands and produced nothing useful. Thanks, -joe On 5/10/05, Internet-Drafts@ietf.org wrote: > 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 Publishing Protocol > Author(s) : R. Sayre, J. Gregorio > Filename : draft-ietf-atompub-protocol-04.txt > Pages : 36 > Date : 2005-5-10 > > This memo presents a protocol for using XML (Extensible Markup > Language) and HTTP (HyperText Transport Protocol) to edit content. > > The Atom Publishing Protocol is an application-level protocol for > publishing and editing Web resources belonging to periodically > updated websites. The protocol at its core is the HTTP transport of > Atom-formatted representations. The Atom format is documented in the > Atom Syndication Format (draft-ietf-atompub-format-06.txt). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.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-protocol-04.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-protocol-04.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. > > > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue May 10 16:30:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17130 for ; Tue, 10 May 2005 16: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 j4AKLbF1057894; Tue, 10 May 2005 13:21: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 j4AKLbX3057893; Tue, 10 May 2005 13:21:37 -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 j4AKLarg057880 for ; Tue, 10 May 2005 13:21:36 -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 2F26EC0 for ; Tue, 10 May 2005 13:21:31 -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 j4AKLVng011621 for ; Tue, 10 May 2005 13:21:31 -0700 (PDT) Date: Tue, 10 May 2005 13:32:46 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: Atom 1.0? Message-ID: <82CD76A9908C76204EAB857F@diva.verity.com> In-Reply-To: References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> 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 Tuesday, May 10, 2005 09:12:09 AM -0700 Paul Hoffman wrote: > At 9:09 PM -0700 5/9/05, Walter Underwood wrote: >> Seriously, I don't mind "Atom 1.0" as long as the next version is >> "Atom 2.0". > > +12 I'd also be happy with just "Atom" and saying "RFC XXXX Atom" when pressed for a version. Even with "Atom 1.0" we'll need to say which RFC. If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue May 10 16:38:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18039 for ; Tue, 10 May 2005 16: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 j4AKRmLc058476; Tue, 10 May 2005 13:27: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 j4AKRm5Y058475; Tue, 10 May 2005 13:27:48 -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 j4AKRlPc058464 for ; Tue, 10 May 2005 13:27:47 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3217266wra for ; Tue, 10 May 2005 13:27:42 -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=N4HgmFH5A0i2qg4tOFz2bV6eyojm0AryaMvy1nPpSgNQ4OJzK4z6k8KuzgBHdSfegpZuWSOpPW+cdWOdr5tAg4KJ3iO9xlO6X7EPH4kjiAwTxxaBEcTt9RsY/5fuVL/B8uXAeAigV0Ee71HnbNoDz1ctuSl/xCMQ2GUyWxIsi8w= Received: by 10.54.50.73 with SMTP id x73mr704512wrx; Tue, 10 May 2005 13:27:42 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 13:27:42 -0700 (PDT) Message-ID: <68fba5c505051013275c485497@mail.gmail.com> Date: Tue, 10 May 2005 16:27:42 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Walter Underwood Subject: Re: Atom 1.0? Cc: Atom Syntax In-Reply-To: <82CD76A9908C76204EAB857F@diva.verity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AKRlPc058469 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Walter Underwood wrote: > > If we choose a specific name, it *must* be in the RFC. Because the RFC > must be a hit for that search. Walter, that's a good point. How about: Marketing: Atom Technical: Atom (RFCxxxx) ? Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 16:44:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18638 for ; Tue, 10 May 2005 16:44: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 j4AKbD8V059196; Tue, 10 May 2005 13:37: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 j4AKbDfj059195; Tue, 10 May 2005 13:37: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AKbCRm059185 for ; Tue, 10 May 2005 13:37:12 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3223327wra for ; Tue, 10 May 2005 13:37:07 -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=SE2fmcvbJgmPhlihD6DV1h+tgDvzB2vZpomoci+7ZvfsVC735ScZ1MfJHV4uTeylVRf2ucu5Iqfv3uF5FpNatPKrVhRaEVphDW40u1Vl+DvWH2izl/WjuE+yAvcvp5T0ruVSVNGfdSMXIzZd9uuCpODVynbpI1uUxLeYuHQXcmw= Received: by 10.54.84.2 with SMTP id h2mr3515660wrb; Tue, 10 May 2005 13:35:52 -0700 (PDT) Received: by 10.54.83.15 with HTTP; Tue, 10 May 2005 13:35:52 -0700 (PDT) Message-ID: <9547bc9c05051013359f9964f@mail.gmail.com> Date: Tue, 10 May 2005 13:35:52 -0700 From: Phil Ringnalda Reply-To: Phil Ringnalda To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt In-Reply-To: <200505101955.PAA07655@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505101955.PAA07655@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AKbCRm059190 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-01.txt > And a more pleasant one is: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html or for your "two words on every page? yay." pleasure: http://philringnalda.com/rfc/diff-00-01.txt Phil Ringnalda From owner-atom-syntax@mail.imc.org Tue May 10 16:52:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19552 for ; Tue, 10 May 2005 16:52: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 j4AKinUu059900; Tue, 10 May 2005 13:44: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 j4AKinfY059899; Tue, 10 May 2005 13:44:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AKimXQ059889 for ; Tue, 10 May 2005 13:44:48 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4AKiBrT028433; Tue, 10 May 2005 21:44:17 +0100 (BST) In-Reply-To: <68fba5c505051013275c485497@mail.gmail.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Atom 1.0? Date: Tue, 10 May 2005 21:44:03 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 10 May 2005, at 9:27 pm, Robert Sayre wrote: > Walter, that's a good point. How about: > > Marketing: Atom > Technical: Atom (RFCxxxx) Around Dave Winer: RFCxxxx The only real problem with dropping the version number is making it clear there've been major changes since 0.3. Graham From owner-atom-syntax@mail.imc.org Tue May 10 17:05:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20589 for ; Tue, 10 May 2005 17:05: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 j4AKncUb060236; Tue, 10 May 2005 13:49: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 j4AKncaQ060235; Tue, 10 May 2005 13:49: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AKnbSJ060224 for ; Tue, 10 May 2005 13:49:37 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so4748wri for ; Tue, 10 May 2005 13:49: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=FnitZyyP1XgLPM4Bdp6K5BB44tPj0EJgWPgiYovIdZIdcTNKczA3GqeuTRfXud9RLnvPAT5caWKqwwP1KOk4DEPc7vCg71U+wJHba7pKrPfQUz5lWooiAKHi+ZlOw19PzNhrzPmG717+OvvVb8D/WmMbEWBgkgYO+5uaL7ZHu7g= Received: by 10.54.37.18 with SMTP id k18mr712849wrk; Tue, 10 May 2005 13:49:28 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 13:49:28 -0700 (PDT) Message-ID: <68fba5c505051013497074772c@mail.gmail.com> Date: Tue, 10 May 2005 16:49:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Atom 1.0? Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AKnbSJ060229 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Graham wrote: > > Around Dave Winer: RFCxxxx Let's not go there, ok? > The only real problem with dropping the version number is making it > clear there've been major changes since 0.3. Who are we trying to make it clear to? I think it will be clear to developers no matter what, and irrelevant to everyone else. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 17:05:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20630 for ; Tue, 10 May 2005 17:05: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 j4AKsHiq060579; Tue, 10 May 2005 13:54: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 j4AKsHMw060578; Tue, 10 May 2005 13:54:17 -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 j4AKsGLQ060571 for ; Tue, 10 May 2005 13:54:17 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4AKt5Yi028715; Tue, 10 May 2005 16:55:05 -0400 Message-ID: <42811F77.3080501@intertwingly.net> Date: Tue, 10 May 2005 16:54:15 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Atom 1.0? References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> In-Reply-To: <82CD76A9908C76204EAB857F@diva.verity.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 Walter Underwood wrote: > > I'd also be happy with just "Atom" and saying "RFC XXXX Atom" when > pressed for a version. +1 - Sam Ruby From owner-atom-syntax@mail.imc.org Tue May 10 17:20:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22016 for ; Tue, 10 May 2005 17:20: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 j4ALAIOZ061533; Tue, 10 May 2005 14:10: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 j4ALAIdo061532; Tue, 10 May 2005 14:10:18 -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 j4ALAHCk061524 for ; Tue, 10 May 2005 14:10:17 -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 4486A4F02B for ; Tue, 10 May 2005 17:10:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <68fba5c5050509204842f42f18@mail.gmail.com> References: <68fba5c5050509204842f42f18@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3BC8E2C9-0334-4372-BEE2-160EEB9B9658@w3.org> From: Karl Dubost Subject: Re: Atom 1.0? Date: Tue, 10 May 2005 17:10:13 -0400 To: "atom-syntax Syntax'" X-Mailer: Apple Mail (2.728) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ALAHCk061527 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-09 23:48, Robert Sayre a crit : > I like "Atom". Fear the non versioning. And yes there will be new version. I would even go as far to be sure to be able to identify the language in the document itself. The namespace should be enough for that. CSS was defined without versioning in mind and it's now a mess for tools developers. +1 to the suggestion of Atom 1.0 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Tue May 10 17:40:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23770 for ; Tue, 10 May 2005 17:40: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 j4ALXPZh063517; Tue, 10 May 2005 14:33: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 j4ALXPp7063516; Tue, 10 May 2005 14:33:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ALXNhG063506 for ; Tue, 10 May 2005 14:33:24 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 11860 invoked by uid 10); 10 May 2005 21:33:17 -0000 Received: (vexira-qq 11853-B33CC58C invoked from network) 10 May 2005 23:33:17 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 10 May 2005 21:33:17 -0000 Message-ID: <428128A2.4060906@annevankesteren.nl> Date: Tue, 10 May 2005 23:33:22 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: Atom 1.0? References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> In-Reply-To: <82CD76A9908C76204EAB857F@diva.verity.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > If we choose a specific name, it *must* be in the RFC. Because the RFC > must be a hit for that search. We can Google-bomb that string I guess. (Atom 1.0.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue May 10 18:23:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29111 for ; Tue, 10 May 2005 18:23: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 j4AM9gE9066223; Tue, 10 May 2005 15:09: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 j4AM9ghp066222; Tue, 10 May 2005 15:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AM9fP7066188 for ; Tue, 10 May 2005 15:09:41 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 29619 invoked by uid 500); 10 May 2005 22:44:27 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 May 2005 22:44:27 -0000 Date: Tue, 10 May 2005 18:44:27 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Sam Ruby cc: Atom Syntax Subject: Re: Atom 1.0? In-Reply-To: <42811F77.3080501@intertwingly.net> Message-ID: 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: Question: for what principal usage context(s) is this name being designed? I heard Tim say "quick, snappy label" ... to distinguish it from Atom 0.3" Does this mean "the default name for the spec/product in any context not requiring any attributes other than version number and minimal title-string"? The names of OASIS specs are legion, and the marketing people found that trying to craft some optimal name for the press only partly works. Works only about as well as orthographies legislated by language academies. The reason is that different contexts demand different identifiers. Thus, if it's "Atom 1.0," (most) people won't say that in any context where "Atom" will do; if it's "Atom," nobody will say that once we have "Atom 2.0" and a need to refer to the earlier version. I'd vote for "Atom 1.0" or "Atom" rather than attempting to enforce a name using "RFC...", which I think will never supplant a name so snappy as "Atom". Robin PS At least I'm happy that none of the candidates nominated so far are as long at the L-O-N-G variants of OASIS specs, which are obliged to posture to every brand element, and become do long that you have to take a breath in the middle. -- From owner-atom-syntax@mail.imc.org Tue May 10 18:34:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00269 for ; Tue, 10 May 2005 18: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 j4AMPppa067270; Tue, 10 May 2005 15:25: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 j4AMPpff067269; Tue, 10 May 2005 15:25:51 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AMPohI067256 for ; Tue, 10 May 2005 15:25:50 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.65]) by smtp.cegetel.net (Postfix) with ESMTP id 4FEF0318384; Wed, 11 May 2005 00:25:44 +0200 (CEST) Message-ID: <42813518.6020602@cegetel.net> Date: Wed, 11 May 2005 00:26:32 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Eric Scheid Cc: Atom Syntax Subject: Re: Autodiscovery paces 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 11/5/05 1:41 AM, "Robert Sayre" wrote: > >>I don't understand what the "feed" relation indicates. What benefit >>does it have over >>... > > It indicates that the @href resource is a feed in the sense that it is a > source of notifications of updated content (and is the place to watch for > updates the current page) to which one might wish to subscribe, and > furthermore it suggests that the resource of @type="application/atom+xml" is > an Atom Feed Document, and not an Atom Entry Document. > > Links you might *not* want to use @rel="feed" on would be... > > example of a broken feed > archives for June 2002 > Tom's feed, very interesting > > Without @rel="feed", a browser with autodiscovery support might well suggest > those links as being worthy of subscription. (The third case iffy -- I rule > it not @rel="feed" because Tom is quite unlikely to include an entry which > is an alternate for this particular page). IMO, autodiscovery should occur only when a @rel (or @rev) is provided (and, ideally, understood). Don't forget HTML does not define a default value for @rel or @rev when they are not provided. This is a link to an Atom document: ... These are links to Atom documents which indicate a relation between the containing document and the feed pointed to by the @href and should therefor trigger autodiscovery: Linking to the news feed from the "news" page: ... Linking to the news feed from another page (e.g. the Mozilla home): ... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 10 18:47:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01220 for ; Tue, 10 May 2005 18:47: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 j4AMcjQt069548; Tue, 10 May 2005 15: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 j4AMcj0r069547; Tue, 10 May 2005 15:38:45 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AMciqq069538 for ; Tue, 10 May 2005 15:38:44 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.65]) by smtp.cegetel.net (Postfix) with ESMTP id 5A3503183CD for ; Wed, 11 May 2005 00:38:38 +0200 (CEST) Message-ID: <42813823.7090700@cegetel.net> Date: Wed, 11 May 2005 00:39:31 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceOriginalAttribute References: <64a444657a0030e17dae00b60a2de80b@sun.com> In-Reply-To: <64a444657a0030e17dae00b60a2de80b@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: > > +1 > > I'm not 100% convinced it solves the problems Rob says it does, but it > seems cheap, lightweight, and unlikely to cause any harm. -Tim > +0.8 It seems to me the proposed wording doesn't accurately reflect the rationale... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 10 19:04:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02125 for ; Tue, 10 May 2005 19:04: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 j4AMtoeN070498; Tue, 10 May 2005 15:55: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 j4AMtoI7070497; Tue, 10 May 2005 15:55:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AMtn5W070485 for ; Tue, 10 May 2005 15:55:49 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4AMsZdJ027037 for ; Tue, 10 May 2005 23:54:41 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) In-Reply-To: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> References: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <564C9633-4E20-4924-B98D-90672A8102EC@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOriginalAttribute Date: Tue, 10 May 2005 23:54:35 +0100 To: atom-syntax X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 An entry only needs one identifier. The way to solve this problem (if it needs solving) is allowing duplicate ids under some or all circumstances. Graham From owner-atom-syntax@mail.imc.org Tue May 10 19:33:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03767 for ; Tue, 10 May 2005 19:33: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 j4ANGNiI072277; Tue, 10 May 2005 16:16: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 j4ANGNcx072275; Tue, 10 May 2005 16:16:23 -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 j4ANGMda072262 for ; Tue, 10 May 2005 16:16:22 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so82115wra for ; Tue, 10 May 2005 16:16:17 -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=IxXC7Ngg1aodA1941vvhuQxzFkUBgK3LjmK/s6kToBk2b0DWmh8p9IYEm+2iFrfeigYXM493YdXPs12XFM5fzz2o1QTq3Xda5x3RiGU/1DLhAJrSUWnc57tg0rEbTl7vJ3lFEh/+iStjhpxrWgfOA9EKYbHsZohC4UdbrbBFocY= Received: by 10.54.76.2 with SMTP id y2mr65682wra; Tue, 10 May 2005 16:16:17 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 16:16:17 -0700 (PDT) Message-ID: <68fba5c50505101616483b102e@mail.gmail.com> Date: Tue, 10 May 2005 19:16:17 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Re: Autodiscovery paces In-Reply-To: <42813518.6020602@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42813518.6020602@cegetel.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ANGMda072270 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit There's no reason for any of the ideas in this thread to be in the same draft as the concepts outlined in autodiscovery-01. Stamp Out Creativity Now. I'm strongly opposed to letting this draft turn into a vast metropolis of bikesheds, where we have 60-message threads on the right way to use HTML @rel values. The WG has limited resources and time. Those resources are most needed by the protocol draft. Bolting fancy new appendages on the autodiscovery draft is a waste of time. You don't need a standards action to add a link relation. Just do it. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 19:34:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03813 for ; Tue, 10 May 2005 19:34: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 j4ANQDLS073117; Tue, 10 May 2005 16:26: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 j4ANQDiH073115; Tue, 10 May 2005 16:26:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web52001.mail.yahoo.com (web52001.mail.yahoo.com [206.190.39.57]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4ANQCIS073102 for ; Tue, 10 May 2005 16:26:13 -0700 (PDT) (envelope-from ecomputerd@yahoo.com) Received: (qmail 30004 invoked by uid 60001); 10 May 2005 23:26:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ue8JrykZ2pQl4R5/i/ykktxSw7Ql1xc6vtlFQeeULCtG3rdPpEV9Wxk2XglDKzBEgpwxDmwQSKyQ8EoUOAlx2QXem5ModXxYs2uIWOYOvu4JEEN5j/M08QpZ5BkNBtKppybo59QYC2h3CTj39zGAJUht8vKIfCgGISLIExDBbIU= ; Message-ID: <20050510232607.30002.qmail@web52001.mail.yahoo.com> Received: from [65.15.100.176] by web52001.mail.yahoo.com via HTTP; Tue, 10 May 2005 16:26:07 PDT Date: Tue, 10 May 2005 16:26:07 -0700 (PDT) From: Greg Smith Subject: draft-ietf-atompub-protocol-04.txt To: atom-syntax@imc.org, Atom Protocol In-Reply-To: 6667 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: In reference to draft-ietf-atompub-protocol-04.txt Just a quick readthrough and I have a few comments: 4.2 Discovery: good description and "easing" into the meat of the document. 6. Should probably reference "see section 8.1.1.3.1.1". 6.1 In the table, what does "x" mean? Not allowed? Seems like it means something else, but not explicitly stated. I'm concerned about the ability of a client, given a Service Document (whether Autodiscovered or not), to determine what the Service Document covers. I think this is where the "entry" and "generic" types are going, but it seems like it might be advantageous to tie the Service Document to Content-Types. Suppose I am a blog hosting service and I allow direct photo, video, audio, and text blogs. By "direct" I mean I allow someone to post a photo directly to a photo blog without any text or metadata in it whatsoever. I will probably want a "public" service document that lists the hrefreadonly links for viewers and a "private" service document for my posting clients. If I do this, and then provide a series of collections within the service document, there is no way to automatically sort out what kind of content to post to each of the collections. If I want you to be able to program "dumb" clients that provide little or no metadata (like directly from a camera or mp3 recorder or phone), then it would be nice to provide a "photo" collection to POST my photos to. While we could create a whole series of "entry", "generic", and other types, it might be better to consider listing for each collection, the acceptable Content-Types. Right now, it looks like a client has to trial and error the Content-Types to determine the allowed Content-Types. It would even be nice to provide a "preferred" Content-Type for each collection as well, but I'm not sure that would be necessary. Just my thoughts. I'm sorry if this has been hashed over already, I'm new to the group. Greg Smith __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From owner-atom-syntax@mail.imc.org Tue May 10 20:30:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07434 for ; Tue, 10 May 2005 20:30: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 j4B0Mw4O077476; Tue, 10 May 2005 17:22: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 j4B0MwPc077475; Tue, 10 May 2005 17:22:58 -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 j4B0Mvng077466 for ; Tue, 10 May 2005 17:22:57 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so108288wra for ; Tue, 10 May 2005 17:22:52 -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=ZFpUqvmrDkwmb/EySYba6rWFAAJDary7nmF4o869yY9A8xiy8aPc5ZNEgNasPmVGQSKT31gpIGMZBm45+KfxHVsoP+xAvFKxSSo3jd54LoxroJ5FPnUfQdA6cF4Y2KIboYeT8oGa+YS3NCcmrXW2oeo7Ck9NxzlDyfOOxqRHFaQ= Received: by 10.54.116.3 with SMTP id o3mr85197wrc; Tue, 10 May 2005 17:22:51 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 17:22:51 -0700 (PDT) Message-ID: <68fba5c50505101722b9cf257@mail.gmail.com> Date: Tue, 10 May 2005 20:22:51 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceOriginalAttribute Cc: atom-syntax In-Reply-To: <564C9633-4E20-4924-B98D-90672A8102EC@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> <564C9633-4E20-4924-B98D-90672A8102EC@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B0Mvng077470 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Graham wrote: > > -1 > > An entry only needs one identifier. The way to solve this problem (if > it needs solving) is allowing duplicate ids under some or all > circumstances. Hmm. I'd be curious to hear what you think the problem is. Every system I can think of that does forwarding or versioning assigns multiple identifiers. Perhaps you have an example system in mind? Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 20:50:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08787 for ; Tue, 10 May 2005 20:50: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 j4B0dx4g079282; Tue, 10 May 2005 17:39: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 j4B0dxwt079280; Tue, 10 May 2005 17:39: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B0dvDF079264 for ; Tue, 10 May 2005 17:39:58 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so209417nzn for ; Tue, 10 May 2005 17:39:52 -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=EP//+UsDnpEAcBIWpavTfFQVvvqIc7PcarpEqui+OSuGeAQ49ZQyGwlSuD3MmaS4NCuZpgGeb6BxV1swSEqVstDcsI+Suad/2uLrahHV8CPaoPj0vIcKlKJDbRH1rHTti6My2kFBVh2MPcMneqgtQbthjIoqw0JAfcsJEU/WYvk= Received: by 10.36.77.10 with SMTP id z10mr1781521nza; Tue, 10 May 2005 17:39:52 -0700 (PDT) Received: by 10.36.65.13 with HTTP; Tue, 10 May 2005 17:39:52 -0700 (PDT) Message-ID: <3f1451f505051017391f11bfbc@mail.gmail.com> Date: Tue, 10 May 2005 20:39:52 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Greg Smith Subject: Re: draft-ietf-atompub-protocol-04.txt Cc: atom-syntax@imc.org, Atom Protocol In-Reply-To: <20050510232607.30002.qmail@web52001.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050510232607.30002.qmail@web52001.mail.yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B0dwDF079271 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Greg, All excellent observations and comments. My replies are inline. On 5/10/05, Greg Smith wrote: > > In reference to draft-ietf-atompub-protocol-04.txt > > Just a quick readthrough and I have a few comments: > > 4.2 Discovery: good description and "easing" into the > meat of the document. > > 6. Should probably reference "see section > 8.1.1.3.1.1". Good points. I have started an errata page for this draft on the wiki: http://www.intertwingly.net/wiki/pie/ProtocolDraft04Errata > > 6.1 In the table, what does "x" mean? Not allowed? > Seems like it means something else, but not explicitly > stated. > > I'm concerned about the ability of a client, given a > Service Document (whether Autodiscovered or not), to > determine what the Service Document covers. I think > this is where the "entry" and "generic" types are > going, but it seems like it might be advantageous to > tie the Service Document to Content-Types. Suppose I > am a blog hosting service and I allow direct photo, > video, audio, and text blogs. By "direct" I mean I > allow someone to post a photo directly to a photo blog > without any text or metadata in it whatsoever. > > I will probably want a "public" service document that > lists the hrefreadonly links for viewers and a > "private" service document for my posting clients. If > I do this, and then provide a series of collections > within the service document, there is no way to > automatically sort out what kind of content to post to > each of the collections. If I want you to be able to > program "dumb" clients that provide little or no > metadata (like directly from a camera or mp3 recorder > or phone), then it would be nice to provide a "photo" > collection to POST my photos to. > > While we could create a whole series of "entry", > "generic", and other types, it might be better to > consider listing for each collection, the acceptable > Content-Types. > > Right now, it looks like a client has to trial and > error the Content-Types to determine the allowed > Content-Types. It would even be nice to provide a > "preferred" Content-Type for each collection as well, > but I'm not sure that would be necessary. This document is just the 'basic' protocol, where we are describing the basic mechanisms and collection types. We are expecting to produce a further specification that covers editing collections of other types of documents, such as templates, etc. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue May 10 21:20:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10583 for ; Tue, 10 May 2005 21:20: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 j4B1Bx0t081100; Tue, 10 May 2005 18:11: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 j4B1BxlE081091; Tue, 10 May 2005 18:11:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1Buxu081070 for ; Tue, 10 May 2005 18:11:58 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4B1Bj711621; Wed, 11 May 2005 10:11:45 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f206c292_c1ba_11d9_9bac_0030482532aa_17666; Wed, 11 May 2005 10:21:05 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005AF6; 11 May 05 10:14:18 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 11 May 05 10:14:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005AF3; 11 May 05 10:14:14 +0900 Message-Id: <6.0.0.20.2.20050510152022.0681c180@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 10 May 2005 15:20:47 +0900 To: Tim Bray , Robin Cover From: Martin Duerst Subject: Re: the "atom:copyright" element Cc: Atom WG In-Reply-To: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> References: <720917b9a58c665f2ed9a45f5dfafcb2@sun.com> 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 01:08 05/05/09, Tim Bray wrote: > >On May 7, 2005, at 3:29 PM, Robin Cover wrote: > >> The publication of a new Implementation Guideline by the >> Open Archives Initiative (OAI) compels me to suggest once >> again [1], as Norm Walsh [2], Bob Wyman [3], and others have >> done before, that the name 'atom:rights' would be better >> than the (current) element name 'atom:copyright'. > >+1 +1 here too. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue May 10 21:20:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10597 for ; Tue, 10 May 2005 21:20: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 j4B1BxmU081101; Tue, 10 May 2005 18:11: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 j4B1BxuZ081097; Tue, 10 May 2005 18:11:59 -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 j4B1BsPr081071; Tue, 10 May 2005 18:11:58 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4B1Bmm16336; Wed, 11 May 2005 10:11:48 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f3e53c6a_c1ba_11d9_9bac_0030482532aa_17666; Wed, 11 May 2005 10:21:08 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005AF7; 11 May 05 10:14:21 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 11 May 05 10:14:16 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005AF4; 11 May 05 10:14:15 +0900 Message-Id: <6.0.0.20.2.20050510160912.06827140@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 10 May 2005 16:15:02 +0900 To: Paul Hoffman , Tim Bray , Robert Sayre From: Martin Duerst Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax In-Reply-To: References: <68fba5c50505091852aee94ab@mail.gmail.com> 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 Hello Paul, What's the difference between "IETF consensus" (for which you gave a -1) and "it's up to the IESG" (which seems what you think we should let happen)? In my view, "IETF consensus" is another way of saying the IESG has the last word. If there is a better way to express this in the spec, then what would that be? Or would we say that because the atom namespace appears in an IETF spec, it's obvious that only the IETF (thus ultimately the IESG) can add stuff, but we don't have to say so? Regards, Martin. At 11:57 05/05/10, Paul Hoffman wrote: > >At 7:22 PM -0700 5/9/05, Tim Bray wrote: >>On May 9, 2005, at 6:52 PM, Robert Sayre wrote: >> >>> >>>I think we should be clearer that new elements in the Atom namespace >>>and unprefixed attributes with parent elements in the Atom namespace >>>can only be added by IETF consensus. Thoughts? >> >>I wonder if there's some standard IETF practice when you define a language as regards future change control? > >No. Nearly every protocol tries to go its own way. It's a mess. > >>Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim > >Agree on the -1. > >At 10:34 PM -0400 5/9/05, Robert Sayre wrote: >>Fair enough. But can just anyone add stuff to the Atom namespace? > >If the IESG lets them, yes. > >We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. > >--Paul Hoffman, Director >--Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Tue May 10 21:25:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10950 for ; Tue, 10 May 2005 21:25: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 j4B16tv7080832; Tue, 10 May 2005 18:06: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 j4B16tSF080831; Tue, 10 May 2005 18:06:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B16s4O080822 for ; Tue, 10 May 2005 18:06:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4B163t9028133; Wed, 11 May 2005 02:06:12 +0100 (BST) In-Reply-To: <68fba5c50505101722b9cf257@mail.gmail.com> References: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> <564C9633-4E20-4924-B98D-90672A8102EC@mac.com> <68fba5c50505101722b9cf257@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6043B5C7-B0E7-410B-AD70-23BC1CF46E76@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOriginalAttribute Date: Wed, 11 May 2005 02:06:01 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 11 May 2005, at 1:22 am, Robert Sayre wrote: > Hmm. I'd be curious to hear what you think the problem is. Every > system I can think of that does forwarding or versioning assigns > multiple identifiers. Perhaps you have an example system in mind? atompub-format-08: "When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change." Graham From owner-atom-syntax@mail.imc.org Tue May 10 21:26:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10988 for ; Tue, 10 May 2005 21: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 j4B1CmAG081168; Tue, 10 May 2005 18:12: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 j4B1CmOe081167; Tue, 10 May 2005 18:12:48 -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 j4B1Ckq4081158 for ; Tue, 10 May 2005 18:12:46 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4B1CLm16347; Wed, 11 May 2005 10:12:21 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 0739a59e_c1bb_11d9_845f_0030482532aa_17642; Wed, 11 May 2005 10:21:40 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005AF9; 11 May 05 10:14:54 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 11 May 05 10:14:27 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005AF8; 11 May 05 10:14:17 +0900 Message-Id: <6.0.0.20.2.20050510165245.06819890@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 May 2005 10:11:36 +0900 To: Sam Hartman From: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: Henri Sivonen , iesg@ietf.org, Thomas Broyer , Alexey Melnikov , atom-syntax@imc.org, Mark Nottingham , Robert Sayre In-Reply-To: References: <42712C6D.4030905@isode.com> <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> <4277B471.7030100@cegetel.net> <6.0.0.20.2.20050504103606.06cab8a0@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050508153646.06271a90@itmail.it.aoyama.ac.jp> 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 Hello Sam, others, At 22:33 05/05/09, Sam Hartman wrote: > >>>>>> "Martin" == Martin Duerst writes: > > Martin> At 17:29 05/05/07, Henri Sivonen wrote: > >> On May 4, 2005, at 04:39, Martin Duerst wrote: > >>> For free-flowing text, however, the line breaks in the source > >>> and those in the display are not (necessarily) the same, and > >>> so linebreaks have to be changed to spaces for Western > >>> languages, but to nothing for Chinese/Japanese (and most > >>> possibly to a zero-width non-breaking space for Thai), and the > >>> spec has to say something about this. > >> Why would you put line breaks in the CJK source, then? Isn't > >> the > Martin> "problem" solved with the least heuristics by the producer > Martin> not putting breaks there? > > Martin> People in China, Japan, and so on (Korean uses spaces, so > Martin> it's not CJK) tend to use similar tools to those in the > Martin> western world. Tools for editing XML, e.g., usually don't > Martin> make it easy to edit very long lines because they assume > Martin> that such long lines can be broken. So it's not as easy as > Martin> it looks for the producer. > >My personal opinion as someone who is very shortly going to have to >evaluate the atom specification is that you've identified an issue >(space and line breaking) for some languages that should be >considered. Your proposed solution seems highly undesirable in that >it requires us to understand the language of the text being displayed. >In the past we've had all sorts of problems doing that. Your proposed >solution also seems quite complicated. It's the solution that is being adopted for HTML and CSS, based on a lot of experience. See Fantasai's post. This also points to a way to solve this, similar to how this is being addressed by other XML-based specs starting with XHMTL: Assume that getting space collapsing/removal right isn't the job of the XML-based format, but the job of the rendering engine and styling. In that sense, Paul and Scott are right that other XML formats themselves don't deal with that. So I think there would be two possible solutions: - Leave the text as is, with the implication that this includes possible removal of all spacing around line ends in some cases. I.e. answering Alex's question to the negative, even if on the list only. - Being more explicit about what is going on. This may include as little as saying that the details are up to rendering/styling mechanisms such as CSS or XSL-FO, but could go further if deemed necessary. In my eyes, this would be desirable, at least to give implementers (of viewers, not of "Atom processors") some hints. A solution that, explicitly or implicitly, says that languages having word spaces can decently format and indent their XML source, but languages that don't have word spaces have to use very long lines in the source for paragraphs, as suggested by some of the commenters on this list, isn't appropriate at all. >It may well be that the solutions to this problem are worse than the >problem itself. However I think it is important to specifically >understand that is the case rather than failing to solve the problem >because we failed to understand it. The solutions are not worse than the problem itself. But Paul is right that it may not be a good idea for Atom to deal with them, because this is an issue on another layer, which shouldn't be dealt with separately by each format spec. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue May 10 21:44:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12008 for ; Tue, 10 May 2005 21:44: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 j4B1aIpD082785; Tue, 10 May 2005 18:36: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 j4B1aI8q082784; Tue, 10 May 2005 18:36: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1aHig082744 for ; Tue, 10 May 2005 18:36:17 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so136267wra for ; Tue, 10 May 2005 18:36: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=QFbVDF9xvHdK7AC32oNX783MTvsvWjSygWpXvC5MtqP7Fx93PKak+o1dOgkb6IsH8XZGLCgz3KNYS7bE4jZQJERjIo7Y1nN7Nka6As1jVR51qKCZxZLG2vfwJyr4WL0HZBYLACLTDCcIaJMUvmBQ6qFWYyb8EBYnUBwnPJtELyA= Received: by 10.54.116.3 with SMTP id o3mr119756wrc; Tue, 10 May 2005 18:36:12 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 18:36:12 -0700 (PDT) Message-ID: <68fba5c50505101836e602653@mail.gmail.com> Date: Tue, 10 May 2005 21:36:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceOriginalAttribute Cc: atom-syntax In-Reply-To: <6043B5C7-B0E7-410B-AD70-23BC1CF46E76@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2945124E-BD79-11D9-AC04-003065EA6144@geckotribe.com> <564C9633-4E20-4924-B98D-90672A8102EC@mac.com> <68fba5c50505101722b9cf257@mail.gmail.com> <6043B5C7-B0E7-410B-AD70-23BC1CF46E76@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B1aHig082778 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/10/05, Graham wrote: > On 11 May 2005, at 1:22 am, Robert Sayre wrote: > > > Hmm. I'd be curious to hear what you think the problem is. Every > > system I can think of that does forwarding or versioning assigns > > multiple identifiers. Perhaps you have an example system in mind? > > atompub-format-08: > > "When an Atom document is relocated, migrated, syndicated, > republished, exported or imported, the content of its atom:id element > MUST NOT change." No, I mean a deployed system. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 10 22:25:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14282 for ; Tue, 10 May 2005 22:25: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 j4B2G9HS085365; Tue, 10 May 2005 19:16: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 j4B2G93H085364; Tue, 10 May 2005 19:16:09 -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 j4B2G3At085351; Tue, 10 May 2005 19:16:04 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.0.0.20.2.20050510160912.06827140@itmail.it.aoyama.ac.jp> References: <68fba5c50505091852aee94ab@mail.gmail.com> <6.0.0.20.2.20050510160912.06827140@itmail.it.aoyama.ac.jp> Date: Tue, 10 May 2005 18:56:20 -0700 To: Martin Duerst , Tim Bray , Robert Sayre From: Paul Hoffman Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax 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 4:15 PM +0900 5/10/05, Martin Duerst wrote: >What's the difference between "IETF consensus" (for which you gave a -1) >and "it's up to the IESG" (which seems what you think we should let happen)? From RFC 2434: IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 10 22:38:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14961 for ; Tue, 10 May 2005 22: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 j4B2Uflq086563; Tue, 10 May 2005 19:30: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 j4B2UfLg086560; Tue, 10 May 2005 19:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web52007.mail.yahoo.com (web52007.mail.yahoo.com [206.190.39.63]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4B2Ueb9086529 for ; Tue, 10 May 2005 19:30:41 -0700 (PDT) (envelope-from ecomputerd@yahoo.com) Received: (qmail 67139 invoked by uid 60001); 11 May 2005 02:30:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=DZBaeTHCFrKq8OetN3rzy4VZiR6dgJaicKAstRigDXCEi+5yJHgyL3GtSeYm9vgJrPPwEoSH1sFj7tGRUwlslIqjhldC1HrFC9s4zdMnepSqUI9mo0Bzgnx9EfbeoZWdfcXtu/nzTln0ZEAVXpfwimhNRekwmfNlxgwgVt3YyAM= ; Message-ID: <20050511023035.67137.qmail@web52007.mail.yahoo.com> Received: from [68.222.79.96] by web52007.mail.yahoo.com via HTTP; Tue, 10 May 2005 19:30:35 PDT Date: Tue, 10 May 2005 19:30:35 -0700 (PDT) From: Greg Smith Subject: Re: draft-ietf-atompub-protocol-04.txt To: Joe Gregorio Cc: atom-syntax@imc.org, Atom Protocol In-Reply-To: 6667 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: Joe, Thanks for your comments on my comments ;-) >> While we could create a whole series of "entry", >> "generic", and other types, it might be better to >> consider listing for each collection, the acceptable >> Content-Types. >> > >This document is just the 'basic' protocol, where we are describing >the basic mechanisms and collection types. We are >expecting to produce >a further specification that covers editing >collections of other types >of documents, such as templates, etc. In the current specification draft (04), it looks like the "entry" and "generic" both specify identical actions (in the table showing Body/No body versus GET/PUT/DELETE/POST. So the real difference between the two is in the Content-types that each can handle: "generic" is unspecified, while "entry" is only defined as "application/atom+xml" or "application/soap+xml". In addition, the PROTOCOL specifies which ATOM elements are Roundtrip. The advantage of specifying Content-Types as opposed to contents attribute of "entry" and "generic" (and further definitions): 1) immediately gain the ability of the client to discern acceptable Content-Types, something sorely missing from the current specification. 2) immediately gain the advantage of the client being able to determine if it can "talk" to the ATOM URI. (Graphic applications can "talk" to ATOM APP that accept "image/*", audio applications="audio/*", etc) 3) Do not have to amend a specification (or create a new one) in order to handle every single Content-Type. 4) Adding different Content-Types to the allowable formats immediately opens the specification to a wide range of fairly obvious uses in the podcasting, videocasting, *casting. And even in corporate use, building in the parsing of Content-Types makes available any kind of syndicated content whatsoever using the same tools built around the APP specification. The current use of "contents" attribute still may have its place (in resolving duplicate Content-Type applications such as application/atom+xml templates vs. application/atom+xml entries -- but I'm not fully convinced of this example, however, there may be others). And then to cover the other specification listed under contents="entry": you could specify that all application/atom+xml entries provide Roundtrip atom:updated and atom:id elements. I don't *think* that this would adversly impact other uses of atom or APP. Again, just thoughts that I'm happy to debate. I don't want to step on anyone's toes here. Greg Smith Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html From owner-atom-syntax@mail.imc.org Tue May 10 23:31:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18255 for ; Tue, 10 May 2005 23:31: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 j4B3KkAx090079; Tue, 10 May 2005 20:20: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 j4B3Kk9f090078; Tue, 10 May 2005 20:20:46 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B3KiXq090071 for ; Tue, 10 May 2005 20:20:45 -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); Wed, 11 May 2005 13:20:42 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 13:20:26 +1000 Subject: Re: Autodiscovery paces From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <8F243BD0-C6E9-499E-8F64-26C5F8F0F3E6@mac.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 11/5/05 2:24 AM, "Graham" wrote: >> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue > > -1 > > I mainly don't see the point of changing it. The point is that just using 'alternate' is hideously ambiguous, and leads to interoperability problems because you cannot rely on the value of @type to accurately guess whether @href points to a feed or some other document. In the history of feed autodiscovery, the exact syntax was corrected within days of being first announced. Since then it's become popular, even without official documentation in a specification. During that time people have come to realise that there is a problem with 'alternate' ... consider that pre-spec time as being a beta test period ... and now that we are on the verge of releasing a fully documented specification it is our last real opportunity to fix any mistakes. Robert says anyone can mint new @rel types, but seriously, in the face of popular usage of 'alternate' being backed up by a RFC specification, does anyone think 'feed' would have a chance? Put it in the spec and we are saying "use of 'alternate' is flawed, the preferred option is 'feed'", and it will have more potency. > Also, while "alternate" > expressly says the feed corresponds in some way to the content of the > current page, "feed" simply says "here is a feed of some kind", and > isn't a relationship at all. Depends on how you read the word 'feed'. It can indicate a relationship, that being "this is the feed in which an entry representing this page (or portion thereof) was once found, and may again be found". I, like some, feel uncomfortable with those usage of autodiscovery links to point to just any feed, from any page. Links to feed resource documents are not necessarily links to feeds. e. From owner-atom-syntax@mail.imc.org Wed May 11 00:07:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20340 for ; Wed, 11 May 2005 00:07: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 j4B3wZtu092582; Tue, 10 May 2005 20:58: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 j4B3wZSq092581; Tue, 10 May 2005 20:58:35 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B3wYrE092575 for ; Tue, 10 May 2005 20:58:34 -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); Wed, 11 May 2005 13:58:37 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 13:58:22 +1000 Subject: Re: Autodiscovery paces From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B3wZrE092576 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 11/5/05 1:20 PM, "Eric Scheid" wrote: >> Also, while "alternate" >> expressly says the feed corresponds in some way to the content of the >> current page, "feed" simply says "here is a feed of some kind", and >> isn't a relationship at all. > > Depends on how you read the word 'feed'. It can indicate a relationship, > that being "this is the feed in which an entry representing this page (or > portion thereof) was once found, and may again be found". > > I, like some, feel uncomfortable with those usage of autodiscovery links to > point to just any feed, from any page. Links to feed resource documents are > not necessarily links to feeds. On reflection, I thought I'd better check what the spec says... http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html The purpose of Atom autodiscovery is for clients who know the URI of a web page to find the location of that page's associated Atom feed. There is also this in section 6 The order of the autodiscovery elements is significant. The first element SHOULD point to the publisher's preferred feed for the document. ... thus [1] auto-discovery is *not* for the general case of linking to just *any* feed resource, but specifically the one associated to the current page/site. Which is a specific relationship, one we can name 'feed' (or 'fred', or 'barney' ... but 'feed' gets my vote). e. [1] I conclude ... and so might any reader of the spec who is ignorant of the full backstory. From owner-atom-syntax@mail.imc.org Wed May 11 00:08:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20385 for ; Wed, 11 May 2005 00:08: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 j4B3wKlY092570; Tue, 10 May 2005 20:58: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 j4B3wKXt092569; Tue, 10 May 2005 20:58:20 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B3wC38092553 for ; Tue, 10 May 2005 20:58:19 -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); Wed, 11 May 2005 13:58:14 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 May 2005 13:57:58 +1000 Subject: Re: Autodiscovery paces From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <14be96d3050510081866b90ab3@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 11/5/05 1:18 AM, "Mark Pilgrim" wrote: >> http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue > > +0. Part of my newfound personal definition of a life well-lived is > to never again argue about semantics, markup, or the "correct" way to > use them. This Pace will break every aggregator on the planet, but > then again, so will Atom 1.0 feeds, so... +0. :-) My belief is that RSS/Atom is at the point of crossing the chasm [1] and going mainstream, and as such if we want the momentum to continue we should be mindful of two things: * adding features/functions/tweaks which appeal to geeks and other 'insiders' is counter-productive * not fixing any warts or bugs which non-geeks won't understand why they get broken behaviour is counter-productive. There is thus a filter to be applied to any suggestions for "improvements". Changing 'alternative' to 'feed' fits the second criteria, but adding fits the first. So, +1 to PaceDifferentRelValue, -1 to PaceAnchorSupport. e. [1] http://en.wikipedia.org/wiki/Crossing_the_Chasm From owner-atom-syntax@mail.imc.org Wed May 11 00:24:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21512 for ; Wed, 11 May 2005 00:24: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 j4B4F42V093512; Tue, 10 May 2005 21:15: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 j4B4F4ku093511; Tue, 10 May 2005 21:15:04 -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 j4B4F315093487 for ; Tue, 10 May 2005 21:15:03 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so202600wra for ; Tue, 10 May 2005 21:14:57 -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=Uy/f4Ej8iycrMdQJGUWwb1aJahAAqodooTarS4dCUlSxVMEmO8imWV/97dfxdd1KhPUa//5J90mRP6jfTeCbGN34+nzdRXgd9n69FAn4UFrqY4uG3ORpD75ooJShOLE9KUgZN8EiQ7949zyd6Lr/M66vqEo8AbcD+K/Sy4IzWTo= Received: by 10.54.51.78 with SMTP id y78mr202625wry; Tue, 10 May 2005 21:14:57 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Tue, 10 May 2005 21:14:57 -0700 (PDT) Message-ID: <68fba5c50505102114188a3b38@mail.gmail.com> Date: Wed, 11 May 2005 00:14:57 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Atom Syntax In-Reply-To: <68fba5c50505092001339ea585@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B4F315093499 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/9/05, Robert Sayre wrote: > I am fine with that. I am concerned that the current draft fails to > differentiate between "foreign markup" and "markup that requires IESG > approval". I am going to try this again, because it's important. ... ... Legal? Which part of the spec rules it out? Maybe I've read it too many times and I'm missing something. Common sense would seem to outlaw it, but that's not good enough. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 06:09:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18785 for ; Wed, 11 May 2005 06:09: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 j4B9xnNJ013433; Wed, 11 May 2005 02:59: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 j4B9xnFI013432; Wed, 11 May 2005 02:59: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 j4B9xnac013424 for ; Wed, 11 May 2005 02:59:49 -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 j4B9xmi7009872 for ; Wed, 11 May 2005 03:59:48 -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 <0IGB001V0L3O4O@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 11 May 2005 03:59:48 -0600 (MDT) Received: from [10.1.2.44] ([220.220.255.84]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGB00AE3L3MO6@mail.sun.net> for atom-syntax@imc.org; Wed, 11 May 2005 03:59:48 -0600 (MDT) Date: Wed, 11 May 2005 03:00:56 -0700 From: Tim Bray Subject: Re: Atom 1.0? In-reply-to: <68fba5c505051013275c485497@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax , Walter Underwood Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 10, 2005, at 1:27 PM, Robert Sayre wrote: >> If we choose a specific name, it *must* be in the RFC. Because the RFC >> must be a hit for that search. > Marketing: Atom > Technical: Atom (RFCxxxx) I was gonna suggest that too. I think RFC's are into the 4000-space these days so if we end up as RFC4321 we could call it "Atom 4321" and "Atom [see RFC4321]". -Tim From owner-atom-syntax@mail.imc.org Wed May 11 09:52:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05050 for ; Wed, 11 May 2005 09:52: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 j4BDgTP9094433; Wed, 11 May 2005 06:42: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 j4BDgSCq094432; Wed, 11 May 2005 06:42:28 -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 j4BDgSgJ094424 for ; Wed, 11 May 2005 06:42:28 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so402580nzp for ; Wed, 11 May 2005 06:42:22 -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=r7qJ7i9nQQNX6e51qmkKgqmP9LNVyWRqAlDvQ/5NilbnNkk0tmoPUUNtCrM/9i9TCYJYn1OzIdBRLOul1mT8+sycsdKxgEfS9IkIqHszvG0ZAIMNyBzWCO2mNaw88zLtqVzt7M9yfduiAwU6D2xDBp0ym5YpOIcLW3CeP1wlr58= Received: by 10.36.119.4 with SMTP id r4mr163786nzc; Wed, 11 May 2005 06:42:22 -0700 (PDT) Received: by 10.36.49.17 with HTTP; Wed, 11 May 2005 06:42:22 -0700 (PDT) Message-ID: <1f2ed5cd050511064257cb42ca@mail.gmail.com> Date: Wed, 11 May 2005 15:42:22 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Atom 1.0? Cc: Robert Sayre , Atom Syntax , Walter Underwood In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BDgSgJ094427 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > Marketing: Atom > > Technical: Atom (RFCxxxx) +1 -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed May 11 09:54:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05135 for ; Wed, 11 May 2005 09: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 j4BDjjFs094717; Wed, 11 May 2005 06:45: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 j4BDjjiB094716; Wed, 11 May 2005 06:45: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BDjiD6094708 for ; Wed, 11 May 2005 06:45:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so456993wra for ; Wed, 11 May 2005 06:45: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=AUTA2WasShHZYQsF7ynBytQv9gjkkA+m6YQ0f68mkFsDDKPkmCw3NgO1Odk0lJ/v4yTRXjHph6ksOzzSz2yfLUSc1zAHCrq/A7tWk5P6YZfVoadhUFiNb4UGweqcrNydITEzRYF+9w6WCEtA/r8dY7yBK3eejMoaPkgTADjv2jo= Received: by 10.54.41.77 with SMTP id o77mr469350wro; Wed, 11 May 2005 06:45:39 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 06:45:39 -0700 (PDT) Message-ID: <68fba5c5050511064566e7d5f1@mail.gmail.com> Date: Wed, 11 May 2005 09:45:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Danny Ayers Subject: Re: Atom 1.0? Cc: Tim Bray , Atom Syntax , Walter Underwood In-Reply-To: <1f2ed5cd050511064257cb42ca@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BDjiD6094711 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Danny Ayers wrote: > > > Marketing: Atom > > > Technical: Atom (RFCxxxx) > > +1 Hmm. I forgot one little detail. It might take like 4-6 months to get an RFC number after IESG approval. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 10:42:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09793 for ; Wed, 11 May 2005 10:42: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 j4BEUcn6098783; Wed, 11 May 2005 07:30: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 j4BEUckc098782; Wed, 11 May 2005 07:30: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 j4BEUa7u098755 for ; Wed, 11 May 2005 07:30:36 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 11 May 2005 14:30:29 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.5.201.10] by mail.gmx.net (mp014) with SMTP; 11 May 2005 16:30:29 +0200 X-Authenticated: #1915285 Message-ID: <42821703.2060504@gmx.de> Date: Wed, 11 May 2005 16:30:27 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Danny Ayers , Tim Bray , Atom Syntax , Walter Underwood Subject: Re: Atom 1.0? References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> <68fba5c5050511064566e7d5f1@mail.gmail.com> In-Reply-To: <68fba5c5050511064566e7d5f1@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 5/11/05, Danny Ayers wrote: > >>>>Marketing: Atom >>>>Technical: Atom (RFCxxxx) >> >>+1 > > > Hmm. I forgot one little detail. It might take like 4-6 months to get > an RFC number after IESG approval. Or even longer. Draft 08 says about the Atom namespace: [[anchor4: This paragraph to be removed by the RFC Editor. The namespace here is a temporary one and will be changed when the IESG approves this document as a standard. At that time, the namespace will be drawn from W3C URI space. The choice of that namespace will be coordinated between the IETF and W3C through their respective liaisons.]] So when IESG approval happens and the draft is added to the RFC Editor's publication queue, do we advertise the "final" namespace (and how?). If we don't, no software can support the Atom "1.0" format until the RFC is actually published... Best regards, Julian From owner-atom-syntax@mail.imc.org Wed May 11 10:52:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10468 for ; Wed, 11 May 2005 10: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 j4BEj4dr000739; Wed, 11 May 2005 07:45: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 j4BEj4e8000738; Wed, 11 May 2005 07:45:04 -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 j4BEj2Gv000730 for ; Wed, 11 May 2005 07:45:03 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:59209 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228773AbVEKOpB (ORCPT ); Wed, 11 May 2005 17:45:01 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <1f2ed5cd050511064257cb42ca@mail.gmail.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6db2ae2154b1cd34241d81045ba43766@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Atom 1.0? Date: Wed, 11 May 2005 17:44:43 +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 >>> Marketing: Atom I'm looking forward to an article by Mark Pilgrim about the incompatible versions of Atom deceitfully marketed as one thing. :-) (Which is why I said +1 to Atom 1.0.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 11 11:02:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11317 for ; Wed, 11 May 2005 11:02: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 j4BEsK7X001563; Wed, 11 May 2005 07:54: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 j4BEsK73001562; Wed, 11 May 2005 07:54:20 -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 j4BEsJ64001547 for ; Wed, 11 May 2005 07:54:19 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 67125 messnum 6676122 invoked from network[83.70.217.193/unknown]); 11 May 2005 14:54:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 67125) with SMTP; 11 May 2005 14:54:12 -0000 Message-ID: <42821C90.708@dehora.net> Date: Wed, 11 May 2005 15:54:08 +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: Atom 1.0? References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> <6db2ae2154b1cd34241d81045ba43766@iki.fi> In-Reply-To: <6db2ae2154b1cd34241d81045ba43766@iki.fi> 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 Henri Sivonen wrote: > >>>> Marketing: Atom > > > I'm looking forward to an article by Mark Pilgrim about the incompatible > versions of Atom deceitfully marketed as one thing. :-) > > (Which is why I said +1 to Atom 1.0.) ARSS, short for Atom RSS. The marketing possibilities are endless. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 11 11:14:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12510 for ; Wed, 11 May 2005 11:14: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 j4BF5uA1002607; Wed, 11 May 2005 08:05: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 j4BF5uWq002606; Wed, 11 May 2005 08:05: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 j4BF5sFb002592 for ; Wed, 11 May 2005 08:05:55 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 11 May 2005 15:05:48 -0000 Received: from xdsl-213-196-247-130.netcologne.de (EHLO klangraum) [213.196.247.130] by mail.gmx.net (mp013) with SMTP; 11 May 2005 17:05:48 +0200 X-Authenticated: #163624 Date: Wed, 11 May 2005 17:09:09 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Atom 1.0? Message-ID: <20050511150909.GA4286@klangraum> Mail-Followup-To: Atom Syntax References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> <6db2ae2154b1cd34241d81045ba43766@iki.fi> <42821C90.708@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42821C90.708@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: 8bit * Bill de hÓra [2005-05-11 17:05]: > ARSS, short for Atom RSS. The marketing possibilities are > endless. How about Atom Syndication Standard? I guess the Firefox crowd can then resurrect the non-Wifi looking autodiscovery icon. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed May 11 11:50:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17440 for ; Wed, 11 May 2005 11:50: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 j4BFciWh006335; Wed, 11 May 2005 08:38: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 j4BFciIv006334; Wed, 11 May 2005 08:38:44 -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 j4BFchqX006307 for ; Wed, 11 May 2005 08:38:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so534184wra for ; Wed, 11 May 2005 08:38:38 -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=ltA6UScmx3U0IuIOpoW7weZ78O+YM8pEsyB2FfxH+vYwPiPdii+wnfY294CAodd3PYW17/bdCDdnJBtJlkrcu7sDxIsueZ5623RLmxcvXoinXdoJgndYAvLK3sXkRMUD1h9b+qB/464lJMDKqBMKtDrXZHLjJ9mU4aM0y+W6pW0= Received: by 10.54.141.10 with SMTP id o10mr538620wrd; Wed, 11 May 2005 08:38:38 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 08:38:38 -0700 (PDT) Message-ID: <68fba5c505051108385062f2e7@mail.gmail.com> Date: Wed, 11 May 2005 11:38:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Fetch Me A Rock 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 j4BFchqX006329 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "Fetch me a rock. No, not that one. Fetch me another. Now jump through this hoop." I think the reason there is no "consensus" on-list is because Sam and Graham are trying to make normative requirements without outlining the operational result they are after. I am disappointed we are putting up with it, but I am not surprised. They'll give you ten different definitions of SHOULD, but there's only one that matters. Remember, if we say SHOULD, that means implementations don't have to interoperate with people who don't provide a summary. That does not mean 'doesn't display' or 'doesn't index', despite what some would have you believe. It means the Atom Processor is allowed to fail. It doesn't matter if that's not what we meant. The document's meaning would be unambiguous. SHOULD does not mean "encourage". Remember that. I'm not going argue any more. My opinion is clear, strong, and supported by many others. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 12:04:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18816 for ; Wed, 11 May 2005 12:04: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 j4BFvAJT007855; Wed, 11 May 2005 08:57: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 j4BFvAgb007854; Wed, 11 May 2005 08:57:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BFv9nH007846 for ; Wed, 11 May 2005 08:57:09 -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 (rwcrmhc13) with SMTP id <2005051115565801500pfklue>; Wed, 11 May 2005 15:57:04 +0000 Date: Wed, 11 May 2005 09:56:52 -0600 Subject: Re: Atom 1.0? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <20050511150909.GA4286@klangraum> Message-Id: <4AC27F32-C235-11D9-B2A6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BFvAnH007849 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, May 11, 2005, at 09:09 AM, A. Pagaltzis wrote: > * Bill de hra [2005-05-11 17:05]: >> ARSS, short for Atom RSS. The marketing possibilities are >> endless. > > How about Atom Syndication Standard? So, ASS = Atom Syndication Standard. Or is it Atom Standard for Syndication? Or is it Atom Site Summary? ARSS = Atom Really Simple Syndication ARSS = Atom Rich Site Summary ARSS = Atom Replacement Syndication Standard ARS = Atom Reformed Syndication ARSE = Atom Revolutionary Syndication Experiment ANR = Atom is Not RSS ... I guess that should be ANR is Not RSS ANA0.3 = Atom is Not Atom 0.3, or ANA0.3 is Not Atom 0.3 Hey, maybe ATOM is an acronym and we didn't even know it. A Tired Old Metaphor. Hmm, not so good. A new Twist on an Old Method. Too many missing letters to explain away. After The Old Method. Same message, right letters. A Trick, Or Magic? From section 7. IANA Considerations: 'Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2.'--must be magic! From owner-atom-syntax@mail.imc.org Wed May 11 12:33:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21858 for ; Wed, 11 May 2005 12:33: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 j4BGPSOd010865; Wed, 11 May 2005 09:25: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 j4BGPSuT010864; Wed, 11 May 2005 09:25:28 -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 j4BGPS7F010854 for ; Wed, 11 May 2005 09:25:28 -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 <2005051116251901200pro3ve>; Wed, 11 May 2005 16:25:20 +0000 Date: Wed, 11 May 2005 10:25:13 -0600 Subject: PaceOriginalAttribute (was Re: Fetch Me A Rock) 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: <68fba5c505051108385062f2e7@mail.gmail.com> Message-Id: <40A0B5F2-C239-11D9-B2A6-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, May 11, 2005, at 09:38 AM, Robert Sayre wrote: > I think the reason there is no "consensus" on-list is because Sam and > Graham are trying to make normative requirements without outlining the > operational result they are after. What was the operation result you were after with this Pace? I haven't yet seen an explanation of how this solves any problem. Can you step us through the process that one would use under this proposal to: detect duplicates, detect DOS attempts, or any other goals relevant to the Pace? Can you explain how this Pace changes and/or improves the process or its results over the current draft? > +1 > > I'm not 100% convinced it solves the problems Rob says it does, but it > seems cheap, lightweight, and unlikely to cause any harm. -Tim Especially this late in the game, doesn't a proposal have to clear a higher bar than this to be accepted? > > It doesn't address the DOS problem--neither > > accidental nor intentional. > > Oh yes it does. Each entry's provenance is documented. The data format > accurately states that the intermediary has munged the original entry. If it does solve the DOS problem (if), then as far as I can tell, it does it by reintroducing the duplicates problem. Does an aggregator show both the original and the copy, or just one of the two? What happens when someone spoofs both the feed ID and the entry ID? Also, a more general question directed to everyone (not people other than Robert couldn't respond to the above, of course)--if someone republishes an entry from another feed, how much/in what ways may they annotate or otherwise alter it while preserving the original ID? Adding elements to annotate it might be fair game. Modifying the contents of existing elements feels out of bounds--that makes it a different entry. It can LINK to the original (...if there is a way to link to the original) in that case, but it isn't the original anymore. What about dropping elements from the original (eg. dropping atom:content, and keeping only atom:summary)? From owner-atom-syntax@mail.imc.org Wed May 11 14:08:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28745 for ; Wed, 11 May 2005 14:08: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 j4BI06QN019416; Wed, 11 May 2005 11:00: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 j4BI06af019415; Wed, 11 May 2005 11:00: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BI03tg019398 for ; Wed, 11 May 2005 11:00:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so627058wra for ; Wed, 11 May 2005 10:59: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=BFxMAKNxmRzNrf8DXF8UGKww25y1+nJE549HoRmBPH/8GlKYEoBXiC3ekKjWzLSL7/cIE1MqiIkxVw3Qwh+J1VefoXy+WYaNtajCVpPPAsCnMnF+/paoGw/i07irRcEvkPsjmLkEDC2truzWJHa0I54MlqsPSDs+8FOk6y8bgDk= Received: by 10.54.76.2 with SMTP id y2mr602614wra; Wed, 11 May 2005 10:59:58 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 10:59:58 -0700 (PDT) Message-ID: <68fba5c505051110593e2c4bf1@mail.gmail.com> Date: Wed, 11 May 2005 13:59:58 -0400 From: Robert Sayre Reply-To: Robert Sayre To: iesg@ietf.org Subject: Re: Last Call: required summary or content? Cc: Robert Sayre , Sam Hartman , Atom-Syntax In-Reply-To: <426D85D1.7060602@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BI04tg019410 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit There's one more issue that I would like to make the IESG aware of before it evaluates the Atom Syndication Format. I don't believe the format satisfies the Atompub charter: The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The current draft fails to satisfy the second bullet point. Robert Sayre P.S. -- Here are a couple of messages underscoring that atom:summary and atom:content both serve as "enclosed content". Tim Bray: http://www.imc.org/atom-syntax/mail-archive/msg14155.html Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html On 4/25/05, Sam Ruby wrote: > > Robert Sayre wrote: > > > >> * What the specification does currently > > > > In an Atom Entry, the specification currently requires a minimum set of > > elements: , <id>, and <updated>. Typically, there will also be a > > <link> element. The specification includes a provision that allows its > > omission on the condition that there is a <content> element. In addition > > to that, the specification requires that either <summary> or <content> > > be present. > > > >> * What you would like it to do instead > > > > I want to allow the metadata-only feeds allowed by all flavors of RSS, > > and the omission of the <content> and <summary>. Such feeds are commonly > > termed "title-only feeds", because that is all that is visible to the > > user (the title is usually hyperlinked w/ the link element). > > I will again point out that the current format allows for empty summary > and/or content elements. > > I have seen errors that the requirement for the inclusion of such > elements would have prevented. > > I have seen no arguments as to why placing such empty elements would > impose an unreasonable burden on implementers. > > - Sam Ruby > > From owner-atom-syntax@mail.imc.org Wed May 11 14:17:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29595 for <atompub-archive@lists.ietf.org>; Wed, 11 May 2005 14:17: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 j4BIBNLE020131; Wed, 11 May 2005 11:11: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 j4BIBN26020130; Wed, 11 May 2005 11:11:23 -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 j4BIBLKV020124 for <atom-syntax@imc.org>; Wed, 11 May 2005 11:11:22 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06210219bea7fb0826ef@[10.20.30.249]> In-Reply-To: <68fba5c50505102114188a3b38@mail.gmail.com> References: <68fba5c50505091852aee94ab@mail.gmail.com> <e792010e511bc826ebaf6f0ee090bf19@sun.com> <p06210219bea5d2be9f38@10.20.30.249> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> Date: Wed, 11 May 2005 11:11:18 -0700 To: Atom WG <atom-syntax@imc.org> From: Paul Hoffman <phoffman@imc.org> Subject: Re: extensions -- Atom NS and unprefixed attributes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 12:14 AM -0400 5/11/05, Robert Sayre wrote: >On 5/9/05, Robert Sayre <sayrer@gmail.com> wrote: > >> I am fine with that. I am concerned that the current draft fails to >> differentiate between "foreign markup" and "markup that requires IESG >> approval". > >I am going to try this again, because it's important. > ><entry fooBar="true"> > <title>... > > ... > > >Legal? Which part of the spec rules it out? Maybe I've read it too >many times and I'm missing something. Common sense would seem to >outlaw it, but that's not good enough. Hearing from as many people who feel that they understand the "XML rules" would be very good right about now... --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 11 14:20:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00070 for ; Wed, 11 May 2005 14: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 j4BIDGP6020282; Wed, 11 May 2005 11:13: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 j4BIDGZB020281; Wed, 11 May 2005 11:13:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BIDFMH020266 for ; Wed, 11 May 2005 11:13:15 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4BICbXm026386; Wed, 11 May 2005 19:12:43 +0100 (BST) In-Reply-To: <68fba5c505051110593e2c4bf1@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Last Call: required summary or content? Date: Wed, 11 May 2005 19:12:36 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 11 May 2005, at 6:59 pm, Robert Sayre wrote: > There's one more issue that I would like to make the IESG aware of > before it eval.. (etc) Can you please do something constructive and suggest language you'd find acceptable, and y'know, help reach consensus? Graham From owner-atom-syntax@mail.imc.org Wed May 11 14:23:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00290 for ; Wed, 11 May 2005 14:23: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 j4BICErx020197; Wed, 11 May 2005 11:12: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 j4BICEv6020196; Wed, 11 May 2005 11:12:14 -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 j4BICCvZ020190 for ; Wed, 11 May 2005 11:12:13 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c5050511064566e7d5f1@mail.gmail.com> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> <68fba5c5050511064566e7d5f1@mail.gmail.com> Date: Wed, 11 May 2005 11:12:10 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Atom 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: At 9:45 AM -0400 5/11/05, Robert Sayre wrote: >On 5/11/05, Danny Ayers wrote: >> > > Marketing: Atom >> > > Technical: Atom (RFCxxxx) >> >> +1 > >Hmm. I forgot one little detail. It might take like 4-6 months to get >an RFC number after IESG approval. s/might/probably will/ --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 11 14:23:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00381 for ; Wed, 11 May 2005 14:23: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 j4BIDiOc020341; Wed, 11 May 2005 11:13: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 j4BIDicV020340; Wed, 11 May 2005 11:13:44 -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 j4BIDhkU020331 for ; Wed, 11 May 2005 11:13:43 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42821703.2060504@gmx.de> References: <4291d2e71f8d649e88d30fd250e83936@sun.com> <1F7D0D5607FCC2A44E7D4AF7@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <82CD76A9908C76204EAB857F@diva.verity.com> <68fba5c505051013275c485497@mail.gmail.com> <1f2ed5cd050511064257cb42ca@mail.gmail.com> <68fba5c5050511064566e7d5f1@mail.gmail.com> <42821703.2060504@gmx.de> Date: Wed, 11 May 2005 11:13:41 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Atom 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: At 4:30 PM +0200 5/11/05, Julian Reschke wrote: >So when IESG approval happens and the draft is added to the RFC >Editor's publication queue, do we advertise the "final" namespace >(and how?). Yes, and on this mailing list and in a new draft whose one change (unless the IESG has asked for others) is to fill in that value and remove the note. > If we don't, no software can support the Atom "1.0" format until >the RFC is actually published... Exactly right. So we won't do that. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 11 15:07:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09204 for ; Wed, 11 May 2005 15:06: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 j4BIsR70023466; Wed, 11 May 2005 11: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 j4BIsRIM023465; Wed, 11 May 2005 11:54:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BIsRKP023456 for ; Wed, 11 May 2005 11:54:27 -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 (rwcrmhc13) with SMTP id <2005051118542101500pdm81e>; Wed, 11 May 2005 18:54:21 +0000 Date: Wed, 11 May 2005 12:54:19 -0600 Subject: Re: extensions -- Atom NS and unprefixed attributes 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: <14EE89B4-C24E-11D9-B2A6-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, May 11, 2005, at 12:11 PM, Paul Hoffman wrote: >> >> ... >> >> ... >> >> >> Legal? Which part of the spec rules it out? Maybe I've read it too >> many times and I'm missing something. Common sense would seem to >> outlaw it, but that's not good enough. > > Hearing from as many people who feel that they understand the "XML > rules" would be very good right about now... > I'm no expert on the actual rules, but here's my take: * HTML has no concept of namespaces, so when people invent a new tag, they don't give it a unique prefix. XML has namespaces, so when inventing new elements, common sense and past experience suggest putting them in a namespace under the control of the inventor. * Atom is being defined by an RFC, in which the namespace is also specified. Common sense suggests that without updating or obsoleting that RFC, new elements can't be added to that namespace unless the RFC itself defines a method for that being done. * Common sense suggests that allowing third parties to insert elements into someone else's namespace makes little more sense than allowing third parties to change the definition of elements in someone else's namespace, which would clearly be ridiculous. * If somebody publishes the above, who's going to do anything with evilExtension? Nobody's going to know what it is, so it won't be processed, and won't do anything evil. If it is evil, it won't get popular enough to be supported. Even if it's not evil, I can't imagine it getting popular without a lot of people screaming about how it needs its own namespace, and thus it getting its own namespace. * I presume the feed validator would choke on the above, right? Question--do RFCs for any other XML formats explicitly state that something like the above is illegal? If not, then I can't imagine we need to worry about it. I'd think that if it needs to be stated explicitly that the above it illegal, unless putting things into others' namespaces was specifically intended to be allowed, the appropriate place for it would be in the namespace spec--not the specs for every XML format that uses namespaces. From owner-atom-syntax@mail.imc.org Wed May 11 15:13:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10093 for ; Wed, 11 May 2005 15:13: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 j4BJ6e09024392; Wed, 11 May 2005 12:06: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 j4BJ6ego024391; Wed, 11 May 2005 12:06:40 -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 j4BJ6d7t024385 for ; Wed, 11 May 2005 12:06:39 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:62062 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228684AbVEKTGh (ORCPT ); Wed, 11 May 2005 22:06:37 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <14EE89B4-C24E-11D9-B2A6-003065EA6144@geckotribe.com> References: <14EE89B4-C24E-11D9-B2A6-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <067e9d77ef1aef645256aa7c6161ab85@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: extensions -- Atom NS and unprefixed attributes Date: Wed, 11 May 2005 22:06:20 +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 May 11, 2005, at 21:54, Antone Roundy wrote: > * HTML has no concept of namespaces, so when people invent a new tag, > they don't give it a unique prefix. XML has namespaces, so when > inventing new elements, common sense and past experience suggest > putting them in a namespace under the control of the inventor. Except it is pragmatic (in the sense of avoiding xmlns cruft) to put them in the NS of the language being extended. This is more likely happen if the original controller of the namespace neglects the language. Case point: XHTML and WHAT WG. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 11 17:48:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29570 for ; Wed, 11 May 2005 17:48: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 j4BLfjoW035738; Wed, 11 May 2005 14:41: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 j4BLfjkX035737; Wed, 11 May 2005 14:41: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 j4BLfiVk035730 for ; Wed, 11 May 2005 14:41:44 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 88539 invoked by uid 17064); 11 May 2005 21:41:42 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.6.57]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 11 May 2005 21:41:42 -0000 In-Reply-To: <68fba5c505051108385062f2e7@mail.gmail.com> References: <68fba5c505051108385062f2e7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <457649A2-5103-4D74-B42B-4ED1AE51E1C2@bblfish.net> Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Fetch Me A Rock Date: Wed, 11 May 2005 23:41:41 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Replying to the note mentioned in Antone Roundy's blog entry [1] I would say that there are only 2 things that need to be a MUST in entries appearing in a feed are: - atom:id - atom:updated The above assumes the atom:id can be used to dereference the entry. If it can't another url needs to be provided that can be used to dereference the entry. But that is all that is needed in a feed. A feed is just a list of state changes to resources that readers of the feed may be interested in knowing about. Henry [1] http://www.geckotribe.com/ibl/b/2005/05/too-many-cooks-spoil-feed- format.php On 11 May 2005, at 17:38, Robert Sayre wrote: > > "Fetch me a rock. No, not that one. Fetch me another. Now jump > through this hoop." > > I think the reason there is no "consensus" on-list is because Sam and > Graham are trying to make normative requirements without outlining the > operational result they are after. > > I am disappointed we are putting up with it, but I am not surprised. > They'll give you ten different definitions of SHOULD, but there's only > one that matters. Remember, if we say SHOULD, that means > implementations don't have to interoperate with people who don't > provide a summary. That does not mean 'doesn't display' or 'doesn't > index', despite what some would have you believe. It means the Atom > Processor is allowed to fail. It doesn't matter if that's not what we > meant. The document's meaning would be unambiguous. > > SHOULD does not mean "encourage". Remember that. > > I'm not going argue any more. My opinion is clear, strong, and > supported by many others. > > Robert Sayre > From owner-atom-syntax@mail.imc.org Wed May 11 18:07:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01659 for ; Wed, 11 May 2005 18:07: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 j4BLwic3036670; Wed, 11 May 2005 14:58: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 j4BLwiZV036669; Wed, 11 May 2005 14:58:44 -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 j4BLwhE7036661 for ; Wed, 11 May 2005 14:58:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so766145wra for ; Wed, 11 May 2005 14:58:37 -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=kBUNuJxLoCkYuomDA9sTW0FXSo7tEQDxagot2QC2brZ6H//hmu9e/EpR879qYmWd1rUYZtwvjRUzKRS3FDP9yMJ44rrhuSP+A+pw5YUXjWqghHjnIWStgiWI9iusLTK3+KeLIomxf9r6WE1ZvWb8gYKvDmxSidKByaQiYQ08bAQ= Received: by 10.54.26.45 with SMTP id 45mr670216wrz; Wed, 11 May 2005 14:58:37 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 14:58:37 -0700 (PDT) Message-ID: <68fba5c5050511145827dfa73f@mail.gmail.com> Date: Wed, 11 May 2005 17:58:37 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Last Call: required summary or content? Cc: atom-syntax In-Reply-To: <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BLwhE7036664 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Graham wrote: > Can you please do something constructive and suggest language you'd > find acceptable, and y'know, help reach consensus? I made a couple of suggestions here: http://www.imc.org/atom-syntax/mail-archive/msg15086.html I don't know what your goal is, so I'm just throwing things out there to see if they're what you want. Please explain your problems with each option, and I will try to work with you. Please note that the interests of other implementors and users may not line up with yours. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 19:20:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09053 for ; Wed, 11 May 2005 19:20: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 j4BNBLOE042415; Wed, 11 May 2005 16:11: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 j4BNBLmB042414; Wed, 11 May 2005 16:11:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BNBKvm042404 for ; Wed, 11 May 2005 16:11:20 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4BNB1ae006570; Thu, 12 May 2005 00:11:07 +0100 (BST) In-Reply-To: <68fba5c5050511145827dfa73f@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Last Call: required summary or content? Date: Thu, 12 May 2005 00:11:01 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 11 May 2005, at 10:58 pm, Robert Sayre wrote: > I don't know what your goal is, so I'm just throwing things out there > to see if they're what you want. Please explain your problems with > each option, and I will try to work with you. Please note that the > interests of other implementors and users may not line up with yours. The "Implementor's Guide" may or may not ever exist and may or may not be read by anyone, so that isn't an option. Myself and Sam, and (I think) Tim and Antone, would all like the actual spec to make an actual recommendation that entries without enclosed content include a textual summary, if at all possible. Note no one wants to ban title- only feeds if they come from title-only resources. What language would you find acceptable that covers these bases? Graham From owner-atom-syntax@mail.imc.org Wed May 11 19:51:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10686 for ; Wed, 11 May 2005 19:51: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 j4BNesLR044561; Wed, 11 May 2005 16:40: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 j4BNesMF044560; Wed, 11 May 2005 16:40:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BNerb8044550 for ; Wed, 11 May 2005 16:40:54 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050511234047.EXEN26549.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Thu, 12 May 2005 00:40:47 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050511234047.DSND24880.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Thu, 12 May 2005 00:40:47 +0100 Date: Thu, 12 May 2005 00:40:45 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC4) Professional X-Priority: 3 (Normal) Message-ID: <1139593020.20050512004045@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: PaceAllowDuplicateIDs In-Reply-To: <73eb986f1cca36c77bfae6708e448e52@sun.com> References: <73eb986f1cca36c77bfae6708e448e52@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 I'm in favour of allowing duplicate ids. This only seems to be a partial solution though: "Their atom:updated timestamps SHOULD be different" But what if they are not? What if I want to represent an archive of a feed - maybe mine, maybe someone else's - but the atom:updated dates are the same in two or more entries? I thought it was up to the publisher to decide whether to rev atom:updated. I was always concerned that the existence of atom:updated without atom:modified would cause the meaning of atom:updated as an alert to be diluted to being equivalent to atom:modified. This proposal would encourage that. It would mean, if you don't update atom:updated, then your entry instances are second class. The restriction forces services that proxy, or re-aggregate feeds to drop entries on the floor, just because the user has chosen not to update atom:updated. atom:updated encourages aggregators to make loud noises when they see a change; anything that encourages atom:updated to be changed just for the sake of it is going to be very annoying to users and make atom:updated useless as an alert flag. I'm in favour of duplicate ids, but unfortunately, the only way I can see them working is if we have atom:modified. I hate to bring this up, especially now, but it would solve some problems, and it is cheap to implement: Is anyone still opposed to atom:modified? -- Dave From owner-atom-syntax@mail.imc.org Wed May 11 20:19:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12326 for ; Wed, 11 May 2005 20:19: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 j4C09wb6046852; Wed, 11 May 2005 17:09: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 j4C09weF046851; Wed, 11 May 2005 17:09:58 -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 j4C09utJ046843 for ; Wed, 11 May 2005 17:09:57 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so819143wra for ; Wed, 11 May 2005 17:09:51 -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=AxzziEbiEr91tYFKU3hb/vvW2gNwW6O5udGvwsjHDOWmB42LlZ5W+InY/UcHPCqyVnCqkUP3dzAqRr18cSdUEhMxr4C7ouUF/i+S1Ew7nv/IU5wambrRdshMyj5kL15ogbPgARUcdzC8lVAvIfBD8DgXJljKhFtInMmKLsh+GE4= Received: by 10.54.23.51 with SMTP id 51mr733157wrw; Wed, 11 May 2005 17:09:50 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 17:09:50 -0700 (PDT) Message-ID: <68fba5c505051117097cd99ce8@mail.gmail.com> Date: Wed, 11 May 2005 20:09:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Last Call: required summary or content? Cc: atom-syntax In-Reply-To: <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C09vtJ046845 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Graham wrote: > The "Implementor's Guide" may or may not ever exist and may or may > not be read by anyone, so that isn't an option. Would you like to rephrase that as "I am concerned that the implementor's Guide will never happen."? My honest impression is that it will be far more popular than the spec itself, since the spec is minimal and abrasive. The style of the document makes sections that don't have specification words stick out like a sore thumb. I think I understand the conflict. > Myself and Sam, and > (I think) Tim and Antone, would all like the actual spec to make an I am asking you to detail the operational result you are after. You are telling me what you want the spec to say. This is not productive. I also made two suggestions in the email I pointed you to, but you responded to only one. > actual recommendation that entries without enclosed content include a > textual summary, if at all possible. Careful rhetoric proposing a different, and very strained, interpretation of our charter is not going to fool me. This is the kind of thing that makes negotiation unworthwhile. The charter is on my side. Live with it. I am not especially fond of making the argument, but it becomes necessary if people make scope arguments. > Note no one wants to ban title- > only feeds if they come from title-only resources. This is the problem I have. Title-only feeds are perfectly ok from any resource. They are probably not a good idea as the only possibility available from a blog or news site, but it's really all semantics and judgement calls. Judgement calls for the publisher to make, based on the type of application and users they are targetting. The whole point of HTTP is to allow servers to represent resources in the amount of detail they see fit. Unfortunately, RFC2119 is not perfect. It contains no specification word that would allow a validator to emit a warning while simultaneously requiring support for title-only feeds. SHOULD would also tar title-only feeds as bad practice. They aren't. If the Implementor's Guide existed and were widely read, would it be the right place for this encouragement? I think it would be. In my opinion, this is advocacy. I happen to agree with it, but I don't agree with normative enforcement in the data format. I will do whatever I possibly can to make sure the Guide gets the attention it deserves. I will write drafts of the section in question, if that's what it takes. Do you want it to receive the most prominent placement on atomenabled.org and atompub.org? I'm sure that could be arranged. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 20:30:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12956 for ; Wed, 11 May 2005 20:30: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 j4C0O18q047743; Wed, 11 May 2005 17:24: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 j4C0O1sY047741; Wed, 11 May 2005 17:24:01 -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 j4C0Nxe4047708 for ; Wed, 11 May 2005 17:24:00 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j4C0Nsm21269; Thu, 12 May 2005 09:23:54 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 45cc57e0_c27c_11d9_9b33_0030482533a1_27187; Thu, 12 May 2005 09:24:58 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005EA3; 12 May 05 09:26:29 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 12 May 05 09:26:09 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005E9F; 12 May 05 09:26:01 +0900 Message-Id: <6.0.0.20.2.20050512091927.04b08ec0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 12 May 2005 09:23:07 +0900 To: Robert Sayre , Atom Syntax From: Martin Duerst Subject: Re: Fetch Me A Rock In-Reply-To: <68fba5c505051108385062f2e7@mail.gmail.com> References: <68fba5c505051108385062f2e7@mail.gmail.com> 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 Hello Robert, I agree that summaries should be optional. I think one possible kind of solution that could help both you and Sam/Graham would be to say the following: - Atom processors MUST accept entries without summary/... - Atom documents SHOULD contain actual text. This hopefully would make it obvious that a SHOULD on the document doesn't give processors any licence to fail. The spec could even go further and say something about where the SHOULD would be expected to not be satisfied. Regards, Martin. At 00:38 05/05/12, Robert Sayre wrote: > >"Fetch me a rock. No, not that one. Fetch me another. Now jump >through this hoop." > >I think the reason there is no "consensus" on-list is because Sam and >Graham are trying to make normative requirements without outlining the >operational result they are after. > >I am disappointed we are putting up with it, but I am not surprised. >They'll give you ten different definitions of SHOULD, but there's only >one that matters. Remember, if we say SHOULD, that means >implementations don't have to interoperate with people who don't >provide a summary. That does not mean 'doesn't display' or 'doesn't >index', despite what some would have you believe. It means the Atom >Processor is allowed to fail. It doesn't matter if that's not what we >meant. The document's meaning would be unambiguous. > >SHOULD does not mean "encourage". Remember that. > >I'm not going argue any more. My opinion is clear, strong, and >supported by many others. > >Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 20:30:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12977 for ; Wed, 11 May 2005 20:30: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 j4C0O1Tt047744; Wed, 11 May 2005 17:24: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 j4C0O17R047742; Wed, 11 May 2005 17:24:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C0NxKH047707; Wed, 11 May 2005 17:23:59 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4C0Nr713698; Thu, 12 May 2005 09:23:53 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 454fd486_c27c_11d9_9b33_0030482533a1_27187; Thu, 12 May 2005 09:24:57 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO005EA1; 12 May 05 09:26:29 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 12 May 05 09:26:09 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG005E9D; 12 May 05 09:26:00 +0900 Message-Id: <6.0.0.20.2.20050511194254.06783ba0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 11 May 2005 19:44:09 +0900 To: Paul Hoffman , Tim Bray , Robert Sayre From: Martin Duerst Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax In-Reply-To: References: <68fba5c50505091852aee94ab@mail.gmail.com> <6.0.0.20.2.20050510160912.06827140@itmail.it.aoyama.ac.jp> 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 Hello Paul, Many thanks for the citations below, this is extremely clear. Going back to the original question/pace that you gave a -1, would that change if in the text "IETF Consensus" was replaced with "IESG Approval"? Regards, Martin. At 10:56 05/05/11, Paul Hoffman wrote: > >At 4:15 PM +0900 5/10/05, Martin Duerst wrote: >>What's the difference between "IETF consensus" (for which you gave a -1) >>and "it's up to the IESG" (which seems what you think we should let happen)? > > From RFC 2434: > > IESG Approval - New assignments must be approved by the IESG, but > there is no requirement that the request be documented in an > RFC (though the IESG has discretion to request documents or > other supporting materials on a case-by-case basis). > > IETF Consensus - New values are assigned through the IETF > consensus process. Specifically, new assignments are made via > RFCs approved by the IESG. Typically, the IESG will seek > input on prospective assignments from appropriate persons > (e.g., a relevant Working Group if one exists). > > >--Paul Hoffman, Director >--Internet Mail Consortium > From owner-atom-syntax@mail.imc.org Wed May 11 20:39:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13911 for ; Wed, 11 May 2005 20:39: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 j4C0WNKK048239; Wed, 11 May 2005 17:32: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 j4C0WN68048238; Wed, 11 May 2005 17:32:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C0WMG5048227 for ; Wed, 11 May 2005 17:32:22 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4C0W1mM019820; Thu, 12 May 2005 01:32:01 +0100 (BST) In-Reply-To: <68fba5c505051117097cd99ce8@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> <68fba5c505051117097cd99ce8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Last Call: required summary or content? Date: Thu, 12 May 2005 01:31:57 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert, I'm trying to include you in this discussion and you're not cooperating. You are the only person in the WG who has said there shouldn't be any recommendation in the specification. You are vastly outnumbered by people who've stated they'd be OK with it. The only question now is the wording. Graham From owner-atom-syntax@mail.imc.org Wed May 11 20:59:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15421 for ; Wed, 11 May 2005 20:59: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 j4C0r26v049581; Wed, 11 May 2005 17:53: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 j4C0r1us049580; Wed, 11 May 2005 17:53:01 -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 j4C0r0TP049573 for ; Wed, 11 May 2005 17:53:01 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so836031wra for ; Wed, 11 May 2005 17:52:55 -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=dui2K2lf1CSiYmz5RML3DlFETZrQxBcWcxCHQZcDPrt/z4WYbk/X3rjWYAhce6oNnlplzFze/ZhopvKc2jLnJOjdGnXkaHYL6xQtq+R6zKwm0j1qQRXYgO3jluo3A85klH7thvclI8fujgL9izSYBxgA28jNaLL5VXHemcfRkE0= Received: by 10.54.51.78 with SMTP id y78mr762705wry; Wed, 11 May 2005 17:52:55 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 17:52:55 -0700 (PDT) Message-ID: <68fba5c50505111752746d152d@mail.gmail.com> Date: Wed, 11 May 2005 20:52:55 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Last Call: required summary or content? Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> <68fba5c505051117097cd99ce8@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C0r1TP049575 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Graham wrote: > Robert, > > I'm trying to include you in this discussion and you're not > cooperating. You are the only person in the WG who has said there > shouldn't be any recommendation in the specification. You are vastly > outnumbered by people who've stated they'd be OK with it. The only > question now is the wording. Is that right? I don't think it is. If you think I've stated something incorrectly, make your opinion known to the IESG. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 21:01:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15566 for ; Wed, 11 May 2005 21:01: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 j4C0q4et049536; Wed, 11 May 2005 17:52: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 j4C0q4Du049535; Wed, 11 May 2005 17:52:04 -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 j4C0q3Xs049518 for ; Wed, 11 May 2005 17:52:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 83985 messnum 5762838 invoked from network[83.70.217.193/unknown]); 12 May 2005 00:51:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 83985) with SMTP; 12 May 2005 00:51:57 -0000 Message-ID: <4282A8A9.6040104@dehora.net> Date: Thu, 12 May 2005 01:51: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: atom-syntax Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> In-Reply-To: <80B4316F-FD5E-47F4-B841-EC419631A514@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: > The "Implementor's Guide" may or may not ever exist and may or may not > be read by anyone, so that isn't an option. The WG has tended to punt assuming on a Fabled Implementors Guide. Why is that punt not acceptable now? > Myself and Sam, and (I > think) Tim and Antone, would all like the actual spec to make an actual > recommendation that entries without enclosed content include a textual > summary, if at all possible. Bray voiced concerns about SHOULD; I suggested MAY. No further discussion occurred. What might be wrong with a MAY requirement in this case? > Note no one wants to ban title- only feeds > if they come from title-only resources. I've claimed here before that kind of reasoning is the same kind of reasoning that lead us to reject 3 dates. It's not something we can manage. What is different here? [Also, the nature of resources ensures this is outside our scope; unless we're breaking with web arch, we deal squarely with representations; granted I may be reading too much into what you mean by resource, but I'm assuming its usage is technical until told otherwise.] > What language would you find > acceptable that covers these bases? Language that doesn't result in confusion. Sam's text pace makes title-only feeds bad practice. I'm not satisfied the text pace has adequate language - the rationale presented is weak, the SHOULD requirement level isn't entirely appropriate, the idea of deliberately issuing mixed messages from the spec is unsatisfactory. I've pushed back on this pace a few times now and haven't seen any good answers as a result of that. At some point someone really ought to provide a clear explanation of its value. What have I already said that you think is wrong so that I should change my position? cheers Bill From owner-atom-syntax@mail.imc.org Wed May 11 21:29:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17472 for ; Wed, 11 May 2005 21:29: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 j4C1M58O051724; Wed, 11 May 2005 18:22: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 j4C1M5aR051723; Wed, 11 May 2005 18:22:05 -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 j4C1LuUs051686; Wed, 11 May 2005 18:21:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.0.0.20.2.20050511194254.06783ba0@itmail.it.aoyama.ac.jp> References: <68fba5c50505091852aee94ab@mail.gmail.com> <6.0.0.20.2.20050510160912.06827140@itmail.it.aoyama.ac.jp> <6.0.0.20.2.20050511194254.06783ba0@itmail.it.aoyama.ac.jp> Date: Wed, 11 May 2005 18:21:53 -0700 To: Martin Duerst , Tim Bray , Robert Sayre From: Paul Hoffman Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Atom Syntax 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:44 PM +0900 5/11/05, Martin Duerst wrote: >Many thanks for the citations below, this is extremely clear. >Going back to the original question/pace that you gave a -1, >would that change if in the text "IETF Consensus" was >replaced with "IESG Approval"? Yup. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 11 21:30:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17554 for ; Wed, 11 May 2005 21:30: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 j4C1NTw7051890; Wed, 11 May 2005 18:23: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 j4C1NTwd051889; Wed, 11 May 2005 18:23:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C1NS2o051869 for ; Wed, 11 May 2005 18:23:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4C1M7iY027015; Thu, 12 May 2005 02:22:13 +0100 (BST) In-Reply-To: <4282A8A9.6040104@dehora.net> References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> <4282A8A9.6040104@dehora.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: atom-syntax From: Graham Subject: Re: Last Call: required summary or content? Date: Thu, 12 May 2005 02:22:08 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C1NS2o051883 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 12 May 2005, at 1:51 am, Bill de hra wrote: > The WG has tended to punt assuming on a Fabled Implementors Guide. > Why is that punt not acceptable now? I know putting things in the IG has been mentioned before, but I can't think of any actual cases where that was the outcome of the debate - things have either been put in the spec, or rejected outright. This needs to go in the spec. It's just as much of an techical/interop issue as "Logos must have a 2:1 aspect ratio". > Bray voiced concerns about SHOULD; I suggested MAY. No further > discussion occurred. What might be wrong with a MAY requirement in > this > case? MAY is fine as the actual RFC term, but needs to be embellished, eg: "atom:summary MAY be included, but software is encouraged to do so when atom:content is not present" As I've said before, I don't know what the exact wording needs to be. Is there an RFC-compatible way to get the intention of this sentence across? This question is put mainly to the chairs and the AD, btw. Graham From owner-atom-syntax@mail.imc.org Wed May 11 21:51:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18761 for ; Wed, 11 May 2005 21: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 j4C1hIa7055095; Wed, 11 May 2005 18:43: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 j4C1hIXN055094; Wed, 11 May 2005 18:43: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C1hHY5055078 for ; Wed, 11 May 2005 18:43:18 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so856352wra for ; Wed, 11 May 2005 18:43: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=fupsnWTwg51ru0QaNL0kdwlml1kOIOPymL5KmaXIMXNS8I9pqcO+LzgxjFdxRGWxMsUEoMS+KrIOiDxYJzTihO0pCVaDmXddrRIyEZEHjIci9RjukZZILgPx7thKOh2YKSjJqoDu7M989WErA5ggYYKChDgBEXZAoJCsozkZ7vI= Received: by 10.54.76.2 with SMTP id y2mr797852wra; Wed, 11 May 2005 18:43:12 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 18:43:12 -0700 (PDT) Message-ID: <68fba5c5050511184370c29181@mail.gmail.com> Date: Wed, 11 May 2005 21:43:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Martin Duerst Subject: Re: Fetch Me A Rock Cc: Atom Syntax In-Reply-To: <6.0.0.20.2.20050512091927.04b08ec0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051108385062f2e7@mail.gmail.com> <6.0.0.20.2.20050512091927.04b08ec0@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C1hIY5055089 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Martin Duerst wrote: > Hello Robert, > > I agree that summaries should be optional. > > I think one possible kind of solution that could help > both you and Sam/Graham Martin, compromise is called for when there are competing technical concerns. Sam/Graham refuse to state their technical concerns. What does a MAY prevent them from doing? If there is nothing, it is an abuse of the process. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 11 22:50:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22714 for ; Wed, 11 May 2005 22:50: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 j4C2gG7M062335; Wed, 11 May 2005 19:42: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 j4C2gGH5062334; Wed, 11 May 2005 19:42:16 -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 j4C2gAXI062320; Wed, 11 May 2005 19:42:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <426D1F6E.60306@franklinmint.fm> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> <68fba5c505051110593e2c4bf1@mail.gmail.com> <7A75C7E4-0FF5-4436-AF16-202CFC9612DB@mac.com> <68fba5c5050511145827dfa73f@mail.gmail.com> <80B4316F-FD5E-47F4-B841-EC419631A514@mac.com> <4282A8A9.6040104@dehora.net> Date: Wed, 11 May 2005 19:42:08 -0700 To: Graham , Bill de =?iso-8859-1?Q?h=D3ra?= From: Paul Hoffman Subject: Re: Last Call: required summary or content? Cc: atom-syntax 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:22 AM +0100 5/12/05, Graham wrote: >"atom:summary MAY be included, but software is encouraged to do so >when atom:content is not present" > >As I've said before, I don't know what the exact wording needs to >be. Is there an RFC-compatible way to get the intention of this >sentence across? This question is put mainly to the chairs and the >AD, btw. The quoted sentence would be fine in an RFC. It gives a clear compliance level (MAY), it gives advice about why one would want to or not want to use it. A slight quibble: I would change "but" to "and". But it world work fine as stated. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 11 23:21:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24841 for ; Wed, 11 May 2005 23:21: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 j4C3Cc6Y066975; Wed, 11 May 2005 20:12: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 j4C3CctU066974; Wed, 11 May 2005 20:12:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C3Cbu7066961 for ; Wed, 11 May 2005 20:12: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 (rwcrmhc11) with SMTP id <2005051203123101300hhvg4e>; Thu, 12 May 2005 03:12:31 +0000 Date: Wed, 11 May 2005 21:12:30 -0600 Subject: Re: Last Call: required summary or content? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <68fba5c505051117097cd99ce8@mail.gmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C3Ccu7066969 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, May 11, 2005, at 06:09 PM, Robert Sayre wrote: > On 5/11/05, Graham wrote: >> Note no one wants to ban title- >> only feeds if they come from title-only resources. > > This is the problem I have. Title-only feeds are perfectly ok from any > resource. They are probably not a good idea as the only possibility > available from a blog or news site This is an excellent way to state a large portion of my opinion on this subject. Let me see if I can state it completely and concisely: 1) I'd like to encourage people to publish useful feeds, and give them guidance about how to do so 2) I'd like to strongly encourage people to publish accessible feeds The rest is details: * What makes a feed useful? -- In most cases, having enough content for it to be a reliable tool for deciding whether to follow a link to more content. -- In some cases, having a nothing more than the consuming application is going to use--for example, a news headline ticker basically needs a headline, a link, and timestamp and an ID. * How does one achieve the goal of publishing a useful feed? -- For the most common case, include atom:summary or atom:content. -- For the less common case, include neither atom:summary nor atom:content. The two conflict with each other. Thus, I'd like to encourage people to at least publish a feed to cover the first case, but in no way prevent them from also publishing a stripped down version for the second case. If they really want to or only can, they should be allowed to only cover the second case. * What makes a feed accessible? -- If the feed has "content", including a textual version or summary of it in one of Atom's special formats ("text", "html" and "xhtml"). I think that captures what I would hope we can find language to achieve. I don't think we're going to achieve that by simply deciding between SHOULD and MAY. On Wednesday, May 11, 2005, at 07:22 PM, Graham wrote: > On 12 May 2005, at 1:51 am, Bill de hra wrote: >> Bray voiced concerns about SHOULD; I suggested MAY. No further >> discussion occurred. What might be wrong with a MAY requirement in >> this >> case? > > MAY is fine as the actual RFC term, but needs to be embellished, eg: > > "atom:summary MAY be included, but software is encouraged to do so > when atom:content is not present" How about something along the lines of: "atom:summary is OPTIONAL, but when atom:content is either not present, or when the value of its type attribute is anything other than "text", "html" or "xhtml", publishers are strongly encouraged to either include atom:summary, or publish another version of the feed which includes atom:summary or atom:content with one of the type attribute values listed above." In the above, 'anything other than "text", "html" or "xhtml"' could be replaced by 'a MIME media type', and correspondingly "one of the type attribute values listed above" with something like 'a type attribute value of "text", "html" or "xhtml"'. From owner-atom-syntax@mail.imc.org Wed May 11 23:21:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24904 for ; Wed, 11 May 2005 23: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 j4C3GEKr067836; Wed, 11 May 2005 20:16: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 j4C3GEu4067835; Wed, 11 May 2005 20:16:14 -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 j4C3GDCR067819 for ; Wed, 11 May 2005 20:16:13 -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]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j4C3H3ns002087; Wed, 11 May 2005 23:17:09 -0400 Message-ID: <4282CA72.6050102@intertwingly.net> Date: Wed, 11 May 2005 23:16:02 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Fetch Me A Rock References: <68fba5c505051108385062f2e7@mail.gmail.com> In-Reply-To: <68fba5c505051108385062f2e7@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: > > They'll give you ten different definitions of SHOULD, but there's only > one that matters. Remember, if we say SHOULD, that means > implementations don't have to interoperate with people who don't > provide a summary. That does not mean 'doesn't display' or 'doesn't > index', despite what some would have you believe. It means the Atom > Processor is allowed to fail. It doesn't matter if that's not what we > meant. The document's meaning would be unambiguous. Are we looking at the same document? curl -s http://www.ietf.org/rfc/rfc2119.txt | grep -i fail | wc http://www.imc.org/atom-syntax/mail-archive/msg14533.html - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 11 23:25:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25063 for ; Wed, 11 May 2005 23:25: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 j4C3Ik5f068306; Wed, 11 May 2005 20:18: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 j4C3IkPo068305; Wed, 11 May 2005 20:18:46 -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 j4C3Ij6e068289 for ; Wed, 11 May 2005 20:18:45 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so897600wra for ; Wed, 11 May 2005 20:18: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=bCWQcbuTi0aHV6LFJv5kGOaQTtcvLHJnfzK7oJrXF6MJdUUKrnXG26t5T8e6IMciccWAUstlzY1P7kuXrtvUPh6pL6kuy0xd5vXU/5p4km5Pf7PqwoGavSFOb8kKo8BA1yCK2QynTQkr4hYU/E7uF5U0bM3DzwnCOI+80frlEYw= Received: by 10.54.23.10 with SMTP id 10mr829393wrw; Wed, 11 May 2005 20:18:38 -0700 (PDT) Received: by 10.54.73.10 with HTTP; Wed, 11 May 2005 20:18:38 -0700 (PDT) Message-ID: <68fba5c5050511201818b26cff@mail.gmail.com> Date: Wed, 11 May 2005 23:18:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: Fetch Me A Rock Cc: Atom Syntax In-Reply-To: <4282CA72.6050102@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C3Ij6e068299 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/11/05, Sam Ruby wrote: > Robert Sayre wrote: > > > > They'll give you ten different definitions of SHOULD, but there's only > > one that matters. Remember, if we say SHOULD, that means > > implementations don't have to interoperate with people who don't > > provide a summary. That does not mean 'doesn't display' or 'doesn't > > index', despite what some would have you believe. It means the Atom > > Processor is allowed to fail. It doesn't matter if that's not what we > > meant. The document's meaning would be unambiguous. > > Are we looking at the same document? My interpretation is correct. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 12 03:35:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01403 for ; Thu, 12 May 2005 03:35: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 j4C7Q8iJ049216; Thu, 12 May 2005 00:26: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 j4C7Q8Jl049215; Thu, 12 May 2005 00:26:08 -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 j4C7Q75s049203 for ; Thu, 12 May 2005 00:26:07 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 28876 invoked by uid 17064); 12 May 2005 07:26:07 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.4.73]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 12 May 2005 07:26:06 -0000 In-Reply-To: <1139593020.20050512004045@djpowell.net> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <1139593020.20050512004045@djpowell.net> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAllowDuplicateIDs Date: Thu, 12 May 2005 09:26:06 +0200 To: David Powell X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Don't you have the same problem with atom:modified? What if the publisher does not update the atom:modified entry? I suppose that if you are making an archive of an atom entries and believe that the author has made a mistake with the atom:updated field, you can of course try to correct the mistake artificially in your own feed by increasing the time precision. So if the original entries both claim to have been updated at 12:45 you could have one of them be modified at 12:45:30 and the other at 12:45:31. Just a thought. Henry Story On 12 May 2005, at 01:40, David Powell wrote: > I'm in favour of allowing duplicate ids. This only seems to be a > partial solution though: > > "Their atom:updated timestamps SHOULD be different" > > But what if they are not? What if I want to represent an archive of a > feed - maybe mine, maybe someone else's - but the atom:updated dates > are the same in two or more entries? I thought it was up to the > publisher to decide whether to rev atom:updated. > > I was always concerned that the existence of atom:updated without > atom:modified would cause the meaning of atom:updated as an alert to > be diluted to being equivalent to atom:modified. This proposal would > encourage that. It would mean, if you don't update atom:updated, then > your entry instances are second class. > > The restriction forces services that proxy, or re-aggregate feeds to > drop entries on the floor, just because the user has chosen not to > update atom:updated. > > atom:updated encourages aggregators to make loud noises when they see > a change; anything that encourages atom:updated to be changed just for > the sake of it is going to be very annoying to users and make > atom:updated useless as an alert flag. > > > I'm in favour of duplicate ids, but unfortunately, the only way I can > see them working is if we have atom:modified. I hate to bring this up, > especially now, but it would solve some problems, and it is cheap to > implement: > > Is anyone still opposed to atom:modified? > > > -- > Dave > From owner-atom-syntax@mail.imc.org Thu May 12 05:56:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10330 for ; Thu, 12 May 2005 05:56: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 j4C9jgCG004235; Thu, 12 May 2005 02:45: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 j4C9jg89004234; Thu, 12 May 2005 02:45:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9jf1E004177 for ; Thu, 12 May 2005 02:45:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4C9hSQY016887; Thu, 12 May 2005 10:43:39 +0100 (BST) In-Reply-To: References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <1139593020.20050512004045@djpowell.net> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIDs Date: Thu, 12 May 2005 10:43:28 +0100 To: Henry Story X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 May 2005, at 8:26 am, Henry Story wrote: > Don't you have the same problem with atom:modified? What if the > publisher does not update the atom:modified entry? I presume any "atom:modified" element would have to be incremented every time any change was made, so this wouldn't be an option. I prefer a solution where the originating point of the entry puts the current time in a new element when it generates the atom:entry. Then it's easy to work out which is the newest version, in a way atom:updated doesn't allow. > On 12 May 2005, at 01:40, David Powell wrote: >> But what if they are not? What if I want to represent an archive of a >> feed - maybe mine, maybe someone else's - but the atom:updated dates >> are the same in two or more entries? I thought it was up to the >> publisher to decide whether to rev atom:updated. Agreed. Graham From owner-atom-syntax@mail.imc.org Thu May 12 08:06:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18523 for ; Thu, 12 May 2005 08:06: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 j4CBuxlT055870; Thu, 12 May 2005 04:56: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 j4CBuxTv055869; Thu, 12 May 2005 04:56:59 -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 j4CBuwXV055842 for ; Thu, 12 May 2005 04:56:58 -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; Thu, 12 May 2005 07:56:54 -0400 id 00594408.42834486.00007614 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Robert Sayre'" , iesg@ietf.org Cc: "'Robert Sayre'" , "'Atom-Syntax'" Subject: RE: Last Call: required summary or content? Date: Thu, 12 May 2005 07:56:28 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07916C75@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <68fba5c505051110593e2c4bf1@mail.gmail.com> Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul, Tim: It would be helpful if you could address the "The current draft fails to satisfy the second bullet point" allegation. -Scott- > -----Original Message----- > From: Robert Sayre [mailto:sayrer@gmail.com] > Sent: Wednesday, May 11, 2005 2:00 PM > To: iesg@ietf.org > Cc: Robert Sayre; Sam Hartman; Atom-Syntax > Subject: Re: Last Call: required summary or content? > > > > There's one more issue that I would like to make the IESG aware of > before it evaluates the Atom Syndication Format. I don't believe the > format satisfies the Atompub charter: > > The format must be able to represent: > * a resource that is a Weblog entry or article (e.g., it has > an author, date, identifier, and content) > * a feed or channel of entries, with or without enclosed > content > * a complete archive of all entries in a feed > * existing well-formed XML (especially XHTML) content > * additional information in an user-extensible manner > > > The current draft fails to satisfy the second bullet point. > > Robert Sayre > > P.S. -- Here are a couple of messages underscoring that atom:summary > and atom:content both serve as "enclosed content". > > Tim Bray: http://www.imc.org/atom-syntax/mail-archive/msg14155.html > Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html > > > > On 4/25/05, Sam Ruby wrote: > > > > Robert Sayre wrote: > > > > > >> * What the specification does currently > > > > > > In an Atom Entry, the specification currently requires a > minimum set of > > > elements: , <id>, and <updated>. Typically, there > will also be a > > > <link> element. The specification includes a provision > that allows its > > > omission on the condition that there is a <content> > element. In addition > > > to that, the specification requires that either <summary> > or <content> > > > be present. > > > > > >> * What you would like it to do instead > > > > > > I want to allow the metadata-only feeds allowed by all > flavors of RSS, > > > and the omission of the <content> and <summary>. Such > feeds are commonly > > > termed "title-only feeds", because that is all that is > visible to the > > > user (the title is usually hyperlinked w/ the link element). > > > > I will again point out that the current format allows for > empty summary > > and/or content elements. > > > > I have seen errors that the requirement for the inclusion of such > > elements would have prevented. > > > > I have seen no arguments as to why placing such empty elements would > > impose an unreasonable burden on implementers. > > > > - Sam Ruby > > > > > > From owner-atom-syntax@mail.imc.org Thu May 12 11:31:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04527 for <atompub-archive@lists.ietf.org>; Thu, 12 May 2005 11:31: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 j4CFOpcs092426; Thu, 12 May 2005 08: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 j4CFOpTX092425; Thu, 12 May 2005 08:24:51 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFOoss092417 for <atom-syntax@imc.org>; Thu, 12 May 2005 08:24:50 -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, 13 May 2005 01:24:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 01:24:34 +1000 Subject: atom:updated vs entry inheritance? From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BEA9B252.59BFB%eric.scheid@ironclad.net.au> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Gah! What is the true atom:updated for the following entry? <feed> <updated>2005-05-12T02:22:59+0000</updated> <author>...</author> <copyright>...</copyright> <entry> <updated>2005-05-11T01:11:59+0000</updated> <id>...</id> <summary>...</summary> <title>... e. From owner-atom-syntax@mail.imc.org Thu May 12 12:16:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04529 for ; Thu, 12 May 2005 11:31: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 j4CFJpgA091914; Thu, 12 May 2005 08:19: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 j4CFJpkd091913; Thu, 12 May 2005 08:19:51 -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 j4CFJjlb091903; Thu, 12 May 2005 08:19:46 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07916C75@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07916C75@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Thu, 12 May 2005 08:19:40 -0700 To: iesg@ietf.org, Atom WG From: Paul Hoffman Subject: RE: Last Call: required summary or content? 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:56 AM -0400 5/12/05, Scott Hollenbeck wrote: >It would be helpful if you could address the "The current draft fails to >satisfy the second bullet point" allegation. > >-Scott- > >> -----Original Message----- >> From: Robert Sayre [mailto:sayrer@gmail.com] >> Sent: Wednesday, May 11, 2005 2:00 PM >> To: iesg@ietf.org >> Cc: Robert Sayre; Sam Hartman; Atom-Syntax >> Subject: Re: Last Call: required summary or content? >> >> >> >> There's one more issue that I would like to make the IESG aware of >> before it evaluates the Atom Syndication Format. I don't believe the >> format satisfies the Atompub charter: >> >> The format must be able to represent: >> * a resource that is a Weblog entry or article (e.g., it has >> an author, date, identifier, and content) >> * a feed or channel of entries, with or without enclosed >> content >> * a complete archive of all entries in a feed >> * existing well-formed XML (especially XHTML) content >> * additional information in an user-extensible manner >> >> >> The current draft fails to satisfy the second bullet point. I don't see how. The current document certainly shows how to create entries with enclosed content (the entry can contain an atom:content element), and it certainly shows how to create entries with no enclosed content (the entry can contain no atom:content elements). > > P.S. -- Here are a couple of messages underscoring that atom:summary >> and atom:content both serve as "enclosed content". >> > > Tim Bray: http://www.imc.org/atom-syntax/mail-archive/msg14155.html > > Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html Those two personal opinions, neither of which appears in the current draft, do not relate to the charter-level description of "enclosed content". In the case of the charter, "enclosed content" means an atom:content element, no other parts of the entry. If we took this too the extreme Rob wants, we would have to allow completely null entries because titles, dates, and even IDs could be considered content. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 12:16:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08104 for ; Thu, 12 May 2005 12:16: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 j4CG4Hm8095820; Thu, 12 May 2005 09:04: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 j4CG4HKo095818; Thu, 12 May 2005 09:04: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CG4FYr095794 for ; Thu, 12 May 2005 09:04:16 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1155366wri for ; Thu, 12 May 2005 09:04:10 -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=Cae4ubmi8DrH4Dk9rcvCfEM1Rq+wqsHzZ2dFOPPJEq2hoDrQNDrdXq+hfTC9ehgpbq6x1XRT5wLmnjAm4lm9WR8dqyMgRpLcDAwHAGhG4gkISp9P5udJYkoOFcc0GgoFuIpOu4toBQoD8oETXIEEKDkFw0vz7kbrxc9DERT5/P0= Received: by 10.54.8.20 with SMTP id 20mr1051164wrh; Thu, 12 May 2005 09:04:10 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Thu, 12 May 2005 09:04:10 -0700 (PDT) Message-ID: <540e3732050512090438f29b0f@mail.gmail.com> Date: Thu, 12 May 2005 11:04:10 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: atom:updated vs entry inheritance? 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 j4CG4GYr095812 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Gah! What is the true atom:updated for the following entry? Eric: The entry-level version, IMO. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu May 12 12:36:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09678 for ; Thu, 12 May 2005 12:36: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 j4CGDgZd096681; Thu, 12 May 2005 09:13: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 j4CGDgpR096680; Thu, 12 May 2005 09:13:42 -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 j4CGDffd096672 for ; Thu, 12 May 2005 09:13:41 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 88722 messnum 5272869 invoked from network[83.70.217.193/unknown]); 12 May 2005 16:13:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail04.svc.cra.dublin.eircom.net (qp 88722) with SMTP; 12 May 2005 16:13:35 -0000 Message-ID: <428380AB.8090006@dehora.net> Date: Thu, 12 May 2005 17:13:31 +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: atom:updated vs entry inheritance? 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: > Gah! What is the true atom:updated for the following entry? > > > 2005-05-12T02:22:59+0000 > ... > ... > > 2005-05-11T01:11:59+0000 > ... > ... > ... > > feed/entry/updated cheers Bill From owner-atom-syntax@mail.imc.org Thu May 12 12:36:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09693 for ; Thu, 12 May 2005 12:36: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 j4CGNodt097573; Thu, 12 May 2005 09:23: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 j4CGNovB097572; Thu, 12 May 2005 09:23:50 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CGNntV097565 for ; Thu, 12 May 2005 09:23:49 -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, 13 May 2005 02:23:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 02:23:34 +1000 Subject: nit: spaces in link@rel? 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 Is this legal according to our spec-08? According to the spec, @rel can contain either isegment-nz-nc or IRI values, where isegment-nz-nc is also described as atomNCName, which is defined in Appendix B (RELAX NG Compact Schema) as atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } Both isegment-nz-nc and atomNCName allows all characters except the colon. This means a string containing a space is permitted, and the @rel above of "foo bar" is actually just one relationship, not two delimited by a space. This is confusingly different from HTML's link@rel and should be fixed. e. From owner-atom-syntax@mail.imc.org Thu May 12 13:16:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12925 for ; Thu, 12 May 2005 13:16: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 j4CH5RxC001197; Thu, 12 May 2005 10:05: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 j4CH5Rmo001196; Thu, 12 May 2005 10:05:27 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CH5MZG001186; Thu, 12 May 2005 10:05:23 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> Date: Thu, 12 May 2005 10:05:17 -0700 To: Robert Sayre , Atom Syntax , Sam Ruby From: Paul Hoffman Subject: Re: Fetch Me A Rock Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thus spake RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. At 11:18 PM -0400 5/11/05, Robert Sayre wrote: >My interpretation is correct. That's impossible to assess because you haven't said which wording you are applying your interpretation to. Please be specific: is it the current draft, a particular Pace, or a particular group of Paces? At 11:38 AM -0400 5/11/05, Robert Sayre wrote: >Remember, if we say SHOULD, that means >implementations don't have to interoperate with people who don't >provide a summary. A receiving implementation must be able to handle all defined elements, regardless if they are defined as MAY sent, SHOULD send, or MUST send, so I'm not sure what you mean by "interoperate". > That does not mean 'doesn't display' or 'doesn't >index', despite what some would have you believe. It means the Atom >Processor is allowed to fail. Fully disagree. >SHOULD does not mean "encourage". Remember that. Fully agree. >I'm not going argue any more. Fully disagree. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 13:26:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13641 for ; Thu, 12 May 2005 13:26: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 j4CHI7qm002469; Thu, 12 May 2005 10:18: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 j4CHI7cG002468; Thu, 12 May 2005 10:18:07 -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 j4CHI6Lc002450 for ; Thu, 12 May 2005 10:18:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1303031wra for ; Thu, 12 May 2005 10:18:01 -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=ilt4f/5z/atxsXQMYaRfPLW2RtolUIcz958LtxA0bRni7JfWUKMEEWKQQUTPY4ONMf8N3NJgeE1S5iFkWGjWr2mnGdrWn/b9mrqmyEkBAXh0d6z18QrqDnFpiRTHrnTjJPQdEo7emCcp5+CkX2zezhik3AvjSFc44RnILITdafg= Received: by 10.54.41.78 with SMTP id o78mr1237529wro; Thu, 12 May 2005 10:18:01 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 12 May 2005 10:18:01 -0700 (PDT) Message-ID: <68fba5c5050512101821efbc4e@mail.gmail.com> Date: Thu, 12 May 2005 13:18:01 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: Fetch Me A Rock Cc: Atom Syntax , Sam Ruby In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CHI7Lc002454 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/12/05, Paul Hoffman wrote: > > At 11:38 AM -0400 5/11/05, Robert Sayre wrote: > >Remember, if we say SHOULD, that means > >implementations don't have to interoperate with people who don't > >provide a summary. > > A receiving implementation must be able to handle all defined > elements, regardless if they are defined as MAY sent, SHOULD send, or > MUST send, so I'm not sure what you mean by "interoperate". That sentence seems to apply to the conformance level known as MAY. "In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" Otherwise, I'm not sure what you mean. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 12 13:26:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13671 for ; Thu, 12 May 2005 13:26: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 j4CHGMN8002048; Thu, 12 May 2005 10: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 j4CHGMqf002047; Thu, 12 May 2005 10:16:22 -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 j4CHGJiW002019 for ; Thu, 12 May 2005 10:16:19 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 May 2005 17:16:12 -0000 Received: from p508FB3FB.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.179.251] by mail.gmx.net (mp025) with SMTP; 12 May 2005 19:16:12 +0200 X-Authenticated: #1915285 Message-ID: <42838F58.9020102@gmx.de> Date: Thu, 12 May 2005 19:16:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Robert Sayre , Atom Syntax , Sam Ruby Subject: Re: Fetch Me A Rock References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> In-Reply-To: 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 Paul Hoffman wrote: > > Thus spake RFC 2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. ...and I think that what we need to do is to define what these "full implications" are. > ... >> Remember, if we say SHOULD, that means >> implementations don't have to interoperate with people who don't >> provide a summary. > > > A receiving implementation must be able to handle all defined elements, > regardless if they are defined as MAY sent, SHOULD send, or MUST send, > so I'm not sure what you mean by "interoperate". Must a receiving implementation handle missing elements? I don't think as long as we say "sender SHOULD include the element". > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu May 12 13:34:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14315 for ; Thu, 12 May 2005 13:34: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 j4CHL5Dw002625; Thu, 12 May 2005 10:21: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 j4CHL5S6002624; Thu, 12 May 2005 10:21: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHL4B0002605 for ; Thu, 12 May 2005 10:21:05 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1304786wra for ; Thu, 12 May 2005 10:20: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=F5VPJkqE8PEfV0xI1f5Quh3CCGHSieKOUinE4Gmhl5zzLxXwyid8NaxXmMhvSD3Ed2OJxdDfJHMwO1XJFw5BPdpDOq/yyFeo13llxfS2Fo7Oo/sv+QvHuyXUv9UjXU0n/QM8GEWSPU3lnou5bqmWmDtq/XSV2cBOj3A5hRgMxwA= Received: by 10.54.51.5 with SMTP id y5mr1232384wry; Thu, 12 May 2005 10:20:58 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 12 May 2005 10:20:58 -0700 (PDT) Message-ID: <68fba5c5050512102012966e9a@mail.gmail.com> Date: Thu, 12 May 2005 13:20:58 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: Fetch Me A Rock Cc: Atom Syntax , Sam Ruby In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CHL5B0002610 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/12/05, Paul Hoffman wrote: > Thus spake RFC 2119: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > At 11:18 PM -0400 5/11/05, Robert Sayre wrote: > >My interpretation is correct. > > That's impossible to assess because you haven't said which wording > you are applying your interpretation to. Please be specific: is it > the current draft, a particular Pace, or a particular group of Paces? PaceTextShouldBeProvided. I trust you'll apply a similar standard of specifity to other members of this working group. > >SHOULD does not mean "encourage". Remember that. > > Fully agree. > > >I'm not going argue any more. > > Fully disagree. bye, Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 12 13:40:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14783 for ; Thu, 12 May 2005 13:40: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 j4CHTLGr003071; Thu, 12 May 2005 10:29: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 j4CHTLim003070; Thu, 12 May 2005 10:29:21 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHTJVk003048 for ; Thu, 12 May 2005 10:29:20 -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, 13 May 2005 03:29:21 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 03:29:02 +1000 Subject: editorial: atom:author and atom:contributor inheritance? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CHTKVk003065 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The spec-08 has this: > 4.2.4The "atom:copyright" Element > [...] > If an atom:entry element does not contain an atom:copyright element, > then the atom:copyright element of the containing atom:feed element's > atom:head element, if present, is considered to apply to the entry. > ... but no similar text is to be found against the spec for atom:author or atom:contributor. I do see this ... > atom:entry elements MUST contain exactly one atom:author element, > unless the atom:entry contains an atom:source element which contains > an atom:author element, or, in an Atom Feed Document, the atom:feed > element contains an atom:author element itself. ... but that doesn't explain that the atom:entry inherits the author from the feed. It actually suggests that an entry may be author-less, because the spec text for atom:author only says this: > The "atom:author" element is a Person construct that indicates the > author of the entry or feed. Meanwhile - atom:contributor doesn't even get that. It only gets this... > atom:entry elements MAY contain any number of atom:contributor elements. ... not even a hint of inheritance. Lastly ... section 4.2.11 (The "atom:source" Element) has this ... > Such metadata SHOULD be preserved if the source atom:feed contains any > of the child elements atom:author, atom:contributor, atom:copyright, or > atom:category and those child elements are not present in the source > atom:entry. ... which calls out atom:category in the same sentence as atom:author, atom:contributor, and atom:copyright ... which might suggest that atom:category should also be inherited. I don't recall what the thinking was, but I'd +1 inheritance of atom:category from atom:feed into atom:entry. e. From owner-atom-syntax@mail.imc.org Thu May 12 13:44:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15076 for ; Thu, 12 May 2005 13: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 j4CHXhXY003307; Thu, 12 May 2005 10:33: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 j4CHXhhe003306; Thu, 12 May 2005 10:33:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHXfOd003299 for ; Thu, 12 May 2005 10:33:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4CHWEES023813; Thu, 12 May 2005 18:32:20 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: nit: spaces in link@rel? Date: Thu, 12 May 2005 18:32:13 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 May 2005, at 5:23 pm, Eric Scheid wrote: > This is confusingly different from HTML's link@rel and should be > fixed. I believe the intention is that only one value is allowed, and any whitespace included is part of the name of the rel value. Perhaps this should be noted in the spec. Or are you suggesting we adopt the HTML method? Graham From owner-atom-syntax@mail.imc.org Thu May 12 13:49:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15488 for ; Thu, 12 May 2005 13:49: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 j4CHgEdU003814; Thu, 12 May 2005 10:42: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 j4CHgE05003813; Thu, 12 May 2005 10:42:14 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHgDZ4003807 for ; Thu, 12 May 2005 10:42:13 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42838F58.9020102@gmx.de> <68fba5c5050512101821efbc4e@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> <42838F58.9020102@gmx.de> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512101821efbc4e@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> Date: Thu, 12 May 2005 10:41:47 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Fetch Me A Rock 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:16 PM +0200 5/12/05, Julian Reschke wrote: >>A receiving implementation must be able to handle all defined >>elements, regardless if they are defined as MAY sent, SHOULD send, >>or MUST send, so I'm not sure what you mean by "interoperate". > >Must a receiving implementation handle missing elements? I don't >think as long as we say "sender SHOULD include the element". Bare with me here; I'm not an implementer. What kind of pseudocode are you envisioning on the receiver side? My picture (which could easily be wrong is): # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 # Atom 1.0 RFC says entries SHOULD have one atom:foo2 # Atom 1.0 RFC says entries MAY have one atom:foo3 Scan the entry. If you don't find an atom:foo1, fail. If you find more than one atom:foo1, fail. Process the atom:foo1. If you find more than one atom:foo2, fail. Process the atom:foo2. If you find more than one atom:foo3, fail. Process the atom:foo3. At 1:18 PM -0400 5/12/05, Robert Sayre wrote: >On 5/12/05, Paul Hoffman wrote: > > > > > At 11:38 AM -0400 5/11/05, Robert Sayre wrote: >> >Remember, if we say SHOULD, that means >> >implementations don't have to interoperate ... >...snip... > > elements, regardless if they are defined as MAY sent, SHOULD send, or >> MUST send, so I'm not sure what you mean by "interoperate". > >That sentence seems to apply to the conformance level known as MAY. Similar to MAY, yes. Senders may or may not send depending on the reason given; receivers must be ready to accept with it present or not. At 1:20 PM -0400 5/12/05, Robert Sayre wrote: >On 5/12/05, Paul Hoffman wrote: > > Thus spake RFC 2119: >> >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >...snip... > > you are applying your interpretation to. Please be specific: is it >> the current draft, a particular Pace, or a particular group of Paces? > >PaceTextShouldBeProvided. Thank you. That Pace, in essence, adds a bunch of "SHOULD NOT be empty" statements without saying when it is or is not acceptable to be empty. I understood those additional SHOULD NOTs to be for sending implementations, not for receiving implementations. However, that understanding came from the mailing list, not the spec itself. If your issue was that you saw them as relevant for both senders and receivers, that's a valid concern. The Pace should be written to be clearer who the SHOULD applies to. Separately, I would like to see the Pace specify in case what scenarios empty values would be allowed. >I trust you'll apply a similar standard of >specifity to other members of this working group. Don't put your trust in fools. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 13:51:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15701 for ; Thu, 12 May 2005 13:51: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 j4CHho7e003898; Thu, 12 May 2005 10:43: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 j4CHhoNg003897; Thu, 12 May 2005 10:43:50 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHhnMu003884 for ; Thu, 12 May 2005 10:43:50 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.103]) by smtp.cegetel.net (Postfix) with ESMTP id 104961A4138; Thu, 12 May 2005 19:43:25 +0200 (CEST) Message-ID: <428395C7.10007@cegetel.net> Date: Thu, 12 May 2005 19:43:35 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: David Powell Cc: Tim Bray , Atom Syntax Subject: Re: PaceAllowDuplicateIDs References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <1139593020.20050512004045@djpowell.net> In-Reply-To: <1139593020.20050512004045@djpowell.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 David Powell wrote: > I'm in favour of allowing duplicate ids. This only seems to be a > partial solution though: > > "Their atom:updated timestamps SHOULD be different" > > But what if they are not? What if I want to represent an archive of a > feed - maybe mine, maybe someone else's - but the atom:updated dates > are the same in two or more entries? I thought it was up to the > publisher to decide whether to rev atom:updated. If you don't update atom:updated (e.g. it's not a "significant" update, fixing typos, etc.), one could (I would) assume you don't want to archive the previous entry "state". There are very few chances that you "significantly" update an entry with the same second (that's the only way to get to the same atom:updated value if the "time-secfrac" is not provided), so you shouldn't have to track "versions" of an entry with the same atom:updated values. So you can have a MUST instead of your SHOULD. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 12 13:59:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16328 for ; Thu, 12 May 2005 13:59: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 j4CHpEwQ004405; Thu, 12 May 2005 10:51: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 j4CHpELI004404; Thu, 12 May 2005 10:51:14 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHpCbf004397 for ; Thu, 12 May 2005 10:51:13 -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, 13 May 2005 02:49:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 02:49:03 +1000 Subject: Re: atom:updated vs entry inheritance? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <540e3732050512090438f29b0f@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 13/5/05 2:04 AM, "Roger B." wrote: >> Gah! What is the true atom:updated for the following entry? > > Eric: The entry-level version, IMO. What if an atom processor had previously seen that entry with that atom:updated ... should it do anything with it? Should it update it's local store in any way? What if the /atom:feed/atom:author element had been changed (and the publisher thought that was significant)? e. From owner-atom-syntax@mail.imc.org Thu May 12 14:19:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17802 for ; Thu, 12 May 2005 14:19: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 j4CIAwMM005750; Thu, 12 May 2005 11:10: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 j4CIAw36005749; Thu, 12 May 2005 11:10:58 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CIAuYp005741 for ; Thu, 12 May 2005 11:10:57 -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, 13 May 2005 04:11:00 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 04:10:41 +1000 Subject: Re: nit: spaces in link@rel? 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 13/5/05 3:32 AM, "Graham" wrote: >> This is confusingly different from HTML's link@rel and should be >> fixed. > > I believe the intention is that only one value is allowed, and any > whitespace included is part of the name of the rel value. Perhaps > this should be noted in the spec. > > Or are you suggesting we adopt the HTML method? perhaps, but it's late, we're in last call, and I'm too tired. I would be happy with allowing only one value, but with that value not including space characters. At least that way we won't be building in breakage if in a future spec the idea of space delimited values is proposed. e. From owner-atom-syntax@mail.imc.org Thu May 12 14:22:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18407 for ; Thu, 12 May 2005 14: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 j4CIFjrT006351; Thu, 12 May 2005 11: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 j4CIFjJo006350; Thu, 12 May 2005 11: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CIFiAT006344 for ; Thu, 12 May 2005 11:15:44 -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, 13 May 2005 04:15:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 04:15:31 +1000 Subject: Re: PaceAllowDuplicateIDs 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 12/5/05 5:26 PM, "Henry Story" wrote: > Don't you have the same problem with atom:modified? What if the > publisher does not update the atom:modified entry? Theoretically, the publisher doesn't get that choice. To not update atom:modified would be an error. There remains the precision issue though. e. From owner-atom-syntax@mail.imc.org Thu May 12 14:30:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19041 for ; Thu, 12 May 2005 14:30: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 j4CIKLk1006602; Thu, 12 May 2005 11:20: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 j4CIKLmt006601; Thu, 12 May 2005 11:20:21 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CIKKE1006593 for ; Thu, 12 May 2005 11:20:20 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.103]) by smtp.cegetel.net (Postfix) with ESMTP id 30AB51A4085; Thu, 12 May 2005 20:19:55 +0200 (CEST) Message-ID: <42839E59.8040202@cegetel.net> Date: Thu, 12 May 2005 20:20:09 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Eric Scheid Cc: Atom Syntax Subject: Re: atom:updated vs entry inheritance? 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: > Gah! What is the true atom:updated for the following entry? > > > 2005-05-12T02:22:59+0000 > ... > ... > > 2005-05-11T01:11:59+0000 > ... > ... > ... > > Well, I don't see any problem here, as the enclosing document (the feed) is said to have been updated later than the enclosed one (the entry). A feed's atom:updated may be later than its latest entry's atom:updated, because you might have changed its title, subtitle, icon, links, etc. It would have been an error, IMO, if the feed's atom:updated had been earlier than its latest entry's atom:updated. However, the spec don't state anything like that. Should I make a Pace? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 12 14:39:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19669 for ; Thu, 12 May 2005 14:39: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 j4CIV2JE007381; Thu, 12 May 2005 11:31: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 j4CIV2jJ007380; Thu, 12 May 2005 11:31:02 -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 j4CIV2w2007366 for ; Thu, 12 May 2005 11:31:02 -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 <2005051218305601400do21pe>; Thu, 12 May 2005 18:30:57 +0000 Date: Thu, 12 May 2005 12:30:55 -0600 Subject: Re: nit: spaces in link@rel? 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 Thursday, May 12, 2005, at 12:10 PM, Eric Scheid wrote: >> I believe the intention is that only one value is allowed, and any >> whitespace included is part of the name of the rel value. Perhaps >> this should be noted in the spec. >> >> Or are you suggesting we adopt the HTML method? > > perhaps, but it's late, we're in last call, and I'm too tired. > > I would be happy with allowing only one value, but with that value not > including space characters. At least that way we won't be building in > breakage if in a future spec the idea of space delimited values is > proposed. From 4.2.9.2 The "rel" Attribute: > The value of "rel" MUST be string that is non-empty, and matches the > "isegment-nz-nc" or "IRI" production in [RFC3987]. If I'm reading RFC3987 correctly, isegment-nz-nc does not include spaces, so I think @rel as spec'd can only contain one value and no whitespace. From owner-atom-syntax@mail.imc.org Thu May 12 14:40:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19766 for ; Thu, 12 May 2005 14:40: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 j4CIWQP5007476; Thu, 12 May 2005 11:32: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 j4CIWQRw007475; Thu, 12 May 2005 11:32: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 j4CIWOkP007455 for ; Thu, 12 May 2005 11:32:25 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 May 2005 18:32:17 -0000 Received: from p508FADEE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.238] by mail.gmx.net (mp005) with SMTP; 12 May 2005 20:32:17 +0200 X-Authenticated: #1915285 Message-ID: <4283A130.6070205@gmx.de> Date: Thu, 12 May 2005 20:32:16 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: Fetch Me A Rock References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> <42838F58.9020102@gmx.de> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512101821efbc4e@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> In-Reply-To: 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 Paul Hoffman wrote: > > At 7:16 PM +0200 5/12/05, Julian Reschke wrote: > >>> A receiving implementation must be able to handle all defined >>> elements, regardless if they are defined as MAY sent, SHOULD send, or >>> MUST send, so I'm not sure what you mean by "interoperate". >> >> >> Must a receiving implementation handle missing elements? I don't think >> as long as we say "sender SHOULD include the element". > > > Bare with me here; I'm not an implementer. What kind of pseudocode are > you envisioning on the receiver side? My picture (which could easily be > wrong is): > > # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 > # Atom 1.0 RFC says entries SHOULD have one atom:foo2 > # Atom 1.0 RFC says entries MAY have one atom:foo3 > > Scan the entry. > > If you don't find an atom:foo1, fail. > If you find more than one atom:foo1, fail. > Process the atom:foo1. > > If you find more than one atom:foo2, fail. > Process the atom:foo2. > > If you find more than one atom:foo3, fail. > Process the atom:foo3. I agree with the analysis. So if our charter says that we should support title-only feeds, we can't make the presence of summary or content a SHOULD, right??? > ... Best regards, Julian From owner-atom-syntax@mail.imc.org Thu May 12 14:49:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20909 for ; Thu, 12 May 2005 14: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 j4CIdswF007922; Thu, 12 May 2005 11:39: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 j4CIdsDG007921; Thu, 12 May 2005 11:39:54 -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 j4CIdsTo007911 for ; Thu, 12 May 2005 11:39:54 -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 <2005051218394901400dkq80e>; Thu, 12 May 2005 18:39:49 +0000 Date: Thu, 12 May 2005 12:39:47 -0600 Subject: Re: atom:updated vs entry inheritance? 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: <42839E59.8040202@cegetel.net> Message-Id: <37674CBE-C315-11D9-8C35-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, May 12, 2005, at 12:20 PM, Thomas Broyer wrote: > Eric Scheid wrote: >> Gah! What is the true atom:updated for the following entry? >> >> 2005-05-12T02:22:59+0000 >> ... >> ... >> >> 2005-05-11T01:11:59+0000 >> ... >> ... >> ... >> >> > > Well, I don't see any problem here, as the enclosing document (the > feed) is said to have been updated later than the enclosed one (the > entry). > A feed's atom:updated may be later than its latest entry's > atom:updated, because you might have changed its title, subtitle, > icon, links, etc. Eric, was your point that the entry might be inheriting data from the feed which was updated after the entry was updated, and therefore, the entry might be though of as having been updated after it's atom:updated timestamp? Other than that, I don't see any problem--the entry was updated when at the time indicated by it's atom:updated element. But back to my question--if for example, the feed/author was updated at the time indicated by feed/updated: 1) If the author of the entry was NOT intended to be changed, the publisher should have put the old author into the entry. 2) If the author of the entry WAS intended to be changed, and the publisher considers this significant to the entry, then the publisher should have updated feed/entry/updated. Because neither of those was done, from the XML shown above, we must assume that whatever change was made to the feed at the time in feed/updated did NOT affect the entry in a way that the publisher considered significant enough to update feed/entry/updated. Another one for the implementors guide? From owner-atom-syntax@mail.imc.org Thu May 12 15:15:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23533 for ; Thu, 12 May 2005 15:15: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 j4CJ7wi2009634; Thu, 12 May 2005 12:07: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 j4CJ7w0u009633; Thu, 12 May 2005 12:07:58 -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 j4CJ7vo6009624 for ; Thu, 12 May 2005 12: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 (sccrmhc14) with SMTP id <200505121907520140037p80e>; Thu, 12 May 2005 19:07:52 +0000 Date: Thu, 12 May 2005 13:07:50 -0600 Subject: Re: Fetch Me A Rock 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: <4283A130.6070205@gmx.de> Message-Id: <226891F4-C319-11D9-8C35-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, May 12, 2005, at 12:32 PM, Julian Reschke wrote: > Paul Hoffman wrote: >> At 7:16 PM +0200 5/12/05, Julian Reschke wrote: >>>> A receiving implementation must be able to handle all defined >>>> elements, regardless if they are defined as MAY sent, SHOULD send, >>>> or MUST send, so I'm not sure what you mean by "interoperate". >>> >>> Must a receiving implementation handle missing elements? I don't >>> think as long as we say "sender SHOULD include the element". >> Bare with me here; I'm not an implementer. What kind of pseudocode >> are you envisioning on the receiver side? My picture (which could >> easily be wrong is): >> # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 >> # Atom 1.0 RFC says entries SHOULD have one atom:foo2 a) ...and MUST NOT have more than one >> # Atom 1.0 RFC says entries MAY have one atom:foo3 b) ...and MUST NOT have more than one >> Scan the entry. >> If you don't find an atom:foo1, fail. >> If you find more than one atom:foo1, fail. >> Process the atom:foo1. >> If you find more than one atom:foo2, fail. >> Process the atom:foo2. c) ...if it exists >> If you find more than one atom:foo3, fail. >> Process the atom:foo3. d) ...if it exists Paul, I presume a, b, c and d are what you intended? > So if our charter says that we should support title-only feeds, we > can't make the presence of summary or content a SHOULD, right??? So what we're discussing here is whether: "If you find more than one atom:foo2, fail. Process the atom:foo2 if it exists." ...should be this instead: "If you find more than one atom:foo2, fail. If you don't find an atom:foo2, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists." RFC 2119 isn't explicit on this point. Here's all it says about SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Perhaps the best we can do from that document is to attempt to divine from what it says about MAY, what it means about SHOULD, but I don't know whether this is valid or not. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) So, if atom:summary is a MAY, then applications MUST be able to deal with feeds whether they have it or not. The text for SHOULD does not call out any such requirements. This omission suggests to me that the intent of SHOULD is to NOT REQUIRE implementations to interoperate with implementations that don't follow the recommendation. Otherwise, would that not have been spelled out? What are "the full implications", if not the possibility of failed interoperability? Reduced functionality? I don't think so, because that is what MAY is about. From owner-atom-syntax@mail.imc.org Thu May 12 15:19:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24106 for ; Thu, 12 May 2005 15: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 j4CJ7EQM009597; Thu, 12 May 2005 12:07: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 j4CJ7EPr009596; Thu, 12 May 2005 12:07:14 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJ7AYT009580; Thu, 12 May 2005 12:07:11 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4283A130.6070205@gmx.de> References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> <42838F58.9020102@gmx.de> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512101821efbc4e@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> <4283A130.6070205@gmx.de> Date: Thu, 12 May 2005 12:07:10 -0700 To: Julian Reschke From: Paul Hoffman Subject: Re: Fetch Me A Rock 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: At 8:32 PM +0200 5/12/05, Julian Reschke wrote: >>Bare with me here; I'm not an implementer. What kind of pseudocode >>are you envisioning on the receiver side? My picture (which could >>easily be wrong is): >> >># Atom 1.0 RFC says entries MUST have exactly one atom:foo1 >># Atom 1.0 RFC says entries SHOULD have one atom:foo2 >># Atom 1.0 RFC says entries MAY have one atom:foo3 >> >>Scan the entry. >> >>If you don't find an atom:foo1, fail. >>If you find more than one atom:foo1, fail. >>Process the atom:foo1. >> >>If you find more than one atom:foo2, fail. >>Process the atom:foo2. >> >>If you find more than one atom:foo3, fail. >>Process the atom:foo3. > >I agree with the analysis. > >So if our charter says that we should support title-only feeds, we >can't make the presence of summary or content a SHOULD, right??? Why not? If the text says something to the effect of, for example, "SHOULD include an atom:summary element unless there really is no summary", then title-only feeds are fine. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 15:24:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24698 for ; Thu, 12 May 2005 15:24: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 j4CJEdWX010084; Thu, 12 May 2005 12:14: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 j4CJEdQI010082; Thu, 12 May 2005 12:14: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.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJEc1D010064 for ; Thu, 12 May 2005 12:14:38 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 12 May 2005 19:14:32 -0000 Received: from p508FADEE.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.173.238] by mail.gmx.net (mp004) with SMTP; 12 May 2005 21:14:32 +0200 X-Authenticated: #1915285 Message-ID: <4283AB10.10009@gmx.de> Date: Thu, 12 May 2005 21:14:24 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: Fetch Me A Rock References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> <42838F58.9020102@gmx.de> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512101821efbc4e@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> <4283A130.6070205@gmx.de> In-Reply-To: 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 Paul Hoffman wrote: > At 8:32 PM +0200 5/12/05, Julian Reschke wrote: > >>> Bare with me here; I'm not an implementer. What kind of pseudocode >>> are you envisioning on the receiver side? My picture (which could >>> easily be wrong is): >>> >>> # Atom 1.0 RFC says entries MUST have exactly one atom:foo1 >>> # Atom 1.0 RFC says entries SHOULD have one atom:foo2 >>> # Atom 1.0 RFC says entries MAY have one atom:foo3 >>> >>> Scan the entry. >>> >>> If you don't find an atom:foo1, fail. >>> If you find more than one atom:foo1, fail. >>> Process the atom:foo1. >>> >>> If you find more than one atom:foo2, fail. >>> Process the atom:foo2. >>> >>> If you find more than one atom:foo3, fail. >>> Process the atom:foo3. >> >> >> I agree with the analysis. >> >> So if our charter says that we should support title-only feeds, we >> can't make the presence of summary or content a SHOULD, right??? > > > Why not? If the text says something to the effect of, for example, > "SHOULD include an atom:summary element unless there really is no > summary", then title-only feeds are fine. :-) Adding "unless there really is no summary" of course changes the meaning in a way that *is* compatible with title-only feeds. So can we change the spec to say that? Best regards, Julian From owner-atom-syntax@mail.imc.org Thu May 12 15:41:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26829 for ; Thu, 12 May 2005 15:41: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 j4CJUoru011284; Thu, 12 May 2005 12:30: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 j4CJUoXg011283; Thu, 12 May 2005 12:30:50 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJUmhR011277 for ; Thu, 12 May 2005 12:30:49 -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, 13 May 2005 05:30:51 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 05:30:33 +1000 Subject: Re: nit: spaces in link@rel? 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 13/5/05 4:30 AM, "Antone Roundy" wrote: > From 4.2.9.2 The "rel" Attribute: >> The value of "rel" MUST be string that is non-empty, and matches the >> "isegment-nz-nc" or "IRI" production in [RFC3987]. > > If I'm reading RFC3987 correctly, isegment-nz-nc does not include > spaces, hmmm - caveat lector. > so I think @rel as spec'd can only contain one value and no > whitespace. but that then means isegment-nz-nc != atomNCName atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } which is easy to fix atomNCName = xsd:string { minLength = "1" pattern = "[^: ]*" } e. From owner-atom-syntax@mail.imc.org Thu May 12 15:48:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27306 for ; Thu, 12 May 2005 15:48: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 j4CJebqa011687; Thu, 12 May 2005 12:40: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 j4CJebL7011686; Thu, 12 May 2005 12:40:37 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJeakh011679 for ; Thu, 12 May 2005 12:40:37 -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, 13 May 2005 05:40:42 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 05:40:23 +1000 Subject: Re: atom:updated vs entry inheritance? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <37674CBE-C315-11D9-8C35-003065EA6144@geckotribe.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 13/5/05 4:39 AM, "Antone Roundy" wrote: > Eric, was your point that the entry might be inheriting data from the > feed which was updated after the entry was updated, and therefore, the > entry might be thought of as having been updated after it's atom:updated > timestamp? Other than that, I don't see any problem--the entry was > updated when at the time indicated by it's atom:updated element. Yes. Which has implications in implementations. Consider an implementation that stores entries in a local database, but doesn't bother doing a record update if it later sees the same entry where /entry/updated hasn't changed. > But back to my question--if for example, the feed/author was updated at > the time indicated by feed/updated: > > 1) If the author of the entry was NOT intended to be changed, the > publisher should have put the old author into the entry. true. not a problem. > 2) If the author of the entry WAS intended to be changed, and the > publisher considers this significant to the entry, then the publisher > should have updated feed/entry/updated. I agree. You can see how easy it would be to not do that though. It could also be argued that the publisher has signalled the significance by updating /feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me. > Because neither of those was done, from the XML shown above, we must > assume that whatever change was made to the feed at the time in > feed/updated did NOT affect the entry in a way that the publisher > considered significant enough to update feed/entry/updated. Another > one for the implementors guide? Yes, another for the implementors guide. e. From owner-atom-syntax@mail.imc.org Thu May 12 16:00:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28614 for ; Thu, 12 May 2005 16:00: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 j4CJpOIw012188; Thu, 12 May 2005 12:51: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 j4CJpOCh012187; Thu, 12 May 2005 12:51:24 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJpNfp012181 for ; Thu, 12 May 2005 12:51:24 -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, 13 May 2005 05:51:28 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 05:51:10 +1000 Subject: Re: Fetch Me A Rock From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <226891F4-C319-11D9-8C35-003065EA6144@geckotribe.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 13/5/05 5:07 AM, "Antone Roundy" wrote: > "If you find more than one atom:foo2, fail. Process the atom:foo2 if it > exists." > > ...should be this instead: > > "If you find more than one atom:foo2, fail. If you don't find an > atom:foo2, you are allowed to fail and still call yourself Atom > compliant. Process the atom:foo2 if it exists." I'd say it should be this instead: "If you find more than one atom:foo2, fail. If you don't find an atom:foo2, * and you really, really need it, you are allowed to fail and still call yourself Atom compliant. Process the atom:foo2 if it exists." Examples of "need it": a search robot that is looking for either summary or content a spammer tool that searches for email addresses in author elements (yes, I know that's a MAY) e. From owner-atom-syntax@mail.imc.org Thu May 12 16:05:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01140 for ; Thu, 12 May 2005 16:05: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 j4CJuQ23012416; Thu, 12 May 2005 12:56: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 j4CJuQb1012415; Thu, 12 May 2005 12:56:26 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJuPAi012397; Thu, 12 May 2005 12:56:25 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.103]) by smtp.cegetel.net (Postfix) with ESMTP id 3B4261A478A; Thu, 12 May 2005 21:56:00 +0200 (CEST) Message-ID: <4283B4E2.7080200@cegetel.net> Date: Thu, 12 May 2005 21:56:18 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Julian Reschke Cc: Paul Hoffman , Atom WG Subject: Re: Fetch Me A Rock References: <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c505051108385062f2e7@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c5050511201818b26cff@mail.gmail.com> <42838F58.9020102@gmx.de> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512101821efbc4e@mail.gmail.com> <4282CA72.6050102@intertwingly.net> <68fba5c505051108385062f2e7@mail.gmail.com> <68fba5c5050511201818b26cff@mail.gmail.com> <68fba5c5050512102012966e9a@mail.gmail.com> <4283A130.6070205@gmx.de> <4283AB10.10009@gmx.de> In-Reply-To: <4283AB10.10009@gmx.de> 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 Julian Reschke wrote: > Paul Hoffman wrote: >> Why not? If the text says something to the effect of, for example, >> "SHOULD include an atom:summary element unless there really is no >> summary", then title-only feeds are fine. > > > :-) > > Adding "unless there really is no summary" of course changes the meaning > in a way that *is* compatible with title-only feeds. So can we change > the spec to say that? No, because you usually provide title-only feeds not because you don't have any content available but because title-only feeds: 1. are smaller and then meet wireless devices constraints (especially reduced bandwidth) 2. meet some users/software needs (a "news ticker" displaying only titles, or people who just want to be advised when something new is available no matter really about its content) IMO, the PaceTextShouldBeProvided thingy should go in an *informative* appendix ("Interoperability considerations"): the spec _allows_ title-only feeds (normative) but authors _recommend_ providing textual content or an alternative feed including such textual content. This is an advice, nothing more (or less). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 12 16:11:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03031 for ; Thu, 12 May 2005 16:11: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 j4CK25ZR013143; Thu, 12 May 2005 13:02: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 j4CK25UR013142; Thu, 12 May 2005 13:02:05 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CK236s013136 for ; Thu, 12 May 2005 13:02:04 -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, 13 May 2005 06:02:07 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 06:01:48 +1000 Subject: Re: Fetch Me A Rock From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4283AB10.10009@gmx.de> 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 13/5/05 5:14 AM, "Julian Reschke" wrote: >> Why not? If the text says something to the effect of, for example, >> "SHOULD include an atom:summary element unless there really is no >> summary", then title-only feeds are fine. > > :-) > > Adding "unless there really is no summary" of course changes the meaning > in a way that *is* compatible with title-only feeds. So can we change > the spec to say that? +1 except that excludes other scenarios... For example: ... ... ... ... where the resource/representation retrievable from @href would include all the other elements (content, summary, author, category, copyright, etc etc). Thus, the 'entry' really does have a summary, but it's just not in the feed. If someone wants to write an aggregator/reader which expects everything to be right there in the feed, then sure, they can happily fail. Or more properly, they can say "we don't support that functionality". Just like how some web browsers don't support displaying images inline with the page ... they don't say "ick, spit, nasty pages, broken pages, has evil tags, it's broken broken broken". No, they simply don't support that functionality. e. From owner-atom-syntax@mail.imc.org Thu May 12 16:22:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06631 for ; Thu, 12 May 2005 16: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 j4CKBtZR013862; Thu, 12 May 2005 13:11: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 j4CKBtGj013861; Thu, 12 May 2005 13:11:55 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CKBr8H013851; Thu, 12 May 2005 13:11:54 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <226891F4-C319-11D9-8C35-003065EA6144@geckotribe.com> References: <226891F4-C319-11D9-8C35-003065EA6144@geckotribe.com> Date: Thu, 12 May 2005 13:11:52 -0700 To: Antone Roundy , atom-syntax@imc.org From: Paul Hoffman Subject: Re: Fetch Me A Rock 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 1:07 PM -0600 5/12/05, Antone Roundy wrote: >On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote: >>Paul Hoffman wrote: >>>At 7:16 PM +0200 5/12/05, Julian Reschke wrote: >>>>>A receiving implementation must be able to handle all defined >>>>>elements, regardless if they are defined as MAY sent, SHOULD >>>>>send, or MUST send, so I'm not sure what you mean by >>>>>"interoperate". >>>> >>>>Must a receiving implementation handle missing elements? I don't >>>>think as long as we say "sender SHOULD include the element". >>>Bare with me here; I'm not an implementer. What kind of pseudocode >>>are you envisioning on the receiver side? My picture (which could >>>easily be wrong is): >>># Atom 1.0 RFC says entries MUST have exactly one atom:foo1 >>># Atom 1.0 RFC says entries SHOULD have one atom:foo2 >a) ...and MUST NOT have more than one >>># Atom 1.0 RFC says entries MAY have one atom:foo3 >b) ...and MUST NOT have more than one >>>Scan the entry. >>>If you don't find an atom:foo1, fail. >>>If you find more than one atom:foo1, fail. >>>Process the atom:foo1. >>>If you find more than one atom:foo2, fail. >>>Process the atom:foo2. >c) ...if it exists >>>If you find more than one atom:foo3, fail. >>>Process the atom:foo3. >d) ...if it exists > >Paul, I presume a, b, c and d are what you intended? Yes, thank you. See why I'm not a developer? :-) >>So if our charter says that we should support title-only feeds, we >>can't make the presence of summary or content a SHOULD, right??? > >So what we're discussing here is whether: > >"If you find more than one atom:foo2, fail. Process the atom:foo2 if >it exists." > >...should be this instead: > >"If you find more than one atom:foo2, fail. If you don't find an >atom:foo2, you are allowed to fail and still call yourself Atom >compliant. Process the atom:foo2 if it exists." > >RFC 2119 isn't explicit on this point. Here's all it says about SHOULD: > >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > >Perhaps the best we can do from that document is to attempt to >divine from what it says about MAY, what it means about SHOULD, but >I don't know whether this is valid or not. > >5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > >So, if atom:summary is a MAY, then applications MUST be able to deal >with feeds whether they have it or not. The text for SHOULD does >not call out any such requirements. This omission suggests to me >that the intent of SHOULD is to NOT REQUIRE implementations to >interoperate with implementations that don't follow the >recommendation. Otherwise, would that not have been spelled out? >What are "the full implications", if not the possibility of failed >interoperability? Reduced functionality? I don't think so, because >that is what MAY is about. You are reading *way* too much into 2119; this is a normal thing to do. The problem we have, as I pointed out earlier on the thread, is that we do not specify whether senders and receivers have the same SHOULD. I made one assumption, and Rob pointed out that I had made one different than he did. The way I read 2119 is that if a sender MAY or SHOULD include something, the receiver MUST NOT fall over if it is in what they receive, and MUST NOT fall over if it is not in what they receive. Does that clarify where I got to on this thread? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 16:46:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08368 for ; Thu, 12 May 2005 16:46: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 j4CKdmWH016162; Thu, 12 May 2005 13:39: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 j4CKdm6k016161; Thu, 12 May 2005 13:39:48 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CKdluC016149 for ; Thu, 12 May 2005 13:39:47 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.70.103]) by smtp.cegetel.net (Postfix) with ESMTP id BE7AC31899A; Thu, 12 May 2005 22:39:41 +0200 (CEST) Message-ID: <4283BF0E.3010503@cegetel.net> Date: Thu, 12 May 2005 22:39:42 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Eric Scheid Cc: Atom Syntax Subject: Re: nit: spaces in link@rel? 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: >>so I think @rel as spec'd can only contain one value and no >>whitespace. > > > but that then means isegment-nz-nc != atomNCName > > atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } > > which is easy to fix > > atomNCName = xsd:string { minLength = "1" pattern = "[^: ]*" } The RNC is not normative and, actually, your modified atomNCName does not match isegment-nz-nc either. Something approaching might be xsd:NMTOKEN (which might later be "extended" to xsd:NMTOKENS to allow space-delimited lists of NMTOKEN) or xsd:NCName. I've not checked but I think they accept the same list of characters (especially the "ucschar" production of RFC3987). Note that none of them accepts percent-encoded characters. This is IMO a good thing and it should be enforced by the Atom spec. Having names matching xsd:NMTOKEN or xsd:NCName should be enforced by the IANA "relations" registry process and/or the Atom spec (I'm not used to the IANA stuff and don't know how values will be later added to the "relations" registry). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 12 16:57:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08938 for ; Thu, 12 May 2005 16:57: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 j4CKhqZO016405; Thu, 12 May 2005 13: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 j4CKhqJg016404; Thu, 12 May 2005 13:43:52 -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 j4CKhpqa016398 for ; Thu, 12 May 2005 13:43:51 -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]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j4CKie3M017340 for ; Thu, 12 May 2005 16:44:52 -0400 Message-ID: <4283BFFA.7000109@intertwingly.net> Date: Thu, 12 May 2005 16:43:38 -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: Re: On SHOULD References: <68fba5c5050509103155337401@mail.gmail.com> In-Reply-To: <68fba5c5050509103155337401@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 People seem confused about RFC 2119. If it helps, here is an example. But, be aware, it is JUST an example at this point. I'd like to be able to discuss it without people questioning each other's commercial viability, personal relevance to this process, or talking about things "caching fire" or the like, OK? I'm also staying away from "atom:summary" for the the moment as there continues to be more heat than light in that particular conversation. With that in mind, I suggest that the following are roughly equivalent: atom:title MAY be empty, but be aware that if it is empty, the recipient MAY chose to ignore the entire entry. atom:title SHOULD NOT be empty, lest the recipient choses to ignore the entire entry. While the latter is slightly stronger, what is being conveyed in each case is "you are free to do this, but be aware that there are implications that you need to consider". This is not meant as a value judgment. And to illustrate this example, I offer the following for Firefox users: http://intertwingly.net/stories/2005/05/12/ Even with this example in mind, things are not cut and dry: We could decide as a group that titles MUST be present and not empty. Even knowing that this means that somewhere that somebody will create a feed either ignoring this requirement. And it might even work. But when things break, it is clear who to blame. We could decide as a group that titles SHOULD be present and not empty. This puts both parties on notice. If you include it, more things work. If you don't, many things will still work. Furthermore, people who parse feeds are put on notice that from time to time they will encounter entries with empty titles. We could decide as a group that titles are completely OPTIONAL. This is pretty much the reverse of the MUST case above. If things break, it is the recipient who is to blame. I claim that we are free to pick amongst all three of these alternatives. We would also shunt this issue off to a Best Current Practices document. What's worse, there is no magic numbers to guide us in this decision. Examples of things you WON'T find: "if not including a title affects more than 17% of the user base" or a if this affects a tool produced by a company with a market cap of greater than 6.3 billion dollars". It comes down to judgment. And on matters of judgment, reasonable people will disagree. - - - So far, we seem to have consensus that atom:id MUST be present in atom:entries. People who intend to consume atom feeds have expressed this requirement pretty clearly, and as a group we seem inclined to satisfy this requirement. So far, I don't recall anybody stepping forward and saying that feeds without atom:category elements will be less effective. Now that I have said that, I'm sure that somebody could come up with an example, but that would only prove my point that this is about judgment. - - - We have RFC 2119. We have Paul on record saying that if this actually is the will of the working group, scenarios such as these are appropriate uses of the word SHOULD. Note: this is not Paul advocating any particular outcome, simply saying that that option is open to us. With all this in mind, my suggestion is that we all calm down for a few days, and discussion things other than text elements. And when we do revisit this discussion early next week, lets not start with atom:summary, OK? - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 12 17:22:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10574 for ; Thu, 12 May 2005 17:22: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 j4CLCVf0017974; Thu, 12 May 2005 14:12: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 j4CLCVZg017973; Thu, 12 May 2005 14:12:31 -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 j4CLCUlP017966 for ; Thu, 12 May 2005 14:12:30 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 83012 invoked by uid 17064); 12 May 2005 21:12:29 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.141.121]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 12 May 2005 21:12:29 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) 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: atom:updated vs entry inheritance? Date: Thu, 12 May 2005 23:12:28 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 May 2005, at 18:49, Eric Scheid wrote: > On 13/5/05 2:04 AM, "Roger B." wrote: >>> Gah! What is the true atom:updated for the following entry? >>> >> >> Eric: The entry-level version, IMO. >> > > What if an atom processor had previously seen that entry with that > atom:updated ... should it do anything with it? Should it update > it's local > store in any way? > > What if the /atom:feed/atom:author element had been changed (and the > publisher thought that was significant)? Just to recapitulate: we have 2 feed documents with successive atom updated values, and with the same entry (same id) with the same time stamp but some values that are not identical. Does the newer feed document trump the older one? Does this not all depend whether you are an optimist or a pessimist? The optimist will think that the future is always an improvement over the past, and so think that the new feed he has received will be giving a correction on the old state of the entry. The pessimist will think that the future is worse than the present, and think that the newer version of the feed documents must contain a mistaken entry. Henry > > e. > From owner-atom-syntax@mail.imc.org Thu May 12 17:30:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11055 for ; Thu, 12 May 2005 17:30: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 j4CLNHTG018729; Thu, 12 May 2005 14:23: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 j4CLNH2Z018728; Thu, 12 May 2005 14:23:17 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CLNGOd018721 for ; Thu, 12 May 2005 14:23: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); Fri, 13 May 2005 07:23:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 May 2005 07:22:58 +1000 Subject: Re: atom:updated vs entry inheritance? 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 13/5/05 7:12 AM, "Henry Story" wrote: > Just to recapitulate: we have 2 feed documents with successive atom updated > values, and with the same entry (same id) with the same time stamp but some > values that are not identical. Does the newer feed document trump the older > one? I assume what you mean by "values" includes the explicit elements of the *plus* the implicit elements inherited from the . Right? It follows then that /feed/updated applies *only* to the feed meta-data, and possibly also the feed entries as a collection of opaque blobs. That is, the contents of the entries don't inherit any 'significant change' semantic from /feed/updated. Best practice then would be to update /feed/entry/updated if an inherited /feed/element is updated 'significantly'. I'm happy with that. e. From owner-atom-syntax@mail.imc.org Thu May 12 17:54:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12874 for ; Thu, 12 May 2005 17:54: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 j4CLkWaQ020446; Thu, 12 May 2005 14: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 j4CLkW93020445; Thu, 12 May 2005 14:46:32 -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 j4CLkWHq020425 for ; Thu, 12 May 2005 14:46:32 -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 <2005051221462201100k16qie>; Thu, 12 May 2005 21:46:22 +0000 Date: Thu, 12 May 2005 15:46:21 -0600 Subject: Re: Fetch Me A Rock 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: <47442987-C32F-11D9-8C35-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, May 12, 2005, at 02:11 PM, Paul Hoffman wrote: >> So, if atom:summary is a MAY, then applications MUST be able to deal >> with feeds whether they have it or not. The text for SHOULD does not >> call out any such requirements. This omission suggests to me that >> the intent of SHOULD is to NOT REQUIRE implementations to >> interoperate with implementations that don't follow the >> recommendation. Otherwise, would that not have been spelled out? >> What are "the full implications", if not the possibility of failed >> interoperability? Reduced functionality? I don't think so, because >> that is what MAY is about. > > You are reading *way* too much into 2119; this is a normal thing to do. I realize I was going beyond what it actually says, thus: >> RFC 2119 isn't explicit on this point. and: >> Perhaps the best we can do from that document is to attempt to divine >> from what it says about MAY, what it means about SHOULD, but I don't >> know whether this is valid or not. > The problem we have, as I pointed out earlier on the thread, is that > we do not specify whether senders and receivers have the same SHOULD. > I made one assumption, and Rob pointed out that I had made one > different than he did. So because both RFC 2119 and the current Atom draft are not explicit on this point, it is open either to varied interpretations, or at least to misinterpretations. > The way I read 2119 is that if a sender MAY or SHOULD include > something, the receiver MUST NOT fall over if it is in what they > receive, and MUST NOT fall over if it is not in what they receive. > Does that clarify where I got to on this thread? Fortunately, as you suggest above, we can resolve the issue at hand by clarifying our spec (by explicitly stating the SHOULDs, MUSTs and MAYs for both the producer and consumer)...if we can come to consensus on what we want, that is! That would probably be a lot easier than coming to consensus on the one true reading of RFC 2119 and figuring out how to apply it to the Atom spec. From owner-atom-syntax@mail.imc.org Thu May 12 18:28:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16145 for ; Thu, 12 May 2005 18:28: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 j4CMHvdo022330; Thu, 12 May 2005 15:17: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 j4CMHvIe022328; Thu, 12 May 2005 15:17:57 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CMHsbx022317; Thu, 12 May 2005 15:17:55 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4283BFFA.7000109@intertwingly.net> References: <68fba5c5050509103155337401@mail.gmail.com> <4283BFFA.7000109@intertwingly.net> Date: Thu, 12 May 2005 15:16:08 -0700 To: Sam Ruby , atom-syntax@imc.org From: Paul Hoffman Subject: Re: On SHOULD 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 4:43 PM -0400 5/12/05, Sam Ruby wrote: >With that in mind, I suggest that the following are roughly equivalent: > > atom:title MAY be empty, but be aware that if it is empty, the > recipient MAY chose to ignore the entire entry. > > atom:title SHOULD NOT be empty, lest the recipient choses to ignore > the entire entry. They are roughly equivalent with normal usage of those words, but in my mind, not with respect to RFC 2119. The latter does not give an implementer enough information to determine when he or she might want to include and atom:title, and when he or she might not. Put another way, if I were implementing, I would understand the first one much more than I would understand the second one, even though the person writing the two thought they were roughly equivalent. Also, as was pointed out to me earlier on this thread, it is not clear to whom these are addressed: Atom producers or Atom consumers. If read as-is by an implementer of consumers, the second one sounds more like an invitation to ignore than the first. >It comes down to judgment. And on matters of judgment, reasonable >people will disagree. +1 >We have RFC 2119. We have Paul on record saying that if this >actually is the will of the working group, scenarios such as these >are appropriate uses of the word SHOULD. Not quite. I think (I hope!) the essence of what I said was "you can use a SHOULD if you explain what the exceptions are". I don't think the example above meets that test. >With all this in mind, my suggestion is that we all calm down for a >few days, and discussion things other than text elements. +1 >And when we do revisit this discussion early next week, lets not >start with atom:summary, OK? The co-chairs will attempt to find a different way to determine WG consensus on atom:summary than the current method, which is not working. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 12 18:59:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18280 for ; Thu, 12 May 2005 18:59: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 j4CMpdqr024557; Thu, 12 May 2005 15:51: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 j4CMpdcP024556; Thu, 12 May 2005 15:51:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CMpWOp024546 for ; Thu, 12 May 2005 15:51:38 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 47667 messnum 2898281 invoked from network[83.70.217.193/unknown]); 12 May 2005 22:51:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail06.svc.cra.dublin.eircom.net (qp 47667) with SMTP; 12 May 2005 22:51:26 -0000 Message-ID: <4283DDEB.4090408@dehora.net> Date: Thu, 12 May 2005 23:51:23 +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: atom:updated vs entry inheritance? 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: > I agree. You can see how easy it would be to not do that though. It could > also be argued that the publisher has signalled the significance by updating > /feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me. "thus effectively", does not follow. That's not warranted unless we say it is. There's no ambiguity, at best there's an optical illusion provided by looking at an XML structure with programming language scope rules in mind. If you're still concerned people are going to get the wrong impression, I'd probably support spec text making such scoping matters explicit - I imagine this would result in a subsection since dates are not the only issue I think. cheers Bill From owner-atom-syntax@mail.imc.org Thu May 12 20:30:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28119 for ; Thu, 12 May 2005 20:30: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 j4D0KDjB029986; Thu, 12 May 2005 17: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 j4D0KDCL029985; Thu, 12 May 2005 17:20:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D0KB5f029971 for ; Thu, 12 May 2005 17:20:11 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050513002004.CLMO9472.mta09-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Fri, 13 May 2005 01:20:04 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050513002004.IASN5678.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Fri, 13 May 2005 01:20:04 +0100 Date: Fri, 13 May 2005 01:20:02 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC8) Professional X-Priority: 3 (Normal) Message-ID: <1095532852.20050513012002@djpowell.net> To: Eric Scheid CC: Atom Syntax Subject: Re: PaceAllowDuplicateIDs alteration In-Reply-To: References: <73C325B6-3791-4348-8CF4-4C1A0E7B1FA7@mac.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 Friday, May 6, 2005, 3:52:19 PM, Eric Scheid wrote: > On 7/5/05 12:09 AM, "Graham" wrote: >> "If an Atom Feed Document contains multiple entries with the same >> atom:id, software MUST treat them as multiple versions of the same >> entry" >> >> I don't think this changes the technical meaning of the proposal, but >> does make it very explicit. > +1, with one minor amendment. > s/versions/instantiations/ > the spec uses that word elsewhere, and 'versions' might suggest a media > adaptation, language variant, etc. How about "revisions"? "versions" could sound too broad, it could imply that the entry could change for all sorts of reasons, conneg etc. "instantiations/instances" could sound like they could be identical copies of the same information. "revisions" suggests something that changes over time, which is closer to what we mean I think? -- Dave From owner-atom-syntax@mail.imc.org Thu May 12 20:44:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29194 for ; Thu, 12 May 2005 20:44: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 j4D0YE0I030850; Thu, 12 May 2005 17:34: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 j4D0YEv5030849; Thu, 12 May 2005 17:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D0YCV7030829 for ; Thu, 12 May 2005 17:34:13 -0700 (PDT) (envelope-from dave@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050513003407.EYSP9472.mta09-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com> for ; Fri, 13 May 2005 01:34:07 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050513003407.JETY5678.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Fri, 13 May 2005 01:34:07 +0100 Date: Thu, 12 May 2005 12:40:45 +0100 From: David Powell X-Mailer: The Bat! (v3.5 Return RC4) Professional Reply-To: David Powell X-Priority: 3 (Normal) Message-ID: <1949918229.20050512124045@djpowell.net> To: Atom Syntax Subject: Editorial: updated 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 Section 4.2.15: "Publishers MAY change the value of this element over time." This sentence seems pretty obvious. It could be said about atom:title, or any of the fields. Does it have some subtle meaning that I am missing? -- Dave From owner-atom-syntax@mail.imc.org Fri May 13 03:24:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16585 for ; Fri, 13 May 2005 03: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 j4D7A303010001; Fri, 13 May 2005 00:10: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 j4D7A3pp010000; Fri, 13 May 2005 00:10:03 -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 j4D7A13Y009981 for ; Fri, 13 May 2005 00:10:01 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 99895 invoked by uid 17064); 13 May 2005 07:10:01 -0000 Received: from unknown (HELO [192.168.0.9]) ([83.112.143.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 13 May 2005 07:10:01 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) 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: atom:updated vs entry inheritance? Date: Fri, 13 May 2005 09:10:00 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 12 May 2005, at 23:22, Eric Scheid wrote: > On 13/5/05 7:12 AM, "Henry Story" wrote: >> Just to recapitulate: we have 2 feed documents with successive >> atom updated >> values, and with the same entry (same id) with the same time >> stamp but some >> values that are not identical. Does the newer feed document trump >> the older >> one? >> > > I assume what you mean by "values" includes the explicit elements > of the > *plus* the implicit elements inherited from the . Right? Oh. I understand your puzzle now (reading this list a little fast at times) I had forgotten about inheritance. The simplest solution is just to remove these inheritance rules of course. Henry > It follows then that /feed/updated applies *only* to the feed meta- > data, and > possibly also the feed entries as a collection of opaque blobs. > That is, the > contents of the entries don't inherit any 'significant change' > semantic from > /feed/updated. > > Best practice then would be to update /feed/entry/updated if an > inherited > /feed/element is updated 'significantly'. > > I'm happy with that. > > e. > From owner-atom-syntax@mail.imc.org Fri May 13 09:28:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14990 for ; Fri, 13 May 2005 09:28: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 j4DDGAEX041518; Fri, 13 May 2005 06:16: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 j4DDGAiW041517; Fri, 13 May 2005 06:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DDG9on041510 for ; Fri, 13 May 2005 06:16:09 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id ED76F16EDF; Fri, 13 May 2005 08:16:26 -0500 (CDT) Date: Fri, 13 May 2005 08:16:26 -0500 From: David Nesting To: atom-syntax@imc.org Subject: Re: Fetch Me A Rock Message-ID: <20050513131626.GW2161@home.fastolfe.net> References: <47442987-C32F-11D9-8C35-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47442987-C32F-11D9-8C35-003065EA6144@geckotribe.com> User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: > > >The problem we have, as I pointed out earlier on the thread, is that > >we do not specify whether senders and receivers have the same SHOULD. > >I made one assumption, and Rob pointed out that I had made one > >different than he did. > > So because both RFC 2119 and the current Atom draft are not explicit on > this point, it is open either to varied interpretations, or at least to > misinterpretations. It is therefore up to us to clarify: A summary SHOULD* be present in an entry. Implementations MUST be capable of processing entries with and without summaries (title-only feeds). This is not intended to suggest that implementations must do something useful with title-only entries. * - The "implications" are that many processors will ignore or reject entries that do not have summaries, because the processor may place the emphasis of its processing on the summary. The feed as a whole is still valid, however, and it's expected that processors will handle entries that DO have summaries in the same feed as entries that do NOT. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Fri May 13 10:29:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20746 for ; Fri, 13 May 2005 10:29: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 j4DEKBf5046658; Fri, 13 May 2005 07:20: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 j4DEKBXv046657; Fri, 13 May 2005 07:20: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 j4DEKAtI046647 for ; Fri, 13 May 2005 07:20:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.107] (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 j4DEL8Lt001149; Fri, 13 May 2005 10:21:08 -0400 Message-ID: <4284B792.5040701@intertwingly.net> Date: Fri, 13 May 2005 10:20:02 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Nesting CC: atom-syntax@imc.org Subject: Re: Fetch Me A Rock References: <47442987-C32F-11D9-8C35-003065EA6144@geckotribe.com> <20050513131626.GW2161@home.fastolfe.net> In-Reply-To: <20050513131626.GW2161@home.fastolfe.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 David Nesting wrote: > On Thu, May 12, 2005 at 03:46:21PM -0600, Antone Roundy wrote: > >>>The problem we have, as I pointed out earlier on the thread, is that >>>we do not specify whether senders and receivers have the same SHOULD. >>>I made one assumption, and Rob pointed out that I had made one >>>different than he did. >> >>So because both RFC 2119 and the current Atom draft are not explicit on >>this point, it is open either to varied interpretations, or at least to >>misinterpretations. > > It is therefore up to us to clarify: > > A summary SHOULD* be present in an entry. Implementations MUST be > capable of processing entries with and without summaries (title-only > feeds). This is not intended to suggest that implementations must > do something useful with title-only entries. > > * - The "implications" are that many processors will ignore or reject > entries that do not have summaries, because the processor may place the > emphasis of its processing on the summary. The feed as a whole is still > valid, however, and it's expected that processors will handle entries > that DO have summaries in the same feed as entries that do NOT. Very nice. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri May 13 12:27:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29077 for ; Fri, 13 May 2005 12:27: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 j4DGBSKW057198; Fri, 13 May 2005 09:11: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 j4DGBS3m057196; Fri, 13 May 2005 09:11:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web52008.mail.yahoo.com (web52008.mail.yahoo.com [206.190.39.64]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4DGBRup057179 for ; Fri, 13 May 2005 09:11:27 -0700 (PDT) (envelope-from ecomputerd@yahoo.com) Received: (qmail 83198 invoked by uid 60001); 13 May 2005 16:11:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=bltLqWc3rphYmpOASqGoEQtzQmPap9PJ3vLRPpkB8TBrYUcdExWMUNgvOt/b4apXRTpRGxLQZxpOFAsRXfoOsIa5Y8B0nYyJeT5+O8O740mcdHcgxZEE7wgotpC1WH6N7g6V/Nm3/CrzOJGo9YYQm6YyynS4wNckZhre5uaWDkA= ; Message-ID: <20050513161121.83196.qmail@web52008.mail.yahoo.com> Received: from [65.15.100.176] by web52008.mail.yahoo.com via HTTP; Fri, 13 May 2005 09:11:20 PDT Date: Fri, 13 May 2005 09:11:20 -0700 (PDT) From: Greg Smith Subject: Re: draft-ietf-atompub-protocol-04.txt To: Greg Smith , Joe Gregorio Cc: atom-syntax@imc.org, Atom Protocol In-Reply-To: 6667 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: As a further clarification of my ideas about replacing "contents" attribute with a "content" element specifying the specific allowed MIME Types. I chose an element because my understanding is that XML attributes are assumed to be listed singly (only one name/value pair per name) whereas an element can be listed multiple times with different values or attributes. I propose the following modification to Section 8.1. For your reference, the MIME Types are listed by the IANA at http://www.iana.org/assignments/media-types/index.html It still seems to me that this would provide a hugely powerful capability to ATOM. Specifically, note the "Documents", "Pictures", and "Audio" collections in the example. For Section 8.1 The Introspection Document has the media-type 'application/ atomserv+xml', see Section 11 This specifies that workspace/collection "Main Title"/"My Blog Entries" can be operated on by a generic atom publishing tool, and so can "Documents". Collection "Pictures" however is designed to take only the image types listed. If your ATOM publishing tool can work with these types, then it may be able to work with the collection using APP. The APP does specify certain actions that alternatiely can or must be supported by each collection and the "Pictures" collection can certainly handle each of these actions, including POST and GET to retrieve collection information associated with this Collection. Even if we were to simply define "audio" as a separate "content" attribute (content="audio"), it still would not have anywhere near the specificity of defining the exact MIME Types allowed. And I predict we would run into all kinds of compatibility problems with clients and servers if MIME Types are not listed SOMEWHERE for the client to determine. A situation which is elegantly solved by this proposal, in my opinion. Greg Smith --- Greg Smith wrote: > > Joe, > > Thanks for your comments on my comments ;-) > > >> While we could create a whole series of "entry", > >> "generic", and other types, it might be better to > >> consider listing for each collection, the > acceptable > >> Content-Types. > >> > > > >This document is just the 'basic' protocol, where > we > are describing > >the basic mechanisms and collection types. We are > >expecting to produce > >a further specification that covers editing > >collections of other types > >of documents, such as templates, etc. > > In the current specification draft (04), it looks > like > the "entry" and "generic" both specify identical > actions (in the table showing Body/No body versus > GET/PUT/DELETE/POST. So the real difference between > the two is in the Content-types that each can > handle: > "generic" is unspecified, while "entry" is > only defined as "application/atom+xml" or > "application/soap+xml". In addition, the PROTOCOL > specifies which ATOM elements are Roundtrip. > > The advantage of specifying Content-Types as opposed > to contents attribute of "entry" and "generic" (and > further definitions): > > 1) immediately gain the ability of the client to > discern acceptable Content-Types, something sorely > missing from the current specification. > > 2) immediately gain the advantage of the client > being > able to determine if it can "talk" to the ATOM URI. > (Graphic applications can "talk" to ATOM APP that > accept "image/*", audio applications="audio/*", etc) > > 3) Do not have to amend a specification (or create a > new one) in order to handle every single > Content-Type. > > 4) Adding different Content-Types to the allowable > formats immediately opens the specification to a > wide > range of fairly obvious uses in the podcasting, > videocasting, *casting. And even in corporate use, > building in the parsing of Content-Types makes > available any kind of syndicated content whatsoever > using the same tools built around the APP > specification. > > The current use of "contents" attribute still may > have > its place (in resolving duplicate Content-Type > applications such as application/atom+xml templates > vs. application/atom+xml entries -- but I'm not > fully > convinced of this example, however, there may be > others). > > And then to cover the other specification listed > under > contents="entry": you could specify that all > application/atom+xml entries provide Roundtrip > atom:updated and atom:id elements. I don't *think* > that this would adversly impact other uses of atom > or > APP. > > Again, just thoughts that I'm happy to debate. I > don't > want to step on anyone's toes here. > > Greg Smith > > > > Yahoo! Mail > Stay connected, organized, and protected. Take the > tour: > http://tour.mail.yahoo.com/mailtour.html > > __________________________________ Yahoo! Mail 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 Fri May 13 13:14:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06398 for ; Fri, 13 May 2005 13: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 j4DH5f8e063382; Fri, 13 May 2005 10:05: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 j4DH5fZU063381; Fri, 13 May 2005 10:05:41 -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 j4DH5c4F063362 for ; Fri, 13 May 2005 10:05:39 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 13 May 2005 17:05:33 -0000 Received: from xdsl-213-196-243-41.netcologne.de (EHLO klangraum) [213.196.243.41] by mail.gmx.net (mp023) with SMTP; 13 May 2005 19:05:33 +0200 X-Authenticated: #163624 Date: Fri, 13 May 2005 19:08:58 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Fetch Me A Rock Message-ID: <20050513170858.GA30124@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <47442987-C32F-11D9-8C35-003065EA6144@geckotribe.com> <20050513131626.GW2161@home.fastolfe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050513131626.GW2161@home.fastolfe.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: * David Nesting [2005-05-13 15:25]: > It is therefore up to us to clarify: > > A summary SHOULD* be present in an entry. Implementations > MUST be capable of processing entries with and without > summaries (title-only feeds). This is not intended to > suggest that implementations must do something useful with > title-only entries. +1 Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri May 13 20:36:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25897 for ; Fri, 13 May 2005 20:36: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 j4E0ScL5000502; Fri, 13 May 2005 17:28: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 j4E0SceB000501; Fri, 13 May 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 pop-a065d01.pas.sa.earthlink.net (pop-a065d01.pas.sa.earthlink.net [207.217.121.248]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4E0SXWG000492 for ; Fri, 13 May 2005 17:28:35 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from h-68-164-89-12.snvacaid.dynamic.covad.net ([68.164.89.12] helo=[10.0.1.4]) by pop-a065d01.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DWkVw-0002xd-00; Fri, 13 May 2005 17:28:20 -0700 In-Reply-To: <200505061921.DCL02846@ms8.netsolmail.com> References: <200505061921.DCL02846@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Sjoerd Visscher'" , "'Atom Syntax'" From: Kevin Marks Subject: Re: Autodiscovery Date: Fri, 13 May 2005 17:28:15 -0700 To: bob@wyman.us 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 May 6, 2005, at 12:21 PM, Bob Wyman wrote: > > Sjoerd Visscher wrote: >> [HTML 4.01 says:] This attribute describes the relationship from >> the current document to the anchor specified by the href attribute. >> The value of this attribute is a space-separated list of link types. > But, if you copy HTML from one document to another, or you construct > an HTML document from parts, you risk carrying tags with rel > attributes > from one document to another. If I quote some HTML in a new HTML > document > and the quoted HTML includes rel="alternate" in an tag, are we > really > saying that the presence of rel="alternate" in the quoted text > establishes a > relation of the new HTML document as a whole? > Personally, I think there is a serious scoping problem here. We've > got attributes of separable components of a page establishing metadata > for > the page as a whole. Not good. Bob, you're the one making them seperable. The HTML spec is very document-focused; when you migrate HTML from one document to another, it is your responsibility to do it in a coherent way. Revising rel values is analogous to changing relative links in the href's. After all, the 'next', 'previous' 'contents' etc rel values also need care when migrating, so it's not just 'alternate' or 'friend'. From owner-atom-syntax@mail.imc.org Sat May 14 08:24:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27346 for ; Sat, 14 May 2005 08: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 j4ECFSOl091616; Sat, 14 May 2005 05:15: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 j4ECFSRV091614; Sat, 14 May 2005 05:15:28 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ECFRLQ091572 for ; Sat, 14 May 2005 05:15:27 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.67.192]) by smtp.cegetel.net (Postfix) with ESMTP id A02611A4370 for ; Sat, 14 May 2005 14:14:58 +0200 (CEST) Message-ID: <4285EBD8.3080405@cegetel.net> Date: Sat, 14 May 2005 14:15:20 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: PaceOptionalXhtmlDiv 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 http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv == Abstract == Make the XHTML div container optional. == Status == New == Rationale == Make the XHTML div optional but not enforce it to be part of content. == Proposal == Make the following changes to format-08: === Section 3.1 === Change the {{{atomXHTMLTextConstruct}}} definition to this one: {{{ atomXHTMLTextConstruct = atomCommonAttributes, attribute type { "xhtml" }, (text | anyXHTML)* }}} === Section 3.1.1.3 === {{{ If the value of "type" is "xhtml", the content of the Text construct MUST be XHTML [XHTML] text and markup that could validly appear within an XHTML div element. Atom Processors which display the content MAY use the markup to aid in displaying it. Escaped characters, such as "&" and ">", represent those characters, not markup. If the content of the Text Construct is a single XHTML div element with no attribute (other than namespace declarations), Atom processors SHOULD consider it not being part of the content and discard it. This process SHOULD be recursively repeated on the content of the XHTML div. Hence, Atom producers MAY enclose the content of the Text Construct within such an XHTML div. }}} == Impacts == People willing to produce prefix-free feeds with "dummy" XHTML containers to carry their XHTML namespace decl. can still do so '''and''' have these containers not being considered part of the content (by some processors). Producers are allowed to add such dummy containers as well without being accused of changing the entry content. == Notes == This Pace is '''not''' incompatible with PaceXhtmlDivSuggestedOnly, at least about the inline vs. block content. If PaceXhtmlDivSuggestedOnly's "inline vs. block content" is adopted, this Pace will need updating to allow discarding XHTML "div" and "span" elements. I further suggest allowing to discard any of them independently of the Text Construct type (Inline or Block): a div with no attribute inside an Inline Text Construct SHOULD be discarded, as well as a span with no attribute inside a Block Text Construct. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 14 08:59:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29740 for ; Sat, 14 May 2005 08:59: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 j4ECrbe3006331; Sat, 14 May 2005 05:53: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 j4ECrbJo006330; Sat, 14 May 2005 05:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ECrahR006269 for ; Sat, 14 May 2005 05:53:37 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4ECq92p000280; Sat, 14 May 2005 13:52:23 +0100 (BST) In-Reply-To: <4285EBD8.3080405@cegetel.net> References: <4285EBD8.3080405@cegetel.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54454D78-4196-442D-836F-D2688245185B@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalXhtmlDiv Date: Sat, 14 May 2005 13:52:11 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 Misunderstands what the div is for (ie a very elegant solution to a difficult problem, with a maximum cost of 11 bytes to those that solve the problem in other ways). Graham From owner-atom-syntax@mail.imc.org Sat May 14 10:22:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06323 for ; Sat, 14 May 2005 10:22: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 j4EEEZNr016017; Sat, 14 May 2005 07:14: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 j4EEEZTH016016; Sat, 14 May 2005 07:14:35 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4EEEYKY016008 for ; Sat, 14 May 2005 07:14:34 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.67.192]) by smtp.cegetel.net (Postfix) with ESMTP id 70AFF1A4237; Sat, 14 May 2005 16:14:05 +0200 (CEST) Message-ID: <428607C9.3020407@cegetel.net> Date: Sat, 14 May 2005 16:14:33 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: atom-syntax Subject: Re: PaceOptionalXhtmlDiv References: <4285EBD8.3080405@cegetel.net> <54454D78-4196-442D-836F-D2688245185B@mac.com> In-Reply-To: <54454D78-4196-442D-836F-D2688245185B@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: > Misunderstands what the div is for (ie a very elegant solution I totally disagree with "elegant": it's a hack! > to a > difficult problem, What's difficult? Namespaces? The spec might add advices and/or examples (like in PaceXhtmlDivSuggestedOnly). Namespaces don't seem to me like a "difficult problem", moreover if there are feed validators out there. What else? > with a maximum cost of 11 bytes ...per XHTML Text Construct and XHTML atom:content, but that's not the problem (at least not a great concern for me, but it is for others). > to those that solve > the problem in other ways). I might have not be enough explicit in what I'm suggesting with this Pace: I just want the XHTML div to be optional for people that don't need it but still meeting other people's needs of a "dummy container to carry their XHTML namespace declarations". That way, those two summaries would be equivalent: This is a sample summary.
This is a sample summary.
Would you be >=0 if it where a MUST? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 14 12:46:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16939 for ; Sat, 14 May 2005 12: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 j4EGagbv028531; Sat, 14 May 2005 09:36: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 j4EGagvs028530; Sat, 14 May 2005 09:36:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop-a065d23.pas.sa.earthlink.net (pop-a065d23.pas.sa.earthlink.net [207.217.121.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4EGadUM028521 for ; Sat, 14 May 2005 09:36:42 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from h-68-164-89-12.snvacaid.dynamic.covad.net ([68.164.89.12] helo=[10.0.1.4]) by pop-a065d23.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DWzd1-0002KK-00 for atom-syntax@imc.org; Sat, 14 May 2005 09:36:39 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'Atom Syntax'" From: Kevin Marks Subject: PaceContentAndSummaryDistinct Date: Sat, 14 May 2005 09:36:31 -0700 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 After seeing 'in the wild' what I consider badly-formed Atom feeds, where both the atom:summary and atom:content contain identical abbreviated entry text, I realised that the spec does not make this clear. As this is a key advantage of Atom, I thought it best to make this explicit, hence: http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct I appreciate this is late, but I recall a long discussion of this early on, and I do want to preserve this distinction, as if it can no longer be relied on a key advantage of Atom for feed processors is lost. From owner-atom-syntax@mail.imc.org Sat May 14 12:46:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17017 for ; Sat, 14 May 2005 12: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 j4EGb2ku028556; Sat, 14 May 2005 09:37: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 j4EGb2Ef028555; Sat, 14 May 2005 09:37:02 -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 j4EGb1tc028547 for ; Sat, 14 May 2005 09:37:01 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 58395 messnum 280716 invoked from network[83.70.217.193/unknown]); 14 May 2005 16:36:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail03.svc.cra.dublin.eircom.net (qp 58395) with SMTP; 14 May 2005 16:36:55 -0000 Message-ID: <42862924.2000407@dehora.net> Date: Sat, 14 May 2005 17:36: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: PaceOptionalXhtmlDiv References: <4285EBD8.3080405@cegetel.net> <54454D78-4196-442D-836F-D2688245185B@mac.com> <428607C9.3020407@cegetel.net> In-Reply-To: <428607C9.3020407@cegetel.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 Thomas Broyer wrote: > I might have not be enough explicit in what I'm suggesting with this > Pace: I just want the XHTML div to be optional for people that don't > need it but still meeting other people's needs of a "dummy container to > carry their XHTML namespace declarations". > > That way, those two summaries would be equivalent: > xmlns:atom="...Atom NS..." > xmlns="...XHTML NS..."> > This is a sample summary. > > > >
> This is a sample summary. >
> -1 to PaceOptionalXhtmlDiv. If we are dealing with systems where a div wrapper is deemed neccessary, then you want to take steps to miminise people's options. For example, PaceOptionalXhtmlDiv will help this to occur: This is one busted-ass document - yow!. If you can't trust people not to need the div, then you can't make it optional. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom. [I disagree with Graham btw, and would say xhtml:div is actually fighting kluges with kluges, but it works more or less as specified.] cheers Bill From owner-atom-syntax@mail.imc.org Sat May 14 13:12:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18562 for ; Sat, 14 May 2005 13:12: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 j4EGxDo6030691; Sat, 14 May 2005 09:59: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 j4EGxDXJ030690; Sat, 14 May 2005 09:59:13 -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 j4EGxCMP030680 for ; Sat, 14 May 2005 09:59: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 (sccrmhc14) with SMTP id <200505141659010140035g4de>; Sat, 14 May 2005 16:59:06 +0000 Date: Sat, 14 May 2005 10:59:00 -0600 Subject: Re: PaceContentAndSummaryDistinct 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: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> Message-Id: <77C812A8-C499-11D9-961E-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 Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote: > After seeing 'in the wild' what I consider badly-formed Atom feeds, > where both the atom:summary and atom:content contain identical > abbreviated entry text, I realised that the spec does not make this > clear. > As this is a key advantage of Atom, I thought it best to make this > explicit, hence: > > http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct > > I appreciate this is late, but I recall a long discussion of this > early on, and I do want to preserve this distinction, as if it can no > longer be relied on a key advantage of Atom for feed processors is > lost. > Clarifying this point is a good idea. However, "The content of atom:content MUST be a complete representation of the entry." isn't quite right, because atom:content doesn't contain the metadata found in other children of atom:entry. Here's another idea: The "atom:content" element either contains or links to the full content of the entry. When publishing less than full content, atom:summary MUST be used instead. The content of atom:content is language-sensitive. From owner-atom-syntax@mail.imc.org Sat May 14 14:11:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23437 for ; Sat, 14 May 2005 14: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 j4EHxSDA035211; Sat, 14 May 2005 10:59: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 j4EHxSJi035210; Sat, 14 May 2005 10:59: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 j4EHxOuT035203 for ; Sat, 14 May 2005 10:59:26 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 14 May 2005 17:59:18 -0000 Received: from xdsl-81-173-173-29.netcologne.de (EHLO klangraum) [81.173.173.29] by mail.gmx.net (mp010) with SMTP; 14 May 2005 19:59:18 +0200 X-Authenticated: #163624 Date: Sat, 14 May 2005 20:02:44 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: PaceContentAndSummaryDistinct Message-ID: <20050514180244.GA858@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77C812A8-C499-11D9-961E-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: > On Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote: > >After seeing 'in the wild' what I consider badly-formed Atom feeds, > >where both the atom:summary and atom:content contain identical > >abbreviated entry text, I realised that the spec does not make this > >clear. > > > >http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct +1 * Antone Roundy [2005-05-14 19:10]: > Clarifying this point is a good idea. However, "The content of > atom:content MUST be a complete representation of the entry." > isn't quite right, because atom:content doesn't contain the > metadata found in other children of atom:entry. Agreed also. > The "atom:content" element either contains or links to the full > content of the entry. When publishing less than full content, > atom:summary MUST be used instead. The content of atom:content > is language-sensitive. -1, this wording is not explicit about the intent of atom:content. How about: The "atom:content" element either contains or links to the full content of the entry. An "atom:entry" containing an "atom:content" element MUST be a complete representation of the entry. If the "atom:entry" is not intended to be a complete representation of the entry, you MUST use "atom:summary" instead. The content of "atom:content" is language-sensitive. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sat May 14 14:57:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25759 for ; Sat, 14 May 2005 14:57: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 j4EIkC4b039389; Sat, 14 May 2005 11:46: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 j4EIkCq9039388; Sat, 14 May 2005 11:46:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4EIkBAv039373 for ; Sat, 14 May 2005 11:46:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4EIidW2001758; Sat, 14 May 2005 19:44:45 +0100 (BST) In-Reply-To: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21C1DB2C-2C2D-4661-BAC0-F7E7486C20EC@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceContentAndSummaryDistinct Date: Sat, 14 May 2005 19:44:38 +0100 To: Kevin Marks X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14 May 2005, at 5:36 pm, Kevin Marks wrote: > > After seeing 'in the wild' what I consider badly-formed Atom feeds, > where both the atom:summary and atom:content contain identical > abbreviated entry text, I realised that the spec does not make this > clear. > As this is a key advantage of Atom, I thought it best to make this > explicit, hence: > > http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct I support the sentiment, but the way it's written is awful. We could just change: The "atom:content" element either contains or links to the content of the entry To: The "atom:content" element either contains or links to the full content of the entry (or "complete", or the adjective of your choice) Graham From owner-atom-syntax@mail.imc.org Sun May 15 08:36:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11918 for ; Sun, 15 May 2005 08:36: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 j4FCPfG2036399; Sun, 15 May 2005 05:25: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 j4FCPfnq036398; Sun, 15 May 2005 05:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FCPdGU036359 for ; Sun, 15 May 2005 05:25:40 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4FCPX700558; Sun, 15 May 2005 21:25:33 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id c2ae2338_c53d_11d9_9ee0_0030482532aa_22253; Sun, 15 May 2005 21:35:03 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0065B4; 15 May 05 21:28:19 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 15 May 05 21:27:59 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.4) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0065B2; 15 May 05 21:27:48 +0900 Message-Id: <6.0.0.20.2.20050515212440.0693d630@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 15 May 2005 21:24:55 +0900 To: Antone Roundy , atom-syntax@imc.org From: Martin Duerst Subject: Re: PaceContentAndSummaryDistinct In-Reply-To: <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> 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 here, in whatever wording turns out to be best. Regards, Martin. At 01:59 05/05/15, Antone Roundy wrote: > >On Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote: >> After seeing 'in the wild' what I consider badly-formed Atom feeds, where both the atom:summary and atom:content contain identical abbreviated entry text, I realised that the spec does not make this clear. >> As this is a key advantage of Atom, I thought it best to make this explicit, hence: >> >> http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct >> >> I appreciate this is late, but I recall a long discussion of this early on, and I do want to preserve this distinction, as if it can no longer be relied on a key advantage of Atom for feed processors is lost. >> >Clarifying this point is a good idea. However, "The content of atom:content MUST be a complete representation of the entry." isn't quite right, because atom:content doesn't contain the metadata found in other children of atom:entry. Here's another idea: > >The "atom:content" element either contains or links to the full content of the entry. When publishing less than full content, atom:summary MUST be used instead. The content of atom:content is language-sensitive. > From owner-atom-syntax@mail.imc.org Sun May 15 11:08:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28023 for ; Sun, 15 May 2005 11:08: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 j4FEvqvS060295; Sun, 15 May 2005 07:57: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 j4FEvqYc060294; Sun, 15 May 2005 07:57:52 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FEvnou060284 for ; Sun, 15 May 2005 07:57:49 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.60.185]) by smtp.cegetel.net (Postfix) with ESMTP id 56AD53180DA; Sun, 15 May 2005 16:57:43 +0200 (CEST) Message-ID: <42876369.4070004@cegetel.net> Date: Sun, 15 May 2005 16:57:45 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: "A. Pagaltzis" Cc: atom-syntax@imc.org Subject: Re: PaceContentAndSummaryDistinct References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> In-Reply-To: <20050514180244.GA858@klangraum> 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 A. Pagaltzis wrote: > The "atom:content" element either contains or links to the > full content of the entry. An "atom:entry" containing an > "atom:content" element MUST be a complete representation of > the entry. If the "atom:entry" is not intended to be a > complete representation of the entry, you MUST use > "atom:summary" instead. The content of "atom:content" is > language-sensitive. > > +1 ...but isn't the "MUST use atom:summary" leading to misinterpretation as of title-only feeds? In that it might be understood as "you MUST use one of atom:content or atom:summary" -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun May 15 13:31:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12451 for ; Sun, 15 May 2005 13:31: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 j4FHNeKN068598; Sun, 15 May 2005 10: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 j4FHNeRa068597; Sun, 15 May 2005 10:23:40 -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 j4FHNcpS068591 for ; Sun, 15 May 2005 10:23:39 -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 j4FHNcjO017078 for ; Sun, 15 May 2005 11:23:38 -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 <0IGJ001GLKBENY@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 15 May 2005 11:23:38 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGJ009D2KBD8J@mail.sun.net> for atom-syntax@imc.org; Sun, 15 May 2005 11:23:38 -0600 (MDT) Date: Sun, 15 May 2005 10:24:53 -0700 From: Tim Bray Subject: Re: PaceContentAndSummaryDistinct In-reply-to: <20050514180244.GA858@klangraum> To: "A. Pagaltzis" Cc: atom-syntax@imc.org Message-id: <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 14, 2005, at 11:02 AM, A. Pagaltzis wrote: > The "atom:content" element either contains or links to the > full content of the entry. An "atom:entry" containing an > "atom:content" element MUST be a complete representation of > the entry. -1 What does "complete" mean? This is untestable and semantically fuzzy. I think anything stronger than "is intended to contain the full content" is just not workable. -Tim From owner-atom-syntax@mail.imc.org Sun May 15 17:20:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12475 for ; Sun, 15 May 2005 17: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 j4FLCwqj083887; Sun, 15 May 2005 14:12: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 j4FLCwMJ083886; Sun, 15 May 2005 14:12: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4FLCuJB083880 for ; Sun, 15 May 2005 14:12:57 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 May 2005 21:12:50 -0000 Received: from xdsl-81-173-229-1.netcologne.de (EHLO klangraum) [81.173.229.1] by mail.gmx.net (mp021) with SMTP; 15 May 2005 23:12:50 +0200 X-Authenticated: #163624 Date: Sun, 15 May 2005 23:16:17 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: PaceContentAndSummaryDistinct Message-ID: <20050515211617.GA12134@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <42876369.4070004@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: Content-Transfer-Encoding: 8bit * Thomas Broyer [2005-05-15 17:10]: > A. Pagaltzis wrote: > > > The "atom:content" element either contains or links to the > > full content of the entry. An "atom:entry" containing an > > "atom:content" element MUST be a complete representation of > > the entry. If the "atom:entry" is not intended to be a > > complete representation of the entry, you MUST use > > "atom:summary" instead. The content of "atom:content" is > > language-sensitive. > > > > > +1 > > ...but isn't the "MUST use atom:summary" leading to > misinterpretation as of title-only feeds? In that it might be > understood as "you MUST use one of atom:content or > atom:summary" Yes, you’re right. I’m not sure what the best way to address that would be; maybe a qualification like “If the "atom:entry" is not intended to be a complete representation of the entry, you MUST instead use "atom:summary" to carry content.” But that is clusmy, I don’t like it. * Tim Bray [2005-05-15 19:35]: > -1 > > What does "complete" mean? This is untestable and semantically > fuzzy. I think anything stronger than "is intended to contain > the full content" is just not workable. In terms of formal verifiability of feed conformance, you are right. In fact, in those terms, there is no way we can clarify the difference between the two elements, at all. Do you suggest that this be left to the implementor’s guide? Personally, I think the spec should try to make an attempt to nail this down. Maybe the right approach would rather be something along these lines? An "atom:entry" MUST NOT have both an "atom:content" and an "atom:summary" element with identical content. That is a formally verifiable criterion, at least. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 15 18:21:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19866 for ; Sun, 15 May 2005 18:21: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 j4FMCOTs088127; Sun, 15 May 2005 15:12: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 j4FMCOgp088126; Sun, 15 May 2005 15:12:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMCM2W088103 for ; Sun, 15 May 2005 15:12:23 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050515221212.IION23015.mta05-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com> for ; Sun, 15 May 2005 23:12:12 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050515221212.FRVF1279.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Sun, 15 May 2005 23:12:12 +0100 Date: Sun, 15 May 2005 23:12:12 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <12336714.20050515231212@djpowell.net> To: Atom Syntax Subject: PaceAllowDuplicateIdsWithModified 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 PaceAllowDuplicateIDs received some opposition because of its use of atom:updated to differentiate multiple revisions of an entry [1][2][3]. I've posted a couple of Paces - basically a single a proposal, split into two bite-size pieces: Apologies in advance. I know what happened last time we discussed dates, and this is hardly the best timing, but it seemed like an obvious fix for the problem. [1] http://www.imc.org/atom-syntax/mail-archive/msg14738.html [2] http://www.imc.org/atom-syntax/mail-archive/msg14750.html [3] http://www.imc.org/atom-syntax/mail-archive/msg15144.html -- Dave From owner-atom-syntax@mail.imc.org Sun May 15 18:26:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20513 for ; Sun, 15 May 2005 18:26: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 j4FMI4g8088323; Sun, 15 May 2005 15:18: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 j4FMI4L9088322; Sun, 15 May 2005 15:18:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMI3Uk088316 for ; Sun, 15 May 2005 15:18:03 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050515221757.RQTH12530.mta13-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Sun, 15 May 2005 23:17:57 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050515221757.OMVA1844.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 15 May 2005 23:17:57 +0100 Date: Sun, 15 May 2005 23:17:57 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1984450414.20050515231757@djpowell.net> To: Thomas Broyer CC: Atom Syntax Subject: Re: PaceAllowDuplicateIDs In-Reply-To: <428395C7.10007@cegetel.net> References: <73eb986f1cca36c77bfae6708e448e52@sun.com> <1139593020.20050512004045@djpowell.net> <428395C7.10007@cegetel.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 Thomas Broyer wrote: > David Powell wrote: >> I'm in favour of allowing duplicate ids. This only seems to be a >> partial solution though: >> >> "Their atom:updated timestamps SHOULD be different" >> >> But what if they are not? What if I want to represent an archive of a >> feed - maybe mine, maybe someone else's - but the atom:updated dates >> are the same in two or more entries? I thought it was up to the >> publisher to decide whether to rev atom:updated. > If you don't update atom:updated (e.g. it's not a "significant" update, > fixing typos, etc.), one could (I would) assume you don't want to > archive the previous entry "state". Archiving was just an example, but the Publisher and the Archiver are different entities. It is up to the Publisher to decide what they consider to be a "significant" update, and it is up to the Archiver to decide what they want to archive. > There are very few chances that you "significantly" update an entry with > the same second I agree, but this proposal distorts the intended meaning of atom:updated, and I think that this risks atom:updated becoming an unreliable indicator for the newness of entries, which is a shame, because it is a useful feature. -- Dave From owner-atom-syntax@mail.imc.org Sun May 15 18:26:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20588 for ; Sun, 15 May 2005 18:26: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 j4FMJDXc088342; Sun, 15 May 2005 15:19: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 j4FMJD5D088341; Sun, 15 May 2005 15:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMJBiE088334 for ; Sun, 15 May 2005 15:19:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4FMIDgH007832 for ; Sun, 15 May 2005 23:18:19 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <36E1EE06-0BEA-4F99-9965-705861129FE5@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: Editorial: "Language-sensitive" Date: Sun, 15 May 2005 23:18:13 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Can we put capital letters on language-sensitive (ie "Language Sensitive") the way we do Text Construct, to make it clear it refers to a specific thing and is not a generic term that is meant to be understood on its own? If not, the term is missing its hyphen in section 4.2.9.5, which needs fixing. Graham From owner-atom-syntax@mail.imc.org Sun May 15 18:30:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20864 for ; Sun, 15 May 2005 18:30: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 j4FMOCtX088862; Sun, 15 May 2005 15:24: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 j4FMOChl088861; Sun, 15 May 2005 15:24:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMOBhe088853 for ; Sun, 15 May 2005 15:24:11 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4FMN6Vu008588 for ; Sun, 15 May 2005 23:23:06 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: PaceContentAndSummaryDistinct2 posted Date: Sun, 15 May 2005 23:23:03 +0100 X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct2 == Abstract == Codify the intended use of content and summary clearly, but more subtly than the original PaceContentAndSummaryDistinct. == Status == Newly posted == Rationale == PaceContentAndSummaryDistinct correctly point out the current definitions are too vague: The "atom:summary" element is a Text construct that conveys a short summary, abstract or excerpt of an entry. The "atom:content" element either contains or links to the content of the entry. The aim of this proposal is to use similar language in both definitions so they can be more easily compared, especially re: the best location of truncated content. == Proposal == In 4.2.13, replace: The "atom:summary" element is a Text construct that conveys a short summary, abstract or excerpt of an entry. with: The "atom:summary" element is a Text construct that conveys a short summary, abstract or excerpt (such as truncated content) of an entry. In 4.1.3 replace: The "atom:content" element either contains or links to the content of the entry with: The "atom:content" element either contains or links to the full content of the entry == Impacts == Alternate to PaceContentAndSummaryDistinct == Notes == The new wording of 4.2.13 is a bit awkward, but since truncated content is by far the most common form of excerpt, its probably worth mentioning specifically. From owner-atom-syntax@mail.imc.org Sun May 15 18:44:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22452 for ; Sun, 15 May 2005 18:44: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 j4FMbmVD089439; Sun, 15 May 2005 15:37: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 j4FMbmi8089438; Sun, 15 May 2005 15:37:48 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMblBD089432 for ; Sun, 15 May 2005 15:37:47 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.60.185]) by smtp.cegetel.net (Postfix) with ESMTP id 01A903180A5; Mon, 16 May 2005 00:37:41 +0200 (CEST) Message-ID: <4287CF4F.9050105@cegetel.net> Date: Mon, 16 May 2005 00:38:07 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: "A. Pagaltzis" Cc: atom-syntax@imc.org Subject: Re: PaceContentAndSummaryDistinct References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> In-Reply-To: <20050515211617.GA12134@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: >Personally, I think the spec should try to make an attempt to >nail this down. Maybe the right approach would rather be >something along these lines? > > An "atom:entry" MUST NOT have both an "atom:content" and an > "atom:summary" element with identical content. > > > You're right, +1 to this -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun May 15 18:56:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23770 for ; Sun, 15 May 2005 18:56: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 j4FMZIWJ089344; Sun, 15 May 2005 15:35: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 j4FMZIiY089343; Sun, 15 May 2005 15:35:18 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FMZGYC089332 for ; Sun, 15 May 2005 15:35:17 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.60.185]) by smtp.cegetel.net (Postfix) with ESMTP id DD044318094; Mon, 16 May 2005 00:35:10 +0200 (CEST) Message-ID: <4287CEB4.8030701@cegetel.net> Date: Mon, 16 May 2005 00:35:32 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: atom-syntax Subject: Re: PaceOptionalXhtmlDiv References: <4285EBD8.3080405@cegetel.net> <54454D78-4196-442D-836F-D2688245185B@mac.com> <428607C9.3020407@cegetel.net> <42862924.2000407@dehora.net> In-Reply-To: <42862924.2000407@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > > Thomas Broyer wrote: > >> I might have not be enough explicit in what I'm suggesting with this >> Pace: I just want the XHTML div to be optional for people that don't >> need it but still meeting other people's needs of a "dummy container >> to carry their XHTML namespace declarations". >> >> That way, those two summaries would be equivalent: >> > xmlns:atom="...Atom NS..." >> xmlns="...XHTML NS..."> >> This is a sample summary. >> >> >> >>
>> This is a sample summary. >>
>> > > > -1 to PaceOptionalXhtmlDiv. > > If we are dealing with systems where a div wrapper is deemed > neccessary, then you want to take steps to miminise people's options. Do you have examples? div wrappers are necessary only when producers don't want to use prefixes. I propose an elegant solution where meaningless wrappers (div without any attribute, other than namespace declarations) may/should/must be discarded. Atom processors will always have to deal with namespaces (because I can still use prefixes for my Atom and/or XHTML elements, even with the format-08 spec) and actually there is no difference at all between taking the mixed content inside the XHTML div and taking the mixed content inside the atom:content. So the only difference is on the producers side, and people who don't know anything about their XHTML content (and consider it a black box) apart from it to be well-formed and use no prefix, those people can still use a dummy div wrapper acting just like a "namespace declaration carrier". I don't see the point. > > For example, PaceOptionalXhtmlDiv will help this to occur: > > xmlns:atom="...Atom NS..." > xmlns="...XHTML NS..."> > This is one busted-ass document - yow!. > Not more than format-08 won't help this not to occur:
This is one busted-ass document - yow!.
What will help people who don't know much about XML and namespaces are examples and pieces of advice in the spec. And, actually, people who don't know much about XML and namespace will probably not read the spec but articles published on mass-market web sites... > If you can't trust people not to need the div, then you can't make it > optional. A div (or span) with no attribute has no meaning at all apart from grouping content, which is already done by the atom:content; so it can be discarded without side effects. > I unfortunately have a good amount of experience dealing with this > kind of thing outside Atompub. The simplest answer is to stop the > 'envelope' from using a default namespace (don't bother to debate this > with me, it's not an imo). We're not doing that with Atom. Failing > that, the next thing consideration is to add/enforce a protective > scoping barrier between the envelope and the content. We are doing > that with Atom. The first solution is not on the protocol side but on the "producers" side: they are responsible of making a well-formed and "valid" document, just like they make well-formed and "valid" MS Word, CSV, etc. documents, SQL queries, etc. The second one is on the protocol side. I don't think such a think have to go on the protocol spec. If hacks have to exists to allow prefix-free Atom documents, people wanting them will have to find (it's already done) and use them, without bothering other people with that. There will be conforming Atom processors, Atom validators, etc. Such a namespace error will show as soon as the Atom document will be read/processed by one of them, that is as soon as it will be used. I don't expect much people continue producing such documents if they're not usable... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun May 15 19:13:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25918 for ; Sun, 15 May 2005 19: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 j4FN4FMQ090795; Sun, 15 May 2005 16:04: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 j4FN4FNU090794; Sun, 15 May 2005 16:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FN4EYY090783 for ; Sun, 15 May 2005 16:04:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4FN3F52014279; Mon, 16 May 2005 00:03:16 +0100 (BST) In-Reply-To: <20050515211617.GA12134@klangraum> References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceContentAndSummaryDistinct Date: Mon, 16 May 2005 00:03:05 +0100 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15 May 2005, at 10:16 pm, A. Pagaltzis wrote: > An "atom:entry" MUST NOT have both an "atom:content" and an > "atom:summary" element with identical content. -1 It might solve this exact problem, but in the general case it makes no sense. Let's say I put the first sentence of each post in atom:summary. What happens when I post a one sentence entry? Graham From owner-atom-syntax@mail.imc.org Sun May 15 19:13:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26008 for ; Sun, 15 May 2005 19:13: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 j4FN65fK090890; Sun, 15 May 2005 16:06: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 j4FN64WJ090889; Sun, 15 May 2005 16:06:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FN63BM090866 for ; Sun, 15 May 2005 16:06:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4FN4uVS014496; Mon, 16 May 2005 00:04:56 +0100 (BST) In-Reply-To: <12336714.20050515231212@djpowell.net> References: <12336714.20050515231212@djpowell.net> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 00:04:53 +0100 To: David Powell X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 15 May 2005, at 11:12 pm, David Powell wrote: > > +1 But mostly symbolically, because I don't think the atom:modified will fly, and I don't like it much. But it's still better and more complete than the original duplicate ids pace. Graham From owner-atom-syntax@mail.imc.org Sun May 15 19:20:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26759 for ; Sun, 15 May 2005 19:20: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 j4FND1Bv091248; Sun, 15 May 2005 16:13: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 j4FND1n8091247; Sun, 15 May 2005 16:13:01 -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 j4FNCxb9091241 for ; Sun, 15 May 2005 16:13:00 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 May 2005 23:12:53 -0000 Received: from xdsl-81-173-229-1.netcologne.de (EHLO klangraum) [81.173.229.1] by mail.gmx.net (mp030) with SMTP; 16 May 2005 01:12:53 +0200 X-Authenticated: #163624 Date: Mon, 16 May 2005 01:16:21 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceContentAndSummaryDistinct Message-ID: <20050515231621.GB13522@klangraum> Mail-Followup-To: atom-syntax References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.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: 8bit * Graham [2005-05-16 01:10]: > Let's say I put the first sentence of each post in > atom:summary. What happens when I post a one sentence entry? Then you must not put it in the summary. And this is my opinion independent of the pace. An even half-way intelligent user agent would do something like display a “read more” link or button when it displays a summary, to alert the user that there is more to be read, either at the atom:link[@rel='alternate'] location or in a supplied atom:content. Would that be applicable to your one-sentence entry? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 15 20:16:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02177 for ; Sun, 15 May 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 j4G07NAn094536; Sun, 15 May 2005 17:07: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 j4G07NrK094535; Sun, 15 May 2005 17:07:23 -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 j4G07NBb094529 for ; Sun, 15 May 2005 17:07: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 j4G07MjO012936 for ; Sun, 15 May 2005 18:07:22 -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 <0IGK00M8W309H2@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 15 May 2005 18:07:22 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGK00HWY309JS@mail.sun.net> for atom-syntax@imc.org; Sun, 15 May 2005 18:07:21 -0600 (MDT) Date: Sun, 15 May 2005 17:08:38 -0700 From: Tim Bray Subject: Re: Editorial: "Language-sensitive" In-reply-to: <36E1EE06-0BEA-4F99-9965-705861129FE5@mac.com> To: Graham Cc: atom-syntax Message-id: <698cacea2bf8888794dea0e3d189e7a7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <36E1EE06-0BEA-4F99-9965-705861129FE5@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 15, 2005, at 3:18 PM, Graham wrote: > > Can we put capital letters on language-sensitive (ie "Language > Sensitive") the way we do Text Construct, to make it clear it refers > to a specific thing and is not a generic term that is meant to be > understood on its own? +1, good idea. -Tim From owner-atom-syntax@mail.imc.org Sun May 15 21:43:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11441 for ; Sun, 15 May 2005 21:43: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 j4G1Nb3M099495; Sun, 15 May 2005 18: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 j4G1Nbuv099494; Sun, 15 May 2005 18:23:37 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G1NQiZ099486 for ; Sun, 15 May 2005 18:23:34 -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, 16 May 2005 11:19:37 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 May 2005 11:19:30 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <12336714.20050515231212@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 16/5/05 8:12 AM, "David Powell" wrote: > PaceAllowDuplicateIDs received some opposition because of its use of > atom:updated to differentiate multiple revisions of an entry [1][2][3]. > > I've posted a couple of Paces - basically a single a proposal, split > into two bite-size pieces: > > > +1 There was opposition to atom:modified because we couldn't see a need for it. Now we have a need for it. e. From owner-atom-syntax@mail.imc.org Sun May 15 22:32:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02608 for ; Sun, 15 May 2005 22:32: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 j4G2O1rG003782; Sun, 15 May 2005 19:24: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 j4G2O1V8003781; Sun, 15 May 2005 19:24: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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G2NwMb003772 for ; Sun, 15 May 2005 19:24:00 -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, 16 May 2005 11:21:06 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 May 2005 11:20:58 +1000 Subject: Re: PaceContentAndSummaryDistinct From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050515211617.GA12134@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 16/5/05 7:16 AM, "A. Pagaltzis" wrote: > An "atom:entry" MUST NOT have both an "atom:content" and an > "atom:summary" element with identical content. +1 From owner-atom-syntax@mail.imc.org Sun May 15 22:57:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20457 for ; Sun, 15 May 2005 22:57: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 j4G2oipr005739; Sun, 15 May 2005 19: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 j4G2oiM9005738; Sun, 15 May 2005 19:50:44 -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 j4G2ohph005725; Sun, 15 May 2005 19:50:43 -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 j4G2ogjO029514; Sun, 15 May 2005 20:50:42 -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 <0IGK00M56AKIH2@edgemail1.Central.Sun.COM>; Sun, 15 May 2005 20:50:42 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGK00AFVAKHTI@mail.sun.net>; Sun, 15 May 2005 20:50:42 -0600 (MDT) Date: Sun, 15 May 2005 19:51:55 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <68fba5c50505102114188a3b38@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Atom Syntax Message-id: <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 10, 2005, at 9:14 PM, Robert Sayre wrote: > > ... > > ... > > > Legal? Which part of the spec rules it out? No part. Per http://www.atompub.org/2005/04/18/draft-ietf-atompub-format -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules for how to handle it, right? -Tim From owner-atom-syntax@mail.imc.org Sun May 15 23:08:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21894 for ; Sun, 15 May 2005 23:08: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 j4G2xNCc006384; Sun, 15 May 2005 19:59: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 j4G2xN7e006383; Sun, 15 May 2005 19:59: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4G2xLEI006357 for ; Sun, 15 May 2005 19:59:22 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 May 2005 02:59:14 -0000 Received: from xdsl-213-196-240-222.netcologne.de (EHLO klangraum) [213.196.240.222] by mail.gmx.net (mp002) with SMTP; 16 May 2005 04:59:14 +0200 X-Authenticated: #163624 Date: Mon, 16 May 2005 05:02:42 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceContentAndSummaryDistinct Message-ID: <20050516030242.GA15343@klangraum> Mail-Followup-To: atom-syntax References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.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: 8bit * Graham [2005-05-16 01:15]: > > An "atom:entry" MUST NOT have both an "atom:content" and an > > "atom:summary" element with identical content. > > -1 > > It might solve this exact problem, but in the general case it > makes no sense. Besides my point in the other mail, I wanted to further address this. It does make sense in the general case, in my opinion. A feed producer is expected to pick the element that reflects the payload’s nature; this requirement would prevent them from just sticking the same payload in both elements and letting the aggregator sort it out. On a more abstract level, it says “atom:summary and atom:content are not the same thing” in formally verifiable terms. It does not express the exact role of each element, but that is unenforcable anyway. OTOH, it forces feed producers to pick one element or the other when they only have one piece payload; and it can reasonably be assumed that they’ll pick as intended. So it seems to me that it is as close as the spec can get to enforcing correct usage of the elements. I’m not wedded to the proposal, but after thinking about it for a while, I believe it actually makes more sense than it seems to at first blush. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 15 23:51:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25609 for ; Sun, 15 May 2005 23:51: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 j4G3fKTU008694; Sun, 15 May 2005 20:41: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 j4G3fKu8008693; Sun, 15 May 2005 20:41:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G3fJDl008687 for ; Sun, 15 May 2005 20:41:20 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from web2.messagingengine.com (web2.internal [10.202.2.211]) by frontend1.messagingengine.com (Postfix) with ESMTP id 07D63C8F271; Sun, 15 May 2005 23:41:18 -0400 (EDT) Received: by web2.messagingengine.com (Postfix, from userid 99) id B20192E97; Sun, 15 May 2005 23:41:06 -0400 (EDT) Message-Id: <1116214866.26863.234192462@webmail.messagingengine.com> X-Sasl-Enc: K8neDmNREoMYBtUHYHW/bSdETM51RUljNC8F6NDgxjt8 1116214866 From: "James Tauber" To: "A. Pagaltzis" , "atom-syntax" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.com> <20050515231621.GB13522@klangraum> Subject: Re: PaceContentAndSummaryDistinct In-Reply-To: <20050515231621.GB13522@klangraum> Date: Mon, 16 May 2005 11:41:06 +0800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 16 May 2005 01:16:21 +0200, "A. Pagaltzis" said: > An even half-way intelligent user agent would do something like > display a "read more" link or button when it displays a summary, > to alert the user that there is more to be read, either at the > atom:link[@rel='alternate'] location or in a supplied > atom:content. I think this is the key criterion albeit not a particularly formal one. Which got me thinking: say I provide both a summary-only feed and a full-content feed. I believe it is reasonable to: 1. include a summary element in my full-content feed in addition to the content element; and 2. have some (short) entries in my summary-only feed which contain a content element but no summary. In other words: 1. "full-content feed" doesn't preclude the existence of a summary element but there will never be a summary element without a content element. 2. "summary-only feed" really means that the included summary/content won't exceed some arbitrary length. If the content is short enough to fit this, I'll use a content element, even though this is a "summary-only" feed because the content is complete---there is no "read more". James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Mon May 16 00:02:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26272 for ; Mon, 16 May 2005 00:02: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 j4G3ua1U009612; Sun, 15 May 2005 20:56: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 j4G3ua9l009611; Sun, 15 May 2005 20:56: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 (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4G3uYTt009588 for ; Sun, 15 May 2005 20:56:35 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 May 2005 03:56:29 -0000 Received: from xdsl-213-196-240-222.netcologne.de (EHLO klangraum) [213.196.240.222] by mail.gmx.net (mp032) with SMTP; 16 May 2005 05:56:29 +0200 X-Authenticated: #163624 Date: Mon, 16 May 2005 05:59:56 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceContentAndSummaryDistinct Message-ID: <20050516035956.GA15580@klangraum> Mail-Followup-To: atom-syntax References: <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <42876369.4070004@cegetel.net> <20050515211617.GA12134@klangraum> <88FB1C2D-4C5E-4F0A-87C8-C42D9B70CDDE@mac.com> <20050515231621.GB13522@klangraum> <1116214866.26863.234192462@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1116214866.26863.234192462@webmail.messagingengine.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: 8bit * James Tauber [2005-05-16 05:45]: > I believe it is reasonable to: > > 1. include a summary element in my full-content feed in > addition to the content element; and Absolutely it is. F.ex, user agents could provide the summary in addition to the title of an entry in a feed overview pane, and display either the atom:content or whatever is located at the atom:link[@rel='alternate'] URL when you click an entry. Compare NetNewsWire’s widescreen view. > [...] In other words: [...] > > 2. "summary-only feed" really means that the included > summary/content won't exceed some arbitrary length. If the > content is short enough to fit this, I'll use a content > element, even though this is a "summary-only" feed because the > content is complete---there is no "read more". Indeed. These are all reasons that convince me that within possibility the spec really should try to enforce the distinction: it is an extraordinarily valuable feature of the format for consumers if applied consistently. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 16 00:52:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00837 for ; Mon, 16 May 2005 00:52: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 j4G4i34P011636; Sun, 15 May 2005 21:44: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 j4G4i3pt011635; Sun, 15 May 2005 21:44: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G4i27A011621 for ; Sun, 15 May 2005 21:44:02 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3198471wra for ; Sun, 15 May 2005 21:43:56 -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=X97WS8pRsaVtjCqt6/i/hfOuQD3lymXMq2NBQxwN9StPoDdhsml2sJ0LMf12eZy2lR86tgcrpekj36VQr1oOkeyqRyHqf47EmCKLUkW1JyOGzWrkh1yCJsW/UY1HkzzCs84XubheMizK6fZKSQZ6iu8ZnqWbyLMI1CaoqYADimk= Received: by 10.54.67.8 with SMTP id p8mr2312116wra; Sun, 15 May 2005 21:43:56 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 15 May 2005 21:43:56 -0700 (PDT) Message-ID: <68fba5c5050515214373a4f9cf@mail.gmail.com> Date: Mon, 16 May 2005 00:43:56 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Paul Hoffman , Atom Syntax In-Reply-To: <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4G4i37A011622 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/15/05, Tim Bray wrote: > On May 10, 2005, at 9:14 PM, Robert Sayre wrote: > > > > > ... > > > > ... > > > > > > Legal? Which part of the spec rules it out? > > No part. Per > http://www.atompub.org/2005/04/18/draft-ietf-atompub-format > -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules > for how to handle it, right? Yes, there are clear parsing rules. What's the benefit of allowing such markup? Robert Sayre P.S. -- I've created an atom:drm element. It resides in the W3C namespace and is RFCxxxx compliant. Its contents are subject to the provisions of the DMCA. For a small fee, you can read its specification. From owner-atom-syntax@mail.imc.org Mon May 16 01:19:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02810 for ; Mon, 16 May 2005 01:19: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 j4G5AFnD015881; Sun, 15 May 2005 22:10: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 j4G5AFg6015880; Sun, 15 May 2005 22:10: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 j4G5AEv5015863; Sun, 15 May 2005 22:10: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 j4G5AEjO005587; Sun, 15 May 2005 23:10:14 -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 <0IGK0002FH11C2@edgemail1.Central.Sun.COM>; Sun, 15 May 2005 23:10:14 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGK000UUH0X8A@mail.sun.net>; Sun, 15 May 2005 23:10:10 -0600 (MDT) Date: Sun, 15 May 2005 22:11:27 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <68fba5c5050515214373a4f9cf@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 15, 2005, at 9:43 PM, Robert Sayre wrote: >>> >>> Legal? Which part of the spec rules it out? >> >> No part. Per >> http://www.atompub.org/2005/04/18/draft-ietf-atompub-format >> -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules >> for how to handle it, right? > > Yes, there are clear parsing rules. What's the benefit of allowing > such markup? The benefit the Web derived from HTML's implicit-but-universally-implemented MustIgnore rule; it introduced enough slack into the system that people could experiment without breaking things. Related resource: http://www.webratio.com/images/20050408Bosworth.pps More generally: ruling things out should be avoided unless (a) you're really sure they're harmful and (b) you think you can actually successfully enforce it. -Tim From owner-atom-syntax@mail.imc.org Mon May 16 06:07:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19195 for ; Mon, 16 May 2005 06:07: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 j4G9spgJ022302; Mon, 16 May 2005 02:54: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 j4G9sp8F022301; Mon, 16 May 2005 02:54:51 -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 j4G9spZT022290 for ; Mon, 16 May 2005 02:54:51 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 33089 invoked by uid 17064); 16 May 2005 09:54:50 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.8.237]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 16 May 2005 09:54:50 -0000 In-Reply-To: <12336714.20050515231212@djpowell.net> References: <12336714.20050515231212@djpowell.net> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) 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: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 11:54:50 +0200 To: David Powell X-Mailer: Apple Mail (2.728) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Should one not then to make atom:update a MAY? We don't really need 2 MUST dates. Henry On 16 May 2005, at 00:12, David Powell wrote: > PaceAllowDuplicateIDs received some opposition because of its use of > atom:updated to differentiate multiple revisions of an entry [1][2] > [3]. > > I've posted a couple of Paces - basically a single a proposal, split > into two bite-size pieces: > > > > > > Apologies in advance. I know what happened last time we discussed > dates, and this is hardly the best timing, but it seemed like an > obvious fix for the problem. > > > [1] http://www.imc.org/atom-syntax/mail-archive/msg14738.html > [2] http://www.imc.org/atom-syntax/mail-archive/msg14750.html > [3] http://www.imc.org/atom-syntax/mail-archive/msg15144.html > > -- > Dave > From owner-atom-syntax@mail.imc.org Mon May 16 06:24:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20727 for ; Mon, 16 May 2005 06:24: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 j4GABdif028528; Mon, 16 May 2005 03: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 j4GABdpA028527; Mon, 16 May 2005 03:11:39 -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 j4GABcEB028517 for ; Mon, 16 May 2005 03:11:38 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4GACt6a000878 for ; Mon, 16 May 2005 06:13:01 -0400 Message-ID: <428871D4.1020504@intertwingly.net> Date: Mon, 16 May 2005 06:11:32 -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: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.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 Tim Bray wrote: > > On May 15, 2005, at 9:43 PM, Robert Sayre wrote: > >>>> >>>> Legal? Which part of the spec rules it out? >>> >>> No part. Per >>> http://www.atompub.org/2005/04/18/draft-ietf-atompub-format >>> -08.html#rfc.section.6.2 it's unknown foreign markup, with clear rules >>> for how to handle it, right? >> >> Yes, there are clear parsing rules. What's the benefit of allowing >> such markup? > > The benefit the Web derived from HTML's > implicit-but-universally-implemented MustIgnore rule; it introduced > enough slack into the system that people could experiment without > breaking things. > > Related resource: http://www.webratio.com/images/20050408Bosworth.pps > > More generally: ruling things out should be avoided unless (a) you're > really sure they're harmful and (b) you think you can actually > successfully enforce it. -Tim A concrete example of the implications of such a rule: http://diveintomark.org/archives/2003/04/13/object_and_internet_explorer ... in particular, follow this link: http://www.robinlionheart.com/stds/html4/objects.html The only way that authors of future revisions of the specification can be confident that they are adding things that don't break anything is if either (1) some names (e.g., the atom namespace) are reserved for such things, or (2) all future additions go into new namespaces. I do believe that schemas and/or the feedvalidator can enforce such a rule. And I don't believe that a requirement that people who wish to extend Atom do so in their own namespace is overly burdensome. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 16 06:42:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22958 for ; Mon, 16 May 2005 06:41: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 j4GAX5A3036019; Mon, 16 May 2005 03:33: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 j4GAX5MX036018; Mon, 16 May 2005 03:33:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GAX4LW035979 for ; Mon, 16 May 2005 03:33:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GAV2Ir007638; Mon, 16 May 2005 11:31:08 +0100 (BST) In-Reply-To: <12336714.20050515231212@djpowell.net> References: <12336714.20050515231212@djpowell.net> Mime-Version: 1.0 (Apple Message framework v728) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07BEEFD6-3E0B-425E-A943-74EF180BA573@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 11:31:04 +0100 To: David Powell X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd like to propose an alternative to atom:modified? I've mentioned this a couple of times before over the last two years, but anyway: The only properties of atom:modified we're interested in are: 1) That different versions have different dates 2) Sorting chronologically puts the versions in the correct order This is to say, the absolute value of the date is irrelevant. The only thing that matters is whether it is before, after or the same as other dates that have appeared on a particular entry. Proposal: atom:version atom:version is a Date Construct that determines the chronology of instances of atom:entry. Each time an atom:entry is modified, atom:version MUST be given a chronologically later value than other values than have appeared in any atom:entry with the same value for atom:id. The value does not need to correspond to any particular event in an entries life-cycle. Suitable values include date of last modification, or the date the atom:entry is generated by an Atom producer. Is this plausible? Graham From owner-atom-syntax@mail.imc.org Mon May 16 07:20:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27040 for ; Mon, 16 May 2005 07:20: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 j4GB7PJa048776; Mon, 16 May 2005 04:07: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 j4GB7PND048775; Mon, 16 May 2005 04:07:25 -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 j4GB7OiO048764 for ; Mon, 16 May 2005 04:07:24 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4GB8lfO006849; Mon, 16 May 2005 07:08:47 -0400 Message-ID: <42887EEB.9040202@intertwingly.net> Date: Mon, 16 May 2005 07:07:23 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: PaceAllowDuplicateIdsWithModified References: <12336714.20050515231212@djpowell.net> <07BEEFD6-3E0B-425E-A943-74EF180BA573@mac.com> In-Reply-To: <07BEEFD6-3E0B-425E-A943-74EF180BA573@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: > > I'd like to propose an alternative to atom:modified? I've mentioned > this a couple of times before over the last two years, but anyway: > > The only properties of atom:modified we're interested in are: > 1) That different versions have different dates > 2) Sorting chronologically puts the versions in the correct order > > This is to say, the absolute value of the date is irrelevant. The only > thing that matters is whether it is before, after or the same as other > dates that have appeared on a particular entry. > > Proposal: > > atom:version > > atom:version is a Date Construct that determines the chronology of > instances of atom:entry. Each time an atom:entry is modified, > atom:version MUST be given a chronologically later value than other > values than have appeared in any atom:entry with the same value for > atom:id. > > The value does not need to correspond to any particular event in an > entries life-cycle. Suitable values include date of last modification, > or the date the atom:entry is generated by an Atom producer. > > Is this plausible? Potential concerns / observations: 1) cvs versions are numbered with things like 1.99 and 1.103. This makes such versions unsuitable for this purpose. How do we make this clear? 2) in the general case, sorting of unicode is culturally sensitive. This isn't a concern for RFC 3339 based dates given the constrained set of characters that that grammar permits. 3) Perhaps version/modified need not be mandatory except in those instances where entries with duplicate ids are present in a feed? 4) No semantics can be inferred by two different entries with two different ids sharing the same version. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 16 08:06:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02140 for ; Mon, 16 May 2005 08:06: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 j4GBuju2066429; Mon, 16 May 2005 04:56: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 j4GBuje9066428; Mon, 16 May 2005 04:56:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GBuiQT066382 for ; Mon, 16 May 2005 04:56:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GBu6PK024600; Mon, 16 May 2005 12:56:12 +0100 (BST) In-Reply-To: <42887EEB.9040202@intertwingly.net> References: <12336714.20050515231212@djpowell.net> <07BEEFD6-3E0B-425E-A943-74EF180BA573@mac.com> <42887EEB.9040202@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 12:56:08 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 May 2005, at 12:07 pm, Sam Ruby wrote: > 1) cvs versions are numbered with things like 1.99 and 1.103. This > makes such versions unsuitable for this purpose. How do we make > this clear? "atom:version is a Date Construct"? It might be worth giving it a clearer name, though. > 2) in the general case, sorting of unicode is culturally sensitive. > This isn't a concern for RFC 3339 based dates given the > constrained > set of characters that that grammar permits. Timezones prevent sorting of RFC 3339 dates alphabetically anyway, so why is this a concern? Dates have to be parsed before the point in time and therefore the chronology can be established. > 3) Perhaps version/modified need not be mandatory except in those > instances where entries with duplicate ids are present in a feed? Yes. > 4) No semantics can be inferred by two different entries with two > different ids sharing the same version. Can they be for atom:modified? Usefully? Graham From owner-atom-syntax@mail.imc.org Mon May 16 09:18:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09650 for ; Mon, 16 May 2005 09:18: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 j4GD2TRY089937; Mon, 16 May 2005 06:02: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 j4GD2TVj089936; Mon, 16 May 2005 06:02:29 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GD2R1p089929 for ; Mon, 16 May 2005 06:02:28 -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, 16 May 2005 23:02:29 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 May 2005 23:02:21 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <07BEEFD6-3E0B-425E-A943-74EF180BA573@mac.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 16/5/05 8:31 PM, "Graham" wrote: > The only properties of atom:modified we're interested in are: > 1) That different versions have different dates > 2) Sorting chronologically puts the versions in the correct order > > This is to say, the absolute value of the date is irrelevant. The > only thing that matters is whether it is before, after or the same as > other dates that have appeared on a particular entry. what about comparing that entry against other entries? how do you sort a set of entries into chrono order? > The value does not need to correspond to any particular event in an > entries life-cycle. Suitable values include date of last > modification, or the date the atom:entry is generated by an Atom > producer. does this mean that a dynamic system could cause the same entry to have a new modification date on every retrieval? -1 e. From owner-atom-syntax@mail.imc.org Mon May 16 09:36:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11737 for ; Mon, 16 May 2005 09:36: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 j4GDRWlD091455; Mon, 16 May 2005 06:27: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 j4GDRWjH091454; Mon, 16 May 2005 06:27: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GDRVlb091433 for ; Mon, 16 May 2005 06:27:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3435622wra for ; Mon, 16 May 2005 06:27:26 -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=a7ikLBJYql0v49nlXwEp9ibYa22Xxhcpk+8ItDAYSUjRumyiilD+/6kRIxHSryV3x73nNLOSCdA+QN41YeZtz1gHx8TKiOpfQdEbko5Y+b6TUUfQp+U1KnNPTuttWCWq2IaToaaTqssUAtgm+oqu5MQOelWRgDzeX7LYXw1c/6g= Received: by 10.54.41.77 with SMTP id o77mr3684220wro; Mon, 16 May 2005 06:27:26 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 06:27:26 -0700 (PDT) Message-ID: <68fba5c505051606273c2a2b75@mail.gmail.com> Date: Mon, 16 May 2005 09:27:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Paul Hoffman , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GDRVlb091442 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Tim Bray wrote: > > The benefit the Web derived from HTML's > implicit-but-universally-implemented MustIgnore rule; it introduced > enough slack into the system that people could experiment without > breaking things. Don't you think the Feed Validator should flag my example as invalid? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 09:37:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11935 for ; Mon, 16 May 2005 09:37: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 j4GDT0uv091551; Mon, 16 May 2005 06:29: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 j4GDT06P091550; Mon, 16 May 2005 06:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GDSxUu091541 for ; Mon, 16 May 2005 06:28:59 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GDS6rK026302; Mon, 16 May 2005 14:28:16 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 14:28:09 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 May 2005, at 2:02 pm, Eric Scheid wrote: > what about comparing that entry against other entries? how do you > sort a set > of entries into chrono order? We have atom:updated and atom:published for that. >> The value does not need to correspond to any particular event in an >> entries life-cycle. Suitable values include date of last >> modification, or the date the atom:entry is generated by an Atom >> producer. >> > > does this mean that a dynamic system could cause the same entry to > have a > new modification date on every retrieval? i) It's not a modification date ii) Yes. The point of atom:modified and atom:version is to differentiate 2 different versions. Dynamic dates do that perfectly well. Graham From owner-atom-syntax@mail.imc.org Mon May 16 12:28:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05901 for ; Mon, 16 May 2005 12:28: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 j4GGGmG8010146; Mon, 16 May 2005 09:16: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 j4GGGmZM010145; Mon, 16 May 2005 09:16:48 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GGGkbg010137 for ; Mon, 16 May 2005 09:16:48 -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); Tue, 17 May 2005 02:16:44 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 May 2005 02:16:37 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified 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 16/5/05 11:28 PM, "Graham" wrote: > On 16 May 2005, at 2:02 pm, Eric Scheid wrote: >> what about comparing that entry against other entries? how do you >> sort a set of entries into chrono order? > > We have atom:updated and atom:published for that. if you want to sort by updated or published, but not for most recently changed (even if not 'significantly') >>> The value does not need to correspond to any particular event in an >>> entries life-cycle. Suitable values include date of last >>> modification, or the date the atom:entry is generated by an Atom >>> producer. >>> >> >> does this mean that a dynamic system could cause the same entry to >> have a new modification date on every retrieval? > > i) It's not a modification date > ii) Yes. The point of atom:modified and atom:version is to > differentiate 2 different versions. Dynamic dates do that perfectly > well. What if the Archivist is not the Publisher? They will then see many many instances, all with different 'versions' ... are they to assume they are different versions/editions, and put each and every dynamic instance into the archive? e. From owner-atom-syntax@mail.imc.org Mon May 16 12:49:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09568 for ; Mon, 16 May 2005 12:49: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 j4GGgABP012895; Mon, 16 May 2005 09:42: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 j4GGgANO012893; Mon, 16 May 2005 09:42:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GGg87Y012883 for ; Mon, 16 May 2005 09:42:09 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GGe8H8016498; Mon, 16 May 2005 17:40:17 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 17:39:17 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 May 2005, at 5:16 pm, Eric Scheid wrote: > if you want to sort by updated or published, but not for most recently > changed (even if not 'significantly') Well yes. So? I consider atom:modified to be unfeasible anyway for all sorts of reasons, so we're not losing any capability here. > What if the Archivist is not the Publisher? They will then see many > many > instances, all with different 'versions' ... are they to assume > they are > different versions/editions, and put each and every dynamic > instance into > the archive? You'd be keying off a semantic atom:version doesn't have, which is a daft thing to do. If you want to determine which versions to store, wait for the content itself to change. Graham From owner-atom-syntax@mail.imc.org Mon May 16 13:08:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11780 for ; Mon, 16 May 2005 13:08: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 j4GGvjtC014086; Mon, 16 May 2005 09:57: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 j4GGvjfs014085; Mon, 16 May 2005 09:57: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-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 j4GGvio5014071; Mon, 16 May 2005 09:57:44 -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 j4GGvijO010396; Mon, 16 May 2005 10:57:44 -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 <0IGL0008WDS7C2@edgemail1.Central.Sun.COM>; Mon, 16 May 2005 10:57:44 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGL000ZDDS68A@mail.sun.net>; Mon, 16 May 2005 10:57:43 -0600 (MDT) Date: Mon, 16 May 2005 09:59:01 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <68fba5c505051606273c2a2b75@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 16, 2005, at 6:27 AM, Robert Sayre wrote: > On 5/16/05, Tim Bray wrote: >> >> The benefit the Web derived from HTML's >> implicit-but-universally-implemented MustIgnore rule; it introduced >> enough slack into the system that people could experiment without >> breaking things. > > Don't you think the Feed Validator should flag my example as invalid? No. I actually thought that what we meant was what the spec said, and that this was the (very reasonable) outcome of our discussion on MustUnderstand. That means that if the IETF wants to extend Atom, we can do it as long as the extensions can be safely ignored. If you want to put something new in that can't be safely ignored, the whole document namespace has to be changed. I thought that the WG had converged on a reasonable and in fact enlightened position and I really would prefer not to go back and repeat the discussion. -Tim From owner-atom-syntax@mail.imc.org Mon May 16 13:15:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12736 for ; Mon, 16 May 2005 13:15: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 j4GH68s9015407; Mon, 16 May 2005 10:06: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 j4GH68BL015406; Mon, 16 May 2005 10:06:08 -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.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GH66bn015397 for ; Mon, 16 May 2005 10:06:07 -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); Tue, 17 May 2005 03:06:08 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 May 2005 03:06:01 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified 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 17/5/05 2:39 AM, "Graham" wrote: >> What if the Archivist is not the Publisher? They will then see many many >> instances, all with different 'versions' ... are they to assume they are >> different versions/editions, and put each and every dynamic instance into >> the archive? >> > You'd be keying off a semantic atom:version doesn't have, which is a daft > thing to do. I'm saying that atom:version is an inferior proposition as compared to atom:modified. Your original premise of there being only two properties we're interested in is faulty. > If you want to determine which versions to store, wait for the > content itself to change. blech. We all know just how successful that approach is. e. From owner-atom-syntax@mail.imc.org Mon May 16 13:24:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13769 for ; Mon, 16 May 2005 13:24: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 j4GHE3k8015917; Mon, 16 May 2005 10:14: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 j4GHE35Y015916; Mon, 16 May 2005 10:14:03 -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 j4GHE2bf015901 for ; Mon, 16 May 2005 10:14:02 -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 <20050516171356012005p232e>; Mon, 16 May 2005 17:13:56 +0000 Date: Mon, 16 May 2005 11:13:55 -0600 Subject: Re: extensions -- Atom NS and unprefixed attributes 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 Monday, May 16, 2005, at 10:59 AM, Tim Bray wrote: > On May 16, 2005, at 6:27 AM, Robert Sayre wrote: >> On 5/16/05, Tim Bray wrote: >>> The benefit the Web derived from HTML's >>> implicit-but-universally-implemented MustIgnore rule; it introduced >>> enough slack into the system that people could experiment without >>> breaking things. >> >> Don't you think the Feed Validator should flag my example as invalid? > > No. I actually thought that what we meant was what the spec said, and > that this was the (very reasonable) outcome of our discussion on > MustUnderstand. That means that if the IETF wants to extend Atom, we > can do it as long as the extensions can be safely ignored. If you > want to put something new in that can't be safely ignored, the whole > document namespace has to be changed. I thought that the WG had > converged on a reasonable and in fact enlightened position and I > really would prefer not to go back and repeat the discussion. -Tim I would think that a warning in that case would be useful that case, since it might be an accidental error--forgetting to prefix an extension element, or misspelling the name of an Atom element. Something along the lines of "Warning: this element is not recognized by the validator as a member of the Atom namespace. It may be from a newer version of the Atom specification than the validator is aware of, or it may be an error." From owner-atom-syntax@mail.imc.org Mon May 16 13:31:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14402 for ; Mon, 16 May 2005 13:31: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 j4GHNbsj016591; Mon, 16 May 2005 10: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 j4GHNbBV016590; Mon, 16 May 2005 10:23:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHNaIV016584 for ; Mon, 16 May 2005 10:23:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GHMV27003003; Mon, 16 May 2005 18:22:38 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17848538-F3B1-4935-B84E-5E309A09C3D8@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Mon, 16 May 2005 18:22:32 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 May 2005, at 6:06 pm, Eric Scheid wrote: > I'm saying that atom:version is an inferior proposition as compared to > atom:modified. Your original premise of there being only two > properties > we're interested in is faulty. With respect to allowing duplicate ids, it isn't. Graham From owner-atom-syntax@mail.imc.org Mon May 16 13:56:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17044 for ; Mon, 16 May 2005 13:56: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 j4GHiY9W018936; Mon, 16 May 2005 10:44: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 j4GHiYl2018935; Mon, 16 May 2005 10:44: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHiWLc018917 for ; Mon, 16 May 2005 10:44:32 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3616950wra for ; Mon, 16 May 2005 10:44:26 -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=dnGIz74uTp6fVPti5aInOmmGzYoL/lxGiJ62dkMT91dQd7T7P7T544kP5DO8LKlnTr/k6YzaRFnpOx+r8+wLhQuwRu5IvB1zYKRgBmpPWIFEFBan/kwd3EncRE9BXf3rYmLRSw2eaKtNkBlh+edn1mHx1Bp5LxkX6IbVSctbXFU= Received: by 10.54.141.10 with SMTP id o10mr3824253wrd; Mon, 16 May 2005 10:44:26 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 10:44:26 -0700 (PDT) Message-ID: <68fba5c5050516104468792287@mail.gmail.com> Date: Mon, 16 May 2005 13:44:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Paul Hoffman , Atom Syntax In-Reply-To: <68fba5c505051606273c2a2b75@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GHiXLc018923 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > On 5/16/05, Tim Bray wrote: >> Don't you think the Feed Validator should flag my example as invalid? > No. I actually thought that what we meant was what the spec said, and > that this was the (very reasonable) outcome of our discussion on > MustUnderstand. I don't think we are talking about the same issue. > That means that if the IETF wants to extend Atom, we > can do it as long as the extensions can be safely ignored. The problem is that anyone can extend the Atom namespace. > If you want > to put something new in that can't be safely ignored, the whole > document namespace has to be changed. Right. I'm not looking to change that. > I thought that the WG had > converged on a reasonable and in fact enlightened position and I really > would prefer not to go back and repeat the discussion. I am not looking for a repeat of that discussion. Atom 1.0 Processors cannot distinguish between markup added later on by the IETF and markup added by a third party, so the processing rules must remain as they are. That doesn't mean we should allow anyone and everyone to add elements and attributes to the Atom namespace. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 13:59:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17555 for ; Mon, 16 May 2005 13: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 j4GHpjd8019358; Mon, 16 May 2005 10:51: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 j4GHpjEH019357; Mon, 16 May 2005 10:51:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHpiQd019346 for ; Mon, 16 May 2005 10:51:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4GHoo3N011883; Mon, 16 May 2005 18:50:51 +0100 (BST) In-Reply-To: References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00ADA118-5484-4D15-AE62-9851675B0A4E@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: extensions -- Atom NS and unprefixed attributes Date: Mon, 16 May 2005 18:50:51 +0100 To: Tim Bray X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 May 2005, at 5:59 pm, Tim Bray wrote: i) >> Don't you think the Feed Validator should flag my example as invalid? > No. ii) > I actually thought that what we meant was what the spec said, and > that this was the (very reasonable) outcome of our discussion on > MustUnderstand. That means that if the IETF wants to extend Atom, > we can do it as long as the extensions can be safely ignored. If > you want to put something new in that can't be safely ignored, the > whole document namespace has to be changed. I thought that the WG > had converged on a reasonable and in fact enlightened position and > I really would prefer not to go back and repeat the discussion. -Tim Extensions being safely ignored is not the same thing as random crap in the Atom namespace. Robert's example was bogus in this regard, since there's no such thing as an "evil extension". On the other hand, I can't see any reason to allow third parties to create extensions in the atom namespace, other than to create problems for ourself when it come to v1.1. Graham From owner-atom-syntax@mail.imc.org Mon May 16 14:17:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19744 for ; Mon, 16 May 2005 14:17: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 j4GI84aW020467; Mon, 16 May 2005 11: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 j4GI84ti020466; Mon, 16 May 2005 11:08:04 -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 j4GI83YG020452; Mon, 16 May 2005 11:08:03 -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 j4GI830R006075; Mon, 16 May 2005 12:08:03 -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 <0IGL00CPEH1DCH@edgemail1.Central.Sun.COM>; Mon, 16 May 2005 12:08:01 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGL009FUH1C8J@mail.sun.net>; Mon, 16 May 2005 12:08:01 -0600 (MDT) Date: Mon, 16 May 2005 11:08:21 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <68fba5c5050516104468792287@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 16, 2005, at 10:44 AM, Robert Sayre wrote: > I am not looking for a repeat of that discussion. Atom 1.0 Processors > cannot distinguish between markup added later on by the IETF and > markup added by a third party, so the processing rules must remain as > they are. That doesn't mean we should allow anyone and everyone to add > elements and attributes to the Atom namespace. > My problem is that putting text in the format spec saying "Nobody but the IETF can extend the namespace" feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It's like clauses in constitutions saying "this clause can't be amended", well yes it can and will be if enough people want it to. I guess staking the claim is not actively harmful. FWIW I don't recall ever seeing such language in any other specs, but maybe I just wasn't looking. -Tim From owner-atom-syntax@mail.imc.org Mon May 16 14:27:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20329 for ; Mon, 16 May 2005 14: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 j4GIKaxF021508; Mon, 16 May 2005 11:20: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 j4GIKahV021506; Mon, 16 May 2005 11:20: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GIKZTx021484 for ; Mon, 16 May 2005 11:20:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3643180wra for ; Mon, 16 May 2005 11:20:29 -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=Tall1qu0Sinbc390WKgXV0LRY/AZnBs5xT9RYi2JD43QfK3aOi2fg6bqiYGncfYpgxqmBIY5eU0Q2cdza3TOENwOsOJqqrmEHovviRCd4oSTqPwXIfb5OEOaFe+DFu+CWHsrL+NS8+Icnj1+36f71yuk35jIo7CwPvQuyTjVTys= Received: by 10.54.98.19 with SMTP id v19mr3818691wrb; Mon, 16 May 2005 11:20:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 11:20:29 -0700 (PDT) Message-ID: <68fba5c50505161120552ad401@mail.gmail.com> Date: Mon, 16 May 2005 14:20:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Paul Hoffman , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GIKZTx021493 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Tim Bray wrote: > On May 16, 2005, at 10:44 AM, Robert Sayre wrote: > > > I am not looking for a repeat of that discussion. Atom 1.0 Processors > > cannot distinguish between markup added later on by the IETF and > > markup added by a third party, so the processing rules must remain as > > they are. That doesn't mean we should allow anyone and everyone to add > > elements and attributes to the Atom namespace. > > > My problem is that putting text in the format spec saying "Nobody but > the IETF can extend the namespace" feels empty and useless, are we > going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. > It's > like clauses in constitutions saying "this clause can't be amended", > well yes it can and will be if enough people want it to. I guess > staking the claim is not actively harmful. FWIW I don't recall ever > seeing such language in any other specs, but maybe I just wasn't > looking. Well, most documents probably use normative schemas for that. In fact, our informative RNC rules it out. So, we'll either have to add language to the spec or fix the RNC. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 14:45:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22288 for ; Mon, 16 May 2005 14:45: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 j4GIZiMB022549; Mon, 16 May 2005 11:35: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 j4GIZiql022548; Mon, 16 May 2005 11:35:44 -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 j4GIZhoU022530 for ; Mon, 16 May 2005 11:35:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 3917 messnum 7059471 invoked from network[83.70.217.193/unknown]); 16 May 2005 18:35:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail01.svc.cra.dublin.eircom.net (qp 3917) with SMTP; 16 May 2005 18:35:36 -0000 Message-ID: <4288E7F5.8040900@dehora.net> Date: Mon, 16 May 2005 19:35: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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> In-Reply-To: <68fba5c50505161120552ad401@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: > On 5/16/05, Tim Bray wrote: > >> >>My problem is that putting text in the format spec saying "Nobody but >>the IETF can extend the namespace" feels empty and useless, are we >>going to send Marshall Rose over to beat up anyone who tries? > > > It will happen and we won't be able to stop it. I have a question - what's the problem? cheers Bill From owner-atom-syntax@mail.imc.org Mon May 16 15:02:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24322 for ; Mon, 16 May 2005 15: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 j4GIqjtH023815; Mon, 16 May 2005 11: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 j4GIqjaW023814; Mon, 16 May 2005 11:52: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 j4GIqhvV023794 for ; Mon, 16 May 2005 11:52:44 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 16 May 2005 18:52:37 -0000 Received: from p508FB287.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.178.135] by mail.gmx.net (mp015) with SMTP; 16 May 2005 20:52:37 +0200 X-Authenticated: #1915285 Message-ID: <4288EBDB.6080507@gmx.de> Date: Mon, 16 May 2005 20:52:11 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Robert Sayre , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505092001339ea585@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> In-Reply-To: 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 Tim Bray wrote: > > On May 16, 2005, at 10:44 AM, Robert Sayre wrote: > >> I am not looking for a repeat of that discussion. Atom 1.0 Processors >> cannot distinguish between markup added later on by the IETF and >> markup added by a third party, so the processing rules must remain as >> they are. That doesn't mean we should allow anyone and everyone to add >> elements and attributes to the Atom namespace. >> > My problem is that putting text in the format spec saying "Nobody but > the IETF can extend the namespace" feels empty and useless, are we going > to send Marshall Rose over to beat up anyone who tries? It's like > clauses in constitutions saying "this clause can't be amended", well yes > it can and will be if enough people want it to. I guess staking the > claim is not actively harmful. FWIW I don't recall ever seeing such > language in any other specs, but maybe I just wasn't looking. -Tim : "Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC." This hasn't been always succesfull, but at least the Working Group can point people to that section in case they try (and they try quite often :-). Best regards, Julian From owner-atom-syntax@mail.imc.org Mon May 16 15:02:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24345 for ; Mon, 16 May 2005 15:02: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 j4GIsP1T023966; Mon, 16 May 2005 11:54: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 j4GIsPWx023965; Mon, 16 May 2005 11:54: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GIsOEr023945 for ; Mon, 16 May 2005 11:54:24 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3666801wra for ; Mon, 16 May 2005 11:54:19 -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=a6DrKCp4qzwXIqI/ejaqhJupLUeSO70yswPHGETyeOOnQPRRwkybcY8eL2GohiCKxnwZBdir6ZNmpeb74xbvYio3ilojGnanLcMEhuMtOQ6hmwBpOYRXtuNNg/oXwoD1csKb1/5cN+OPuPXcyxmdjNqFUnEdCDD/LJgzvAv0f3o= Received: by 10.54.24.46 with SMTP id 46mr3831687wrx; Mon, 16 May 2005 11:54:19 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 11:54:19 -0700 (PDT) Message-ID: <68fba5c5050516115439a94095@mail.gmail.com> Date: Mon, 16 May 2005 14:54:19 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <4288E7F5.8040900@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GIsPEr023947 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > Robert Sayre wrote: > > On 5/16/05, Tim Bray wrote: > > > >> > >>My problem is that putting text in the format spec saying "Nobody but > >>the IETF can extend the namespace" feels empty and useless, are we > >>going to send Marshall Rose over to beat up anyone who tries? > > > > > > It will happen and we won't be able to stop it. > > I have a question - what's the problem? I can think of a couple things. One would be collisions (which Sam mentioned). Another would be that validators couldn't catch typos. ... My trip... My trip to the beach Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 15:41:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00106 for ; Mon, 16 May 2005 15: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 j4GJV9N7026328; Mon, 16 May 2005 12: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 j4GJV9EF026327; Mon, 16 May 2005 12:31:09 -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 j4GJV8Hb026320 for ; Mon, 16 May 2005 12:31:09 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4GJWUOw031293 for ; Mon, 16 May 2005 15:32:34 -0400 Message-ID: <4288F4F3.4020107@intertwingly.net> Date: Mon, 16 May 2005 15:30:59 -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: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> In-Reply-To: <68fba5c5050516115439a94095@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>Robert Sayre wrote: >> >>>On 5/16/05, Tim Bray wrote: >>> >>>>My problem is that putting text in the format spec saying "Nobody but >>>>the IETF can extend the namespace" feels empty and useless, are we >>>>going to send Marshall Rose over to beat up anyone who tries? >>> >>>It will happen and we won't be able to stop it. >> >>I have a question - what's the problem? > > I can think of a couple things. One would be collisions (which Sam > mentioned). Another would be that validators couldn't catch typos. > > ... > My trip... > My trip to the beach > > Does the same principle apply to attributes? If a validator can't catch typos, what's left? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 16 15:42:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00423 for ; Mon, 16 May 2005 15:42: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 j4GJWwV5026462; Mon, 16 May 2005 12:32: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 j4GJWwPf026461; Mon, 16 May 2005 12:32:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4GJWvHt026444 for ; Mon, 16 May 2005 12:32:57 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 35410 messnum 5381586 invoked from network[83.70.217.193/unknown]); 16 May 2005 19:32:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail08.svc.cra.dublin.eircom.net (qp 35410) with SMTP; 16 May 2005 19:32:51 -0000 Message-ID: <4288F560.4010601@dehora.net> Date: Mon, 16 May 2005 20:32:48 +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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> In-Reply-To: <68fba5c5050516115439a94095@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>Robert Sayre wrote: >> >>>On 5/16/05, Tim Bray wrote: >>> >>> >>>>My problem is that putting text in the format spec saying "Nobody but >>>>the IETF can extend the namespace" feels empty and useless, are we >>>>going to send Marshall Rose over to beat up anyone who tries? >>> >>> >>>It will happen and we won't be able to stop it. >> >>I have a question - what's the problem? > > > I can think of a couple things. One would be collisions (which Sam > mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html > Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 16 15:50:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02788 for ; Mon, 16 May 2005 15: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 j4GJgXuw027166; Mon, 16 May 2005 12:42: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 j4GJgXxE027165; Mon, 16 May 2005 12:42:33 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GJgWXR027148 for ; Mon, 16 May 2005 12:42:32 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3698416wra for ; Mon, 16 May 2005 12:42:27 -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=kohnS2iurbnuCl+Wic2N9o70G5WtXCHYCrlftUsM2ajLBZ+8cV0poa4v3oH+MAxr5wJOwUD0H6wyczac2K9z4kGy9/YPsbsji08Y01oWG1V8YrasTXYjlfEw93yawC7hHRtS4/lfMNoR1BQ+DV3Wbkh6CXLGmHnb0r+DQH5w/Wo= Received: by 10.54.23.10 with SMTP id 10mr3854453wrw; Mon, 16 May 2005 12:42:26 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 12:42:26 -0700 (PDT) Message-ID: <68fba5c505051612425e783a8a@mail.gmail.com> Date: Mon, 16 May 2005 15:42:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <4288F560.4010601@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GJgWXR027157 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > > I can think of a couple things. One would be collisions (which Sam > > mentioned). > > I don't understand- maybe I'm looking at the wrong post? > > http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. > > Another would be that validators couldn't catch typos. > > Validators won't be able to catch typos for optional markup. What do you mean? The extended example in the spec has a generator element. The RNC has caught me adding an attribute called 'url'. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 16:31:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16765 for ; Mon, 16 May 2005 16:31: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 j4GKNb3o031077; Mon, 16 May 2005 13: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 j4GKNbnk031076; Mon, 16 May 2005 13:23:37 -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 j4GKNaWg031069 for ; Mon, 16 May 2005 13:23:36 -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 j4GKNa0R027378 for ; Mon, 16 May 2005 14:23:36 -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 <0IGL00BBSNBBWI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 16 May 2005 14:23:36 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGL00H2INBBJS@mail.sun.net> for atom-syntax@imc.org; Mon, 16 May 2005 14:23:35 -0600 (MDT) Date: Mon, 16 May 2005 13:24:53 -0700 From: Tim Bray Subject: Re: extensions -- Atom NS and unprefixed attributes In-reply-to: <4288F4F3.4020107@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: <1396f29ce4c261834419aa6cf4c39ee9@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505102114188a3b38@mail.gmail.com> <2f9d249090e7ee767fa6647ff7cf58d7@sun.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F4F3.4020107@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 16, 2005, at 12:30 PM, Sam Ruby wrote: >> ... >> My trip... >> My trip to the beach >> >> > > Does the same principle apply to attributes? > > If a validator can't catch typos, what's left? It would be perfectly OK and expected for a validator to emit an "unrecognized element" diagnostic. It would be really out of line for a desktop newsreader to refuse to display a feed because it has an unrecognized element, whether it's from the Atom namespace or not. That's the behavior the current language supports. I don't see how it gets in the way of validators. -Tim From owner-atom-syntax@mail.imc.org Mon May 16 16:34:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17144 for ; Mon, 16 May 2005 16:34: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 j4GKS3km031347; Mon, 16 May 2005 13:28: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 j4GKS3iH031346; Mon, 16 May 2005 13:28:03 -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 j4GKS2JS031328 for ; Mon, 16 May 2005 13:28:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 48164 messnum 2893695 invoked from network[83.70.217.193/unknown]); 16 May 2005 20:27:56 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail07.svc.cra.dublin.eircom.net (qp 48164) with SMTP; 16 May 2005 20:27:56 -0000 Message-ID: <4289024A.80504@dehora.net> Date: Mon, 16 May 2005 21:27:54 +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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c5050515214373a4f9cf@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> In-Reply-To: <68fba5c505051612425e783a8a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > > >>>I can think of a couple things. One would be collisions (which Sam >>>mentioned). >> >>I don't understand- maybe I'm looking at the wrong post? >> >>http://www.imc.org/atom-syntax/mail-archive/msg15236.html > > > Sam is saying that the IETF can't add a new element to the Atom > namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? >>>Another would be that validators couldn't catch typos. >> >>Validators won't be able to catch typos for optional markup. If there is a non-optional piece of markup expected, and you enter a typo instead of it, it won't be in the markup, then a validator won't find it, hence the validator will flag that something is missing. > What do you mean? The extended example in the spec has a generator > element. The RNC has caught me adding an attribute called 'url'. Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 16 17:22:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21976 for ; Mon, 16 May 2005 17: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 j4GLEMGw035995; Mon, 16 May 2005 14:14: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 j4GLEMhQ035994; Mon, 16 May 2005 14:14: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLEK8H035967 for ; Mon, 16 May 2005 14:14:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3758867wra for ; Mon, 16 May 2005 14:14:14 -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=S6++DR0Keojylb30IvwfruunaWw8bVBy3oYXSoS64SLOiNYkE7QKI4PF+siv51NdkUGRf44lbJ0n9SNEcGOtrkTvxBuVFQA9H7+z8C16Pwj1yLyT6h3WE6zKPCleIyAzTZbQqk+a/QatntTgsvZFXr/gZkf3qUgL0djHcYA3Ngs= Received: by 10.54.13.77 with SMTP id 77mr3895212wrm; Mon, 16 May 2005 14:14:13 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 14:14:13 -0700 (PDT) Message-ID: <68fba5c50505161414468bf2d7@mail.gmail.com> Date: Mon, 16 May 2005 17:14:13 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <4289024A.80504@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GLEL8H035981 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > Robert Sayre wrote: > > On 5/16/05, Bill de hra wrote: > > > > > >>>I can think of a couple things. One would be collisions (which Sam > >>>mentioned). > >> > >>I don't understand- maybe I'm looking at the wrong post? > >> > >>http://www.imc.org/atom-syntax/mail-archive/msg15236.html > > > > > > Sam is saying that the IETF can't add a new element to the Atom > > namespace and be sure there would be no collision. > > I still don't understand. Can't the IETF read their own specs? The spec allows anyone to add stuff to the Atom namespace, so the IETF will have to read everyone's documents before they add something to the Atom namespace. Maybe you folks are implying that collisions just aren't a problem. > Can validators catch typos or not? You seem to be saying they can't, but > they did catch you adding an attribute called url. > > I'm honestly not getting the gist of this issue, sorry. If anyone can add unqualified attributes, how can the validator distinguish between a typo and an extension? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 18:01:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00150 for ; Mon, 16 May 2005 18: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 j4GLhD7f037758; Mon, 16 May 2005 14:43: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 j4GLhDTr037754; Mon, 16 May 2005 14:43:13 -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 j4GLhCNL037737 for ; Mon, 16 May 2005 14:43:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 289 messnum 6690760 invoked from network[83.70.217.193/unknown]); 16 May 2005 21:43:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 289) with SMTP; 16 May 2005 21:43:04 -0000 Message-ID: <428913E5.2040400@dehora.net> Date: Mon, 16 May 2005 22:43: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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c505051606273c2a2b75@mail.gmail.com> <68fba5c5050516104468792287@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> In-Reply-To: <68fba5c50505161414468bf2d7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>Robert Sayre wrote: >> >>>On 5/16/05, Bill de hra wrote: >>> >>> >>> >>>>>I can think of a couple things. One would be collisions (which Sam >>>>>mentioned). >>>> >>>>I don't understand- maybe I'm looking at the wrong post? >>>> >>>>http://www.imc.org/atom-syntax/mail-archive/msg15236.html >>> >>> >>>Sam is saying that the IETF can't add a new element to the Atom >>>namespace and be sure there would be no collision. >> >>I still don't understand. Can't the IETF read their own specs? > > > The spec allows anyone to add stuff to the Atom namespace, so the IETF > will have to read everyone's documents before they add something to > the Atom namespace. The spec does no such thing; that's a psychotic interpretation at best. If people are going to add stuff to the Atom namespace, then they're going to add stuff to the Atom namespace, irrespective of what the spec says. Your options are to live with that or enforce the building of machinery that will reject the markup of people who do it. To build that machinery you'll have to have an ability to proof-check the markup. To proof-check the markup you have to have to ensure its legal names and their combinations can be enumerated at design time - at a minimum. > Maybe you folks are implying that collisions just > aren't a problem. If they are a problem, then they're universal to XML+namespaces. I'll argue we're not hear to solve that (possible) problem, even if we are responsible for choosing that technology to begin with. One approach for minimising honest-john name collisions for attributes is to state that further added attributes be namespace qualified. If we are still worried about unprefixed attributes, we can either ban them all except for the ones we have designed, or ban them all and place the ones we have inside the atom namespace. Either way, no further unprefixed attributes will be accepted by validators than the ones we mandate now. I suppose if we're going to worry about this stuff, let's worry about these too: - will it be hard for people to use atom attributes outside atom? - will adding new attributes result in spec combination breakage a la the recent situations with new xml:* attributes? [But personally speaking, I find this debate unimportant compared to consequences of say default namespaces and the introduction of xhtml:div] >>Can validators catch typos or not? You seem to be saying they can't, but >>they did catch you adding an attribute called url. >> >>I'm honestly not getting the gist of this issue, sorry. > > > If anyone can add unqualified attributes, how can the validator > distinguish between a typo and an extension? For non-optional attributes, a validator will pick up on a typo to non-optional attribute by way of the non-optional attribute not being there. * Optional attributes can't easily be distinguished because you can't enumerate all of them in advance - formally, that would be a non-existence of bugs class problem. But as they're optional, it's not a disaster. If it is a disaster, we have a design problem first and foremost, not a validation problem. cheers Bill * barring statistically unfortunate events like a typing an attribute in once mistakenly and then typing it in correctly. From owner-atom-syntax@mail.imc.org Mon May 16 18:11:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01853 for ; Mon, 16 May 2005 18: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 j4GLrv2l038825; Mon, 16 May 2005 14:53: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 j4GLrvmx038824; Mon, 16 May 2005 14:53: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLruH4038788 for ; Mon, 16 May 2005 14:53:56 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3783439wra for ; Mon, 16 May 2005 14:53:50 -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=Z5OVef2QRFN+/uc41IKKdGnUe58anXzSmzAuB4Zxew5Vwol8zM7B6u/pgqsYfW//v6cYgzO9dIaxoPIt093MEG8Yc9vLPkb3EappKFaIK0a1VoukM6DLAMxRMP90zUNglnl4iLxtGEyZFqy1/WicABQL3NYuVzQVb3ftZrRKDK4= Received: by 10.54.67.8 with SMTP id p8mr2790642wra; Mon, 16 May 2005 14:53:50 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 14:53:50 -0700 (PDT) Message-ID: <68fba5c505051614533c0a773f@mail.gmail.com> Date: Mon, 16 May 2005 17:53:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <428913E5.2040400@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GLruH4038801 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > > > > The spec allows anyone to add stuff to the Atom namespace, so the IETF > > will have to read everyone's documents before they add something to > > the Atom namespace. > > The spec does no such thing; that's a psychotic interpretation at best. What? If the spec doesn't ban it, it allows it. Why shouldn't we do what Julian's DAV spec did? [0] > If people are going to add stuff to the Atom namespace, then they're > going to add stuff to the Atom namespace, irrespective of what the spec > says. Your options are to live with that or enforce the building of > machinery that will reject the markup of people who do it. To build that > machinery you'll have to have an ability to proof-check the markup. To > proof-check the markup you have to have to ensure its legal names and > their combinations can be enumerated at design time - at a minimum. I am actually fine with going this route, but we should get rid of the syntactic constraints on link @rel if we're going to have a dictionary free-for-all in element names. What's the point, really. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg15255.html From owner-atom-syntax@mail.imc.org Mon May 16 18:35:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08444 for ; Mon, 16 May 2005 18:35: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 j4GMQd2W041351; Mon, 16 May 2005 15:26: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 j4GMQdcY041350; Mon, 16 May 2005 15:26:39 -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 j4GMQcav041312 for ; Mon, 16 May 2005 15:26:39 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 94651 messnum 5266492 invoked from network[83.70.217.193/unknown]); 16 May 2005 22:26:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail04.svc.cra.dublin.eircom.net (qp 94651) with SMTP; 16 May 2005 22:26:32 -0000 Message-ID: <42891E16.2040208@dehora.net> Date: Mon, 16 May 2005 23:26:30 +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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <68fba5c50505161120552ad401@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> In-Reply-To: <68fba5c505051614533c0a773f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>>The spec allows anyone to add stuff to the Atom namespace, so the IETF >>>will have to read everyone's documents before they add something to >>>the Atom namespace. >> >>The spec does no such thing; that's a psychotic interpretation at best. > > > What? If the spec doesn't ban it, it allows it. Why shouldn't we do > what Julian's DAV spec did? [0] Only, and this is not a joke, if you agree to add the text "What this specification doesn't ban, it allows". Let's leave no room for doubt as to the spirit of interpretation. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 16 18:43:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09790 for ; Mon, 16 May 2005 18:43: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 j4GMZ9Gk041951; Mon, 16 May 2005 15:35: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 j4GMZ9D2041950; Mon, 16 May 2005 15:35: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GMZ8ZE041942 for ; Mon, 16 May 2005 15:35:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3806107wra for ; Mon, 16 May 2005 15:35: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=b1pQwkQwOuyUBy5WfoGrgWUo0XLG/VzsRqjxG8moPvJRXsU4HO8R9vHqJLU/exw+lGVa+mY+S9hS3GwRc0jkj0wKIrSvTMdAi1ZTI5Cb0cirsNABFiCBBHHqxMDYBccOEOnH2wQm4stfuPRaxVGUoDNCgWQgx+0S2iM0RJ6oatE= Received: by 10.54.51.45 with SMTP id y45mr3918320wry; Mon, 16 May 2005 15:35:03 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 15:35:02 -0700 (PDT) Message-ID: <68fba5c505051615353723dded@mail.gmail.com> Date: Mon, 16 May 2005 18:35:02 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: PaceOtherVocabularies 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 j4GMZ8ZE041945 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit http://www.intertwingly.net/wiki/pie/PaceOtherVocabularies == Abstract == Ban non-IETF use of the Atom namespace. == Status == Open == Rationale == Keep extensions in other namespaces, so the Atom namespace can be safely extended by the IETF. == Proposal == === 6.1 Extensions From Non-Atom Vocabularies === This specification describes Atom's XML markup vocabulary. Markup from other vocabularies ("foreign markup") can be used in an Atom document, but MUST be namespace-qualified and in a namespace other than Atom's. Note that the atom:content element is designed to support the inclusion of arbitrary foreign markup. === 6.2 Extensions To the Atom Vocabulary === Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. For the purposes of this discussion, unrecognized markup from the Atom vocabulary will be considered "foreign markup". == Impacts == == Notes == From owner-atom-syntax@mail.imc.org Mon May 16 18:49:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10399 for ; Mon, 16 May 2005 18: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 j4GMhrcH042361; Mon, 16 May 2005 15: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 j4GMhrLX042360; Mon, 16 May 2005 15:43:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GMhqWI042353 for ; Mon, 16 May 2005 15:43:52 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from [198.144.206.184] (helo=[192.168.1.122]) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DXoJT-0002qW-QZ; Mon, 16 May 2005 18:43:51 -0400 In-Reply-To: <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> References: <6b4e5faa5bdfc334933e71362ba0965d@epeus.com> <77C812A8-C499-11D9-961E-003065EA6144@geckotribe.com> <20050514180244.GA858@klangraum> <2eb5d3ce1dc5f76c42004d18031e4a7f@sun.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "A. Pagaltzis" , atom-syntax@imc.org From: Kevin Marks Subject: Re: PaceContentAndSummaryDistinct Date: Mon, 16 May 2005 15:43:43 -0700 To: Tim Bray X-Mailer: Apple Mail (2.622) X-ELNK-Trace: b7e272d7a574036deb604bd72476f039239a348a220c26092e3091c853c115ab8f143b90d7c8a5e6a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 198.144.206.184 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On May 15, 2005, at 10:24 AM, Tim Bray wrote: > > On May 14, 2005, at 11:02 AM, A. Pagaltzis wrote: > >> The "atom:content" element either contains or links to the >> full content of the entry. An "atom:entry" containing an >> "atom:content" element MUST be a complete representation of >> the entry. > > -1 > > What does "complete" mean? This is untestable and semantically fuzzy. > I think anything stronger than "is intended to contain the full > content" is just not workable. -Tim Tim, that is exactly the point. When parsing RSS , there is no way to know if what is there is complete or an extract. Atom rightly expresses these as semantically distinct entities. There isn't a good way to distinguish them algorithmically, so we really need explicit language in the spec making this clear. It needs human validation, as it can't be done by code, but it needs to be in the spec so we can point implementers to it, or better, that they see it and realise why there are 2 distinct elements for these purposes. Putting abbreviated forms in both is the semantic pollution; if an entry is brief enough to be unsummarizable, having the same in both summary and content is perhaps legitimate, but if making the 'not the same' requirement explicit requires that very short entries have no summary, that works and increases feed consistency. The difficulty comes when people view the feed content as something distinct from the content of the entry itself; in that case we want them to use atom:summary rather than atom:content. Just saying 'they can't be the same' is insufficient; the reason they are distinct needs to be there in the specification too. My initial language may be clumsy or overdone, but this requires a MUST rather than a SHOULD if the content/summary elements are to remain useful and distinct. From owner-atom-syntax@mail.imc.org Mon May 16 19:02:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11852 for ; Mon, 16 May 2005 19:02: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 j4GMsfNt042979; Mon, 16 May 2005 15: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 j4GMsf3l042978; Mon, 16 May 2005 15:54: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 j4GMse82042960 for ; Mon, 16 May 2005 15:54:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3815466wra for ; Mon, 16 May 2005 15:54: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=llYiMPn0n5LHY2MpGUXy+PeIbtqryci0kqn5wTuY9g9Ap/vUpg64dxrAzKcSsX9kVscQyjSqAC7+dnN0oBqhOQ7QnmSEKi4R64IQbG3ULTjLf+NNm2K/uPpMa71t0VBOIHv2hpD4KQyNcm+bNv4s4mRdWXxKCbinEUjtmWkqviE= Received: by 10.54.51.78 with SMTP id y78mr3929866wry; Mon, 16 May 2005 15:54:35 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 15:54:35 -0700 (PDT) Message-ID: <68fba5c5050516155460ed7717@mail.gmail.com> Date: Mon, 16 May 2005 18:54:35 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <42891E16.2040208@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> <42891E16.2040208@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GMsf82042966 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > > Only, and this is not a joke, if you agree to add the text "What this > specification doesn't ban, it allows". Let's leave no room for doubt as > to the spirit of interpretation. "Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error." What error would that be? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 19:28:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15229 for ; Mon, 16 May 2005 19:28: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 j4GNH48M044814; Mon, 16 May 2005 16:17: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 j4GNH4XJ044813; Mon, 16 May 2005 16:17:04 -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 j4GNH35p044796 for ; Mon, 16 May 2005 16:17:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 89298 messnum 6395062 invoked from network[83.70.217.193/unknown]); 16 May 2005 23:16:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 89298) with SMTP; 16 May 2005 23:16:57 -0000 Message-ID: <428929E6.1050501@dehora.net> Date: Tue, 17 May 2005 00:16:54 +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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <4288E7F5.8040900@dehora.net> <68fba5c5050516115439a94095@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> <42891E16.2040208@dehora.net> <68fba5c5050516155460ed7717@mail.gmail.com> In-Reply-To: <68fba5c5050516155460ed7717@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>Only, and this is not a joke, if you agree to add the text "What this >>specification doesn't ban, it allows". Let's leave no room for doubt as >>to the spirit of interpretation. > > > "Future versions of this specification could add new elements and > attributes to the Atom markup vocabulary. Software written to conform > to this version of the specification will not be able to process such > markup correctly and, in fact, will not be able to distinguish it from > markup error." > > What error would that be? Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 16 19:28:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15257 for ; Mon, 16 May 2005 19:28: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 j4GNGcsT044771; Mon, 16 May 2005 16:16: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 j4GNGclf044770; Mon, 16 May 2005 16:16:38 -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 j4GNGbTG044760 for ; Mon, 16 May 2005 16:16:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.105] (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 j4GNI10w024094; Mon, 16 May 2005 19:18:01 -0400 Message-ID: <428929D2.7050000@intertwingly.net> Date: Mon, 16 May 2005 19:16:34 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: PaceOtherVocabularies References: <68fba5c505051615353723dded@mail.gmail.com> In-Reply-To: <68fba5c505051615353723dded@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: > > Software written to conform > to this version of the specification will not be able to process such > markup correctly and, in fact, will not be able to distinguish it from > markup error. Please replace that sentence with something reemphasizing the MustIgnore rule. Stating that nobody else is allowed to use the Atom namespace, coupled with a statement that everybody must ignore elements that they don't understand paves the way for future IETF spec authors to safely add optional elements in a backwards compatible manner. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon May 16 19:33:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15757 for ; Mon, 16 May 2005 19:33: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 j4GNQ68j045351; Mon, 16 May 2005 16:26: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 j4GNQ6vh045350; Mon, 16 May 2005 16:26: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GNQ5W5045338 for ; Mon, 16 May 2005 16:26:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3829637wra for ; Mon, 16 May 2005 16:26:00 -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=VD4SW4nD3F1agO0Lb4kbDZ5q/RgsFT+bQaAL2qv1lzoHrIO8G7YoGRVZLh2Stkwv5GzKeg4CyzwQ8gz5c4Avnl3Oreezwpbg1rviCrJ95+hYMKcbh8OHvI75aSL5nb8P1q75RIKgwtIPiyPW8DAoF/IE5bskdcUDjBIzqfIRaVo= Received: by 10.54.51.45 with SMTP id y45mr3941628wry; Mon, 16 May 2005 16:26:00 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 16:26:00 -0700 (PDT) Message-ID: <68fba5c50505161626738b014@mail.gmail.com> Date: Mon, 16 May 2005 19:26:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOtherVocabularies Cc: Atom Syntax In-Reply-To: <428929D2.7050000@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051615353723dded@mail.gmail.com> <428929D2.7050000@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GNQ6W5045344 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Sam Ruby wrote: > Robert Sayre wrote: > > > > Software written to conform > > to this version of the specification will not be able to process such > > markup correctly and, in fact, will not be able to distinguish it from > > markup error. > > Please replace that sentence with something reemphasizing the MustIgnore > rule. Hmm. Section 6.2 was unchanged from format-08. I just put that in there for context. Now I've included section 6.3 for more context. The MustIgnore rule's first occurrence was always in 6.3. In format-08, there's no difference between Atom and non-Atom extensions. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 20:47:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21159 for ; Mon, 16 May 2005 20: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 j4H0d1gF049134; Mon, 16 May 2005 17:39: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 j4H0d1vW049133; Mon, 16 May 2005 17:39:01 -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 j4H0cwxD049119 for ; Mon, 16 May 2005 17:39:00 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.5] (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 2F128A32B8; Mon, 16 May 2005 20:38:56 -0400 (EDT) In-Reply-To: <68fba5c505051615353723dded@mail.gmail.com> References: <68fba5c505051615353723dded@mail.gmail.com> 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 X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceOtherVocabularies Date: Mon, 16 May 2005 17:38:53 -0700 To: Robert Sayre 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 Does this imply that this (or another IETF) Working Group cannot mint an Atom extension without putting it into a new namespace, or changing the version number? If so, I think it's a needless constraint. This WG might come up with a backwards-compatible extension and want to put it in the Atom namespace for convenience; that shouldn't necessitate bumping the version number (which would cause a lot of compatibility problems). Cheers, On May 16, 2005, at 3:35 PM, Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceOtherVocabularies > > == Abstract == > > Ban non-IETF use of the Atom namespace. > > == Status == > > Open > > == Rationale == > > Keep extensions in other namespaces, so the Atom namespace can be > safely extended by the IETF. > > == Proposal == > > === 6.1 Extensions From Non-Atom Vocabularies === > > This specification describes Atom's XML markup vocabulary. Markup from > other vocabularies ("foreign markup") can be used in an Atom document, > but MUST be namespace-qualified and in a namespace other than Atom's. > Note that the atom:content element is designed to support the > inclusion of arbitrary foreign markup. > > === 6.2 Extensions To the Atom Vocabulary === > > Future versions of this specification could add new elements and > attributes to the Atom markup vocabulary. Software written to conform > to this version of the specification will not be able to process such > markup correctly and, in fact, will not be able to distinguish it from > markup error. For the purposes of this discussion, unrecognized markup > from the Atom vocabulary will be considered "foreign markup". > > == Impacts == > > == Notes == > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon May 16 20:54:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21683 for ; Mon, 16 May 2005 20:54: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 j4H0lu4p049741; Mon, 16 May 2005 17: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 j4H0luSV049740; Mon, 16 May 2005 17:47:56 -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 j4H0ltSj049725 for ; Mon, 16 May 2005 17:47:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3868144wra for ; Mon, 16 May 2005 17:47:49 -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=DFJvGDkSCmxVuEyq2s0/p01o/aagIo6tzgeVBp4Kd1wr52r3w//W2DDuyfyyICbIRrAkg/08XscSEzKVAQejcBiwsLWdkZPFnXnMmX0/lY8uS2uE6RRnwiEs+N/favwas0lKRLgUbiG7XzklmogfEwt+UYsxdKht41Mcxtl5voU= Received: by 10.54.141.10 with SMTP id o10mr4004097wrd; Mon, 16 May 2005 17:47:49 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 17:47:48 -0700 (PDT) Message-ID: <68fba5c5050516174757214625@mail.gmail.com> Date: Mon, 16 May 2005 20:47:48 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Mark Nottingham Subject: Re: PaceOtherVocabularies Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505051615353723dded@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4H0ltSj049735 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Mark Nottingham wrote: > Does this imply that this (or another IETF) Working Group cannot mint > an Atom extension without putting it into a new namespace, or changing > the version number? They would have to bump the version number. That was the idea behind PaceRemoveVersionAttr, AFAIK. Backwords-compatible changes bump the version number, while backwords-incompatible changes need a new namespace. Robert Sayre > If so, I think it's a needless constraint. This WG might come up with a > backwards-compatible extension and want to put it in the Atom namespace > for convenience; that shouldn't necessitate bumping the version number > (which would cause a lot of compatibility problems). From owner-atom-syntax@mail.imc.org Mon May 16 21:12:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23621 for ; Mon, 16 May 2005 21:12: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 j4H12xCE050837; Mon, 16 May 2005 18:02: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 j4H12xXh050836; Mon, 16 May 2005 18:02:59 -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 j4H12w63050820 for ; Mon, 16 May 2005 18:02:58 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3876480wra for ; Mon, 16 May 2005 18:02:52 -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=SEXeVC7V0PqFJoDCEp2KGkxvyKW3TxpCEAQdRx26HifRbnkioWdxrkR+e3NIYfLTfMR4vKk1iaRvbbro+U/o/E0CWbpKl7sZpN+p2JU74TeSD4W40H2F+ORXaKL3Ch7U7qzSum82NaQfQNZBLuJSOp54MTDYEHj+6i5qtFuYpVU= Received: by 10.54.51.45 with SMTP id y45mr3995101wry; Mon, 16 May 2005 18:02:52 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 16 May 2005 18:02:52 -0700 (PDT) Message-ID: <68fba5c505051618029ef3648@mail.gmail.com> Date: Mon, 16 May 2005 21:02:52 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: extensions -- Atom NS and unprefixed attributes Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <428929E6.1050501@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> <42891E16.2040208@dehora.net> <68fba5c5050516155460ed7717@mail.gmail.com> <428929E6.1050501@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4H12w63050823 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/16/05, Bill de hra wrote: > > Too terse - I don't understand why you're asking this. But if you really > think that we allow everything we don't ban, we should say that > somewhere in the spec. hmm. I could write that Pace if you want, but maybe it would be more productive to explain why you find my interpretation "psychotic". Maybe you could point to some spec text to back up your opinion. MarkN seems to think its only this or other IETF working groups that can extend the Atom namespace. I don't see anything in the spec about that. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 16 22:34:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00874 for ; Mon, 16 May 2005 22:34: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 j4H2QRbW056680; Mon, 16 May 2005 19:26: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 j4H2QRqv056679; Mon, 16 May 2005 19:26:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H2QQO5056661 for ; Mon, 16 May 2005 19:26:26 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4H2QJ725149; Tue, 17 May 2005 11:26:20 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 63fb2ff8_c67c_11d9_9bfa_0030482532aa_28273; Tue, 17 May 2005 11:35:53 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0068D5; 17 May 05 11:29:10 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 17 May 05 11:28:46 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.59) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0068D2; 17 May 05 11:28:41 +0900 Message-Id: <6.0.0.20.2.20050516180756.06943df0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 16 May 2005 18:57:06 +0900 To: Bill de =?ISO-2022-JP?B?aBskQiViGyhCcmE=?= , atom-syntax From: Martin Duerst Subject: Re: PaceOptionalXhtmlDiv In-Reply-To: <42862924.2000407@dehora.net> References: <4285EBD8.3080405@cegetel.net> <54454D78-4196-442D-836F-D2688245185B@mac.com> <428607C9.3020407@cegetel.net> <42862924.2000407@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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 just had another idea: Why don't we use a totally different element name, rather than
? What about e.g. ? This could be pro-forma in the XHTML Namespace, but as this isn't handed over to the XHTML rendering engine (as far as I understand), it wouldn't matter. Also, it would be much easier to make optional (otherwise we get into the discussion of whether it's a wrapper div or a real div. Also, it would make things clearer to people who read the source but not the spec. Other names would of course be fine, I don't particularly care about a specific one. So we would have any of the following: A) No wrapper, none needed, because default namespace set outside This is one busted-ass document - yow!. B) No wrapper, none needed, because XHTML has prefix This is one busted-ass document - yow!. C) With wrapper This is one busted-ass document - yow!. If there is some support, I'll write a pace. Regards, Martin. At 01:36 05/05/15, Bill de h$B%b(Bra wrote: >-1 to PaceOptionalXhtmlDiv. > >If we are dealing with systems where a div wrapper is deemed neccessary, then you want to take steps to miminise people's options. > >For example, PaceOptionalXhtmlDiv will help this to occur: > > xmlns:atom="...Atom NS..." > xmlns="...XHTML NS..."> > This is one busted-ass document - yow!. > > >If you can't trust people not to need the div, then you can't make it optional. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom. > >[I disagree with Graham btw, and would say xhtml:div is actually fighting kluges with kluges, but it works more or less as specified.] From owner-atom-syntax@mail.imc.org Mon May 16 22:38:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01343 for ; Mon, 16 May 2005 22:38: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 j4H2Mtlv056209; Mon, 16 May 2005 19:22: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 j4H2MtSA056208; Mon, 16 May 2005 19:22:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.myoutlookonline.com (mx1.MyOutlookOnline.com [69.25.74.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H2Mqd9056186 for ; Mon, 16 May 2005 19:22:52 -0700 (PDT) (envelope-from anil@sixapart.com) Received: from be022.mail.lan ([10.109.209.122]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 22:22:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Autodiscovery Date: Mon, 16 May 2005 22:22:44 -0400 Message-ID: Thread-Topic: Autodiscovery Thread-Index: AcVYHgaOEPFYHE/HQrWuZdSnI+OhYQCaSChA From: "Anil Dash" To: "Kevin Marks" , Cc: "Sjoerd Visscher" , "Atom Syntax" X-OriginalArrivalTime: 17 May 2005 02:22:46.0714 (UTC) FILETIME=[507951A0:01C55A87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4H2Mqd9056201 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom- > syntax@mail.imc.org] On Behalf Of Kevin Marks > Subject: Re: Autodiscovery > > On May 6, 2005, at 12:21 PM, Bob Wyman wrote: > > > > > Sjoerd Visscher wrote: > >> [HTML 4.01 says:] This attribute describes the relationship from > >> the current document to the anchor specified by the href attribute. > >> The value of this attribute is a space-separated list of link types. Not to go *too* far off-topic, but is syndication/aggregation a media type instead of (or in combination with) merely an alternate rel type? __________________________________________________ Anil Dash +1 646 541 5843 From owner-atom-syntax@mail.imc.org Tue May 17 03:39:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18507 for ; Tue, 17 May 2005 03:39: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 j4H7OswR034634; Tue, 17 May 2005 00:24: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 j4H7OsCR034633; Tue, 17 May 2005 00:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop-a065c28.pas.sa.earthlink.net (pop-a065c28.pas.sa.earthlink.net [207.217.121.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7OpZW034614 for ; Tue, 17 May 2005 00:24:53 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from h-68-164-85-174.snvacaid.dynamic.covad.net ([68.164.85.174] helo=[10.0.1.4]) by pop-a065c28.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DXwRf-00041i-00; Tue, 17 May 2005 00:24:51 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3f7b077a21b1fc15d9d134442051ca7c@epeus.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Kevin Marks Subject: Re: PaceContentAndSummaryDistinct2 posted Date: Tue, 17 May 2005 00:24:42 -0700 To: Graham 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 -1 This is insufficiently explicit. We need to make implementers stop and think which element to use, rather than just copy/pasting their RSS generation code into both. The requirement the summary and content be different would do that; stating it unequivocally as in PaceContentAndSummaryDistinct would also. PaceContentAndSummaryDistinct2 requires them to grasp both definitions, compare them and realise that we mean them to be different from a close textual reading. On May 15, 2005, at 3:23 PM, Graham wrote: > > http://www.intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct2 > > == Abstract == > > Codify the intended use of content and summary clearly, but more > subtly than the original PaceContentAndSummaryDistinct. > > == Status == > > Newly posted > > == Rationale == > > PaceContentAndSummaryDistinct correctly point out the current > definitions are too vague: > > The "atom:summary" element is a Text construct that conveys a short > summary, abstract or excerpt of an entry. > The "atom:content" element either contains or links to the content of > the entry. > > The aim of this proposal is to use similar language in both > definitions so they can be more easily compared, especially re: the > best location of truncated content. > > == Proposal == > > In 4.2.13, replace: > The "atom:summary" element is a Text construct that conveys a short > summary, abstract or excerpt of an entry. > > with: > The "atom:summary" element is a Text construct that conveys a short > summary, abstract or excerpt (such as truncated content) of an entry. > > In 4.1.3 replace: > The "atom:content" element either contains or links to the content of > the entry > > with: > The "atom:content" element either contains or links to the full > content of the entry > > == Impacts == > > Alternate to PaceContentAndSummaryDistinct > > == Notes == > > The new wording of 4.2.13 is a bit awkward, but since truncated > content is by far the most common form of excerpt, its probably worth > mentioning specifically. > From owner-atom-syntax@mail.imc.org Tue May 17 03:44:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18851 for ; Tue, 17 May 2005 03:44: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 j4H7RPu7035695; Tue, 17 May 2005 00:27: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 j4H7RPTi035693; Tue, 17 May 2005 00:27:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop-a065c28.pas.sa.earthlink.net (pop-a065c28.pas.sa.earthlink.net [207.217.121.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7ROaI035685 for ; Tue, 17 May 2005 00:27:24 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from h-68-164-85-174.snvacaid.dynamic.covad.net ([68.164.85.174] helo=[10.0.1.4]) by pop-a065c28.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DXwU7-0004Md-00; Tue, 17 May 2005 00:27:24 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2af8a2fb57ebf80cf21b82b86c1c671a@epeus.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax , Eric Scheid From: Kevin Marks Subject: Re: nit: spaces in link@rel? Date: Tue, 17 May 2005 00:27:17 -0700 To: Graham 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 -1 This is a gratuitous variation from exisiting practice. As you may have noted from previous work, allowing multiple rel values enables a great deal of useful flexibility in HTML. On May 12, 2005, at 10:32 AM, Graham wrote: > > On 12 May 2005, at 5:23 pm, Eric Scheid wrote: > >> This is confusingly different from HTML's link@rel and should be >> fixed. > > I believe the intention is that only one value is allowed, and any > whitespace included is part of the name of the rel value. Perhaps this > should be noted in the spec. > > Or are you suggesting we adopt the HTML method? > > Graham > From owner-atom-syntax@mail.imc.org Tue May 17 04:47:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24108 for ; Tue, 17 May 2005 04:47: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 j4H8bO7N059318; Tue, 17 May 2005 01:37: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 j4H8bOoU059314; Tue, 17 May 2005 01:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4H8bNLx059253 for ; Tue, 17 May 2005 01:37:24 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 47174 messnum 2898465 invoked from network[213.94.211.166/dev2.mcpps.com]); 17 May 2005 08:37:17 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail06.svc.cra.dublin.eircom.net (qp 47174) with SMTP; 17 May 2005 08:37:17 -0000 Message-ID: <4289AD3A.8000707@dehora.net> Date: Tue, 17 May 2005 09:37:14 +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: Robert Sayre CC: Tim Bray , Paul Hoffman , Atom Syntax Subject: Re: extensions -- Atom NS and unprefixed attributes References: <68fba5c50505091852aee94ab@mail.gmail.com> <4288F560.4010601@dehora.net> <68fba5c505051612425e783a8a@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> <42891E16.2040208@dehora.net> <68fba5c5050516155460ed7717@mail.gmail.com> <428929E6.1050501@dehora.net> <68fba5c505051618029ef3648@mail.gmail.com> In-Reply-To: <68fba5c505051618029ef3648@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/16/05, Bill de hra wrote: > >>Too terse - I don't understand why you're asking this. But if you really >>think that we allow everything we don't ban, we should say that >>somewhere in the spec. > > > hmm. I could write that Pace if you want, but maybe it would be more > productive to explain why you find my interpretation "psychotic". Because it's an interpretation that cares not for others. I could ask if you could maybe explain why that was more a productive direction, but isn't this getting silly now? > Maybe you could point to some spec text to back up your opinion. Postel's law. > MarkN > seems to think its only this or other IETF working groups that can > extend the Atom namespace. I don't see anything in the spec about > that. Let's agree I made an error of judgement in my characterisation and call your interpretation something neutral instead - "interpretation-x". As I've withdrawn 'psychotic' I think it's reasonable to say we can stop quibbling and move on. The point remains - if you think interpretation-x is valid way of systematically evaluating the spec, then there is room to discuss whether we should make mention of it. Will you address now whether we should mention or approve that interpretation in the spec? cheers Bill From owner-atom-syntax@mail.imc.org Tue May 17 09:56:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25170 for ; Tue, 17 May 2005 09:56: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 j4HDjKWx058631; Tue, 17 May 2005 06:45: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 j4HDjKMi058630; Tue, 17 May 2005 06:45:20 -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 j4HDjJYU058622 for ; Tue, 17 May 2005 06:45:19 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:50237 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228759AbVEQNpR (ORCPT ); Tue, 17 May 2005 16:45:17 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <68fba5c505051615353723dded@mail.gmail.com> References: <68fba5c505051615353723dded@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3c2a278b6ebec2da7b8cfc9543eece06@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: PaceOtherVocabularies Date: Tue, 17 May 2005 16:45:00 +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 May 17, 2005, at 01:35, Robert Sayre wrote: > Markup from other vocabularies ("foreign markup") can be used in an > Atom document, > but MUST be namespace-qualified and in a namespace other than Atom's. Surely attributes on extension elements don't need to be ns-qualified? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue May 17 10:31:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00174 for ; Tue, 17 May 2005 10:31: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 j4HEMJuH061563; Tue, 17 May 2005 07:22: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 j4HEMJOp061562; Tue, 17 May 2005 07:22: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HEMHh1061548 for ; Tue, 17 May 2005 07:22:18 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4304415wra for ; Tue, 17 May 2005 07:22: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=p/MfIpVb3+hHCn/QTyvPJ5iWtMocno217VhfgnDnF79SBUc+6ca1PCOT8VmFue20EnEKSsbZhcx1qQdsRk70n53+IQHEC2VYuuZ/NPvtlOeSs5A5ck/lawgp/mjB/NzENHgXCXOHJ8R/39sPu7TFIau9D7yq+ugiM1ZlAVawe3g= Received: by 10.54.50.46 with SMTP id x46mr2707112wrx; Tue, 17 May 2005 07:22:12 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 17 May 2005 07:22:12 -0700 (PDT) Message-ID: <68fba5c505051707221dff5eba@mail.gmail.com> Date: Tue, 17 May 2005 10:22:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Change Control (was: extensions -- Atom NS and unprefixed attributes) Cc: Tim Bray , Paul Hoffman , Atom Syntax In-Reply-To: <4289AD3A.8000707@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505091852aee94ab@mail.gmail.com> <4289024A.80504@dehora.net> <68fba5c50505161414468bf2d7@mail.gmail.com> <428913E5.2040400@dehora.net> <68fba5c505051614533c0a773f@mail.gmail.com> <42891E16.2040208@dehora.net> <68fba5c5050516155460ed7717@mail.gmail.com> <428929E6.1050501@dehora.net> <68fba5c505051618029ef3648@mail.gmail.com> <4289AD3A.8000707@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4HEMIh1061552 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/17/05, Bill de hra wrote: > > > Maybe you could point to some spec text to back up your opinion. > > Postel's law. My concern is about change control, not processing. We have an elaborate system for controlling additions to the list of link relations. Why aren't we more explicit with element names in the Atom namespace? I don't particularly care which strategy we settle on, but it's important to be clear. Do we have a situation similar to HTTP headers and methods, where you can extend it as needed, but you had better 'coordinate' if you want to make sure everyone interprets it the same way? That's fine. Or do we have an IETF-administered registry? If we do settle on the looser approach for elements, I suggest we drop the link registry and go with the space-separated lists allowed by HTML. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 17 10:56:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03209 for ; Tue, 17 May 2005 10: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 j4HElhHZ070956; Tue, 17 May 2005 07:47: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 j4HElhIT070955; Tue, 17 May 2005 07:47:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HElgmf070837 for ; Tue, 17 May 2005 07:47: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 (rwcrmhc14) with SMTP id <2005051714473701400c67ape>; Tue, 17 May 2005 14:47:37 +0000 Date: Tue, 17 May 2005 08:47:31 -0600 Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) 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: <68fba5c505051707221dff5eba@mail.gmail.com> Message-Id: <992938A8-C6E2-11D9-8AA1-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 Tuesday, May 17, 2005, at 08:22 AM, Robert Sayre wrote: > Do we have a situation similar to HTTP headers and methods, where you > can extend it as needed, but you had better 'coordinate' if you want > to make sure everyone interprets it the same way? That's fine. Or do > we have an IETF-administered registry? > XML namespaces create a middle road between the two--anyone can add elements to an XML document without fear of naming collisions because XML has a built-in coordination method. What possible advantage would there be to allowing just anyone to add elements to Atom's namespace, or any other namespace, for that matter? I can't think of any. In my opinion, alteration of a namespace by anyone other than the entity that created it, or someone authorized by its creator, would completely violate the nature of namespaces. I wouldn't think it would be necessary to spell that out explicitly, but since obviously not everyone agrees, we may as well do so. So I'd say we have an IETF-administered registry. From owner-atom-syntax@mail.imc.org Tue May 17 12:08:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09940 for ; Tue, 17 May 2005 12:08: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 j4HFxxmG094124; Tue, 17 May 2005 08:59: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 j4HFxxkm094123; Tue, 17 May 2005 08:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HFxwnO094116 for ; Tue, 17 May 2005 08:59:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4HFwFMK002059; Tue, 17 May 2005 16:58:15 +0100 (BST) In-Reply-To: <3c2a278b6ebec2da7b8cfc9543eece06@iki.fi> References: <68fba5c505051615353723dded@mail.gmail.com> <3c2a278b6ebec2da7b8cfc9543eece06@iki.fi> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D242B6A-EB1F-413A-9A71-15E0EF643EB6@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOtherVocabularies Date: Tue, 17 May 2005 16:58:16 +0100 To: Henri Sivonen X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 May 2005, at 2:45 pm, Henri Sivonen wrote: >> Markup from other vocabularies ("foreign markup") can be used in >> an Atom document, >> but MUST be namespace-qualified and in a namespace other than Atom's. > > Surely attributes on extension elements don't need to be ns-qualified? Yes, although extension attributes on Atom elements do need to be. Graham From owner-atom-syntax@mail.imc.org Tue May 17 12:08:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10001 for ; Tue, 17 May 2005 12:08: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 j4HFwYwU094046; Tue, 17 May 2005 08:58: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 j4HFwYnV094045; Tue, 17 May 2005 08:58:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HFwXh7094007 for ; Tue, 17 May 2005 08:58:33 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4HFv0q7001432; Tue, 17 May 2005 16:57:05 +0100 (BST) In-Reply-To: <992938A8-C6E2-11D9-8AA1-003065EA6144@geckotribe.com> References: <992938A8-C6E2-11D9-8AA1-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) Date: Tue, 17 May 2005 16:57:00 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 May 2005, at 3:47 pm, Antone Roundy wrote: > XML namespaces create a middle road between the two--anyone can add > elements to an XML document without fear of naming collisions > because XML has a built-in coordination method. What possible > advantage would there be to allowing just anyone to add elements to > Atom's namespace, or any other namespace, for that matter? I can't > think of any. In my opinion, alteration of a namespace by anyone > other than the entity that created it, or someone authorized by its > creator, would completely violate the nature of namespaces. I > wouldn't think it would be necessary to spell that out explicitly, > but since obviously not everyone agrees, we may as well do so. > > So I'd say we have an IETF-administered registry. Put me in the "Only those elements defined in IETF RFCs may use the Atom namespace" column. Graham From owner-atom-syntax@mail.imc.org Tue May 17 12:32:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12977 for ; Tue, 17 May 2005 12:32: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 j4HGKTZP095872; Tue, 17 May 2005 09:20: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 j4HGKTAJ095871; Tue, 17 May 2005 09:20:29 -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 j4HGKRBW095865 for ; Tue, 17 May 2005 09:20:28 -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); Wed, 18 May 2005 02:17:04 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 18 May 2005 02:16:55 +1000 Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) 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 18/5/05 1:57 AM, "Graham" wrote: > Put me in the "Only those elements defined in IETF RFCs may use the > Atom namespace" column. +1 From owner-atom-syntax@mail.imc.org Tue May 17 13:38:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19297 for ; Tue, 17 May 2005 13:38: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 j4HHVReE007519; Tue, 17 May 2005 10:31: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 j4HHVRSG007518; Tue, 17 May 2005 10:31:27 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HHVPJc007486 for ; Tue, 17 May 2005 10:31:26 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.49.121]) by smtp.cegetel.net (Postfix) with ESMTP id 7A1671A426A for ; Tue, 17 May 2005 19:30:50 +0200 (CEST) Message-ID: <428A2A64.4080307@cegetel.net> Date: Tue, 17 May 2005 19:31:16 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) 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 18/5/05 1:57 AM, "Graham" wrote: > > > >>Put me in the "Only those elements defined in IETF RFCs may use the >>Atom namespace" column. >> >> > >+1 > > > +1 as well -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 17 20:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06242 for ; Tue, 17 May 2005 20: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 j4I03rfH088647; Tue, 17 May 2005 17:03: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 j4I03r8a088645; Tue, 17 May 2005 17:03:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I03pe4088636 for ; Tue, 17 May 2005 17:03:52 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050518000341.ROEI9046.mta09-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Wed, 18 May 2005 01:03:41 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050518000341.SFYO1279.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 18 May 2005 01:03:41 +0100 Date: Wed, 18 May 2005 01:03:38 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <562902089.20050518010338@djpowell.net> To: Graham CC: atom-syntax Subject: Re: PaceAllowDuplicateIdsWithModified In-Reply-To: References: 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 Monday, May 16, 2005, 5:39:17 PM, Graham wrote: > On 16 May 2005, at 5:16 pm, Eric Scheid wrote: >> if you want to sort by updated or published, but not for most recently >> changed (even if not 'significantly') > Well yes. So? I consider atom:modified to be unfeasible anyway for > all sorts of reasons, so we're not losing any capability here. Can you explain some? I don't see atom:version would be more feasible. atom:version doesn't support some cases that atom:modified does, and it doesn't really seem easier to explain in the spec or implement. Are you thinking of some scenarios where a publisher wouldn't be able to produce a modified date, but would be able to produce a version? - or do you mean it wouldn't be feasible for other non-technical reasons? -- Dave From owner-atom-syntax@mail.imc.org Tue May 17 20:21:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06765 for ; Tue, 17 May 2005 20:21: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 j4I0CZc9090095; Tue, 17 May 2005 17:12: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 j4I0CZ3b090094; Tue, 17 May 2005 17:12:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0CXV0090067 for ; Tue, 17 May 2005 17:12:34 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050518001228.XFQB12530.mta13-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Wed, 18 May 2005 01:12:28 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050518001228.XDL1280.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 18 May 2005 01:12:28 +0100 Date: Wed, 18 May 2005 01:12:26 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1934120815.20050518011226@djpowell.net> To: Sam Ruby CC: atom-syntax Subject: Re: PaceAllowDuplicateIdsWithModified In-Reply-To: <42887EEB.9040202@intertwingly.net> References: <12336714.20050515231212@djpowell.net> <07BEEFD6-3E0B-425E-A943-74EF180BA573@mac.com> <42887EEB.9040202@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 Monday, May 16, 2005, 12:07:23 PM, Sam Ruby wrote: > 3) Perhaps version/modified need not be mandatory except in those > instances where entries with duplicate ids are present in a feed? If we want to support the cases of aggregating multiple feeds and of full archiving (other than by the publisher), then it needs to be mandatory doesn't it? The subscriber/archiver may be a different entity than the publisher; if the publisher doesn't provide modified/version, then what is the subscriber supposed to do? -- Dave From owner-atom-syntax@mail.imc.org Tue May 17 20:41:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09242 for ; Tue, 17 May 2005 20: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 j4I0XF37096715; Tue, 17 May 2005 17:33: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 j4I0XFCX096714; Tue, 17 May 2005 17:33:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0XExn096678 for ; Tue, 17 May 2005 17:33:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4I0WJqU015159; Wed, 18 May 2005 01:32:24 +0100 (BST) In-Reply-To: <562902089.20050518010338@djpowell.net> References: <562902089.20050518010338@djpowell.net> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F2E7FEF-5DFA-4420-A41B-1D50108E5479@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Wed, 18 May 2005 01:32:21 +0100 To: David Powell X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 1:03 am, David Powell wrote: > Can you explain some? I don't see atom:version would be more feasible. > atom:version doesn't support some cases that atom:modified does, and > it doesn't really seem easier to explain in the spec or implement. The first problem is that not all systems track a modified date. If you're obtaining entries using an API on a closed system, and the system doesn't supply a modified date for whatever data you're syndicating, you're screwed. The second problem is that "modification" is an incredibly hard thing to pin down, eg: - I modify my atom-generating script to change which optional elements are included. Does the modification date change? - I modify my atom-generating script to change the order elements appear in. Does the modification date change? - I change the location of my entries, and therefore the atom:link element values. Does the modification date change? - I change the location of my entries, and therefore the xml:base attribute on a parent element. Does the modification date change? - I change the email address of an entry's author, but not the entry itself. Does the modification date change? etc etc Don't bother answering yes or no to any of these here. The point is that even if you do pin down exactly which count as modifications, you have to demonstrate it can easily be implemented and tracked exactly that way on the average CMS (Note adding new columns to the database may not be possible). Graham From owner-atom-syntax@mail.imc.org Wed May 18 00:28:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24286 for ; Wed, 18 May 2005 00:28: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 j4I4DeYu041903; Tue, 17 May 2005 21:13: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 j4I4Dewp041902; Tue, 17 May 2005 21:13:40 -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 j4I4Ddxi041896 for ; Tue, 17 May 2005 21:13:39 -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 j4I4Dd0R007994 for ; Tue, 17 May 2005 22:13:39 -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 <0IGO002I73QQXQ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 17 May 2005 22:13:39 -0600 (MDT) Received: from [10.6.31.225] ([206.17.140.111]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGO00AF43QQTI@mail.sun.net> for atom-syntax@imc.org; Tue, 17 May 2005 22:13:38 -0600 (MDT) Date: Tue, 17 May 2005 21:13:37 -0700 From: Tim Bray Subject: Consensus call on last raft of issues To: Atom Syntax Message-id: <7518fb35fb3952de6590df9581989685@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4I4Ddxi041897 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On behalf of Paul and myself. Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList The volume of correspondence was unfortunately high for an IETF Last Call that came after a Working Group Last call. It is quite possible, as always, that the co-chairs have mis-read the consensus of the group on one or more issues; in which case please push back. We can work on this as long as is needed, and given the passion (and, in some cases, intransigence) we have seen so far, we do not expect to reach unanimity. When you respond to any of these readings of consensus, please do so with the intention of helping the chairs figure out whether or not we have determined consensus, not just to state an opinion one way or another. Thanks! ======================================================== PaceAllowDuplicateIDs We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has been mostly against, but a close reading of his posts make it clear that his issue is in large part with atom:updated, he remains convinced that readers desire notification of every change however minor and are unwilling to trust publishers' opinions as expressed in atom:updated. He could live with this Pace if we re-introduced atom:modified or inserted wording in the spec emphasizing that if multiple entries with the same atom:id appear in a feed, software must treat them as XXX of the same entry; there was lively debate as to whether XXX was "versions", "instantiations", or "representations". Conclusion: The Pace is accepted. The editors are directed to modify the phrase which starts "If multiple atom:entry elements..." as follows: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." ================================ PaceAlternateLinkWeakening Only one +1, not good enough, it fails. ================================ PaceBriefExample Two +1's, seems awfully uncontroversial, verging on editorial, accepted unless someone shouts. =============================== PaceCaching Multiple -1's, it fails. ================================= PaceCoConstraintsAreBad Obsoleted. Rejected. ============================ PaceContentAndSummaryDistinct This was modified in the course of debate. It can't be accepted because the +1's (and -1's too) were referring to multiple different wordings and there were three pretty strong -1's. Conclusion: The editors are asked to strengthen the language in the draft that emphasizes the difference in intended purpose between content and summary. This can be done by adding a sentence to 4.2.13 that says "The text in atom:summary should not be identical to the text in atom:content or identical to the text in atom:title." However, this might have gained consensus if it were stable. If a bunch of voices get behind a single version in the next 72 hours and win the hearts of the -1's, the door is open. ============================= PaceContentAndSummaryDistinct2 One each +1 and -1, hardly consensus. Rejected. ========================== PaceDuplicateIDWithModified A handful of +1's, one -1. The consensus of the group against atom:modified months and months ago was quite strong and this is not enough momentum to accomplish such a major policy reversal. Rejected. =========================== PaceDuplicateIDWithSource PaceDuplicateIDWithSource2 A couple of -1's, no support, rejected. =============================== PaceEntryState Rejected, no support. ================================= PaceExplainDuplicateIDs Only one +1 but once again, uncontroversial, mostly editorial, accepted unless someone squawks. ================================ PaceFeedIdOrAlternate No postings. Rejected. ===================== PaceFeedIdOrSelf Reworded in progress, too many -1's, rejected. ============================= PaceNoAlternativeForFeed Only one +1 from its author, it fails. ============================= PaceOptionalFeedLink Lots of +1's, moderate objections from Ruby, accepted. ================================== PaceOptionalSummary There is a massive amount of support, with two clear -1's. Several of the +1's could see a case for a SHOULD, hence PaceTextShouldBeProvided (see below). This Pace has rough consensus support and is accepted. ================================ PaceOptionalXhtmlDiv A handful of -1's, no support, rejected. =============================== PaceOriginalAttribute Number of +1's and -1's approximately equal, plus Ruby pointed out some wording problems. Rejected. ================================ PacePubControl Some opposition, but out-of-scope for data format draft. Send back for reconsideration in protocol context. ================================ PacePubStatusResource Send back for reconsideration in protocol context. ================================ PaceRecommendPlainTextContent Multiple -1's, no support, it fails. =============================== PaceRenameImageToLogo A handful of +1's no objections, accepted. ================================= PaceSourceRec One -1, not enough defense, rejected. ====================== PaceTextShouldBeProvided +1 from Ruby, explicit -1's from Sayre and de hra. However, taking this and PaceOptionalSummary together, it seems clear that the WG generally believes the following: - Title-only feeds are OK for data where that's really all you have. - Failing to provide summaries when they could potentially exist is regrettable and should be discouraged. - There are certain classes of software which will not be able to make use of content-light feeds, for example full-text indexers. - It is not acceptable for software to fail (note "fail", as opposed to "not make full use of") just because the summary is missing. There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is an appropriate level of language to use in encouraging the provision of summaries. Conclusion: This Pace is rejected. However, the editors are directed to include the following text in 4.2.13: "Experience teaches that feeds which contain textual content are in general more useful than those which do not. There are certain classes of application, for example full-text indexers, which will be unable to make effective use of entries which do not contain text in either atom:summary or atom:content. Feed producers should be aware of these issues and are encouraged to include a meaningful atom:summary in entries lacking atom:content wherever possible. However, the absence of atom:summary is not an error and software MUST NOT fail to function correctly as a consequence of such an absence." ===================== Change atom:copyright to atom:rights Two -1's but many many +1's. Accepted. From owner-atom-syntax@mail.imc.org Wed May 18 00:47:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25703 for ; Wed, 18 May 2005 00:47: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 j4I4WMwo045800; Tue, 17 May 2005 21: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 j4I4WMxc045799; Tue, 17 May 2005 21:32:22 -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 j4I4WLwx045793 for ; Tue, 17 May 2005 21:32:21 -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 j4I4WFjO012476 for ; Tue, 17 May 2005 22:32:20 -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 <0IGO004WP4LQ4K@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 17 May 2005 22:32:15 -0600 (MDT) Received: from [10.6.31.225] ([206.17.140.111]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGO00AGR4LQTI@mail.sun.net> for atom-syntax@imc.org; Tue, 17 May 2005 22:32:14 -0600 (MDT) Date: Tue, 17 May 2005 21:32:13 -0700 From: Tim Bray Subject: Posted PaceAtom10 To: Atom Syntax Message-id: <4f4ee116aa3e21595619e245f90cdf83@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) 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 See http://www.intertwingly.net/wiki/pie/PaceAtom10 For our final issue discussion, let's has out what language changes we need to license us to go out and shout "Atom 1.0" at the world. Improvements to this proposal gratefully received. -Tim From owner-atom-syntax@mail.imc.org Wed May 18 01:12:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27848 for ; Wed, 18 May 2005 01:12: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 j4I51t6I051737; Tue, 17 May 2005 22: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 j4I51tUD051735; Tue, 17 May 2005 22:01:55 -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 j4I51rs0051696 for ; Tue, 17 May 2005 22:01:55 -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, 18 May 2005 15:01:58 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 18 May 2005 15:01:48 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <7F2E7FEF-5DFA-4420-A41B-1D50108E5479@mac.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 18/5/05 10:32 AM, "Graham" wrote: > The first problem is that not all systems track a modified date. If > you're obtaining entries using an API on a closed system, and the > system doesn't supply a modified date for whatever data you're > syndicating, you're screwed. Not so very long ago you suggested that aggregators look at the content to determine if it's changed. If it's good enough for aggregators, it's good enough for publishers (actually better than good enough since the publisher would be able to do the test before other transformations occur, thus eliminating some false positives). > - I modify my atom-generating script to change which optional > elements are included. Does the modification date change? > - I modify my atom-generating script to change the order elements > appear in. Does the modification date change? > - I change the location of my entries, and therefore the atom:link > element values. Does the modification date change? > - I change the location of my entries, and therefore the xml:base > attribute on a parent element. Does the modification date change? > - I change the email address of an entry's author, but not the entry > itself. Does the modification date change? Some of these are format level changes, which would also include - the publisher changes the text encoding - the publisher starts using xml:base and relative references, but without changing the fully resolved location of hrefs Some are content changes, or metadata changes. One suggests a problem with the object model. > Don't bother answering yes or no to any of these here. ok, I won't. > The point is that even if you do pin down exactly which count as > modifications, you have to demonstrate it can easily be implemented and > tracked exactly that way on the average CMS (Note adding new columns to the > database may not be possible). which is more likely to be supported by the average CMS? an automated date stamp of last modification a user selectable date stamp of last "significant" update According to http://www.intertwingly.net/wiki/pie/BlogToolDateSurvey it appears that the former is already well supported. e. From owner-atom-syntax@mail.imc.org Wed May 18 01:15:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28044 for ; Wed, 18 May 2005 01:15: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 j4I57bNu054602; Tue, 17 May 2005 22:07: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 j4I57bLK054601; Tue, 17 May 2005 22:07:37 -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 j4I57amL054591 for ; Tue, 17 May 2005 22:07:36 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.107] (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 j4I59ANU031930; Wed, 18 May 2005 01:09:11 -0400 Message-ID: <428ACD94.4070108@intertwingly.net> Date: Wed, 18 May 2005 01:07:32 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> In-Reply-To: <7518fb35fb3952de6590df9581989685@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: > > On behalf of Paul and myself. > > Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList > > The volume of correspondence was unfortunately high for an IETF Last > Call that came after a Working Group Last call. It is quite possible, > as always, that the co-chairs have mis-read the consensus of the group > on one or more issues; in which case please push back. > > We can work on this as long as is needed, and given the passion (and, in > some cases, intransigence) we have seen so far, we do not expect to > reach unanimity. When you respond to any of these readings of consensus, > please do so with the intention of helping the chairs figure out whether > or not we have determined consensus, not just to state an opinion one > way or another. Thanks! There is a danger of looking at changes in isolation. I will point out two instances that jump out at me. There may be more. > ======================================================== > > PaceAllowDuplicateIDs > > We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre > was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has > been mostly against, but a close reading of his posts make it clear that > his issue is in large part with atom:updated, he remains convinced that > readers desire notification of every change however minor and are > unwilling to trust publishers' opinions as expressed in atom:updated. > He could live with this Pace if we re-introduced atom:modified or > inserted wording in the spec emphasizing that if multiple entries with > the same atom:id appear in a feed, software must treat them as XXX of > the same entry; there was lively debate as to whether XXX was > "versions", "instantiations", or "representations". > > Conclusion: The Pace is accepted. The editors are directed to modify > the phrase which starts "If multiple atom:entry elements..." as follows: > > "If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry and software MUST > treat them as such." IIRC, much of this started due to an objection by Bob Wyman that treating atom:entries from different sources with the same atom:id as the same entry would cause problems for PubSub. What ever happened to that objection? Also, it seemed to me that much of the discussion centered around distinguishing between multiple versions. Reintroducing modified was rejected, and atom:version never made it into a pace, but should there be some hint (perhaps non-normative) that software should look to atom:updated to resolve collisions? > ============================= > > PaceOptionalFeedLink > > Lots of +1's, moderate objections from Ruby, accepted. http://www.imc.org/atom-syntax/mail-archive/msg14896.html If feed link becomes optional, there is nothing to anchor atom:source elements, which relates back to Bob's objection above. > ============================= Finally, I'm not sure what the next step is, but some determination of consensus on extensibility (also referred to as change control) is needed. There does seem to be a lot of voices in support of the following statement: Only those elements defined in IETF RFCs may use the Atom namespace - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 01:24:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28545 for ; Wed, 18 May 2005 01:24: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 j4I5FppO058925; Tue, 17 May 2005 22:15: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 j4I5FpZM058924; Tue, 17 May 2005 22:15:51 -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 j4I5FoL3058912 for ; Tue, 17 May 2005 22:15:50 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.107] (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 j4I5HO4J000480; Wed, 18 May 2005 01:17:24 -0400 Message-ID: <428ACF85.8000506@intertwingly.net> Date: Wed, 18 May 2005 01:15:49 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> In-Reply-To: <7518fb35fb3952de6590df9581989685@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > > > PaceTextShouldBeProvided > > +1 from Ruby, explicit -1's from Sayre and de hra. However, taking > this and PaceOptionalSummary together, it seems clear that the WG > generally believes the following: > > - Title-only feeds are OK for data where that's really all you have. > - Failing to provide summaries when they could potentially exist is > regrettable and should be discouraged. > - There are certain classes of software which will not be able to make > use of content-light feeds, for example full-text indexers. > - It is not acceptable for software to fail (note "fail", as opposed to > "not make full use of") just because the summary is missing. > > There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is > an appropriate level of language to use in encouraging the provision of > summaries. > > Conclusion: This Pace is rejected. However, the editors are directed to > include the following text in 4.2.13: > > "Experience teaches that feeds which contain textual content are in > general more useful than those which do not. There are certain classes > of application, for example full-text indexers, which will be unable to > make effective use of entries which do not contain text in either > atom:summary or atom:content. Feed producers should be aware of these > issues and are encouraged to include a meaningful atom:summary in > entries lacking atom:content wherever possible. However, the absence of > atom:summary is not an error and software MUST NOT fail to function > correctly as a consequence of such an absence." Much of the discussion of this pace centered around the proposed changes to section 4.1.2. However, there is more to this pace. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 05:51:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27647 for ; Wed, 18 May 2005 05:51: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 j4I9gTXh090486; Wed, 18 May 2005 02:42: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 j4I9gTV6090485; Wed, 18 May 2005 02:42:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I9gSVL090437 for ; Wed, 18 May 2005 02:42:28 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4I9fi2I007309; Wed, 18 May 2005 10:41:49 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E14FA9B-24D9-4DD1-AF4E-4AA7987572E4@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAllowDuplicateIdsWithModified Date: Wed, 18 May 2005 10:41:42 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 6:01 am, Eric Scheid wrote: > Not so very long ago you suggested that aggregators look at the > content to > determine if it's changed. If it's good enough for aggregators, > it's good > enough for publishers (actually better than good enough since the > publisher > would be able to do the test before other transformations occur, thus > eliminating some false positives). But if the publisher does that, atom:modified is going to end up being the date the atom-generating program is run rather than the date the modification happened. You may argue that functionally this doesn't matter, and you'd be right. You'd also be admitting that the absolute date is not important, as long as the dates are in the right order - aka atom:version. > Some are content changes, or metadata changes. I see no discussion of this distinction in the atom:modified proposal. > an automated date stamp of last modification > a user selectable date stamp of last "significant" update atom:updated does not have to be user selectable. It's perfectly valid to leave it as the first publishing date, or to use a last modification date. (Not that either of these are useful - I think atom:updated should be optional, but Tim doesn't listen) Graham From owner-atom-syntax@mail.imc.org Wed May 18 06:51:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04399 for ; Wed, 18 May 2005 06:51: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 j4I8lt7m070070; Wed, 18 May 2005 01:47: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 j4I8lt2s070069; Wed, 18 May 2005 01:47:55 -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 j4I8lsVl070028 for ; Wed, 18 May 2005 01:47:55 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 2313 messnum 7061217 invoked from network[213.94.211.166/dev2.mcpps.com]); 18 May 2005 08:47:48 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail01.svc.cra.dublin.eircom.net (qp 2313) with SMTP; 18 May 2005 08:47:48 -0000 Message-ID: <428B0131.2070604@dehora.net> Date: Wed, 18 May 2005 09:47:45 +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: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> In-Reply-To: <7518fb35fb3952de6590df9581989685@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: > Conclusion: This Pace is rejected. However, the editors are directed to > include the following text in 4.2.13: > > "Experience teaches that feeds which contain textual content are in > general more useful than those which do not. There are certain classes > of application, for example full-text indexers, which will be unable to > make effective use of entries which do not contain text in either > atom:summary or atom:content. Feed producers should be aware of these > issues and are encouraged to include a meaningful atom:summary in > entries lacking atom:content wherever possible. However, the absence of > atom:summary is not an error and software MUST NOT fail to function > correctly as a consequence of such an absence." +1 cheers Bill From owner-atom-syntax@mail.imc.org Wed May 18 08:29:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12505 for ; Wed, 18 May 2005 08: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 j4ICGLcB050677; Wed, 18 May 2005 05:16: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 j4ICGLne050675; Wed, 18 May 2005 05:16: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ICGK6Y050610 for ; Wed, 18 May 2005 05:16:21 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so351429wri for ; Wed, 18 May 2005 05:16:15 -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=ozIzSWKATehcCj5YRSLP0sgyxrcVV/UxE3ILeKjl3mqCgRfKUpS/V2PQAvq0PRJekyn+++t9R/FTHGOt3e0DMgtRk6jpDdxN0QFCaZY1iLcs7+IaLPX14SLmnSLNchE1PWu6urx39Zhnjjgi7tyE/C7uEkmSeCxrcDBBrQclaw0= Received: by 10.54.49.38 with SMTP id w38mr407000wrw; Wed, 18 May 2005 05:16:15 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Wed, 18 May 2005 05:16:15 -0700 (PDT) Message-ID: <540e37320505180516156a5569@mail.gmail.com> Date: Wed, 18 May 2005 07:16:15 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: PaceAllowDuplicateIdsWithModified In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <12336714.20050515231212@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ICGL6Y050667 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > There was opposition to atom:modified because we couldn't see a need for it. > Now we have a need for it. Eric: That most definitely wasn't the core reason for opposition, to my recollection. It was opposed because it can't be reliably produced by existing systems, among other things. (See the wiki for a survey of tools and the dates they support.) A big -1 for any pace that depends upon a mandatory atom:modified. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed May 18 10:54:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28509 for ; Wed, 18 May 2005 10: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 j4IEfKQZ090441; Wed, 18 May 2005 07:41: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 j4IEfKqC090440; Wed, 18 May 2005 07:41:20 -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 j4IEfJ78090424 for ; Wed, 18 May 2005 07:41:19 -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 <2005051814411101100itth0e>; Wed, 18 May 2005 14:41:11 +0000 Date: Wed, 18 May 2005 08:41:09 -0600 Subject: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues) 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: <428ACD94.4070108@intertwingly.net> 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 Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote: >> "If multiple atom:entry elements with the same atom:id value appear >> in an Atom Feed document, they describe the same entry and software >> MUST treat them as such." > > IIRC, much of this started due to an objection by Bob Wyman that > treating atom:entries from different sources with the same atom:id as > the same entry would cause problems for PubSub. What ever happened to > that objection? This is the one remaining issue I'm aware of that I think we really need to resolve. Until mankind evolves to the point that DOS attacks are no longer attempted, we need to try to protect against them. A MUST here goes beyond just allowing DOS attacks, it's practically an invitation: copy the target entry, increment atom:updated, change a few critical details, publish. How can an aggregator protect against this without violating the spec? An oddity this language introduces is that if the entries don't appear in the same Atom Feed Document, they apparently don't have to be treated as the same entry, but if they're aggregated together, they do. Going a little further, if I'm subscribed to both original feeds and an aggregation that includes both, then I have potentially four s with the same id. Which are the same entry and which aren't? Only the two in the aggregation, which really aren't, are required to be treated as the same. From owner-atom-syntax@mail.imc.org Wed May 18 11:25:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01591 for ; Wed, 18 May 2005 11: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 j4IFCJaN094052; Wed, 18 May 2005 08:12: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 j4IFCJUx094051; Wed, 18 May 2005 08:12:19 -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 j4IFCJxv094039 for ; Wed, 18 May 2005 08:12:19 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 72038 invoked by uid 17064); 18 May 2005 15:12:14 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.229.162]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 18 May 2005 15:12:14 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D2958E6-7356-467A-83B1-E63AEDA6B524@bblfish.net> Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues) Date: Wed, 18 May 2005 17:12:08 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 16:41, Antone Roundy wrote: > On Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote: > >>> "If multiple atom:entry elements with the same atom:id value >>> appear in an Atom Feed document, they describe the same entry and >>> software MUST treat them as such." >>> >> >> IIRC, much of this started due to an objection by Bob Wyman that >> treating atom:entries from different sources with the same atom:id >> as the same entry would cause problems for PubSub. What ever >> happened to that objection? >> > > This is the one remaining issue I'm aware of that I think we really > need to resolve. Until mankind evolves to the point that DOS > attacks are no longer attempted, we need to try to protect against > them. A MUST here goes beyond just allowing DOS attacks, it's > practically an invitation: copy the target entry, increment > atom:updated, change a few critical details, publish. How can an > aggregator protect against this without violating the spec? I supposed the surest way to make it impossible to fake the id, is to specify that by dereferencing the id and doing a GET (whatever the correct method of doing that for the protocol happens to be) one should be able to retrieve the entry. This I know goes against some of the hopes built into id, but I think that it may be that this is the cost of working in on the web. You just can't escape REST. > An oddity this language introduces is that if the entries don't > appear in the same Atom Feed Document, they apparently don't have > to be treated as the same entry, but if they're aggregated > together, they do. Going a little further, if I'm subscribed to > both original feeds and an aggregation that includes both, then I > have potentially four s with the same id. Which are the > same entry and which aren't? Only the two in the aggregation, > which really aren't, are required to be treated as the same. I always thought that two entries with the same id should be treated as the same entry. What makes you thing otherwise? Henry Story http://bblfish.net/blog/ From owner-atom-syntax@mail.imc.org Wed May 18 11:35:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02601 for ; Wed, 18 May 2005 11:35: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 j4IFOaiP096195; Wed, 18 May 2005 08:24: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 j4IFOanH096194; Wed, 18 May 2005 08:24: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 j4IFOYet096173 for ; Wed, 18 May 2005 08:24:35 -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); Thu, 19 May 2005 01:11:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 May 2005 01:11:21 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0E14FA9B-24D9-4DD1-AF4E-4AA7987572E4@mac.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 18/5/05 7:41 PM, "Graham" wrote: >> Some are content changes, or metadata changes. > > I see no discussion of this distinction in the atom:modified proposal. I meant "content or metadata changes". I don't care so much about the distinction between those two senses. I was however making a distinction between those and representation/format changes. The atom:modified proposal refers to changes in "the entry", not changes in "atom:entry". Subtle, I know. > atom:updated does not have to be user selectable. It's perfectly > valid to leave it as the first publishing date, or to use a last > modification date. > > (Not that either of these are useful and one is actively harmful, in the sense of being polluting. >I think atom:updated should be optional, but Tim doesn't listen) the problem is that if atom:updated is optional we then have to spec the fall-back precedence for when it is missing, and also spec what it means if an entry had atom:updated, but is then published without atom:updated. can of worms. e. From owner-atom-syntax@mail.imc.org Wed May 18 11:35:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02619 for ; Wed, 18 May 2005 11:35: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 j4IFOaXQ096206; Wed, 18 May 2005 08:24: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 j4IFOaZd096203; Wed, 18 May 2005 08:24: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 j4IFOZTO096187 for ; Wed, 18 May 2005 08:24:36 -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); Thu, 19 May 2005 01:12:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 May 2005 01:12:22 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <540e37320505180516156a5569@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 18/5/05 10:16 PM, "Roger B." wrote: > Eric: That most definitely wasn't the core reason for opposition, to > my recollection. It was opposed because it can't be reliably produced > by existing systems, among other things. The exact same argument can be made against atom:published and atom:updated, and pretty much any date for that matter. Sutely you are not suggesting that atom:published and atom:updated should be stricken from the spec? >(See the wiki for a survey of tools and the dates they support.) hmmm ... Blogger, Moveable Type, JournURL, bloxsom, ExpressionEngine, ongoing, Roller, Macsanomat, WordPress, and BigBlogTool all provide dates which represent the last date/time the entry was modified, and there is no info for LiveJournal. Sam has mentioned they have the same three dates as blogger, but if not it is open-source code and can be patch. Real world practice thus suggests that atom:modified is not such a great burden. Could there be systems incapable of storing/producing atom:modified, or incapable of being patched to do so? Yes. But the same can be said for atom:updated, atom:published, atom:id, atom:link, atom:content, etc etc etc. e. From owner-atom-syntax@mail.imc.org Wed May 18 11:39:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03110 for ; Wed, 18 May 2005 11:39: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 j4IFUUbn097256; Wed, 18 May 2005 08:30: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 j4IFUUWc097255; Wed, 18 May 2005 08:30:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IFUTF4097236 for ; Wed, 18 May 2005 08:30: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 (rwcrmhc13) with SMTP id <20050518153023015007gtkfe>; Wed, 18 May 2005 15:30:23 +0000 Date: Wed, 18 May 2005 09:30:22 -0600 Subject: Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues) 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: <5D2958E6-7356-467A-83B1-E63AEDA6B524@bblfish.net> 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 Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote: > I supposed the surest way to make it impossible to fake the id, is to > specify that > by dereferencing the id and doing a GET (whatever the correct method > of doing that for the > protocol happens to be) one should be able to retrieve the entry. The unlikelihood of anyone actually retrieving each entry to verify that it's accurate would make this method only trivially effective. >> An oddity this language introduces is that if the entries don't >> appear in the same Atom Feed Document, they apparently don't have to >> be treated as the same entry, but if they're aggregated together, >> they do. Going a little further, if I'm subscribed to both original >> feeds and an aggregation that includes both, then I have potentially >> four s with the same id. Which are the same entry and which >> aren't? Only the two in the aggregation, which really aren't, are >> required to be treated as the same. > > I always thought that two entries with the same id should be treated > as the same entry. > What makes you thing otherwise? > Consider the following three simplified feed documents (or any two of them, or just the last one): // this is the legitimate one http://a.com/feeda http://a.com/feeda/entry1 2005-01-01T05:00+00:00 I am the legitimate entry <a href="https://a.com/feedback.php">Use this form to submit your credit card number</a> // this one is phishing http://b.com/feedb http://a.com/feeda/entry1 2005-01-01T10:00+00:00 I am the legitimate entry <a href="https://b.com/feedback.php">Use this form to submit your credit card number</a> // this is an aggregation http://c.com/feedc http://a.com/feeda http://a.com/feeda/entry1 2005-01-01T05:00+00:00 I am the legitimate entry <a href="https://a.com/feedback.php">Use this form to submit your credit card number</a> http://b.com/feedb http://a.com/feeda/entry1 2005-01-01T10:00+00:00 I am the legitimate entry <a href="https://b.com/feedback.php">Use this form to submit your credit card number</a> This is already bad enough. Now how about if the phishing feed claims that it's atom:id is http://a.com/feeda. Worse still. With the current spec text, an Atom consumer that does a little extra work, somehow figures out that the phishing version of the entry is not the same as the legitimate version, and tells the user that would be violating the spec. From owner-atom-syntax@mail.imc.org Wed May 18 12:25:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08330 for ; Wed, 18 May 2005 12:25: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 j4IGBRVm003044; Wed, 18 May 2005 09:11: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 j4IGBRD3003043; Wed, 18 May 2005 09:11: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 j4IGBQ3g003037 for ; Wed, 18 May 2005 09:11:27 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4IGD1kg008068 for ; Wed, 18 May 2005 12:13:03 -0400 Message-ID: <428B692B.9060704@intertwingly.net> Date: Wed, 18 May 2005 12:11:23 -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: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> In-Reply-To: <428ACD94.4070108@intertwingly.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 Sam Ruby wrote: > > Tim Bray wrote: > >> On behalf of Paul and myself. >> >> Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList >> >> The volume of correspondence was unfortunately high for an IETF Last >> Call that came after a Working Group Last call. It is quite possible, >> as always, that the co-chairs have mis-read the consensus of the group >> on one or more issues; in which case please push back. >> >> We can work on this as long as is needed, and given the passion (and, >> in some cases, intransigence) we have seen so far, we do not expect to >> reach unanimity. When you respond to any of these readings of >> consensus, please do so with the intention of helping the chairs >> figure out whether or not we have determined consensus, not just to >> state an opinion one way or another. Thanks! > > There is a danger of looking at changes in isolation. I will point out > two instances that jump out at me. There may be more. > >> ======================================================== >> >> PaceAllowDuplicateIDs >> >> We see a bunch of +1's with an unambiguous -1 only from Duerst. Sayre >> was negative (2005/05/05 6:41 AM) but didn't record a -1. Parks has >> been mostly against, but a close reading of his posts make it clear >> that his issue is in large part with atom:updated, he remains >> convinced that readers desire notification of every change however >> minor and are unwilling to trust publishers' opinions as expressed in >> atom:updated. He could live with this Pace if we re-introduced >> atom:modified or inserted wording in the spec emphasizing that if >> multiple entries with the same atom:id appear in a feed, software must >> treat them as XXX of the same entry; there was lively debate as to >> whether XXX was "versions", "instantiations", or "representations". >> >> Conclusion: The Pace is accepted. The editors are directed to modify >> the phrase which starts "If multiple atom:entry elements..." as follows: >> >> "If multiple atom:entry elements with the same atom:id value appear in >> an Atom Feed document, they describe the same entry and software MUST >> treat them as such." > > IIRC, much of this started due to an objection by Bob Wyman that > treating atom:entries from different sources with the same atom:id as > the same entry would cause problems for PubSub. What ever happened to > that objection? > > Also, it seemed to me that much of the discussion centered around > distinguishing between multiple versions. Reintroducing modified was > rejected, and atom:version never made it into a pace, but should there > be some hint (perhaps non-normative) that software should look to > atom:updated to resolve collisions? > >> ============================= >> >> PaceOptionalFeedLink >> >> Lots of +1's, moderate objections from Ruby, accepted. > > http://www.imc.org/atom-syntax/mail-archive/msg14896.html > > If feed link becomes optional, there is nothing to anchor atom:source > elements, which relates back to Bob's objection above. > >> ============================= I guess I wrote this too quickly last night, in any case, it wasn't clear to Paul, so it might not be clear to others. Off list, I offered the following, and Paul suggested that I post it to the list: There seemed to be consensus that feeds needed something to identify them. What there wasn't consensus on is which element should be that identifier. The solution selected was to make none of the identifiers required - something I don't think has much support, and furthermore creates problems with the ability to cite a source. Done! - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 12:47:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11495 for ; Wed, 18 May 2005 12: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 j4IGcoKd009518; Wed, 18 May 2005 09: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 j4IGcoxp009517; Wed, 18 May 2005 09:38: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 j4IGcnq1009493 for ; Wed, 18 May 2005 09:38: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 6110DE5 for ; Wed, 18 May 2005 09:38:44 -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 j4IGcbng011029 for ; Wed, 18 May 2005 09:38:44 -0700 (PDT) Date: Wed, 18 May 2005 09:51:39 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: PaceAllowDuplicateIdsWithModified Message-ID: <1DB3FBC8045A2190BEB5E4B1@diva.verity.com> In-Reply-To: References: 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 Thursday, May 19, 2005 01:12:22 AM +1000 Eric Scheid wrote: >> >> (See the wiki for a survey of tools and the dates they support.) > > hmmm ... Blogger, Moveable Type, JournURL, bloxsom, ExpressionEngine, > ongoing, Roller, Macsanomat, WordPress, and BigBlogTool all provide dates > which represent the last date/time the entry was modified, and there is no > info for LiveJournal. We abaondoned full LiveJournal compatability a long time ago by requiring time zones. Older LJ posts do not have time zones. Don't know about the current ones. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed May 18 13:16:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14348 for ; Wed, 18 May 2005 13:16: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 j4IH39fG014502; Wed, 18 May 2005 10:03: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 j4IH39U7014501; Wed, 18 May 2005 10:03: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IH38iw014482 for ; Wed, 18 May 2005 10:03:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so542878wra for ; Wed, 18 May 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=a/hmtSC+qINo+8C0Ngc2iPyPxRKiJryhn4uyy1LnyWhlliixA5EWggoZO+4DuKFkfMv7z2O44kUNHMAFR4sSyhlLsS6hGAuyeTdcloJXVVqJUwqwp+9TVYWWCDaCS22w5csIXYXlO++MHvboGgXZQBO8ju/9TAvWUTgNY7qW790= Received: by 10.54.33.80 with SMTP id g80mr430079wrg; Wed, 18 May 2005 10:03:03 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 18 May 2005 10:03:03 -0700 (PDT) Message-ID: <68fba5c5050518100320204d77@mail.gmail.com> Date: Wed, 18 May 2005 13:03:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Re: Consensus call on last raft of issues 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 j4IH39iw014496 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I broadly agree with the chairs' opinions. > Tim Bray wrote: >> >> >> PaceTextShouldBeProvided >> >> +1 from Ruby, explicit -1's from Sayre and de hra. However, taking >> this and PaceOptionalSummary together, it seems clear that the WG >> generally believes the following: >> >> - Title-only feeds are OK for data where that's really all you have. >> - Failing to provide summaries when they could potentially exist is >> regrettable and should be discouraged. >> - There are certain classes of software which will not be able to make >> use of content-light feeds, for example full-text indexers. >> - It is not acceptable for software to fail (note "fail", as opposed to >> "not make full use of") just because the summary is missing. Missed one: - There are many applications and users that *don't want* summaries. Some examples include Firefox, Cellphones, Tivos, and whoever is subscribing to JamesT's title-only feed. This makes the second bullet point false. It is not regrettable to provide applications with exactly what they need. However, I agree that some education is in order. >> >> There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is >> an appropriate level of language to use in encouraging the provision of >> summaries. >> >> Conclusion: This Pace is rejected. However, the editors are directed to >> include the following text in 4.2.13: >> >> "Experience teaches that feeds which contain textual content are in >> general more useful than those which do not. This statement seems overbroad to me, and doesn't directly speak to the data format. >> There are certain classes >> of application, for example full-text indexers, which will be unable to >> make effective use of entries which do not contain text in either >> atom:summary or atom:content. Walter mentioned that he wouldn't index them, but just skip through them to the resources they're linking to. This is a title-only feed's purpose in life, so it's probably not a good example. I think it would be more productive to explain why one might want to omit a summary (see below). >> Feed producers should be aware of these >> issues and are encouraged to include a meaningful atom:summary in >> entries lacking atom:content wherever possible. See above. >>However, the absence of >> atom:summary is not an error and software MUST NOT fail to function >> correctly as a consequence of such an absence." We don't use the term 'software' in the draft. We discuss Atom Processors. If we were to define Atom Processors in opposition to an 'application', as in PaceDefineAtomProcessor, we could say a lot about applications. Note that one major goal of PaceDefineAtomProcessor is to avoid making normative requirements on applications. ----- Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:summary element when the entry contains no atom:content element. The atom:summary element can be omitted if the Atom entry is generated for an application with known requirements that make the inclusion of an atom:summary element impractical (such as limited bandwidth). However, when some general-purpose applications encounter such entries, those entries might be ignored. Regardless of how an associated application will handle entries with no atom:summary element, all Atom Processors MUST NOT fail to process Atom entries simply because they contain no atom:summary or atom:content element. ---- Sam Ruby wrote: > Much of the discussion of this pace centered around the proposed changes > to section 4.1.2. However, there is more to this pace. Sam, do you think any of your concerns could be incorporated into the text above? If so, please make suggestions. If not, could you be more specific about the parts of the Pace you feel were overlooked? Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 18 13:41:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16629 for ; Wed, 18 May 2005 13:41: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 j4IHSp7m019937; Wed, 18 May 2005 10:28: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 j4IHSpi2019936; Wed, 18 May 2005 10:28:51 -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 j4IHSoFt019908 for ; Wed, 18 May 2005 10:28:51 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 80286 messnum 11063398 invoked from network[83.70.217.193/unknown]); 18 May 2005 17:28:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail11.svc.cra.dublin.eircom.net (qp 80286) with SMTP; 18 May 2005 17:28:44 -0000 Message-ID: <428B7B4A.8030404@dehora.net> Date: Wed, 18 May 2005 18:28:42 +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: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues) 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 Antone Roundy wrote: > This is already bad enough. Now how about if the phishing feed claims > that it's atom:id is http://a.com/feeda. Worse still. With the current > spec text, an Atom consumer that does a little extra work, somehow > figures out that the phishing version of the entry is not the same as > the legitimate version, and tells the user that would be violating the > spec. I don't think this (spam, phishing) is solvable without widespread adoption of dsig/pki technology. More snarkily, all the people who complain about these things ought to consider using appropriate technology. We do need to make sure that Atom entries are easily signed tho'. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 18 13:53:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17794 for ; Wed, 18 May 2005 13:53: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 j4IHeMAh022920; Wed, 18 May 2005 10:40: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 j4IHeMJM022919; Wed, 18 May 2005 10:40:22 -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 j4IHeLWj022913 for ; Wed, 18 May 2005 10:40:21 -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 j4IHeL0R024361 for ; Wed, 18 May 2005 11:40:21 -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 <0IGP00IBE538LF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 18 May 2005 11:40:21 -0600 (MDT) Received: from [10.6.31.223] ([199.106.92.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGP00AWF538O6@mail.sun.net> for atom-syntax@imc.org; Wed, 18 May 2005 11:40:20 -0600 (MDT) Date: Wed, 18 May 2005 10:40:19 -0700 From: Tim Bray Subject: Re: Consensus call on last raft of issues In-reply-to: <68fba5c5050518100320204d77@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: <25ab4b94e9d60994bf080d922eb4f81c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050518100320204d77@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 18, 2005, at 10:03 AM, Robert Sayre wrote: >>> However, the absence of >>> atom:summary is not an error and software MUST NOT fail to function >>> correctly as a consequence of such an absence." > > We don't use the term 'software' in the draft. We discuss Atom > Processors. Oops, editorial issue, please maintain consistency in the draft. > If we were to define Atom Processors in opposition to an > 'application', as in PaceDefineAtomProcessor, we could say a lot about > applications. Note that one major goal of PaceDefineAtomProcessor is > to avoid making normative requirements on applications. Yeah, in the case of XML, having the notion of an XML processor allowed us to describe some real important things that turned out to be hard to describe any other way. My personal opinion is that the benefit of defining this in the Atom case does not justify the cost. --Tim From owner-atom-syntax@mail.imc.org Wed May 18 14:06:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18957 for ; Wed, 18 May 2005 14: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 j4IHvb49026511; Wed, 18 May 2005 10:57: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 j4IHvbMI026510; Wed, 18 May 2005 10:57: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IHva2b026481 for ; Wed, 18 May 2005 10:57:36 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so584506wra for ; Wed, 18 May 2005 10:57: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=fjd7/oR7rd6NdrVxOmxhwyTaBjylgqR5jbXSW98yzYonVN0lWSFRT/OYAgH9V02lv3xMq2RRp2ReoNDFL1y5+0duJZmjm6Ur0ZPG+0aLWIdLohZjPZrcNB04Mc7xjlABKgqRuHPfzsaJCIMRR2mKLjN+8t9OZxNmpOMxoNKwlq4= Received: by 10.54.13.38 with SMTP id 38mr456148wrm; Wed, 18 May 2005 10:57:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 18 May 2005 10:57:31 -0700 (PDT) Message-ID: <68fba5c50505181057686fe91c@mail.gmail.com> Date: Wed, 18 May 2005 13:57:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: Consensus call on last raft of issues Cc: Atom Syntax In-Reply-To: <25ab4b94e9d60994bf080d922eb4f81c@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <25ab4b94e9d60994bf080d922eb4f81c@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4IHva2b026505 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/18/05, Tim Bray wrote: > Yeah, in the case of XML, having the notion of an XML processor allowed > us to describe some real important things that turned out to be hard to > describe any other way. My personal opinion is that the benefit of > defining this in the Atom case does not justify the cost. What's the cost? Atom Processor is an undefined specification term, and we need to define it. The fact that the spec has Atom Processors 'displaying' things is particularly bothersome to me. I found that borrowing the idea of a processor in relation to an application clarified a bunch of other issues. For example, "Atom Processors MAY provide some or all of that markup to the application" accurately describes the behavior of MarkP's parser.[0] Robert Sayre [0] http://www.feedparser.org/docs/html-sanitization.html From owner-atom-syntax@mail.imc.org Wed May 18 14:18:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20276 for ; Wed, 18 May 2005 14:18: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 j4II3PGu027304; Wed, 18 May 2005 11:03: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 j4II3PuJ027303; Wed, 18 May 2005 11:03: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4II3OKd027270 for ; Wed, 18 May 2005 11:03:25 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so588853wra for ; Wed, 18 May 2005 11:03:19 -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=DE9PTzUaS4FvlDROqNztTOBAjpVZc2N5GKc6EZ6LEihEXcQJqf/wYfyIupDNFex9HgYNCu+6YC3gsYr9oDxwUTnQkWOZY1z4xbcYVlrRH9MF9jgTgLvjnKYmIxXy73izEqzGrmKDIFRPMlJKAoJo/5fACdL3/AwGKdbu7aLzIzY= Received: by 10.54.140.3 with SMTP id n3mr550696wrd; Wed, 18 May 2005 11:03:19 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 18 May 2005 11:03:19 -0700 (PDT) Message-ID: <68fba5c5050518110378b53ceb@mail.gmail.com> Date: Wed, 18 May 2005 14:03:19 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Consensus call on last raft of issues Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4II3PKd027288 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/18/05, Graham wrote: > On 18 May 2005, at 6:03 pm, Robert Sayre wrote: > > > Missed one: > > - There are many applications and users that *don't want* summaries. > > Some examples include Firefox, Cellphones, Tivos > > What happens when FireFox expands their Atom support to show > summaries, but everyone's subscribed to title-only feeds? Well, if they plan to expand support, they probably won't get in that situation anyway. I've found they are more concerned about sucking down huge full-content feeds and interupting the browser experience. Of course, if someone figured out some content-negotation, they wouldn't get themselves in either bind. > And why > wouldn't a TiVo or a cellphone want summaries? They have big screens > and decent storage space, and the data transfer overhead is pretty > negligible, and should be handled by a gateway if the pipe is that > narrow. Graham, I am not making this up. Review the list for posts on this issue from people with email addresses that come from places like Motorola and Nokia. RogerB specifically mentioned that TiVo users squawked when he took away title-only feeds. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 18 15:41:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28964 for ; Wed, 18 May 2005 15:41: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 j4IJVsSg045353; Wed, 18 May 2005 12:31: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 j4IJVskY045352; Wed, 18 May 2005 12:31: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 j4IJVqP2045336 for ; Wed, 18 May 2005 12:31:53 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2005 19:31:45 -0000 Received: from xdsl-213-196-245-171.netcologne.de (EHLO klangraum) [213.196.245.171] by mail.gmx.net (mp013) with SMTP; 18 May 2005 21:31:45 +0200 X-Authenticated: #163624 Date: Wed, 18 May 2005 21:35:17 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: PaceContentAndSummaryDistinct (was: Consensus call on last raft of issues) Message-ID: <20050518193517.GA15619@klangraum> Mail-Followup-To: Atom Syntax References: <7518fb35fb3952de6590df9581989685@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7518fb35fb3952de6590df9581989685@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: 8bit * Tim Bray [2005-05-18 06:30]: > This was modified in the course of debate. It can't be accepted > because the +1's (and -1's too) were referring to multiple different > wordings and there were three pretty strong -1's. > > Conclusion: The editors are asked to strengthen the language in the > draft that emphasizes the difference in intended purpose between > content and summary. This can be done by adding a sentence to 4.2.13 > that says "The text in atom:summary should not be identical to the text > in atom:content or identical to the text in atom:title." > > However, this might have gained consensus if it were stable. If a > bunch of voices get behind a single version in the next 72 hours and > win the hearts of the -1's, the door is open. For the reasons I argued in… • <20050515211617.GA12134@klangraum>: http://www.imc.org/atom-syntax/mail-archive/msg15216.html • <20050516030242.GA15343@klangraum>: http://www.imc.org/atom-syntax/mail-archive/msg15230.html • <20050516035956.GA15580@klangraum>: http://www.imc.org/atom-syntax/mail-archive/msg15232.html …which can be summarized in the following points… • It is extremely valuable for consumers that the format allows a distinction between summaries/excerpts and full content, and this distinction should therefore be enforced within possibility. • The only formally verifiable criterion that a feed producer is using these elements *in*correctly is if he is sticking the same content in both and letting aggregators worry about it. By merely forcing feed producers to make any choice at all, it can expected that they will choose correctly. …I suggest that the proposed editorial be accepted as is, with the sole modification of turning the informal “should not” into a normative “MUST NOT,” ie: The text in atom:summary MUST NOT be identical to the text in atom:content or identical to the text in atom:title. Meta-PS.: do I need to follow any formal procedures (such as writing a pace) for consensus do be determined? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed May 18 16:19:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11993 for ; Wed, 18 May 2005 16:19: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 j4IKAOo5053820; Wed, 18 May 2005 13:10: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 j4IKAOIu053819; Wed, 18 May 2005 13:10:24 -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 j4IKANni053805 for ; Wed, 18 May 2005 13:10:24 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4IKBsYW006670; Wed, 18 May 2005 16:11:59 -0400 Message-ID: <428BA124.7060409@intertwingly.net> Date: Wed, 18 May 2005 16:10:12 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.gmail.com> In-Reply-To: <68fba5c5050518100320204d77@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > I broadly agree with the chairs' opinions. > > >>Tim Bray wrote: >> >>> >>>PaceTextShouldBeProvided >>> >>>+1 from Ruby, explicit -1's from Sayre and de hra. However, taking >>>this and PaceOptionalSummary together, it seems clear that the WG >>>generally believes the following: >>> >>>- Title-only feeds are OK for data where that's really all you have. >>>- Failing to provide summaries when they could potentially exist is >>>regrettable and should be discouraged. >>>- There are certain classes of software which will not be able to make >>>use of content-light feeds, for example full-text indexers. >>>- It is not acceptable for software to fail (note "fail", as opposed to >>>"not make full use of") just because the summary is missing. > > > Missed one: > - There are many applications and users that *don't want* summaries. > Some examples include Firefox, Cellphones, Tivos, and whoever is > subscribing to JamesT's title-only feed. > > This makes the second bullet point false. It is not regrettable to > provide applications with exactly what they need. However, I agree > that some education is in order. > > > >>>There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is >>>an appropriate level of language to use in encouraging the provision of >>>summaries. >>> >>>Conclusion: This Pace is rejected. However, the editors are directed to >>>include the following text in 4.2.13: >>> >>>"Experience teaches that feeds which contain textual content are in >>>general more useful than those which do not. > > > This statement seems overbroad to me, and doesn't directly speak to > the data format. > > >>>There are certain classes >>>of application, for example full-text indexers, which will be unable to >>>make effective use of entries which do not contain text in either >>>atom:summary or atom:content. > > > Walter mentioned that he wouldn't index them, but just skip through > them to the resources they're linking to. This is a title-only feed's > purpose in life, so it's probably not a good example. I think it would > be more productive to explain why one might want to omit a summary > (see below). > > >>>Feed producers should be aware of these >>>issues and are encouraged to include a meaningful atom:summary in >>>entries lacking atom:content wherever possible. > > > See above. > > >>>However, the absence of >>>atom:summary is not an error and software MUST NOT fail to function >>>correctly as a consequence of such an absence." > > > We don't use the term 'software' in the draft. We discuss Atom > Processors. If we were to define Atom Processors in opposition to an > 'application', as in PaceDefineAtomProcessor, we could say a lot about > applications. Note that one major goal of PaceDefineAtomProcessor is > to avoid making normative requirements on applications. > > ----- > Some applications may choose to require a minimum amount of inline > text or (X)HTML data to function reliably and predictably. For that > reason, atom:entry elements are advised to contain a non-empty > atom:summary element when the entry contains no atom:content element. > > The atom:summary element can be omitted if the Atom entry is generated > for an application with known requirements that make the inclusion of > an atom:summary element impractical (such as limited bandwidth). > However, when some general-purpose applications encounter such > entries, those entries might be ignored. > > Regardless of how an associated application will handle entries with > no atom:summary element, all Atom Processors MUST NOT fail to process > Atom entries simply because they contain no atom:summary or > atom:content element. > ---- > > Sam Ruby wrote: > >>Much of the discussion of this pace centered around the proposed changes >>to section 4.1.2. However, there is more to this pace. > > Sam, do you think any of your concerns could be incorporated into the > text above? If so, please make suggestions. If not, could you be more > specific about the parts of the Pace you feel were overlooked? A concrete example of my concern is that feeds with atom:entries containing will have those entries omitted by Firefox's livebookmark support. The proposed changes to sections 3.1.1.1, 3.1.1.2, and 3.1.1.3, apply to all text constructs, not simply atom:summary. All that needs to be done is to expand whatever wording we come up with to include title and content. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 16:22:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13525 for ; Wed, 18 May 2005 16:22: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 j4IKEAXR054591; Wed, 18 May 2005 13:14: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 j4IKEAXs054590; Wed, 18 May 2005 13:14:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IKE9Dk054579 for ; Wed, 18 May 2005 13:14:10 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [192.168.1.8] (trillian.student.umd.edu [129.2.249.178]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AKU41508 (AUTH atrus); Wed, 18 May 2005 16:16:10 -0400 (EDT) Message-ID: <428BA209.3070109@atrus.org> Date: Wed, 18 May 2005 16:14:01 -0400 From: Nikolas Coukouma User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax@imc.org Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.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 Graham wrote: > On 18 May 2005, at 6:03 pm, Robert Sayre wrote: > >> Missed one: >> - There are many applications and users that *don't want* summaries. >> Some examples include Firefox, Cellphones, Tivos > > > What happens when FireFox expands their Atom support to show > summaries, but everyone's subscribed to title-only feeds? And why > wouldn't a TiVo or a cellphone want summaries? They have big screens > and decent storage space, and the data transfer overhead is pretty > negligible, and should be handled by a gateway if the pipe is that > narrow. > > Graham This is a bit nitpicky, but * I doubt Firefox will ever support summaries in it's Live Bookmarks feature. It's intended for link (title-only) feeds, as the name suggests. There's a number of extensions that provide this functionality, but it seems Mozilla has opted to keep this in the mail component (Thunderbird) * Cellphones (and PDAs, for that matter) don't have big screens or decent storage space. * TiVo's have big screens, but the resolution sucks so you don't want to display anything in font size < 25pt. The last two suggest that summaries should be very short (e.g. not a paragraph, but a sentence or two) more than they suggest no summary at all. -Nikolas Coukouma From owner-atom-syntax@mail.imc.org Wed May 18 16:40:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18143 for ; Wed, 18 May 2005 16:40: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 j4IKWNTO059436; Wed, 18 May 2005 13:32: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 j4IKWNr3059434; Wed, 18 May 2005 13:32:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IKWMkH059408 for ; Wed, 18 May 2005 13:32:22 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050518203216.ZAVS26549.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Wed, 18 May 2005 21:32:16 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050518203216.CVNM28553.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 18 May 2005 21:32:16 +0100 Date: Wed, 18 May 2005 21:32:13 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1026251736.20050518213213@djpowell.net> To: "Roger B." CC: Atom Syntax Subject: Re: PaceAllowDuplicateIdsWithModified In-Reply-To: <540e37320505180516156a5569@mail.gmail.com> References: <12336714.20050515231212@djpowell.net> <540e37320505180516156a5569@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, May 18, 2005, 1:16:15 PM, Roger B wrote: >> There was opposition to atom:modified because we couldn't see a need for it. >> Now we have a need for it. > Eric: That most definitely wasn't the core reason for opposition, to > my recollection. I just checked the PaceDateModified thread, and Eric's recollection seems correct. I couldn't see a single objection on the basis of software support. > It was opposed because it can't be reliably produced > by existing systems, among other things. (See the wiki for a survey of > tools and the dates they support.) Am I looking at the same page? BlogToolDateSurvey shows atom:modified as having widespread support. Support for atom:updated isn't shown, but I would bet on it being a lot scarcer than atom:modified. -- Dave From owner-atom-syntax@mail.imc.org Wed May 18 16:44:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18444 for ; Wed, 18 May 2005 16:44: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 j4IKaEWW060523; Wed, 18 May 2005 13:36: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 j4IKaEGo060522; Wed, 18 May 2005 13:36: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IKaDnJ060500 for ; Wed, 18 May 2005 13:36:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so700815wra for ; Wed, 18 May 2005 13:36:07 -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=NHJ1SOK+xe+XeGYKLZdb+Q5HFstJ8ljEjtrmS0mqETKRXm8v+R+BDwixaYZn0dd5EVsGe2cqJMXvC6KZcfgQY7iHixG/JttmqJhhSToyfl2yQ/GwRf5OtpR7RBL/rATA8rKYLa+dUCDe4VoSoELnI03/L/GqiR3ep17KtnuGdas= Received: by 10.54.10.61 with SMTP id 61mr527049wrj; Wed, 18 May 2005 13:36:07 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 18 May 2005 13:36:07 -0700 (PDT) Message-ID: <68fba5c50505181336296efc83@mail.gmail.com> Date: Wed, 18 May 2005 16:36:07 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: Consensus call on last raft of issues Cc: Atom Syntax In-Reply-To: <428BA124.7060409@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4IKaDnJ060517 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/18/05, Sam Ruby wrote: > A concrete example of my concern is that feeds with atom:entries > containing will have those entries omitted by Firefox's > livebookmark support. > > The proposed changes to sections 3.1.1.1, 3.1.1.2, and 3.1.1.3, apply to > all text constructs, not simply atom:summary. > > All that needs to be done is to expand whatever wording we come up with > to include title and content. How about this: ----- Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. The atom:summary element can be omitted if the Atom entry is generated for an application with known requirements that make the inclusion of an atom:summary element impractical (such as limited bandwidth). However, when some general-purpose applications encounter such entries, those entries might be ignored. Regardless of how an associated application will handle entries with no atom:summary element, all Atom Processors MUST NOT fail to process Atom entries simply because they contain no atom:summary or atom:content element. ----- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 18 17:05:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20471 for ; Wed, 18 May 2005 17:05: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 j4IKviNk064465; Wed, 18 May 2005 13:57: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 j4IKvihU064464; Wed, 18 May 2005 13:57:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IKvgjo064440 for ; Wed, 18 May 2005 13:57:43 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050518205737.EYPQ26549.mta08-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Wed, 18 May 2005 21:57:37 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050518205737.EENI18002.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 18 May 2005 21:57:37 +0100 Date: Wed, 18 May 2005 21:57:35 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1941604521.20050518215735@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Consensus call on last raft of issues In-Reply-To: <7518fb35fb3952de6590df9581989685@sun.com> References: <7518fb35fb3952de6590df9581989685@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 > PaceDuplicateIDWithModified > The consensus of the group against atom:modified months and months > ago was quite strong and this is not enough momentum to accomplish > such a major policy reversal. Rejected. I don't think that this Pace has had enough discussion to be rejected just yet - it's was only posted 2.5ish days ago. The consensus against PaceDateModified can't be applied to PaceDateModified2 - the -1s against PaceDateModifed were overwhelming, but as far as I can see all of the -1s were for the reason that there was insufficient need for PaceDateModified. PaceDateModified was closed prior to the issue of duplicate entries being raised. Duplicate entries create a need for atom:modified that wasn't discussed at the time of PaceDateModified. If this proposal is rejected, then we still have a fundamental data-loss problem if the sequence of revisions in an archive is not preserved. -- Dave From owner-atom-syntax@mail.imc.org Wed May 18 17:08:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20814 for ; Wed, 18 May 2005 17:08: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 j4IKxst0065175; Wed, 18 May 2005 13:59: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 j4IKxskI065174; Wed, 18 May 2005 13:59: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 j4IKxr0r065159 for ; Wed, 18 May 2005 13:59:53 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4IL1Utg012724; Wed, 18 May 2005 17:01:30 -0400 Message-ID: <428BACC6.2090609@intertwingly.net> Date: Wed, 18 May 2005 16:59:50 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> In-Reply-To: <68fba5c50505181336296efc83@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: > > How about this: > > Some applications may choose to require a minimum amount of inline > text or (X)HTML data to function reliably and predictably. For that > reason, atom:entry elements are advised to contain a non-empty > atom:title element, a non-empty atom:summary element when the entry > contains no atom:content element, and a non-empty atom:content element > when that element is present. That works. Thanks! - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 17:15:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21301 for ; Wed, 18 May 2005 17:15: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 j4IL7D1F066737; Wed, 18 May 2005 14:07: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 j4IL7DE2066736; Wed, 18 May 2005 14:07:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IL7CRF066697 for ; Wed, 18 May 2005 14:07:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4IL5jeT017965; Wed, 18 May 2005 22:06:06 +0100 (BST) In-Reply-To: <68fba5c50505181336296efc83@mail.gmail.com> References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Consensus call on last raft of issues Date: Wed, 18 May 2005 22:05:37 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 9:36 pm, Robert Sayre wrote: > atom:entry elements are advised to contain ... a non-empty > atom:summary element when the entry > contains no atom:content element I'd like us to advise including an atom:summary when atom:content is binary (or for that matter, any non-text/html/xhtml type) > The atom:summary element can be omitted if the Atom entry is generated > for an application with known requirements that make the inclusion of > an atom:summary element impractical (such as limited bandwidth). > However, when some general-purpose applications encounter such > entries, those entries might be ignored. I like this. > Regardless of how an associated application will handle entries with > no atom:summary element, all Atom Processors MUST NOT fail to process > Atom entries simply because they contain no atom:summary or > atom:content element. Do we have a definition of "process" (and/or "fail")? Graham From owner-atom-syntax@mail.imc.org Wed May 18 17:26:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22818 for ; Wed, 18 May 2005 17:26: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 j4ILHnbP069133; Wed, 18 May 2005 14:17: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 j4ILHnjk069132; Wed, 18 May 2005 14:17:49 -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 j4ILHmpM069116 for ; Wed, 18 May 2005 14:17:48 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:61632 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228804AbVERVRq (ORCPT ); Thu, 19 May 2005 00:17:46 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <992938A8-C6E2-11D9-8AA1-003065EA6144@geckotribe.com> References: <992938A8-C6E2-11D9-8AA1-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) Date: Thu, 19 May 2005 00:17:38 +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 May 17, 2005, at 17:47, Antone Roundy wrote: > What possible advantage would there be to allowing just anyone to add > elements to Atom's namespace, or any other namespace, for that matter? > I can't think of any. If you add to an existing namespace, you don't need to add confusing namespace declarations. > In my opinion, alteration of a namespace by anyone other than the > entity that created it, or someone authorized by its creator, would > completely violate the nature of namespaces. Sure. But it happens for practical reasons. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 18 17:26:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22839 for ; Wed, 18 May 2005 17: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 j4ILGbbU068863; Wed, 18 May 2005 14:16: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 j4ILGbjm068862; Wed, 18 May 2005 14:16: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4ILGZOh068812 for ; Wed, 18 May 2005 14:16:36 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2005 21:16:29 -0000 Received: from xdsl-213-196-245-171.netcologne.de (EHLO klangraum) [213.196.245.171] by mail.gmx.net (mp008) with SMTP; 18 May 2005 23:16:29 +0200 X-Authenticated: #163624 Date: Wed, 18 May 2005 23:20:00 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Consensus call on last raft of issues Message-ID: <20050518212000.GA15701@klangraum> Mail-Followup-To: atom-syntax References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.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: 8bit * Graham [2005-05-18 23:15]: > On 18 May 2005, at 9:36 pm, Robert Sayre wrote: >> Regardless of how an associated application will handle >> entries with no atom:summary element, all Atom Processors MUST >> NOT fail to process Atom entries simply because they contain >> no atom:summary or atom:content element. > > Do we have a definition of "process" (and/or "fail")? I think the original intent of the previous discussion was to say at this point that “an Atom Processor MUST NOT fail to process an Atom feed with entries that lack an atom:summary or atom:content,” as opposed to saying they “MUST NOT fail process Atom entries […],” which is an entirely different kettle of fish. In other words, it had been suggested that processors may freely skip entries which they consider insufficiently rich, but they may not refuse processing a feed that contains such entries. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed May 18 17:38:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24389 for ; Wed, 18 May 2005 17:38: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 j4IHonWd024989; Wed, 18 May 2005 10: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 j4IHon1Y024988; Wed, 18 May 2005 10:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IHomat024966 for ; Wed, 18 May 2005 10:50:49 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4IHnXwj027816; Wed, 18 May 2005 18:49:44 +0100 (BST) In-Reply-To: <68fba5c5050518100320204d77@mail.gmail.com> References: <68fba5c5050518100320204d77@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Consensus call on last raft of issues Date: Wed, 18 May 2005 18:49:39 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 6:03 pm, Robert Sayre wrote: > Missed one: > - There are many applications and users that *don't want* summaries. > Some examples include Firefox, Cellphones, Tivos What happens when FireFox expands their Atom support to show summaries, but everyone's subscribed to title-only feeds? And why wouldn't a TiVo or a cellphone want summaries? They have big screens and decent storage space, and the data transfer overhead is pretty negligible, and should be handled by a gateway if the pipe is that narrow. Graham From owner-atom-syntax@mail.imc.org Wed May 18 17:52:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25729 for ; Wed, 18 May 2005 17:52: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 j4ILjX7T075175; Wed, 18 May 2005 14:45: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 j4ILjXdd075174; Wed, 18 May 2005 14:45:33 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ILjWpK075147 for ; Wed, 18 May 2005 14:45:32 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.58.133]) by smtp.cegetel.net (Postfix) with ESMTP id 54ADE318665; Wed, 18 May 2005 23:45:26 +0200 (CEST) Message-ID: <428BB79F.6060909@cegetel.net> Date: Wed, 18 May 2005 23:46:07 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Tim Bray Cc: Atom Syntax Subject: Re: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> In-Reply-To: <7518fb35fb3952de6590df9581989685@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: > PaceEntryState > > Rejected, no support. Wasn't it intended for the protocol spec? (though section 3.5 doesn't exist in protocol-04) > PaceOptionalXhtmlDiv > > A handful of -1's, no support, rejected. Maybe it came a bit late? And I think the -1's were misinterpretations of the Pace. Nonetheless, my understanding of Text Construct and "special @type values" or atom:content is that they aim to provide textual content, eventually enriched with escaped-HTML or XHTML markup. As I explained in my last mail in the related thread [1], (X)HTML div (or span) elements without any attribute (except eventual namespace declarations) have no mean other than grouping their content on behalf of their siblings (text and markup living outside the div but having the same parent/enclosing element). There's then no matter discarding them. Some people might object that those "dummy" div elements can be used for styling (here, something like CSS; XSLT is a transformation, not really a stylesheet). Let's examine that special case a bit, figuring out how such elements (a div element with no attribute being the only child of a Text Construct or atom:content with type="xhtml") would then be used for styling. Styling an XHTML element is possible only from outside of it (through a stylesheet) or with a @style attribute, but it's not what we're talking about. In the first case, the only solution is to embed the content in a document (at least adding an xml-stylesheet processing instruction) or process it somehow to apply it a stylesheet. Whatever mean is used, it's the responsibility of the application to style the XHTML content, thus to add dummy XHTML div wrappers if necessary. Moreover, the current spec states the div must be discarded, so an application would already have to add these dummy XHTML div wrappers. In the second case, the div has an attribute so it's out of scope. Styling an Atom document and using a dummy XHTML div for that purpose is also out of scope as we're talking about Atom documents containing dummy XHTML div element that could be discarded when processed by an Atom Processor (which an application applying a stylesheet is not). As I already said (in the same mail [1]), as Atom uses XML Namespaces, an namespace-aware XML parser is required, so "I need this div not to be discarded in order to carry the namespace declaration" is not an acceptable argument. Again, if the Atom Processor or the application have no mean to keep the namespace scope without a dummy div wrapper, it's its responsibility to add such (and, e.g. if it's a library, document it so that users know that what they receive is not what really was in the Atom document). And again, the current spec states the div must be discarded, so such an Atom Processor would already have to add such a wrapper. For people worried about misuse of XML namespaces, I suggest adding some wording and examples to the spec, and I don't think the current spec sorts out the problem better (though not worse either). I've asked for examples of XHTML content that would need a div without attribute and which would be kept part of the content, there has not been any answer yet. I ask the question again: is there any reason such a div should be kept part of the content? Just to make sure nobody would misinterpret the Pace, we're only talking about those XHTML div elements that are the single child of a Text Construct or atom:content with @type="xhtml" and have no attribute at all except namespace declarations. Should I edit the Pace to make it reflect the above better than it currently does? ===================== Last (but not least), my English is not as good as I'd want and my dictionary is of no help: what does really mean "recommended for closure"? Actually, what about PaceXhtmlDivSuggestedOnly (and more accurately the part about inline vs. block content, which is not implied by the Pace name)? Do you think I should withdraw this Pace and write up a new one for that particular matter (say, e.g., PaceInlineVsBlockContent)? [1] http://www.imc.org/atom-syntax/mail-archive/msg15222.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed May 18 18:13:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28005 for ; Wed, 18 May 2005 18:13: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 j4IM0joj078040; Wed, 18 May 2005 15: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 j4IM0jeU078039; Wed, 18 May 2005 15: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IM0ijg078031 for ; Wed, 18 May 2005 15:00:44 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so808361wri for ; Wed, 18 May 2005 15:00:38 -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=rWn8vwOKypHeahisquqgoCKw2Ul6jvDHMiqAXw5EqMRfBJ7ew/0/qc7scJlLwrppZcY/fxHH478+ch/bI2wNbDccytaNpTVpznBF86BCJKl6Ll5feIjyfHG/Zb+qXOY+tZAl368AiAsjSVAqc8kFL44seQC9shH0rmHCiVXwKhw= Received: by 10.54.125.9 with SMTP id x9mr711922wrc; Wed, 18 May 2005 15:00:38 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Wed, 18 May 2005 15:00:38 -0700 (PDT) Message-ID: <540e3732050518150041a40cbb@mail.gmail.com> Date: Wed, 18 May 2005 17:00:38 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: PaceAllowDuplicateIdsWithModified In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <540e37320505180516156a5569@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4IM0jjg078034 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Eric: My bad... I was looking at Ye Olde PaceDateModified, not PaceDateModified2. Template-based systems can't reliably produce a PaceDateModified, but PDM2 is a different story. Consider the -1 moved to +0. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Wed May 18 18:13:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28020 for ; Wed, 18 May 2005 18:13: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 j4IM2wob078172; Wed, 18 May 2005 15:02: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 j4IM2wFu078171; Wed, 18 May 2005 15:02:58 -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 j4IM2wGu078155 for ; Wed, 18 May 2005 15:02: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 (sccrmhc14) with SMTP id <2005051822025101400nssgre>; Wed, 18 May 2005 22:02:51 +0000 Date: Wed, 18 May 2005 16:02:50 -0600 Subject: Re: Change Control (was: extensions -- Atom NS and unprefixed attributes) 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: <934A56DA-C7E8-11D9-A5DA-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, May 18, 2005, at 03:17 PM, Henri Sivonen wrote: > On May 17, 2005, at 17:47, Antone Roundy wrote: >> What possible advantage would there be to allowing just anyone to add >> elements to Atom's namespace, or any other namespace, for that >> matter? I can't think of any. > > If you add to an existing namespace, you don't need to add confusing > namespace declarations. > Sheesh. If you can't be bothered to add a "confusing" namespace declaration, then you should be using plain text instead of XML. From owner-atom-syntax@mail.imc.org Wed May 18 18:17:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28642 for ; Wed, 18 May 2005 18:17: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 j4IMAn7J079936; Wed, 18 May 2005 15:10: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 j4IMAnw7079935; Wed, 18 May 2005 15:10:49 -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 j4IMAmlZ079909 for ; Wed, 18 May 2005 15:10:48 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so758942wra for ; Wed, 18 May 2005 15:10:42 -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=K5DaIkGgIVe4OT6vV9TOc62TRgEJyU2+HJc7dLRsPRHCx8g7V62R4Svh1zm0JGeSV2VQShkqpxa33h9lgkpntpByBTEJt8HBFdKGhZEJv53TX6oG+Spea+JdXXT5ZYKaQ6DvcTiiyFveX7ODnTJ/Sngj1PMb2P2/zpGA6AHJmf8= Received: by 10.54.76.12 with SMTP id y12mr668640wra; Wed, 18 May 2005 15:10:41 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 18 May 2005 15:10:41 -0700 (PDT) Message-ID: <68fba5c505051815104b93aeee@mail.gmail.com> Date: Wed, 18 May 2005 18:10:41 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Consensus call on last raft of issues Cc: atom-syntax In-Reply-To: <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4IMAmlZ079929 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/18/05, Graham wrote: > On 18 May 2005, at 9:36 pm, Robert Sayre wrote: > > > atom:entry elements are advised to contain ... a non-empty > > atom:summary element when the entry > > contains no atom:content element > > I'd like us to advise including an atom:summary when atom:content is > binary (or for that matter, any non-text/html/xhtml type) OK. We can do that by accounting for atom:content elements with media types in @type. ----- Some applications may choose to require a minimum amount of inline text or (X)HTML data to function reliably and predictably. For that reason, atom:entry elements are advised to contain a non-empty atom:title element, a non-empty atom:content element when that element is present, and a non-empty atom:summary element when the entry contains no atom:content element or the atom:content element's type is a MIME media type. The atom:summary element can be omitted if the Atom entry is generated for an application with known requirements that make the inclusion of an atom:summary element impractical (such as limited bandwidth). However, when some general-purpose applications encounter such entries, those entries might be ignored. Regardless of how an associated application will handle entries with no atom:summary element, all Atom Processors MUST NOT fail to process Atom entries simply because they contain no atom:summary or atom:content element. ----- > > > Regardless of how an associated application will handle entries with > > no atom:summary element, all Atom Processors MUST NOT fail to process > > Atom entries simply because they contain no atom:summary or > > atom:content element. > > Do we have a definition of "process" (and/or "fail")? Well, this text assumes something similar to this paragraph in PaceDefineAtomProcessor: This specification describes conformance in terms of two artifacts; Atom Feed Documents and Atom Entry Documents. Additionally, it places some requirements on Atom Processors. An Atom Processor is a software module used to read Atom Documents and provide access to their content and structure. It is assumed that an Atom Processor is doing its work on behalf of another module, called the application. If we had text like that, it would be reasonable to assume that 'process' means 'provide access to their content and structure'. It also be reasonable to assume that 'fail' means 'doesn't provide access to their content and structure'. Obviously, Tim is not a fan of that proposal. I think we should steal from the best. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 18 19:18:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04899 for ; Wed, 18 May 2005 19:18: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 j4INAWwe090961; Wed, 18 May 2005 16:10: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 j4INAWO7090960; Wed, 18 May 2005 16:10:32 -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 j4INAV4X090946 for ; Wed, 18 May 2005 16:10:31 -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 <2005051823101501200601hse>; Wed, 18 May 2005 23:10:25 +0000 Date: Wed, 18 May 2005 17:10:13 -0600 Subject: Why and how to identify a feed (was Re: Consensus call on last raft of issues) 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: <428B692B.9060704@intertwingly.net> 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 Wednesday, May 18, 2005, at 10:11 AM, Sam Ruby wrote: > There seemed to be consensus that feeds needed something to > identify > them. What there wasn't consensus on is which element should be > that identifier. The solution selected was to make none of the > identifiers required - something I don't think has much support, > and > furthermore creates problems with the ability to cite a source. > Agreed. In a probably-vain attempt to seed a semi-organized discussion of the topic, let me start a list of reasons and ways to identify a feed. There are weaknesses to all of the following. I won't discuss those yet because I'd rather wait till the lists are more complete so that a decision can be made by choosing the best from among alternatives rather than just ranting about the drawbacks of a few of them and never reaching a reasoned conclusion. Please chime in if you have other reasons and/or methods. Why might someone (even if not you) want to have an identifier for a feed? 1) To use as or to generate a database key for the feed and its entries 2) To associate aggregated entries with the feed that they are claimed to have originated in 3) To verify the integrity of aggregated entries with more confidence than is possible simply by believing the aggregated feed's claims about their origins Any others? How might a feed be identified? 1) atom:id 2) atom:link[@rel="alternate"] 3) atom:link[@rel="self"] 4) the IRI from which it was retrieved Any others? ---------- A comment on atom:link[@rel="self"]: Does anyone else feel that the current spec text doesn't fully reflect what we intended, or at least could be improved to make it more useful? 3. The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element. This text is not explicit on whether "self" points to Atom document, or whether it could point to any data format. Unless it points to an Atom document, how is it different from "alternate"? Was not it intended that the feed or entry be retrievable from that IRI (I seem to recall someone claiming that the current spec text doesn't say that--if I'm incorrect, just ignore this whole paragraph)? If not, what is the point of having this link? "The "atom:link" element is an empty element that defines a reference from an entry or feed to a Web resource." Doesn't that mean that the IRI can be used for retrieval? Was it not intended that it be the "preferred" IRI to use to subscribe to the feed? If that wasn't the original intent, would that not be a good thing to add? What drawbacks would there be to doing that to "self"'s semantics? I'll comment on other things later. From owner-atom-syntax@mail.imc.org Wed May 18 21:29:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15095 for ; Wed, 18 May 2005 21:29: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 j4J1JTl3010413; Wed, 18 May 2005 18:19: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 j4J1JTQW010412; Wed, 18 May 2005 18:19: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 j4J1JSfN010404 for ; Wed, 18 May 2005 18:19:28 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4J1L1Ut007172; Wed, 18 May 2005 21:21:01 -0400 Message-ID: <428BE996.2000606@intertwingly.net> Date: Wed, 18 May 2005 21:19:18 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Graham , atom-syntax Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> <68fba5c505051815104b93aeee@mail.gmail.com> In-Reply-To: <68fba5c505051815104b93aeee@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: > On 5/18/05, Graham wrote: > >>On 18 May 2005, at 9:36 pm, Robert Sayre wrote: >> >>>atom:entry elements are advised to contain ... a non-empty >>>atom:summary element when the entry >>>contains no atom:content element >> >>I'd like us to advise including an atom:summary when atom:content is >>binary (or for that matter, any non-text/html/xhtml type) > > OK. We can do that by accounting for atom:content elements with media > types in @type. > > ----- > Some applications may choose to require a minimum amount of inline > text or (X)HTML data to function reliably and predictably. For that > reason, atom:entry elements are advised to contain a non-empty > atom:title element, a non-empty atom:content element > when that element is present, and a non-empty atom:summary element > when the entry > contains no atom:content element or the atom:content element's type is > a MIME media type. Isn't that redundant? From PaceOptionalSummary: atom:entry elements MUST contain an atom:summary element in any of the following cases: * the atom:entry contains an atom:content that has a "src" attribute (and is thus empty). * the atom:entry contains content that is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [MIMEREG] and does not begin with "text/" nor end with "+xml". - Sam Ruby From owner-atom-syntax@mail.imc.org Wed May 18 23:31:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23355 for ; Wed, 18 May 2005 23: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 j4J3IVqn037730; Wed, 18 May 2005 20:18: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 j4J3IVKI037729; Wed, 18 May 2005 20:18:31 -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 j4J3ITiJ037709 for ; Wed, 18 May 2005 20:18:29 -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 j4J3IT0R015547 for ; Wed, 18 May 2005 21:18:29 -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 <0IGP008OPVUSDJ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 18 May 2005 21:18:29 -0600 (MDT) Received: from [192.168.1.32] ([70.18.42.127]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGP00A27VUROI@mail.sun.net> for atom-syntax@imc.org; Wed, 18 May 2005 21:18:28 -0600 (MDT) Date: Wed, 18 May 2005 20:18:28 -0700 From: Tim Bray Subject: Re: Consensus call on last raft of issues In-reply-to: <428BE996.2000606@intertwingly.net> To: Sam Ruby Cc: Graham , atom-syntax , Robert Sayre Message-id: <2d1f09e658b7907e5d199b7f4f7658c1@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> <68fba5c505051815104b93aeee@mail.gmail.com> <428BE996.2000606@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 18, 2005, at 6:19 PM, Sam Ruby wrote: > Isn't that redundant? From PaceOptionalSummary: Yup. Think we got that covered. -Tim From owner-atom-syntax@mail.imc.org Thu May 19 05:01:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07523 for ; Thu, 19 May 2005 05:01: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 j4J8oARB015969; Thu, 19 May 2005 01:50: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 j4J8oATj015968; Thu, 19 May 2005 01:50:10 -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 j4J8o6po015876 for ; Thu, 19 May 2005 01:50:09 -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); Thu, 19 May 2005 18:50:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 19 May 2005 18:49:57 +1000 Subject: Re: PaceAllowDuplicateIdsWithModified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0E14FA9B-24D9-4DD1-AF4E-4AA7987572E4@mac.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 18/5/05 7:41 PM, "Graham" wrote: >> Not so very long ago you suggested that aggregators look at the content to >> determine if it's changed. If it's good enough for aggregators, it's good >> enough for publishers (actually better than good enough since the publisher >> would be able to do the test before other transformations occur, thus >> eliminating some false positives). >> > But if the publisher does that, atom:modified is going to end up being the > date the atom-generating program is run rather than the date the modification > happened. You may argue that functionally this doesn't matter, and you'd be > right. You'd also be admitting that the absolute date is not important, as > long as the dates are in the right order - aka atom:version. not quite. I agree "the absolute date of modification" is open to philosophical argument (eg. an author retrieves an entry into their editor, changes some bit, goes off for 5 minutes to answer the phone, comes back and presses the submit button ... what is the true date of modification now?) The absolute or true date of modification isn't the quality I'm interested in though. What I am interested in is having one such timestamp for any given modified content. Not multiple timestamps for the exact same content, which is what atom:version sloppily allows. e. From owner-atom-syntax@mail.imc.org Thu May 19 06:45:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18208 for ; Thu, 19 May 2005 06:45: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 j4JAWYU6083904; Thu, 19 May 2005 03:32: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 j4JAWYxG083903; Thu, 19 May 2005 03:32:34 -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 j4JAWXlW083892 for ; Thu, 19 May 2005 03:32:33 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4JAYBRR000864; Thu, 19 May 2005 06:34:11 -0400 Message-ID: <428C6B3B.3080502@intertwingly.net> Date: Thu, 19 May 2005 06:32:27 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Graham , atom-syntax , Robert Sayre Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> <68fba5c505051815104b93aeee@mail.gmail.com> <428BE996.2000606@intertwingly.net> <2d1f09e658b7907e5d199b7f4f7658c1@sun.com> In-Reply-To: <2d1f09e658b7907e5d199b7f4f7658c1@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: > > On May 18, 2005, at 6:19 PM, Sam Ruby wrote: > >> Isn't that redundant? From PaceOptionalSummary: > > Yup. Think we got that covered. -Tim Off list, Robert pointed out to me that that the spec text I cited didn't cover empty summaries. He's right. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 19 13:34:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27955 for ; Thu, 19 May 2005 13:34: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 j4JHIiQf010082; Thu, 19 May 2005 10:18: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 j4JHIiqL010081; Thu, 19 May 2005 10:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailm1.svr.pol.co.uk (cmailm1.svr.pol.co.uk [195.92.193.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JHIhv3010072 for ; Thu, 19 May 2005 10:18:43 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7935.lns6-c10.dsl.pol.co.uk ([84.68.190.255] helo=[192.168.0.2]) by cmailm1.svr.pol.co.uk with esmtp (Exim 4.41) id 1DYofR-0007Im-Tr; Thu, 19 May 2005 18:18:42 +0100 Message-ID: <428CCA66.8010504@isofarro.uklinux.net> Date: Thu, 19 May 2005 18:18:30 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> In-Reply-To: <7518fb35fb3952de6590df9581989685@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > PaceTextShouldBeProvided > > +1 from Ruby, explicit -1's from Sayre and de hra. However, taking > this and PaceOptionalSummary together, it seems clear that the WG > generally believes the following: > > - Title-only feeds are OK for data where that's really all you have. > - Failing to provide summaries when they could potentially exist is > regrettable and should be discouraged. > - There are certain classes of software which will not be able to make > use of content-light feeds, for example full-text indexers. > - It is not acceptable for software to fail (note "fail", as opposed to > "not make full use of") just because the summary is missing. > > There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is > an appropriate level of language to use in encouraging the provision of > summaries. > > Conclusion: This Pace is rejected. However, the editors are directed to > include the following text in 4.2.13: > > "Experience teaches that feeds which contain textual content are in > general more useful than those which do not. There are certain classes > of application, for example full-text indexers, which will be unable to > make effective use of entries which do not contain text in either > atom:summary or atom:content. Feed producers should be aware of these > issues and are encouraged to include a meaningful atom:summary in > entries lacking atom:content wherever possible. However, the absence of > atom:summary is not an error and software MUST NOT fail to function > correctly as a consequence of such an absence." I'd urge that the wording here should also include accessibility concerns, especially to encourage accessible alternatives to to be adopted when the content is known to be inaccessible - e.g. images, sound files, movies, flash. HTML for instance has a number of accessible alternatives to inaccessible constructs - images have a src attribute, flash and embedded movies allow the child of the object element to contain accessible alternatives to the content. In the situation where an Atom Entry is presented to a human being, if one of those representations is HTML, e.g. (representing the non-textual content in HTML as an object element with a @src reference), then without the presence of accessible alternatives to inaccessible media, its going to be problematical, and downright impossible to generate accessible content for the user. May I suggest the following addition: "Where an Atom Entry with non-textual content is created for use by people - either in their browsers or screen readers, it must also include an equivalent accessible alternative." From the XML Accessibility Guidelines, Guideline 1.1 "1.1 Provide a mechanism to explicitly associate alternatives for content or content fragments. Authors using the elements/attributes in your language must have the ability to provide alternatives for any content, be it images, movies, songs, running text, whatever." We've got the mechanism - e.g. the summary and link elements of an Atom Entry, we need to highlight these uses in 4.2.13. Thanks, Mike From owner-atom-syntax@mail.imc.org Thu May 19 13:44:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28583 for ; Thu, 19 May 2005 13:44: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 j4JHVo3Z012246; Thu, 19 May 2005 10:31: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 j4JHVoA7012245; Thu, 19 May 2005 10:31:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JHVnjW012237 for ; Thu, 19 May 2005 10:31:50 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7935.lns6-c10.dsl.pol.co.uk ([84.68.190.255] helo=[192.168.0.2]) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.41) id 1DYos2-0002l0-9P; Thu, 19 May 2005 18:31:42 +0100 Message-ID: <428CCD72.8020003@isofarro.uklinux.net> Date: Thu, 19 May 2005 18:31:30 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Robert Sayre , atom-syntax Subject: Re: Consensus call on last raft of issues References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@mac.com> In-Reply-To: <3873F491-4D15-4BAD-8CAA-7E5C39F0DD3C@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: > > On 18 May 2005, at 9:36 pm, Robert Sayre wrote: > >> atom:entry elements are advised to contain ... a non-empty >> atom:summary element when the entry >> contains no atom:content element > > > I'd like us to advise including an atom:summary when atom:content is > binary (or for that matter, any non-text/html/xhtml type) +1 (From an accessibility perspective) From owner-atom-syntax@mail.imc.org Thu May 19 13:57:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29892 for ; Thu, 19 May 2005 13:57: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 j4JHjbrx015085; Thu, 19 May 2005 10:45: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 j4JHjbeT015084; Thu, 19 May 2005 10:45: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JHjarY015056 for ; Thu, 19 May 2005 10:45:36 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1516605wri for ; Thu, 19 May 2005 10:45:30 -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=nxDm5auiphVwota6sGHXnoLWAXIlA+Vb0gqGRV/5dfamJgsRcux7l4c/xgiZnskayh8I0wJDh/gvqk0OinEPfMSt6kA5DpNiZKtKusRKtgVQv6cfzgAeMAvyjMFTnyZ0Vmhevqgsd0WCWngBTFuqRvxaTeA0az/qg/oc1EW+mC4= Received: by 10.54.42.32 with SMTP id p32mr547877wrp; Thu, 19 May 2005 10:45:30 -0700 (PDT) Received: by 10.54.25.4 with HTTP; Thu, 19 May 2005 10:45:30 -0700 (PDT) Message-ID: <14be96d305051910452ae16e1a@mail.gmail.com> Date: Thu, 19 May 2005 13:45:30 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Isofarro Subject: Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues Cc: Tim Bray , Atom Syntax In-Reply-To: <428CCA66.8010504@isofarro.uklinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7518fb35fb3952de6590df9581989685@sun.com> <428CCA66.8010504@isofarro.uklinux.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JHjarY015069 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Isofarro wrote: > I'd urge that the wording here should also include accessibility > concerns, especially to encourage accessible alternatives to to be > adopted when the content is known to be inaccessible - e.g. images, > sound files, movies, flash. > > HTML for instance has a number of accessible alternatives to > inaccessible constructs - images have a src attribute, flash and > embedded movies allow the child of the object element to contain > accessible alternatives to the content. Presumably you mean "images have an alt attribute", but otherwise +1. Note that HTML 4 and beyond *require* an alt attribute for images, but does not similarly require non-script alternatives to script elements. Nor does it explicitly require accessible alternatives to embedded media such as Flash or video; the mechanism is present and encouraged, but ultimately optional. Since the last time this came up on the list, I have relaxed my position, and I am now fine with defining a feed format that encourages, but ultimately does not require, accessible content. Note that inaccessible content is A Bad Thing(tm) and in some contexts content producers will be legally or contractually obligated to provide it, but I will not go so far as to say that the format itself should force you to provide it. The format spec is the proper place to STRONGLY RECOMMEND that you provide accessible alternatives to inaccessible context (and we already have sufficient mechanisms to provide such alternatives), but I will no longer go so far as to call it a MUST. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 19 14:49:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05708 for ; Thu, 19 May 2005 14:49: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 j4JIWW3O021308; Thu, 19 May 2005 11:32: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 j4JIWWFk021307; Thu, 19 May 2005 11:32: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JIWVJT021297 for ; Thu, 19 May 2005 11:32:31 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1550472wri for ; Thu, 19 May 2005 11:32:26 -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=n4zC81/w/z/BisooPcoi7QDzzohVfvFEv3M0dfSZ1mX5g8DVCjMUyyB1SvtKoVuSH3uE3PTxg8ExKmxyaKxvISpDmFlM/kXRZ/nWVr6UgpAwVl0Yw54ZpNv+IX66PSelNKzwwuFo64KJGnlkCjA1NvKJo9ghGJkXYyeVqgNIpw4= Received: by 10.54.83.5 with SMTP id g5mr573923wrb; Thu, 19 May 2005 11:32:25 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Thu, 19 May 2005 11:32:25 -0700 (PDT) Message-ID: <540e373205051911326f3f6f29@mail.gmail.com> Date: Thu, 19 May 2005 13:32:25 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: Consensus call on last raft of issues In-Reply-To: <68fba5c5050518110378b53ceb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <68fba5c5050518110378b53ceb@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JIWVJT021302 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > RogerB specifically mentioned that TiVo users > squawked when he took away title-only feeds. Robert: Two things: (1) By "TiVo users", I was referring to the folks inhabiting TiVo's official message boards... my scraped, title-only feeds were better suited for a high-traffic forum than the native feeds produced by vBulletin or whatever they're using. So just to clarify, I was *not* referring to apps running on a TiVo box itself. The only non-hack RSS reader currently running on the TiVo platform just uses a proxy to access Bloglines, and therefore doesn't have any unique preference for or against summary-free feeds. (2) I support the notion of an Atom Processor. Tim's proposed language implies that dropping content-free entries on the floor is a failure to function correctly, which is misleading. Defining the distinction between "a thing that is looping over a series of XML entries to extract data" and "a thing that is displaying, manipulating, or otherwise making use of that data" would be useful. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu May 19 14:53:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06273 for ; Thu, 19 May 2005 14:52: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 j4JIePWq021806; Thu, 19 May 2005 11:40: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 j4JIeOVB021804; Thu, 19 May 2005 11:40: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-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 j4JIeOGe021797 for ; Thu, 19 May 2005 11:40:24 -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 j4JIeN0R029618 for ; Thu, 19 May 2005 12:40:23 -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 <0IGR0017Z2J9B9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 May 2005 12:40:23 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGR000AR2IQ8A@mail.sun.net> for atom-syntax@imc.org; Thu, 19 May 2005 12:40:11 -0600 (MDT) Date: Thu, 19 May 2005 05:41:15 -0700 From: Tim Bray Subject: Compulsory feed ID? In-reply-to: <428B692B.9060704@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 18, 2005, at 9:11 AM, Sam Ruby wrote: > There seemed to be consensus that feeds needed something to > identify > them. What there wasn't consensus on is which element should be > that identifier. The solution selected was to make none of the > identifiers required - something I don't think has much support, > and > furthermore creates problems with the ability to cite a source. Paul and I talked this over, and while we're not sure (the email trail was confusing) Sam may be right; so let's find out. Note that it seems pretty clear that the cost of requiring atom:id is nearly zero, since anyone who's generating Atom has to have an ID generator around for entries. So, let's find out if Sam is right: We suggest that there may be WG consensus in favor of changing the format spec to make atom:id a required child of atom:feed. (Text not provided, we trust the editors to figure out the correct way to say this). Please indicate agreement or disagreement with this proposition in the next day or two. From owner-atom-syntax@mail.imc.org Thu May 19 14:54:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06623 for ; Thu, 19 May 2005 14:54: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 j4JIePrC021815; Thu, 19 May 2005 11:40: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 j4JIePZG021814; Thu, 19 May 2005 11:40:25 -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 j4JIePOm021805 for ; Thu, 19 May 2005 11:40:25 -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 j4JIeO0R029639 for ; Thu, 19 May 2005 12:40:24 -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 <0IGR0017Z2J9B9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 May 2005 12:40:24 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGR000AR2IQ8A@mail.sun.net> for atom-syntax@imc.org; Thu, 19 May 2005 12:40:12 -0600 (MDT) Date: Thu, 19 May 2005 06:07:03 -0700 From: Tim Bray Subject: Non-empty elements In-reply-to: <68fba5c50505181336296efc83@mail.gmail.com> To: Atom Syntax Message-id: <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT > Some applications may choose to require a minimum amount of inline > text or (X)HTML data to function reliably and predictably. For that > reason, atom:entry elements are advised to contain a non-empty > atom:title element, a non-empty atom:summary element when the entry > contains no atom:content element, and a non-empty atom:content element > when that element is present. We observe that the paragraph above is getting support from the WG members who have been most engaged in this area of the discussion. Rephrasing slightly because I don't believe that XML elements are very responsive to advice. As an example freak, I'd also like to keep the concrete example of a full-text indexer from the consensus call. Thus, Paul and I consider that the following text has consensus support of the WG and the editors are directed to include it in the format draft (editorial judgment call on where to insert): Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. For that reason, it is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. -Tim From owner-atom-syntax@mail.imc.org Thu May 19 15:16:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09912 for ; Thu, 19 May 2005 15:16: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 j4JJ4dnp024124; Thu, 19 May 2005 12:04: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 j4JJ4dSR024123; Thu, 19 May 2005 12:04: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 j4JJ4b5R024116 for ; Thu, 19 May 2005 12:04:37 -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 j4JJ4bjO012295 for ; Thu, 19 May 2005 13:04: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 <0IGR00NGI3NO4Y@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 19 May 2005 13:04:37 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGR000JW3NO87@mail.sun.net> for atom-syntax@imc.org; Thu, 19 May 2005 13:04:36 -0600 (MDT) Date: Thu, 19 May 2005 12:04:38 -0700 From: Tim Bray Subject: Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues In-reply-to: <14be96d305051910452ae16e1a@mail.gmail.com> To: Mark Pilgrim Cc: Isofarro , Atom Syntax Message-id: <0092d74989c8cffbca8c09b3b1641e65@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <7518fb35fb3952de6590df9581989685@sun.com> <428CCA66.8010504@isofarro.uklinux.net> <14be96d305051910452ae16e1a@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 10:45 AM, Mark Pilgrim wrote: > On 5/19/05, Isofarro wrote: >> I'd urge that the wording here should also include accessibility >> concerns, especially to encourage accessible alternatives to to be >> adopted when the content is known to be inaccessible - e.g. images, >> sound files, movies, flash. > > Presumably you mean "images have an alt attribute", but otherwise +1. Right now our draft says: atom:entry elements MUST contain an atom:summary element in any of the following cases: ... - the atom:entry contains an atom:content that has a "src" attribute (and is thus empty). - the atom:entry contains content that is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [MIMEREG] and does not begin with "text/" nor end with "+xml". It seems to me that this addresses the concern, or am I missing something? -Tim From owner-atom-syntax@mail.imc.org Thu May 19 15:50:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15761 for ; Thu, 19 May 2005 15: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 j4JJaVKX030082; Thu, 19 May 2005 12:36: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 j4JJaVva030081; Thu, 19 May 2005 12:36: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JJaUmw030049 for ; Thu, 19 May 2005 12:36:30 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1482805wra for ; Thu, 19 May 2005 12:36:24 -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=G9rimdWebstE37CGL7+Y12yYTLhaIAyVjVIvMZ4eqXy5N2I710OZnERC5M3ppZg23Tr0IUYq5eNE8gs3d/7e5foyt80xtI3ZtxylUcGd/1iAVpSp8eXFoIoXPzwXJc0Mb/JGDUZ+ZIndrPnm80xExblVv1OLqgHwFzMLiYq6wXc= Received: by 10.54.7.16 with SMTP id 16mr1273002wrg; Thu, 19 May 2005 12:36:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 19 May 2005 12:36:23 -0700 (PDT) Message-ID: <68fba5c505051912364be862e4@mail.gmail.com> Date: Thu, 19 May 2005 15:36:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: Compulsory feed ID? Cc: Sam Ruby , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JJaVmw030075 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Tim Bray wrote: > > (Text not > provided, we trust the editors to figure out the correct way to say > this). The editors request that text be provided. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 19 15:50:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15828 for ; Thu, 19 May 2005 15:50: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 j4JJesrd031015; Thu, 19 May 2005 12:40: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 j4JJesNH031014; Thu, 19 May 2005 12:40: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JJerrl030983 for ; Thu, 19 May 2005 12:40:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1485411wra for ; Thu, 19 May 2005 12:40:48 -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=FzQDtSDURv3KM9UV8TbW5lYGRnraB9lBgRiBEsUhFJ8/sibnXp4eZhE8ClypzJuuqgl6I0qopvzlASVQWBkqYV9e5QD2l3M1q2mbCThOsoO2TyYQ0pbSWzPLJXp6jK3bHKQw8bK+2JDBZVo43SEVmYCWA8YB+VMe0sAYipax1BU= Received: by 10.54.16.60 with SMTP id 60mr929320wrp; Thu, 19 May 2005 12:40:48 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 19 May 2005 12:40:47 -0700 (PDT) Message-ID: <68fba5c505051912402e5b0995@mail.gmail.com> Date: Thu, 19 May 2005 15:40:47 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: Non-empty elements Cc: Atom Syntax In-Reply-To: <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JJerrl031001 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Tim Bray wrote: > > Paul and I consider that the following text has consensus support of > the WG and the editors are directed to include it in the format draft > (editorial judgment call on where to insert): > > Some applications (one example is full-text indexers) require a minimum > amount of text or (X)HTML to function reliably and predictably. For > that reason, it is advisable that each atom:entry element contain a > non-empty atom:title element, a non-empty atom:summary element when the > entry contains no atom:content element, and a non-empty atom:content > element when that element is present. > Is this text intended to replace the paragraph the editors were previously directed to insert? Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 19 15:52:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16451 for ; Thu, 19 May 2005 15: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 j4JJhpNQ031660; Thu, 19 May 2005 12:43: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 j4JJhpKA031659; Thu, 19 May 2005 12:43:51 -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 j4JJhoef031629 for ; Thu, 19 May 2005 12:43:50 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1487144wra for ; Thu, 19 May 2005 12:43:45 -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=SxzSoAMG5/AQ0HeT7Iy/aEVFh4nQ8NVSLTrVz3aNlsURilyaelxt2SGMnoi2N81xP6oaso4vtyQhKTV46xV10kKZynn6ujwRH1QHI5pCt4hfc8kQqvc9hGhdHjfam3SAHMgVleKUQyo2NGTogatnKyYZmLUlYGj3w4san9+OM/k= Received: by 10.54.79.8 with SMTP id c8mr577789wrb; Thu, 19 May 2005 12:43:44 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 19 May 2005 12:43:44 -0700 (PDT) Message-ID: <68fba5c50505191243ba68053@mail.gmail.com> Date: Thu, 19 May 2005 15:43:44 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: multiple ids 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 j4JJhoef031653 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit --------------- The editors are directed to modify the phrase which starts "If multiple atom:entry elements..." as follows: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." --------------- We don't use the word 'software' in the draft. The editors request replacement text. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 19 16:09:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23608 for ; Thu, 19 May 2005 16:09: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 j4JJwdbF035522; Thu, 19 May 2005 12:58: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 j4JJwdtI035521; Thu, 19 May 2005 12:58: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 j4JJwbsA035468 for ; Thu, 19 May 2005 12:58:38 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1496704wra for ; Thu, 19 May 2005 12:58:32 -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=QLUP24eddj731ssbpj3cdREy+HDXkbueOOvBk16Uo01THb6Nb9FMOb5/MXnjIoR/Neqv5k8ZAeT+SBy3D/s4n53196Fy/T9sxEmGGJn/pXQ4PdZLyIBqfLY8/j38c/ZTpejHvDdYQnxAFSMPDpQCFW9V6+cPQQtoFaKQFWj8UEM= Received: by 10.54.79.8 with SMTP id c8mr584658wrb; Thu, 19 May 2005 12:58:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 19 May 2005 12:58:31 -0700 (PDT) Message-ID: <68fba5c505051912583ff9d5c8@mail.gmail.com> Date: Thu, 19 May 2005 15:58:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax , Tim Bray , Paul Hoffman Subject: remote content? 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 j4JJwdsA035506 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I don't think we ever resolved this last call issue. http://www.imc.org/atom-syntax/mail-archive/msg14383.html Tim Bray wrote: > OK, WG, what do you think? I have long supported the SHOULD here, but > I can't help observing that a lot of different parties have > questioned it, I'm not 100% sure it really has consensus support, > even rough. Rob & John's alternative, as outlined above, seems like a > fair trade-off that would better reflect the community consensus and > not really harm interoperability. Anybody want to disagree? Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 19 16:33:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28236 for ; Thu, 19 May 2005 16:33: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 j4JKNYD1041623; Thu, 19 May 2005 13:23: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 j4JKNYSE041622; Thu, 19 May 2005 13:23:34 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JKNWwo041604 for ; Thu, 19 May 2005 13:23:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 19 May 2005 13:23:24 -0700 To: Atom WG From: Paul Hoffman Subject: Acknowledgements in the format draft 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. The nearly-nearly-complete format draft has a short list of contributors in Appendix A. This WG has been phenomenally active, and much of that activity is reflected in the specific text in the document. Wearing my co-chair hat, I can think of at least a dozen more people who should be listed in Appendix A because they helped shape the final output. Having said that, some people who have actively contributed to the spec may not want their names listed. If you would like to be listed in Appendix A because you have helped create the format document, please drop me a note. It is unlikely that we will get this into the next draft, but we have another shot after the IESG review, and I can't imagine that the IESG will mind adding more to this section. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 19 16:50:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29868 for ; Thu, 19 May 2005 16: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 j4JKd6AW046386; Thu, 19 May 2005 13:39: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 j4JKd6NC046385; Thu, 19 May 2005 13:39:06 -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 j4JKd5nM046368 for ; Thu, 19 May 2005 13:39:05 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4JKeia1000803; Thu, 19 May 2005 16:40:45 -0400 Message-ID: <428CF963.50609@intertwingly.net> Date: Thu, 19 May 2005 16:38:59 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Compulsory feed ID? References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > > On May 18, 2005, at 9:11 AM, Sam Ruby wrote: > >> There seemed to be consensus that feeds needed something to identify >> them. What there wasn't consensus on is which element should be >> that identifier. The solution selected was to make none of the >> identifiers required - something I don't think has much support, and >> furthermore creates problems with the ability to cite a source. > > Paul and I talked this over, and while we're not sure (the email trail > was confusing) Sam may be right; so let's find out. Note that it seems > pretty clear that the cost of requiring atom:id is nearly zero, since > anyone who's generating Atom has to have an ID generator around for > entries. So, let's find out if Sam is right: Permit me to provide some more background. I *think* that there is some desire that if the SAME entry appears in multiple places (say, TheServerSide, Java.net, Artima, etc.) that it not appear multiple times. This specific example was called out here: http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now#p-1 I appologize for referencing something outside of the mailing list, and if the item I cited does not represent the consensus of the working group, then the following text should be removed from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry - - - If, however, this above is what we desire (and I certainly support it), let's see what Bob's objection was: http://www.imc.org/atom-syntax/mail-archive/msg14470.html In that, he said: The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively erase entries written by another author. Now, lets take a look again at that text from PaceDuplicateIDs: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they represent the same entry. It seems to me that this does not solve the problem that Bob described. More specifically, if pubsub were to republish data from TheServerSide, Artima, or other places, then the "erasure" that Bob fears would come to pass. What's most puzzling is that it appears that PaceDuplicate IDs was specifically written in response to Bob's concerns: http://www.imc.org/atom-syntax/mail-archive/msg14731.html What is missing in all this is the following, again from Bob's original statement of the problem: Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URIs in self links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. This proposal seemed to have enjoyed some support, yet it did not seem to have made it into the current draft, despite being crucial to the solving the issue that PaceDuplicateIDs was designed to address. However, for it to work, the re-aggregator would need to have access to a "self" link, which is not required by the current draft. What should we do? One way to solve this is to require "id" *and* update Graham's original proposal accordingly, *and* incorporate it into the next (and presumably final draft). - - - That's what I meant by "There is a danger of looking at changes in isolation.": http://www.imc.org/atom-syntax/mail-archive/msg15292.html Of course, breaking any link in my complicated chain of logic above would cause the whole argument to collapse, which would be fine with me. Does anybody see something that I am missing? - Sam Ruby From owner-atom-syntax@mail.imc.org Thu May 19 17:13:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01968 for ; Thu, 19 May 2005 17:13: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 j4JL2aWI053236; Thu, 19 May 2005 14:02: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 j4JL2asW053235; Thu, 19 May 2005 14:02: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JL2Z8P053175 for ; Thu, 19 May 2005 14:02:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1535061wra for ; Thu, 19 May 2005 14:02:29 -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=obHLm2lEhYoMUKDOa/vWtyomkdiZipN81at91b1lBmtP1pmzGjJVFeuWbxHCNgKczlUhgday2X+qrmkxhcvDyzzBezZUT1YQMxxRaIssccDPCnCPPAT/iIl8KdMTFEamcWhn8dK2g/F1K6BItJj4IW83KHPlae5rnT5bccorMF0= Received: by 10.54.23.26 with SMTP id 26mr1231816wrw; Thu, 19 May 2005 14:02:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Thu, 19 May 2005 14:02:29 -0700 (PDT) Message-ID: <68fba5c505051914026329eb06@mail.gmail.com> Date: Thu, 19 May 2005 17:02:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: Compulsory feed ID? Cc: Tim Bray , Atom Syntax In-Reply-To: <428CF963.50609@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JL2Z8P053222 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Sam Ruby wrote: > Of course, breaking any link in my complicated chain of logic above > would cause the whole argument to collapse, which would be fine with me. Maybe the requirement is useless. "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and software MUST treat them as such." "MUST treat them as such" isn't particularly meaningful, and two atom:entry elements occuring anywhere are supposed to be describing the same entry. When I get CCed on an atom-syntax message, some of my email programs show two messages, and some show one. It's a security/annoyance trade-off, and I don't see why the format should be making that decision. Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 19 17:17:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02260 for ; Thu, 19 May 2005 17:17: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 j4JL7mrK054284; Thu, 19 May 2005 14:07: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 j4JL7m37054283; Thu, 19 May 2005 14:07:48 -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 j4JL7lpa054276 for ; Thu, 19 May 2005 14:07:47 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4JL7kjS016071 for ; Thu, 19 May 2005 15:07:47 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IGR00B0196EDP@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 19 May 2005 17:07:46 -0400 (EDT) Received: from localhost (vpn-129-150-32-211.Central.Sun.COM [129.150.32.211]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IGR001VB9CXNK@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 19 May 2005 17:07:46 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DYsEx-0007IC-Sg for atom-syntax@imc.org; Thu, 19 May 2005 17:07:35 -0400 X-URL: http://nwalsh.com/ Date: Thu, 19 May 2005 17:07:35 -0400 From: Norman Walsh Subject: Re: Compulsory feed ID? In-reply-to: <428CF963.50609@intertwingly.net> To: atom-syntax@imc.org Message-id: <87sm0ic4bs.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Sam Ruby was heard to say: | What should we do? One way to solve this is to require "id" *and* update | Graham's original proposal accordingly, *and* incorporate it into the next | (and presumably final draft). | | - - - | | That's what I meant by "There is a danger of looking at changes in | isolation.": | | http://www.imc.org/atom-syntax/mail-archive/msg15292.html | | Of course, breaking any link in my complicated chain of logic above would | cause the whole argument to collapse, which would be fine with me. | | Does anybody see something that I am missing? I have to say that the DoS issue hadn't occurred to me before Bob raised it and I've been a bit depressed about it ever since it came up. Is there really anything that we can do here, short of providing a mechanism for signing entries and telling aggregators that a duplicate is an entry with the same id and the same signature? Seems to me if I'm unscrupulous enough to attempt DoS, I can fake all of the required parameters. /me shrugs Be seeing you, norm =2D-=20 Norman Walsh | Happiness is a how, not a what; a http://nwalsh.com/ | talent, not an object.--Herman Hesse --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCjQAXOyltUcwYWjsRAsX6AJ9roPYt9/LhwErjq2Js/ATOatdtCACdGGii +nn0as9KhgDYNJpbnNPyAO4= =oZDg -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu May 19 17:18:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02376 for ; Thu, 19 May 2005 17:18: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 j4JL8spx054545; Thu, 19 May 2005 14:08: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 j4JL8sDP054544; Thu, 19 May 2005 14:08:54 -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 j4JL8sD3054537 for ; Thu, 19 May 2005 14:08:54 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4JL8m0R024432 for ; Thu, 19 May 2005 15:08:54 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IGR00C019ECSG@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 19 May 2005 17:08:48 -0400 (EDT) Received: from localhost (vpn-129-150-32-211.Central.Sun.COM [129.150.32.211]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IGR0011G9ENNK@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 19 May 2005 17:08:48 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DYsFx-0007IS-HS for atom-syntax@imc.org; Thu, 19 May 2005 17:08:37 -0400 X-URL: http://nwalsh.com/ Date: Thu, 19 May 2005 17:08:37 -0400 From: Norman Walsh Subject: Re: Non-empty elements In-reply-to: <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> To: atom-syntax@imc.org Message-id: <87oeb6c4a2.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Tim Bray was heard to say: | | Paul and I consider that the following text has consensus support of the = WG | and the editors are directed to include it in the format draft (editorial | judgment call on where to insert): | | Some applications (one example is full-text indexers) require a minimum | amount of text or (X)HTML to function reliably and predictably. For that | reason, it is advisable that each atom:entry element contain a non-empty | atom:title element, a non-empty atom:summary element when the entry | contains no atom:content element, and a non-empty atom:content element wh= en | that element is present. | +1 Be seeing you, norm =2D-=20 Norman Walsh | The first step towards madness is to http://nwalsh.com/ | think oneself wise.--Fernando De Rojas --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCjQBVOyltUcwYWjsRApBQAJ9RmGI4rbKsgh8h39OAFaxfAfE+XACdE3Pc lPtqA4gChhyb8fW9AJ+VuN4= =xTsv -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu May 19 17:51:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04824 for ; Thu, 19 May 2005 17:51: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 j4JLX20N059863; Thu, 19 May 2005 14:33: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 j4JLX2HI059862; Thu, 19 May 2005 14:33: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLX1eI059837 for ; Thu, 19 May 2005 14:33:01 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1047687nzk for ; Thu, 19 May 2005 14:32:56 -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=b6C8RnScE5eqpXJwsgpUVoKU3+J3LlxtH/DC9jIX2BfaXwBLgEQfL8UiMT+r/YxDUG4SAcmh7fUrN+aXgonhn1qYlMRYvG1wOE28nfLAxWbohdrynB9dH7l4iFVFe+hdwbVTirlaEyk4a1pUDqLqJH7d4G/OmJOyp92D6X0ld18= Received: by 10.36.82.7 with SMTP id f7mr615586nzb; Thu, 19 May 2005 14:32:56 -0700 (PDT) Received: by 10.36.50.4 with HTTP; Thu, 19 May 2005 14:32:56 -0700 (PDT) Message-ID: <1f2ed5cd05051914321299c4c@mail.gmail.com> Date: Thu, 19 May 2005 23:32:56 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: Compulsory feed ID? Cc: Tim Bray , Atom Syntax In-Reply-To: <428CF963.50609@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JLX2eI059857 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Sam Ruby wrote: > Graham Park has proposed that we loosen the existing language to > permit duplicate ids in the case where the entries have atom:source > elements which identify different URI's in "self" links. I support > this compromise and believe it should be supported by the WG and > incorporated into the Atom Draft. I believe it makes sense to give the notional "atoms" (entries) individual identifiers which will be preserved globally, irrespective of the source, irrespective of where the entries are found - so yes, duplicate IDs in a feed seem an acceptable scenario. I don't personally care how it's done, but a reference back from the feed document to the URI from whence it is begetted is pretty essential for the easier one-click subscription strategies, and should come in handy later for aggregate-republish processing. I think a reference back to the source (original better, intermediate better than nothing) is also desirable to help reduce duplicate posts appearing in any end-of-chain UI. Take this scenario - two entries identical in every respect *except* for their ID. Any resource on the Web may have any number of different URIs, which suggests any entry might /potentially/ have any number of IDs. Should the two entries be allowed in the same feed? If you change the name of an entry, do you change its nature? Sorry, slipping, it's a bit late here - scratch the philosophy, ;-) Basically I reckon duplicate IDs in a feed are ok - leave it to the (final or intermediate) consumer to filter out if required according to local rules/heuristics. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu May 19 18:03:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05829 for ; Thu, 19 May 2005 18: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 j4JLmvUh063204; Thu, 19 May 2005 14:48: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 j4JLmvob063203; Thu, 19 May 2005 14:48: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLmuOk063180 for ; Thu, 19 May 2005 14:48:56 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1678984wri for ; Thu, 19 May 2005 14:48:50 -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=HXuSbfNXEwFxrvZ5FOrzFkWHSMXRmzPYQlPv1SKZschhmHe8j1OjV9tzhXuzVCkOLNakGfaCRmoD4pVBJ6EL1TW2TkraZ0eU0Vqn9qdaywlP9NGbWkUX1OMSdo7HXEkXRv2gbyPYGG5hnjyJE56lnp32gN/RfTw2fyUDl+5hpMw= Received: by 10.54.79.16 with SMTP id c16mr1419942wrb; Thu, 19 May 2005 14:48:50 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Thu, 19 May 2005 14:48:50 -0700 (PDT) Message-ID: <540e373205051914482a872ad6@mail.gmail.com> Date: Thu, 19 May 2005 16:48:50 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Non-empty elements In-Reply-To: <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JLmuOk063198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Rephrasing slightly... + 1 -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu May 19 18:46:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11290 for ; Thu, 19 May 2005 18:46: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 j4JMX89c070554; Thu, 19 May 2005 15:33: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 j4JMX8hR070553; Thu, 19 May 2005 15:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JMX7Fd070524 for ; Thu, 19 May 2005 15:33:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4JMVu7i020469; Thu, 19 May 2005 23:32:01 +0100 (BST) In-Reply-To: <428CF963.50609@intertwingly.net> References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42C6A283-D817-4AA1-BA88-736E8C00381A@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Compulsory feed ID? Date: Thu, 19 May 2005 23:31:54 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19 May 2005, at 9:38 pm, Sam Ruby wrote: > What should we do? One way to solve this is to require "id" *and* > update Graham's original proposal accordingly, *and* incorporate it > into the next (and presumably final draft). The original proposal actually relied on ids: http://www.intertwingly.net/wiki/pie/PaceDuplicateIDWithSource Just to be clear, the idea wasn't that an entry would have a concatenated entry:id-source:id as its identifier. The entry:id would still be primary, its just multiple versions received from different sources could be represented. > If multiple atom:entry elements with the same atom:id value > appear in > an Atom Feed document, they represent the same entry. > > It seems to me that this does not solve the problem that Bob > described. More specifically, if pubsub were to republish data > from TheServerSide, Artima, or other places, then the "erasure" > that Bob fears would come to pass. I don't really believe this to be so. An aggregator can treat them as the same entry without having one overwrite the other. It can easily present to the user "Here's the version from Site A" and "Here's the version from Site B". That was kind of the idea of PaceDuplicateIDWithSource. Of course, the atom:source element is as fakeable as the entry's id. The only reliable origin is the URI it was directly fetched from. Oh, and compulsory feed:ids are fine with me. Certainly better than the hybrid proposals. Graham From owner-atom-syntax@mail.imc.org Thu May 19 19:57:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18025 for ; Thu, 19 May 2005 19:57: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 j4JNliKm083390; Thu, 19 May 2005 16:47: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 j4JNliPl083389; Thu, 19 May 2005 16:47:44 -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 j4JNlgVs083372 for ; Thu, 19 May 2005 16:47:43 -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); Fri, 20 May 2005 09:47:48 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 May 2005 09:47:36 +1000 Subject: Re: Compulsory feed ID? 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 19/5/05 10:41 PM, "Tim Bray" wrote: > We suggest that there may be WG consensus in favor of changing the > format spec to make atom:id a required child of atom:feed. (Text not > provided, we trust the editors to figure out the correct way to say > this). Please indicate agreement or disagreement with this proposition > in the next day or two. wth, +1 From owner-atom-syntax@mail.imc.org Thu May 19 19:59:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18092 for ; Thu, 19 May 2005 19:59: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 j4JNjKBN082899; Thu, 19 May 2005 16:45: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 j4JNjKNo082898; Thu, 19 May 2005 16:45:20 -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 j4JNjInJ082862 for ; Thu, 19 May 2005 16:45:19 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1738442wri for ; Thu, 19 May 2005 16:45: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=rMqPerrz659JPl4MIOjFwY8RnKWAlj/TBmXaB4vOxYgNWM/DUS2AGfVJ+OuQONxfnXVyJA2aAPYAqbIId7OGc7OBT4G3Wscyr0S4ztNvNbVpYpEmvFmmhLW+vKcV1ZzZXoIJke1TnSfIOCelFJ1MHvdRfLRbCe4ZzgxDT/jXZSk= Received: by 10.54.135.7 with SMTP id i7mr1487140wrd; Thu, 19 May 2005 16:45:13 -0700 (PDT) Received: by 10.54.25.4 with HTTP; Thu, 19 May 2005 16:45:12 -0700 (PDT) Message-ID: <14be96d305051916456ab0218d@mail.gmail.com> Date: Thu, 19 May 2005 19:45:12 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Tim Bray Subject: Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues Cc: Isofarro , Atom Syntax In-Reply-To: <0092d74989c8cffbca8c09b3b1641e65@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <7518fb35fb3952de6590df9581989685@sun.com> <428CCA66.8010504@isofarro.uklinux.net> <14be96d305051910452ae16e1a@mail.gmail.com> <0092d74989c8cffbca8c09b3b1641e65@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JNjJnJ082884 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Tim Bray wrote: > Right now our draft says: > > atom:entry elements MUST contain an atom:summary element in any of the > following cases: > ... > - the atom:entry contains an atom:content that has a "src" attribute > (and is thus empty). > - the atom:entry contains content that is encoded in Base64; i.e. the > "type" attribute of atom:content is a MIME media type [MIMEREG] and > does not begin with "text/" nor end with "+xml". I'm saying that "MUST" is probably too strong here. I don't mind it personally, but I don't see the case for requiring it on grounds of interoperability. If we keep it, the format spec should probably mention *why* this is required, if only in passing. Then again, if it got changed to "SHOULD", I wouldn't raise holy hell about it. But I'm not going to write a Pace to change it. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Thu May 19 20:20:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20834 for ; Thu, 19 May 2005 20:20: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 j4K0AZOq088464; Thu, 19 May 2005 17: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 j4K0AZVA088463; Thu, 19 May 2005 17:10:35 -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 j4K0AYnV088446 for ; Thu, 19 May 2005 17:10:35 -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 <2005052000102801400nqii7e>; Fri, 20 May 2005 00:10:28 +0000 Date: Thu, 19 May 2005 18:10:27 -0600 Subject: Re: Compulsory feed ID? 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: <91A34C85-C8C3-11D9-B7C5-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, May 19, 2005, at 06:41 AM, Tim Bray wrote: > We suggest that there may be WG consensus in favor of changing the > format spec to make atom:id a required child of atom:feed. (Text not > provided, we trust the editors to figure out the correct way to say > this). Please indicate agreement or disagreement with this > proposition in the next day or two. > Since I've already expressed my opinions on this issue, I'll be brief just to register my opinion in this thread. I don't think atom:id is the most useful possible identifier, so this isn't my first choice. But if we can't agree to use a better one, it'll be better than nothing. From owner-atom-syntax@mail.imc.org Thu May 19 20:27:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21391 for ; Thu, 19 May 2005 20:27: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 j4K0HAZO089735; Thu, 19 May 2005 17:17: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 j4K0HA7f089734; Thu, 19 May 2005 17:17:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K0H9Yg089710 for ; Thu, 19 May 2005 17:17:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4K0G42s007392; Fri, 20 May 2005 01:16:10 +0100 (BST) In-Reply-To: <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <837948B8-D072-4EBA-B529-07ED55380A5A@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Non-empty elements Date: Fri, 20 May 2005 01:16:03 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19 May 2005, at 2:07 pm, Tim Bray wrote: > Some applications (one example is full-text indexers) require a > minimum amount of text or (X)HTML to function reliably and > predictably. For that reason, it is advisable that each atom:entry > element contain a non-empty atom:title element, a non-empty > atom:summary element when the entry contains no atom:content > element, and a non-empty atom:content element when that element is > present. I find the conflation of presence and emptiness a little opaque. I'd rather the text said that, in general, when any of these elements are present they shouldn't be empty. The other part of this text, that summary be present when content isn't, can then be separated out for the sake of clarity. Otherwise, it's fine. Graham From owner-atom-syntax@mail.imc.org Thu May 19 23:55:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08439 for ; Thu, 19 May 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 j4K3fxmN031765; Thu, 19 May 2005 20:41: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 j4K3fxUm031763; Thu, 19 May 2005 20:41:59 -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 j4K3ftgO031728 for ; Thu, 19 May 2005 20:41:57 -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); Fri, 20 May 2005 13:41:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 May 2005 13:41:49 +1000 Subject: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4K3fxgO031757 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I see this as a problem... > 4.1.2The "atom:entry" Element > > * atom:entry elements MUST contain exactly one atom:author element, unless > the atom:entry contains an atom:source element which contains an atom:author > element, or, in an Atom Feed Document, the atom:feed element contains an > atom:author element itself. > * atom:entry elements MUST NOT contain more than one atom:author element. Science Journals are just one example of feeds which require being able to specify multiple authors per entry. I have Library clients who want to make their indexing efforts available in XML form - currently I can recommend RSS 1.0, but I would like to be able to recommend Atom 1.0 when it becomes available. With a one-author-per-article restriction this would be impossible. Shall I write a Pace? e. From owner-atom-syntax@mail.imc.org Fri May 20 00:23:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11276 for ; Fri, 20 May 2005 00:23: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 j4K4ArpN038626; Thu, 19 May 2005 21:10: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 j4K4Argw038625; Thu, 19 May 2005 21:10:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K4Aqtw038589 for ; Thu, 19 May 2005 21:10:53 -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 (rwcrmhc11) with SMTP id <2005052004104501300phb3oe>; Fri, 20 May 2005 04:10:45 +0000 Date: Thu, 19 May 2005 22:10:44 -0600 Subject: Re: multiple atom:author elements? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: Message-Id: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4K4Artw038618 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: > I see this as a problem... >> 4.1.2The "atom:entry" Element >> >> * atom:entry elements MUST contain exactly one atom:author element, >> unless >> the atom:entry contains an atom:source element which contains an >> atom:author >> element, or, in an Atom Feed Document, the atom:feed element >> contains an >> atom:author element itself. >> * atom:entry elements MUST NOT contain more than one atom:author >> element. > > Science Journals are just one example of feeds which require being > able to > specify multiple authors per entry. I have Library clients who want to > make > their indexing efforts available in XML form - currently I can > recommend RSS > 1.0, but I would like to be able to recommend Atom 1.0 when it becomes > available. With a one-author-per-article restriction this would be > impossible. > > Shall I write a Pace? If we do allow multiple authors, we might want to put a warning in that consuming applications MAY ignore some of them if more than one is supplied. As long as we do that, and perhaps even if not, I'd be in favor of allowing more than one. From owner-atom-syntax@mail.imc.org Fri May 20 00:51:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12981 for ; Fri, 20 May 2005 00:51: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 j4K4fFb4045872; Thu, 19 May 2005 21: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 j4K4fFXK045871; Thu, 19 May 2005 21:41:15 -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 j4K4fErp045857 for ; Thu, 19 May 2005 21:41:15 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id D53F04F0E7; Fri, 20 May 2005 00:41:13 -0400 (EDT) Date: Fri, 20 May 2005 00:41:13 -0400 From: Dan Brickley To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: multiple atom:author elements? Message-ID: <20050520044113.GA12760@homer.w3.org> References: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Antone Roundy [2005-05-19 22:10-0600] > > On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote: > >I see this as a problem... > >>4.1.2The "atom:entry" Element > >> > >>* atom:entry elements MUST contain exactly one atom:author element, > >>unless > >> the atom:entry contains an atom:source element which contains an > >>atom:author > >> element, or, in an Atom Feed Document, the atom:feed element > >>contains an > >> atom:author element itself. > >>* atom:entry elements MUST NOT contain more than one atom:author > >>element. > > > >Science Journals are just one example of feeds which require being > >able to > >specify multiple authors per entry. I have Library clients who want to > >make > >their indexing efforts available in XML form - currently I can > >recommend RSS > >1.0, but I would like to be able to recommend Atom 1.0 when it becomes > >available. With a one-author-per-article restriction this would be > >impossible. > > > >Shall I write a Pace? > > If we do allow multiple authors, we might want to put a warning in that > consuming applications MAY ignore some of them if more than one is > supplied. As long as we do that, and perhaps even if not, I'd be in > favor of allowing more than one. Consuming apps can do whatever they like; that's a freedom this spec can't offer, or restrict. It's just a document. Atom's job here imho is to be clear about what the document means. It's much easier to standardise on a type of document, than a type of software application for consuming those documents. (I support allowing multiple authors, fwiw) Dan From owner-atom-syntax@mail.imc.org Fri May 20 01:12:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14599 for ; Fri, 20 May 2005 01:12: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 j4K51hTD050537; Thu, 19 May 2005 22:01: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 j4K51hiP050536; Thu, 19 May 2005 22:01:43 -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 j4K51Zmt050436 for ; Thu, 19 May 2005 22:01:41 -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); Fri, 20 May 2005 15:01:39 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 May 2005 15:01:15 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.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 20/5/05 2:10 PM, "Antone Roundy" wrote: > If we do allow multiple authors, we might want to put a warning in that > consuming applications MAY ignore some of them if more than one is > supplied. As long as we do that, and perhaps even if not, I'd be in > favor of allowing more than one. I'm happy with that - the market will sort out what is an acceptable level of support. I really don't want to see this in an Atom feed: Raggett, D, Hors, A, and I Jacobs (perfectly acceptable for display, but not for data) e. From owner-atom-syntax@mail.imc.org Fri May 20 02:14:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02057 for ; Fri, 20 May 2005 02: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 j4K5vigJ085512; Thu, 19 May 2005 22:57: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 j4K5vidt085511; Thu, 19 May 2005 22:57:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailm1.svr.pol.co.uk (cmailm1.svr.pol.co.uk [195.92.193.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K5vhqD085488 for ; Thu, 19 May 2005 22:57:43 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-7935.lns6-c10.dsl.pol.co.uk ([84.68.190.255] helo=[192.168.0.2]) by cmailm1.svr.pol.co.uk with esmtp (Exim 4.41) id 1DZ0Vw-00070p-UV; Fri, 20 May 2005 06:57:41 +0100 Message-ID: <428D7C47.5030505@isofarro.uklinux.net> Date: Fri, 20 May 2005 06:57:27 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Pilgrim CC: Tim Bray , Atom Syntax Subject: Re: PaceTextShouldBeProvided and accessibility - was Re: Consensus call on last raft of issues References: <7518fb35fb3952de6590df9581989685@sun.com> <428CCA66.8010504@isofarro.uklinux.net> <14be96d305051910452ae16e1a@mail.gmail.com> <0092d74989c8cffbca8c09b3b1641e65@sun.com> <14be96d305051916456ab0218d@mail.gmail.com> In-Reply-To: <14be96d305051916456ab0218d@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 Mark Pilgrim wrote: > On 5/19/05, Tim Bray wrote: [atom:summary and accessibility] >>Right now our draft says: >> >>atom:entry elements MUST contain an atom:summary element in any of the >>following cases: >>... >>- the atom:entry contains an atom:content that has a "src" attribute >>(and is thus empty). >>- the atom:entry contains content that is encoded in Base64; i.e. the >>"type" attribute of atom:content is a MIME media type [MIMEREG] and >>does not begin with "text/" nor end with "+xml". > > > I'm saying that "MUST" is probably too strong here. I don't mind it > personally, but I don't see the case for requiring it on grounds of > interoperability. If we keep it, the format spec should probably > mention *why* this is required, if only in passing. +1 Particulary on the first point above "atom:content that has a "src" attribute", "MUST" is a bit heavy handed for accesibility, since the "src" attribute could reference an accessible resource - like an external html file. Its when "src" references an inaccessible resource is it essential that atom:summary convey an accessible equivalent. The second point about Base64 encoding, "MUST" or "strongly recommended/encouraged for the purpose of accessibility" is needed. In respect to Mark's suggestion of mentioning why: Perhaps "4.2.13 The "atom:summary" element" is a good place to mention the accessibility. As an initial suggestion, after the first paragraph of "The "atom:summary" element is a Text construct that conveys a short summary, abstract or excerpt of an entry." Insert the paragraph: " In cases where atom:content is Base64 encoded, or has a "src" attribute, the atom:summary conveys an accessible text equivalent to the non-text atom:content." > Then again, if it got changed to "SHOULD", I wouldn't raise holy hell > about it. But I'm not going to write a Pace to change it. That suits me fine too. Thanks, Mike From owner-atom-syntax@mail.imc.org Fri May 20 03:50:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16581 for ; Fri, 20 May 2005 03:50: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 j4K70Na9005452; Fri, 20 May 2005 00:00: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 j4K70NKa005451; Fri, 20 May 2005 00:00:23 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K70Jg7005437 for ; Fri, 20 May 2005 00:00:22 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-104.dti.cegetel.net [217.19.192.104]) by smtp.cegetel.net (Postfix) with SMTP id 2F9F23187D6 for ; Fri, 20 May 2005 09:00:07 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Fri, 20 May 2005 09:00:10 +0200 (CEST) Message-ID: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> Date: Fri, 20 May 2005 09:00:10 +0200 (CEST) Subject: Editorial: rules based on MIME media types in @type attributes From: "Thomas Broyer" To: X-Priority: 3 Importance: Normal 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 I'd like to raise this up one more time: http://www.imc.org/atom-syntax/mail-archive/msg14247.html Atom defines rules based on MIME media types in @type attributes, and I'm not sure they are actually accurate... They also don't explain the actual meaning behind the technical rules. In 4.1.3.2: [ If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided. ] Replace with: [ If the value of type is a text or XML media type, that is, if it begins with "text/", is one the XML Media Types [XMLMIME] or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided. ] In 4.1.3.3: [ 4. If the value of "type" ends with "+xml" or "/xml" (case-insensitive), the content of atom:content MAY include child elements, and SHOULD be suitable for handling as the indicated media type. [...] ] Replace with: [ 4. If the value of "type" is an XML media type, that is, if it is one of the XML Media Types [XMLMIME] or ends with "+xml" (case-insensitive), the content of atom:content MAY include child elements, and SHOULD be suitable for handling as the indicated media type. [...] ] Note that the above (in 4.1.3.3) uses "(case-insensitive)" while the first (in 4.1.3.2) doesn't. I didn't fix it but I think someone should. In 4.1.3.3: [ 5. If the value of "type" begins with "text/" (case-insensitive), the content of atom:content MUST NOT contain child elements. ] Replace with: [ 5. If the value of "type" is a text media type, that is, if it begins with "text/" (case-insensitive), the content of atom:content MUST NOT contain child elements. ] As Julian raised at that time, having to apply the 4.1.3.3 rules in order is not explicit and thus quite confusing. [XMLMIME] http://www.ietf.org/rfc/rfc3023.txt -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri May 20 05:01:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21928 for ; Fri, 20 May 2005 05:01: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 j4K8hxXq021549; Fri, 20 May 2005 01:43: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 j4K8hxUO021548; Fri, 20 May 2005 01:43: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 j4K8huVC021493 for ; Fri, 20 May 2005 01:43:57 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 20 May 2005 06:57:11 -0000 Received: from p508FB147.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.177.71] by mail.gmx.net (mp029) with SMTP; 20 May 2005 08:57:11 +0200 X-Authenticated: #1915285 Message-ID: <428D8A44.8070608@gmx.de> Date: Fri, 20 May 2005 08:57:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: multiple atom:author elements? References: In-Reply-To: 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 Eric Scheid wrote: > On 20/5/05 2:10 PM, "Antone Roundy" wrote: > > >>If we do allow multiple authors, we might want to put a warning in that >>consuming applications MAY ignore some of them if more than one is >>supplied. As long as we do that, and perhaps even if not, I'd be in >>favor of allowing more than one. > > > I'm happy with that - the market will sort out what is an acceptable level > of support. > > I really don't want to see this in an Atom feed: > > Raggett, D, Hors, A, and I Jacobs > > (perfectly acceptable for display, but not for data) +1 As a general rule: trying to forbid reasonable things usually causes producers to look for workarounds that seem to "work" in most clients. This is a very nice example where insisting on a single entry will probably do more harm than allowing multiple entries. Julian From owner-atom-syntax@mail.imc.org Fri May 20 06:20:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27570 for ; Fri, 20 May 2005 06:20: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 j4KA595C050981; Fri, 20 May 2005 03:05: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 j4KA59rA050980; Fri, 20 May 2005 03:05: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KA57Pv050832 for ; Fri, 20 May 2005 03:05:07 -0700 (PDT) (envelope-from jalkanen@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so2019390wri for ; Fri, 20 May 2005 03:05:01 -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=Nf72vjPyenMYENLGB3fJkL6ElPqe8Bdx2XxGMmPWzEN1fSNXKFCAaDxY3587wbV6ymezJ88fHZdWsrR3MF9WoGC2KObTBASpRYHBntVtXNuS5JkGoVfz8gz/y51gbuCgfRmgWXjOSjbvuz+ZmI7lS6maliCE7zpkLBtyz78E/AE= Received: by 10.54.27.65 with SMTP id a65mr1791267wra; Fri, 20 May 2005 03:05:01 -0700 (PDT) Received: by 10.54.28.73 with HTTP; Fri, 20 May 2005 03:05:01 -0700 (PDT) Message-ID: <7aebae7d05052003052080bafe@mail.gmail.com> Date: Fri, 20 May 2005 13:05:01 +0300 From: Janne Jalkanen Reply-To: Janne Jalkanen To: Julian Reschke Subject: Re: multiple atom:author elements? Cc: Atom Syntax In-Reply-To: <428D8A44.8070608@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428D8A44.8070608@gmx.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KA57Pv050970 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > >>If we do allow multiple authors, we might want to put a warning in that > >>consuming applications MAY ignore some of them if more than one is > >>supplied. As long as we do that, and perhaps even if not, I'd be in > >>favor of allowing more than one. +1 from me as well, from the Wiki perspective. If you want to do things like "daily feeds", you're going to get more than one author. /Janne From owner-atom-syntax@mail.imc.org Fri May 20 07:27:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02747 for ; Fri, 20 May 2005 07:27: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 j4KBEmUT079868; Fri, 20 May 2005 04:14: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 j4KBEmCd079867; Fri, 20 May 2005 04:14:48 -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 j4KBElN8079830 for ; Fri, 20 May 2005 04:14:47 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1905131wra for ; Fri, 20 May 2005 04:14:41 -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=BZrbRCdgY4xZ/dt14NlrRs4klqa+2WdeZtdS2dE+ZO0U0wBlBLzulq5/MOtaxz9/PqzsvWQGmkQ5ozqqqssatePMJYV+Oj7RPCddRX6S7OF5l6bNfrYWNUwV8QpsksrgmhRgeAZVqLgoxWHTfkh64Vo2iTUghMKj2fnjSsXteRs= Received: by 10.54.117.4 with SMTP id p4mr1647902wrc; Fri, 20 May 2005 04:14:40 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 04:14:40 -0700 (PDT) Message-ID: <68fba5c5050520041439e15ac1@mail.gmail.com> Date: Fri, 20 May 2005 07:14:40 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: multiple atom:author elements? Cc: Atom Syntax 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 j4KBElN8079858 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/19/05, Eric Scheid wrote: > Science Journals are just one example of feeds which require being able to > specify multiple authors per entry. I have Library clients who want to make > their indexing efforts available in XML form - currently I can recommend RSS > 1.0, but I would like to be able to recommend Atom 1.0 when it becomes > available. With a one-author-per-article restriction this would be > impossible. -1. This is an edge case, and one that's not covered by RSS 1.0, btw. Dublin Core elements make perfect sense in an Atom feed. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 07:35:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03223 for ; Fri, 20 May 2005 07:35: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 j4KBMd9c082801; Fri, 20 May 2005 04:22: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 j4KBMd7G082800; Fri, 20 May 2005 04:22:39 -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 j4KBMccm082760 for ; Fri, 20 May 2005 04:22:39 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 92596 messnum 5277028 invoked from network[213.94.211.166/dev2.mcpps.com]); 20 May 2005 11:22:32 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 92596) with SMTP; 20 May 2005 11:22:32 -0000 Message-ID: <428DC876.9000200@dehora.net> Date: Fri, 20 May 2005 12:22:30 +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: multiple atom:author elements? 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: > Science Journals are just one example of feeds which require being able to > specify multiple authors per entry. I have Library clients who want to make > their indexing efforts available in XML form - currently I can recommend RSS > 1.0, but I would like to be able to recommend Atom 1.0 when it becomes > available. With a one-author-per-article restriction this would be > impossible. > > Shall I write a Pace? Legal documents and legislation are others. Good catch Eric. I'll support this. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 20 07:36:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03263 for ; Fri, 20 May 2005 07:36: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 j4KBPdLx083807; Fri, 20 May 2005 04: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 j4KBPdfF083806; Fri, 20 May 2005 04:25:39 -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 j4KBPcSI083765 for ; Fri, 20 May 2005 04:25:39 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 15076 messnum 6398709 invoked from network[213.94.211.166/dev2.mcpps.com]); 20 May 2005 11:25:32 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail00.svc.cra.dublin.eircom.net (qp 15076) with SMTP; 20 May 2005 11:25:32 -0000 Message-ID: <428DC92A.1000504@dehora.net> Date: Fri, 20 May 2005 12:25:30 +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: multiple atom:author elements? References: <68fba5c5050520041439e15ac1@mail.gmail.com> In-Reply-To: <68fba5c5050520041439e15ac1@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: > -1. This is an edge case, and one that's not covered by RSS 1.0, btw. > Dublin Core elements make perfect sense in an Atom feed. DC elements makes sense, but we have consistently chosen not to use them. So, if consensus is that it's not an edge case, then that would argue in favour of designing something into the format. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 20 07:55:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04873 for ; Fri, 20 May 2005 07: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 j4KBgfWv089814; Fri, 20 May 2005 04:42: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 j4KBgfEC089813; Fri, 20 May 2005 04:42:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KBge1A089775 for ; Fri, 20 May 2005 04:42:40 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4KBeEpF020563; Fri, 20 May 2005 12:40:20 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <998597A5-665B-4023-9D9D-DE3950DEC98D@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: multiple atom:author elements? Date: Fri, 20 May 2005 12:40:16 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 May 2005, at 4:41 am, Eric Scheid wrote: > I have Library clients who want to make their indexing efforts > available in XML form - currently I can recommend RSS > 1.0, but I would like to be able to recommend Atom 1.0 when it becomes > available. With a one-author-per-article restriction this would be > impossible. The one author restriction isn't really necessary. My only problem is with our "order is not significant" rule since there's a strong likelihood that authors will be displayed in the the order they appear in the XML, and that publishers will expect it. Graham From owner-atom-syntax@mail.imc.org Fri May 20 08:01:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05344 for ; Fri, 20 May 2005 08:01: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 j4KBpPVU092772; Fri, 20 May 2005 04:51: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 j4KBpPlR092771; Fri, 20 May 2005 04:51: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 j4KBpOWk092738 for ; Fri, 20 May 2005 04:51:25 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1922415wra for ; Fri, 20 May 2005 04:51:19 -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=FaxyhiPuS9mzE4Wd17y/f0Fjf38N9NWEEBm8Y8oiea3SJSsGM4D40v9WnZ8Z2LbUt3ZDo/x3GuaefybmJ1pBLMA4Gf+GkK7Q/UXUOtPGsuvJtYiLzb5RjSjuSorVDv2YHoTrwwFO6MkYoB1yq6Ei1pSUaa4elltYs9WtGUuIwUg= Received: by 10.54.7.16 with SMTP id 16mr1740405wrg; Fri, 20 May 2005 04:51:19 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 04:51:19 -0700 (PDT) Message-ID: <68fba5c50505200451b2b7f55@mail.gmail.com> Date: Fri, 20 May 2005 07:51:19 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: multiple atom:author elements? Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KBpPWk092764 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Eric Scheid wrote: > I really don't want to see this in an Atom feed: > > Raggett, D, Hors, A, and I Jacobs *gasp. multiple nouns inside a single element. I don't see why that's a problem. For example, you wouldn't be able to recreate that string from three atom:author elements. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 08:30:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08621 for ; Fri, 20 May 2005 08:30: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 j4KCKoBi002379; Fri, 20 May 2005 05:20: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 j4KCKoe2002378; Fri, 20 May 2005 05:20:50 -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 j4KCKnce002336 for ; Fri, 20 May 2005 05:20:50 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 50265 messnum 5769849 invoked from network[213.94.211.166/dev2.mcpps.com]); 20 May 2005 12:20:42 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail12.svc.cra.dublin.eircom.net (qp 50265) with SMTP; 20 May 2005 12:20:42 -0000 Message-ID: <428DD617.1060502@dehora.net> Date: Fri, 20 May 2005 13:20:39 +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: multiple atom:author elements? References: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> <68fba5c50505200451b2b7f55@mail.gmail.com> In-Reply-To: <68fba5c50505200451b2b7f55@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: > On 5/20/05, Eric Scheid wrote: > > >>I really don't want to see this in an Atom feed: >> >> Raggett, D, Hors, A, and I Jacobs > > > *gasp. multiple nouns inside a single element. *gasp. multiple nouns inside a single noun element. > I don't see why that's a problem. For example, you wouldn't be able to > recreate that string from three atom:author elements. I see why that's problem. For example you could recreate that string from three atom author elements. cheers Bill http://www.ucc.ie/sdata/faq.html#whatis From owner-atom-syntax@mail.imc.org Fri May 20 08:45:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09685 for ; Fri, 20 May 2005 08: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 j4KCXiXK007643; Fri, 20 May 2005 05:33: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 j4KCXi0I007642; Fri, 20 May 2005 05:33:44 -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 j4KCXhCg007607 for ; Fri, 20 May 2005 05:33:43 -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); Fri, 20 May 2005 22:33:47 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 May 2005 22:33:36 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c50505200451b2b7f55@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 20/5/05 9:51 PM, "Robert Sayre" wrote: >> Raggett, D, Hors, A, and I Jacobs > > *gasp. multiple nouns inside a single element. > > I don't see why that's a problem. Try then importing those article feeds and producing an a-z index by author. e. From owner-atom-syntax@mail.imc.org Fri May 20 09:02:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10947 for ; Fri, 20 May 2005 09: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 j4KCnfub014611; Fri, 20 May 2005 05:49: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 j4KCnfGb014610; Fri, 20 May 2005 05:49:41 -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 j4KCnevn014550 for ; Fri, 20 May 2005 05:49:40 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so944326nzf for ; Fri, 20 May 2005 05:49:34 -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=Y0lk+Ro9dMdyGLq+k9LBt0Z9RhfqkzAXMSUVp1B8plq2/ED6xWcchh1KzeG+VdIYaxY62X6hBGdhmLTQjQzS64/Db0XziivtmIo9a+kDgDabeIWK30Zud/csYSHq9Z8bLZM5c+LI+3y88RXteC+n6HAPzRZSO9uZSiFHxWeJsUM= Received: by 10.36.74.1 with SMTP id w1mr791010nza; Fri, 20 May 2005 05:49:34 -0700 (PDT) Received: by 10.36.65.4 with HTTP; Fri, 20 May 2005 05:49:34 -0700 (PDT) Message-ID: <3f1451f5050520054910641333@mail.gmail.com> Date: Fri, 20 May 2005 08:49:34 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Thomas Broyer Subject: Re: Editorial: rules based on MIME media types in @type attributes Cc: atom-syntax@imc.org In-Reply-To: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KCnevn014603 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Thomas Broyer wrote: > > > I'd like to raise this up one more time: > http://www.imc.org/atom-syntax/mail-archive/msg14247.html > > Atom defines rules based on MIME media types in @type attributes, and I'm > not sure they are actually accurate... > They also don't explain the actual meaning behind the technical rules. > > In 4.1.3.2: > [ > If the value of type begins with "text/" or ends with "+xml", the > content SHOULD be local; that is to say, no "src" attribute should be > provided. > ] > > Replace with: > [ > If the value of type is a text or XML media type, that is, if it begins > with "text/", is one the XML Media Types [XMLMIME] or ends with "+xml", > the content SHOULD be local; that is to say, no "src" attribute should > be provided. > ] To be completely accurate, the part before the '/' is called the type, the part after the '/' is called the sub-type, so to rephrase your re-phrasing: If the value of is a text or XML media type, that is, if the type component of the mime-type is equal to "text", or if the mime-type is one the XML Media Types [XMLMIME], or the mime-type's sub-type ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri May 20 09:48:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15043 for ; Fri, 20 May 2005 09:48: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 j4KDX7Yb037029; Fri, 20 May 2005 06:33: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 j4KDX769037028; Fri, 20 May 2005 06:33:07 -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 j4KDX6rO036961 for ; Fri, 20 May 2005 06:33:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1978390wra for ; Fri, 20 May 2005 06:33:01 -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=PH3KuKYe/+a8mSENp3tjILaGsW5twHs5UIVaLKuTXDoxz3h8rp87lGs3f2PFCGH07LbGe7KzUysa/SRcsHWtvSzk03ied1dVDinrc8om34IJ/ykZ4SiwbIru5q42WR1puFTYWC0MmyfPwVhOWVjacyrhPox2dc6jtM3iefk/SIw= Received: by 10.54.140.3 with SMTP id n3mr1806135wrd; Fri, 20 May 2005 06:33:01 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 06:33:01 -0700 (PDT) Message-ID: <68fba5c505052006335328e2bf@mail.gmail.com> Date: Fri, 20 May 2005 09:33:01 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: multiple atom:author elements? Cc: Atom Syntax In-Reply-To: <428DC876.9000200@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KDX6rO037021 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Bill de hra wrote: > > Eric Scheid wrote: > > > Science Journals are just one example of feeds which require being able to > > specify multiple authors per entry. I have Library clients who want to make > > their indexing efforts available in XML form - currently I can recommend RSS > > 1.0, but I would like to be able to recommend Atom 1.0 when it becomes > > available. With a one-author-per-article restriction this would be > > impossible. > > > > Shall I write a Pace? > > Legal documents and legislation are others. Good catch Eric. I'll > support this. Those are three terrible use cases. Shall we go through every element in the format and evaluate their fitness for scientific journals, legal documents, and legislation? Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 10:18:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20951 for ; Fri, 20 May 2005 10:18: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 j4KE3n5T053352; Fri, 20 May 2005 07:03: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 j4KE3nZK053351; Fri, 20 May 2005 07:03:49 -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 j4KE3mHN053299 for ; Fri, 20 May 2005 07:03:48 -0700 (PDT) (envelope-from b.lund@nature.com) Received: from uk1apps2.mpl.root-domain.org (172.25.0.10) by hermes-ldn.macmillan.co.uk with ESMTP; 20 May 2005 14:03:41 +0000 X-IronPort-AV: i="3.93,123,1114992000"; d="scan'208"; a="36191188:sNHT17381764" Received: from [172.25.2.112] (L2009 [172.25.2.112]) by UK1APPS2.mpl.root-domain.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KMZHRNF8; Fri, 20 May 2005 15:03:41 +0100 Message-ID: <428DEE59.4050709@nature.com> Date: Fri, 20 May 2005 15:04:09 +0100 From: Ben Lund User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax Subject: Re: multiple atom:author elements? References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> In-Reply-To: <68fba5c505052006335328e2bf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/20/05, Bill de hra wrote: > >>Eric Scheid wrote: >> >> >>>Science Journals are just one example of feeds which require being able to >>>specify multiple authors per entry. >> >>Legal documents and legislation are others. Good catch Eric. I'll >>support this. > > > Those are three terrible use cases. Shall we go through every element > in the format and evaluate their fitness for scientific journals, > legal documents, and legislation? I find it astonishing that you dismiss publishing markets amounting to approximately $17 billion annually [1], [2]. Given that this is a need for this (see [3] for an example of how we currently choose to deal with this in RSS 1.0), what other rationale is there for not having multiple authors? [1] http://www.epsltd.com/press/pr.28.10.2004.asp [2] http://www.epsltd.com/press/pr.26.03.2004.asp [3] http://www.nature.com/nature/current_issue/rss Ta, Ben Lund --- ******************************************************************************** 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 Fri May 20 10:19:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21163 for ; Fri, 20 May 2005 10:19: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 j4KE9EHr055835; Fri, 20 May 2005 07:09: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 j4KE9EHm055834; Fri, 20 May 2005 07:09: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KE9CLt055777 for ; Fri, 20 May 2005 07:09:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2002484wra for ; Fri, 20 May 2005 07:09:07 -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=H3B2xvwEIgmbiAZbxuYwMv0DdFwmsxhG3LM9DNl2Ikc1mcIfIbM36fJpBT1NuZy+Ju6IavpNigN+mj1mN6RpHhRFmJcMxhuSLM4C5+CczovHvgKqvT0C6mbOqQtdnD3DXH3l8c7l0fS6C4C0cyjbQYVxc3HPOSB53/bxUTQaCik= Received: by 10.54.33.73 with SMTP id g73mr1108603wrg; Fri, 20 May 2005 07:09:07 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 07:09:07 -0700 (PDT) Message-ID: <68fba5c505052007092fe5d0db@mail.gmail.com> Date: Fri, 20 May 2005 10:09:07 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Ben Lund Subject: Re: multiple atom:author elements? Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <428DEE59.4050709@nature.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KE9DLt055828 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Ben Lund wrote: > Robert Sayre wrote: > > On 5/20/05, Bill de hra wrote: > > > >>Eric Scheid wrote: > >> > >> > >>>Science Journals are just one example of feeds which require being able to > >>>specify multiple authors per entry. > >> > >>Legal documents and legislation are others. Good catch Eric. I'll > >>support this. > > > > > > Those are three terrible use cases. Shall we go through every element > > in the format and evaluate their fitness for scientific journals, > > legal documents, and legislation? > > I find it astonishing that you dismiss publishing markets amounting to > approximately $17 billion annually [1], [2]. I'm not dismissing them. I'm saying they should use an extension, which they'll be needing anyway. > Given that this is a need for this (see [3] for an example of how we > currently choose to deal with this in RSS 1.0), what other rationale is > there for not having multiple authors? We better do something about that from: header in email, too. Just pick a string. That's all you have to do. Here's one: the format is done. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 10:40:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23604 for ; Fri, 20 May 2005 10:40: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 j4KESY0j064380; Fri, 20 May 2005 07:28: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 j4KESYap064379; Fri, 20 May 2005 07:28: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KESXo7064335 for ; Fri, 20 May 2005 07:28:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2015584wra for ; Fri, 20 May 2005 07:28: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=CN8LDYsYiJS3nKr4byr7VUgbzuU8DXFf26wypzdRfgQATlGZZSMbBKjh/EqxM2WPk+utBnsMHOILfBXhuj2d7tgHvwgn3J0sMthn9J2NcE3JZ0tKVSRNXu8IAx7AvCvCPFCup1eDYQnBgItYLvWYOV0jCWNpfkpPivQPto8mAGQ= Received: by 10.54.7.16 with SMTP id 16mr1818765wrg; Fri, 20 May 2005 07:28:28 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 07:28:28 -0700 (PDT) Message-ID: <68fba5c505052007286b4b2531@mail.gmail.com> Date: Fri, 20 May 2005 10:28:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Ben Lund Subject: Re: multiple atom:author elements? Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <428DEE59.4050709@nature.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KESYo7064373 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Ben Lund wrote: > Given that this is a need for this (see [3] for an example of how we > currently choose to deal with this in RSS 1.0), what other rationale is > there for not having multiple authors? > > [3] http://www.nature.com/nature/current_issue/rss Ooh. Actually, this is quite interesting. What's up with that description field? Robert Sayre Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit http://dx.doi.org/10.1038/nature03425 Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen Three-dimensional deformation caused by the Bam, Iran, earthquake and the origin of shallow slip deficit Yuri Fialko David Sandwell Mark Simons Paul Rosen doi:10.1038/nature03425 Nature 435, 295 (2005) Nature 435 7040 Article 295 299 From owner-atom-syntax@mail.imc.org Fri May 20 10:47:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24060 for ; Fri, 20 May 2005 10: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 j4KEYd57066830; Fri, 20 May 2005 07:34: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 j4KEYduS066829; Fri, 20 May 2005 07:34:39 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KEYcVj066787 for ; Fri, 20 May 2005 07:34:39 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102]) by smtp.cegetel.net (Postfix) with SMTP id 8BDCA1A4224; Fri, 20 May 2005 16:33:57 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Fri, 20 May 2005 16:34:33 +0200 (CEST) Message-ID: <1452.82.127.77.43.1116599673.squirrel@ssl-webmail.sitadelle.com> Date: Fri, 20 May 2005 16:34:33 +0200 (CEST) Subject: Re: Editorial: rules based on MIME media types in @type attributes From: "Thomas Broyer" To: In-Reply-To: <3f1451f5050520054910641333@mail.gmail.com> References: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> <3f1451f5050520054910641333@mail.gmail.com> 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 Joe Gregorio wrote: > To be completely accurate, the part before the '/' is called the type, > the part after the '/' is called the sub-type I know. I chose not to use these terms to make the wording "lighter" and thus easier to read and understand. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri May 20 10:47:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24122 for ; Fri, 20 May 2005 10:47: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 j4KEbStV068149; Fri, 20 May 2005 07:37: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 j4KEbSHM068148; Fri, 20 May 2005 07:37:28 -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 j4KEbRMA068099 for ; Fri, 20 May 2005 07:37:27 -0700 (PDT) (envelope-from b.lund@nature.com) Received: from uk1apps2.mpl.root-domain.org (172.25.0.10) by hermes-ldn.macmillan.co.uk with ESMTP; 20 May 2005 14:37:23 +0000 X-IronPort-AV: i="3.93,123,1114992000"; d="scan'208"; a="36195277:sNHT17842380" Received: from [172.25.2.112] (L2009 [172.25.2.112]) by UK1APPS2.mpl.root-domain.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KMZHR3BG; Fri, 20 May 2005 15:37:22 +0100 Message-ID: <428DF63E.2040808@nature.com> Date: Fri, 20 May 2005 15:37:50 +0100 From: Ben Lund User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax Subject: Re: multiple atom:author elements? References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007286b4b2531@mail.gmail.com> In-Reply-To: <68fba5c505052007286b4b2531@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: > On 5/20/05, Ben Lund wrote: > >>Given that this is a need for this (see [3] for an example of how we >>currently choose to deal with this in RSS 1.0), what other rationale is >>there for not having multiple authors? >> >>[3] http://www.nature.com/nature/current_issue/rss > > > Ooh. Actually, this is quite interesting. What's up with that description field? > Yes, it's less than ideal, but there were a couple of reasons for this: 1) It's important to us that the full author string is put in front of most readers' eyes very early on, but also that each individual author's name is given in a unique field. Using the description field and multiple, separate dc:creator fields [*] seemed like the best compromise [*] This is actually against the letter of the RSS 1.0 spec 2) There's not much else to go in the description field, as we're not putting the abstracts of articles in our feeds (yet...). Ta, Ben > Robert Sayre > > > > > Three-dimensional deformation caused by the Bam, Iran, earthquake and > the origin of shallow slip deficit > > http://dx.doi.org/10.1038/nature03425 > > Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen > > > Three-dimensional deformation caused by the Bam, Iran, earthquake and > the origin of shallow slip deficit > > Yuri Fialko > David Sandwell > Mark Simons > Paul Rosen > doi:10.1038/nature03425 > Nature 435, 295 > (2005) > > Nature > 435 > 7040 > Article > 295 > 299 > ******************************************************************************** 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 Fri May 20 10:49:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24359 for ; Fri, 20 May 2005 10:49: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 j4KEageB067779; Fri, 20 May 2005 07:36: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 j4KEagoE067778; Fri, 20 May 2005 07:36:42 -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 j4KEafNF067701 for ; Fri, 20 May 2005 07:36:42 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 23241 messnum 270110 invoked from network[213.94.211.166/vienna.propylon.com]); 20 May 2005 14:36:35 -0000 Received: from vienna.propylon.com (HELO ?127.0.0.1?) (213.94.211.166) by mail03.svc.cra.dublin.eircom.net (qp 23241) with SMTP; 20 May 2005 14:36:35 -0000 Message-ID: <428DF5F1.5060400@dehora.net> Date: Fri, 20 May 2005 15:36: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: multiple atom:author elements? References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> In-Reply-To: <68fba5c505052006335328e2bf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/20/05, Bill de hra wrote: > >>Legal documents and legislation are others. Good catch Eric. I'll >>support this. > > Those are three terrible use cases. Let's suppose there's general agreement here with that opinion. The things to ask here nonetheless are a) whether drilling multiple author names through a name element indicates a design flaw in Atom (overconstraint). b) whether multiple authoring is an edge-case; it could well be. I'm open to persuasion on b); it's not my intent to force this anyone's throat. But a) does bother me. > Shall we go through every element > in the format and evaluate their fitness for scientific journals, > legal documents, and legislation? Unfair :\ Not the least because you're assuming that hasn't been done. cheers Bill From owner-atom-syntax@mail.imc.org Fri May 20 10:53:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25080 for ; Fri, 20 May 2005 10: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 j4KEafkn067768; Fri, 20 May 2005 07:36: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 j4KEafJ4067767; Fri, 20 May 2005 07:36:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KEaeY8067693 for ; Fri, 20 May 2005 07:36:41 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050520143634.VIVR12530.mta13-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Fri, 20 May 2005 15:36:34 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050520143634.RBGX18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Fri, 20 May 2005 15:36:34 +0100 Date: Fri, 20 May 2005 15:36:31 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1105766971.20050520153631@djpowell.net> To: Robert Sayre CC: Ben Lund , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax Subject: Re: multiple atom:author elements? In-Reply-To: <68fba5c505052007092fe5d0db@mail.gmail.com> References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KEafY8067761 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Friday, May 20, 2005, 3:09:07 PM, Robert Sayre wrote: > I'm not dismissing them. I'm saying they should use an extension, > which they'll be needing anyway. The important thing is that we should make sure that they can use an extension to do this. The current wording for Person construct might suggest that a Person construct is a singular entity. Perhaps the definition of atom:name should be tweaked to make it a label for the Person construct. atom:name sounds too much like a singular name of a person or company. Simple Extension Elements could be a useful way of adding additional information about multiple author. Multiple dc:creator or foaf:name elements could be used directly in the person construct to document the separate names, leaving atom:name as a printable label, eg: Mark Nottingham and Robert Sayre Mark Nottingham Robert Sayre There is a limitation though that this approach couldn't be used to include the email addresses or organisations of multiple authors because there wouldn't be an easy way to associate these properties with the correct person. A risk of allowing multiple atom:author elements is that it might break the feed/entry inheritance thing: does atom:entry/atom:author override or merge with atom:feed/atom:author? I suppose a FOAF block could be included as a Structured Extension Element. >> Given that this is a need for this (see [3] for an example of how we >> currently choose to deal with this in RSS 1.0), what other rationale is >> there for not having multiple authors? > We better do something about that from: header in email, too. Just > pick a string. That's all you have to do. Bad example :) from = "From:" mailbox-list CRLF -- Dave From owner-atom-syntax@mail.imc.org Fri May 20 10:59:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25566 for ; Fri, 20 May 2005 10:59: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 j4KEjSkR071764; Fri, 20 May 2005 07:45: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 j4KEjSmf071763; Fri, 20 May 2005 07:45:28 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KEjQXW071750 for ; Fri, 20 May 2005 07:45:27 -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 1DZ8kd-0004mi-00; Fri, 20 May 2005 15:45:23 +0100 Date: Fri, 20 May 2005 15:45:21 +0100 From: James Aylett To: Atom Syntax Subject: Re: multiple atom:author elements? Message-ID: <20050520144521.GF28662@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c505052007092fe5d0db@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, May 20, 2005 at 10:09:07AM -0400, Robert Sayre wrote: > > Given that this is a need for this (see [3] for an example of how we > > currently choose to deal with this in RSS 1.0), what other rationale is > > there for not having multiple authors? > > We better do something about that from: header in email, too. Just > pick a string. That's all you have to do. The from header in RFC 2822 is a structured header that supports multiple email addresses, so this isn't a terribly good example. (If I understand your intention.) Personally I'm in favour of having multiple authors, but I'm +0.5 on ending this discussion any way possible. Although it does actually affect me, there are workarounds which I'll tolerate (although it precludes Atom as an archival format in some cases, there are workarounds in these cases as well if necessary). So I'm actually +0, I guess. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Fri May 20 11:00:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25693 for ; Fri, 20 May 2005 11:00: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 j4KEnNGW073590; Fri, 20 May 2005 07:49: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 j4KEnNC7073589; Fri, 20 May 2005 07:49:23 -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 j4KEnMuh073547 for ; Fri, 20 May 2005 07:49:22 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2030139wra for ; Fri, 20 May 2005 07:49:17 -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=n0uykOskQSqpOGFWEJVfX3GMwTD7QU4rqyFK1SNR02nD/zpiHsl3ejl+xyvHzNdDp0Wb09RQVxEePmxhy/Foru3KpvP4KGhxyzRSrQdLtB6tOV2BjJaj+JDJlnp3VQ24GE1wj+n3nQlv+3EHbFRUVsfA0exERBnYPE8ha0iqeXg= Received: by 10.54.23.26 with SMTP id 26mr1750600wrw; Fri, 20 May 2005 07:49:16 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 07:49:16 -0700 (PDT) Message-ID: <68fba5c505052007497bfe5996@mail.gmail.com> Date: Fri, 20 May 2005 10:49:16 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: multiple atom:author elements? Cc: Ben Lund , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <1105766971.20050520153631@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KEnMuh073580 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, David Powell wrote: > > Perhaps the definition of atom:name should be tweaked to make it a > label for the Person construct. atom:name sounds too much like a > singular name of a person or company. Hmmm. That's true. There also seems to be a stigma attached to atom:contributor. > > Mark Nottingham and Robert Sayre > Mark Nottingham > Robert Sayre > > > There is a limitation though that this approach couldn't be used to > include the email addresses or organisations of multiple authors > because there wouldn't be an easy way to associate these properties > with the correct person. Right now, the spec reads as if there is one primary person, and then a bunch of contributor minions. The example also makes it look that way. Maybe we could adjust it to make atom:author a 'primary field' and then atom:contributor could break each entity. So, Ben's example would have 1 atom author field and four atom:contributors. > > Bad example :) > > from = "From:" mailbox-list CRLF Doh! RFC2822 can be so harsh. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 11:14:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27103 for ; Fri, 20 May 2005 11:14: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 j4KF20v4078453; Fri, 20 May 2005 08:02: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 j4KF20KZ078452; Fri, 20 May 2005 08:02:00 -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 j4KF1wfJ078394 for ; Fri, 20 May 2005 08:01:59 -0700 (PDT) (envelope-from b.lund@nature.com) Received: from uk1apps2.mpl.root-domain.org (172.25.0.10) by hermes-ldn.macmillan.co.uk with ESMTP; 20 May 2005 15:01:52 +0000 X-IronPort-AV: i="3.93,123,1114992000"; d="scan'208"; a="36198374:sNHT18905340" Received: from [172.25.2.112] (L2009 [172.25.2.112]) by UK1APPS2.mpl.root-domain.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KMZHR3SN; Fri, 20 May 2005 16:01:52 +0100 Message-ID: <428DFBFD.1010208@nature.com> Date: Fri, 20 May 2005 16:02:21 +0100 From: Ben Lund User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: David Powell , =?ISO-8859-1?Q?Bill_de_h=D3?= =?ISO-8859-1?Q?ra?= , Atom Syntax Subject: Re: multiple atom:author elements? References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> In-Reply-To: <68fba5c505052007497bfe5996@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: > Right now, the spec reads as if there is one primary person, and then > a bunch of contributor minions. The example also makes it look that > way. Maybe we could adjust it to make atom:author a 'primary field' > and then atom:contributor could break each entity. So, Ben's example > would have 1 atom author field and four atom:contributors. > > You mean: -------- Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen Yuri Fialko David Sandwell Mark Simons Paul Rosen -------- ? I like that structure. Ta, Ben ******************************************************************************** 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 Fri May 20 11:14:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27124 for ; Fri, 20 May 2005 11:14: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 j4KF4jt9079629; Fri, 20 May 2005 08:04: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 j4KF4jp9079628; Fri, 20 May 2005 08:04:45 -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 j4KF4hoN079604 for ; Fri, 20 May 2005 08:04:45 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 2EA724F599; Fri, 20 May 2005 11:04:42 -0400 (EDT) Date: Fri, 20 May 2005 11:04:42 -0400 From: Dan Brickley To: Ben Lund Cc: Robert Sayre , Bill de =?iso-8859-15?Q?h=D3ra?= , Atom Syntax Subject: Re: multiple atom:author elements? Message-ID: <20050520150442.GB18952@homer.w3.org> References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <428DEE59.4050709@nature.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Ben Lund [2005-05-20 15:04+0100] > > Robert Sayre wrote: > >On 5/20/05, Bill de hra wrote: > > > >>Eric Scheid wrote: > >> > >> > >>>Science Journals are just one example of feeds which require being able > >>>to > >>>specify multiple authors per entry. > >> > >>Legal documents and legislation are others. Good catch Eric. I'll > >>support this. > > > > > >Those are three terrible use cases. Shall we go through every element > >in the format and evaluate their fitness for scientific journals, > >legal documents, and legislation? > > I find it astonishing that you dismiss publishing markets amounting to > approximately $17 billion annually [1], [2]. +1 I guess those who chose to use Atom despite this constraint will just use extension namespaces instead of Atom's built-in 'author' construct for feeds that describe multiple-author documents. If Atom is basically optimised for blogging, then this kind of design is only to be expected. If Atom feeds are for all kinds of documents, the constraint seems short-sighted. Dan > Given that this is a need for this (see [3] for an example of how we > currently choose to deal with this in RSS 1.0), what other rationale is > there for not having multiple authors? > > > [1] http://www.epsltd.com/press/pr.28.10.2004.asp > [2] http://www.epsltd.com/press/pr.26.03.2004.asp > [3] http://www.nature.com/nature/current_issue/rss > > Ta, > > Ben Lund > > --- > > ******************************************************************************** > 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 Fri May 20 11:23:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28140 for ; Fri, 20 May 2005 11:23: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 j4KFAM9B081773; Fri, 20 May 2005 08: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 j4KFAMbl081772; Fri, 20 May 2005 08:10:22 -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 j4KFALre081739 for ; Fri, 20 May 2005 08:10:22 -0700 (PDT) (envelope-from b.lund@nature.com) Received: from uk1apps2.mpl.root-domain.org (172.25.0.10) by hermes-ldn.macmillan.co.uk with ESMTP; 20 May 2005 15:10:16 +0000 X-IronPort-AV: i="3.93,123,1114992000"; d="scan'208"; a="36199376:sNHT18329788" Received: from [172.25.2.112] (L2009 [172.25.2.112]) by UK1APPS2.mpl.root-domain.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KMZHR3YN; Fri, 20 May 2005 16:10:16 +0100 Message-ID: <428DFDF4.2060203@nature.com> Date: Fri, 20 May 2005 16:10:44 +0100 From: Ben Lund User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: David Powell , =?ISO-8859-1?Q?Bill_de_h=D3?= =?ISO-8859-1?Q?_ra?= , Atom Syntax Subject: Re: multiple atom:author elements? References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> <428DFBFD.1010208@nature.com> <68fba5c5050520080857c8aa0b@mail.gmail.com> In-Reply-To: <68fba5c5050520080857c8aa0b@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: > > I meant > > > > > Yuri Fialko, David Sandwell, Mark Simons & Paul > Rosen > http://research.example.org/dept/ > > > > Yuri Fialko > http://research.example.org/dept/fialko/ > > > > David Sandwell > http://research.example.org/dept/sandwell/ > > > Mark Simons > http://research.example.org/dept/simons/ > > > Paul Rosen > http://research.example.org/dept/rosen/ > > > ... > > Okay, cool. I like that too... Ta, Ben ******************************************************************************** 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 Fri May 20 11:23:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28154 for ; Fri, 20 May 2005 11:23: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 j4KF8A0B080928; Fri, 20 May 2005 08: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 j4KF8AKI080926; Fri, 20 May 2005 08:08: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.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KF88tJ080872 for ; Fri, 20 May 2005 08:08:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2042353wra for ; Fri, 20 May 2005 08:08: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=XLhqy9TbskPBtafy7mHFqD8/OugT18DuAI5nGWmEOTv2BBY4md0MyTSdhhjDp377wZ7O1a78Nm/H/SQHIWzSwJM/nRAWOhlE57bLrrXm/ifvgUaQEd2v9u3AK6oZ4z1h8wQCzVT1ya+x0QC7wKEBlaYBgMqAEGLlgVRpeZ/3bB0= Received: by 10.54.23.26 with SMTP id 26mr1758859wrw; Fri, 20 May 2005 08:08:00 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 08:08:00 -0700 (PDT) Message-ID: <68fba5c5050520080857c8aa0b@mail.gmail.com> Date: Fri, 20 May 2005 11:08:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Ben Lund Subject: Re: multiple atom:author elements? Cc: David Powell , =?ISO-8859-1?Q?Bill_de_h=D3_ra?= , Atom Syntax In-Reply-To: <428DFBFD.1010208@nature.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> <428DFBFD.1010208@nature.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KF89tJ080920 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Ben Lund wrote: > Robert Sayre wrote: > > Right now, the spec reads as if there is one primary person, and then > > a bunch of contributor minions. The example also makes it look that > > way. Maybe we could adjust it to make atom:author a 'primary field' > > and then atom:contributor could break each entity. So, Ben's example > > would have 1 atom author field and four atom:contributors. > > > > I meant Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen http://research.example.org/dept/ Yuri Fialko http://research.example.org/dept/fialko/ David Sandwell http://research.example.org/dept/sandwell/ Mark Simons http://research.example.org/dept/simons/ Paul Rosen http://research.example.org/dept/rosen/ ... Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 11:29:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28742 for ; Fri, 20 May 2005 11:29: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 j4KCrENf016220; Fri, 20 May 2005 05: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 j4KCrEZC016219; Fri, 20 May 2005 05: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KCrDIV016177 for ; Fri, 20 May 2005 05:53:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1954468wra for ; Fri, 20 May 2005 05:53:08 -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=WHQXv0lCcpYvKwsS6Wd6XDYnC7Bm44JOgGLasymL5U3pLItCCUc7zUfaKHNg3hmzJkwdgH9c7XDHPzUGXFbYHltiFs7sjzqtMU0LXV4q9PFW4ILBvurMrefKCNLxIDy/GRv0IiJ3YcvfM0WDRTxjUUGUTi/19rGRbFaLUO9LuXQ= Received: by 10.54.7.16 with SMTP id 16mr1772446wrg; Fri, 20 May 2005 05:53:08 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 05:53:08 -0700 (PDT) Message-ID: <68fba5c505052005532da42598@mail.gmail.com> Date: Fri, 20 May 2005 08:53:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: multiple atom:author elements? Cc: Atom Syntax In-Reply-To: <428DD617.1060502@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <22DBB4BC-C8E5-11D9-B7C5-003065EA6144@geckotribe.com> <68fba5c50505200451b2b7f55@mail.gmail.com> <428DD617.1060502@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KCrEIV016212 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Bill de hra wrote: > > Robert Sayre wrote: > > On 5/20/05, Eric Scheid wrote: > > > > > >>I really don't want to see this in an Atom feed: > >> > >> Raggett, D, Hors, A, and I Jacobs > > > > > > *gasp. multiple nouns inside a single element. > > *gasp. multiple nouns inside a single noun element. > > > > I don't see why that's a problem. For example, you wouldn't be able to > > recreate that string from three atom:author elements. > > I see why that's problem. For example you could recreate that string > from three atom author elements. Here's what's required to produce that string http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 11:33:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29067 for ; Fri, 20 May 2005 11: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 j4KFIpUc085385; Fri, 20 May 2005 08:18: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 j4KFIpXS085384; Fri, 20 May 2005 08:18:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KFIoAl085329 for ; Fri, 20 May 2005 08:18:51 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4KFH5ur013034; Fri, 20 May 2005 16:17:10 +0100 (BST) In-Reply-To: <68fba5c505052008122d7b57e6@mail.gmail.com> References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> <6A7B964F-A816-4D92-ABF6-59B90BA318BB@mac.com> <68fba5c505052008122d7b57e6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <095615CE-38B5-4AE8-9BD6-3AA479A03FF0@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: multiple atom:author elements? Date: Fri, 20 May 2005 16:17:06 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 May 2005, at 4:12 pm, Robert Sayre wrote: > Well, the two examples we've been shown want to control presentation > when multiple authors are grouped. > > "Raggett, D, Hors, A, and I Jacobs" > "Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen" The logical answer would then be a new element for that label when multiple atom:authors are present. Does anyone remember the reason we have atom:contributor? I say drop it. Graham From owner-atom-syntax@mail.imc.org Fri May 20 11:49:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00292 for ; Fri, 20 May 2005 11:49: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 j4KFZbak092908; Fri, 20 May 2005 08:35: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 j4KFZba8092907; Fri, 20 May 2005 08:35:37 -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 j4KFZUKc092882 for ; Fri, 20 May 2005 08:35:35 -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); Sat, 21 May 2005 01:35:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 01:35:03 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505052007497bfe5996@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 21/5/05 12:49 AM, "Robert Sayre" wrote: > Right now, the spec reads as if there is one primary person, and then > a bunch of contributor minions. The example also makes it look that > way. Maybe we could adjust it to make atom:author a 'primary field' > and then atom:contributor could break each entity. So, Ben's example > would have 1 atom author field and four atom:contributors. I'm liking this idea. The main thing we'd want to fish out of (sic) would be ... which would be renamed to be . All the nitty gritty details on each person involved would then be described in multiple s. We'd still need to cater to the use case of the Esteemed Author And His Lowly Contributor Minions though ... and thus (assuming the above model) introduce a new contributor attribute for role of contribution (such as "author", "contributor", "editor", "photographer"). An example: this is the title Foo, Bar, and Fum Barnable Foo <.../> Sir Ignacious Bar, Esq. <.../> Fred Fum <.../> Some guy <.../> Or ... and this is a crazy idea ... we could instead support inserting inside the element, thus even allowing us to link to a controlled schema, just in case people have lots of funky roles. Barnable Foo <.../> e. From owner-atom-syntax@mail.imc.org Fri May 20 11:54:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00655 for ; Fri, 20 May 2005 11: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 j4KFaq3n093132; Fri, 20 May 2005 08:36: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 j4KFaq2F093130; Fri, 20 May 2005 08:36: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 j4KFapPD093117 for ; Fri, 20 May 2005 08:36:51 -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); Sat, 21 May 2005 01:37:00 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 01:36:51 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1105766971.20050520153631@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 21/5/05 12:36 AM, "David Powell" wrote: > A risk of allowing multiple atom:author elements is that it might > break the feed/entry inheritance thing: does atom:entry/atom:author > override or merge with atom:feed/atom:author? I suppose a FOAF block > could be included as a Structured Extension Element. That feed/entry inheritance thing is going to bite us again, I'm sure. e. From owner-atom-syntax@mail.imc.org Fri May 20 13:34:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11704 for ; Fri, 20 May 2005 13:34: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 j4KHJQaC017967; Fri, 20 May 2005 10:19: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 j4KHJQnd017966; Fri, 20 May 2005 10:19:26 -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 j4KHJOJY017951 for ; Fri, 20 May 2005 10:19: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); Sat, 21 May 2005 03:19:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 03:19:22 +1000 Subject: Re: multiple atom:author elements? 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 21/5/05 1:35 AM, "Eric Scheid" wrote: > > > Barnable Foo > <.../> > actually, I'm liking this more and more, because... Barnable Foo <.../> (Just in case it's not obvious, my use of the elements above describe the nature of *contribution* of that person to that entry, and not a sense of identity for that person.) e. From owner-atom-syntax@mail.imc.org Fri May 20 13:53:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16154 for ; Fri, 20 May 2005 13:53: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 j4KHcA3F019721; Fri, 20 May 2005 10:38: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 j4KHcAjU019720; Fri, 20 May 2005 10:38:10 -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 j4KHc9J6019702 for ; Fri, 20 May 2005 10:38:09 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2005 17:38:03 -0000 Received: from xdsl-81-173-173-171.netcologne.de (EHLO klangraum) [81.173.173.171] by mail.gmx.net (mp024) with SMTP; 20 May 2005 19:38:03 +0200 X-Authenticated: #163624 Date: Fri, 20 May 2005 19:41:35 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: multiple atom:author elements? Message-ID: <20050520174135.GA12093@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c505052007497bfe5996@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Eric Scheid [2005-05-20 17:50]: > > > Barnable Foo > <.../> > +1 Very elegant. As for the inheritance problem this does bring up: the current spec implicitly defines that no inheritance from the feed takes place when an entry has its own author element, because there is only ever one author for any entry, so if it’s the one at the entry level, it can’t be the one at the feed level. I suggest that the same approach be chosen in case of this atom:contributor element, just explicitly. Trying to specify a merging scheme here would be boiling the ocean. However, it does pose a problem of default semantics. Do we define particular categories in the spec? If we don’t, do we define a default category to be assumed in absence of explicit category elements in the document? If we do, do we define such a default? Lastly, the atom:byline should be optional for those publishers who wont to control presentation, IMO. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri May 20 13:58:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17187 for ; Fri, 20 May 2005 13: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 j4KHg3ov020060; Fri, 20 May 2005 10:42: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 j4KHg388020059; Fri, 20 May 2005 10:42:03 -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 j4KHg2XO020053 for ; Fri, 20 May 2005 10:42:02 -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); Sat, 21 May 2005 03:42:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 03:42:01 +1000 Subject: extension elements anywhere? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHg3XO020054 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > 6.4Extension Elements > > Atom allows foreign markup anywhere in an Atom document. does this mean this is allowed: hello world!<foo:evil>:-)</foo:evil> e. From owner-atom-syntax@mail.imc.org Fri May 20 14:04:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17632 for ; Fri, 20 May 2005 14: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 j4KHqmwQ021116; Fri, 20 May 2005 10: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 j4KHqmoc021115; Fri, 20 May 2005 10:52:48 -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 j4KHqk9j021108 for ; Fri, 20 May 2005 10:52:47 -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); Sat, 21 May 2005 03:52:56 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 03:52:48 +1000 Subject: editorial: "software" From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHql9j021110 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit did someone say that the spec doesn't use the word "software"? > 6.3Software Processing of Foreign Markup e. From owner-atom-syntax@mail.imc.org Fri May 20 14:08:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18272 for ; Fri, 20 May 2005 14:08: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 j4KHvQvS021436; Fri, 20 May 2005 10:57: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 j4KHvQqS021435; Fri, 20 May 2005 10:57:26 -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 j4KHvNmO021406 for ; Fri, 20 May 2005 10:57:25 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so1717353nzp for ; Fri, 20 May 2005 10:57:17 -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=iqRiJRy+/elyzGW1fUhK/1C2/161U6sfMNH5MMvzmVVgD38/71MxVIu8S0qFdQ8f0jCEgeamPzOBmynhhMW6RCuLFfPFMMlpDx92RjOCqTqgd4bsZZEj+6GQmLYhP7Y650iSHUx71+7jY1C+JWeolF0RcJ6QXeOQ9tg6InebOpk= Received: by 10.36.100.5 with SMTP id x5mr860917nzb; Fri, 20 May 2005 10:57:17 -0700 (PDT) Received: by 10.36.50.4 with HTTP; Fri, 20 May 2005 10:57:17 -0700 (PDT) Message-ID: <1f2ed5cd050520105725540e15@mail.gmail.com> Date: Fri, 20 May 2005 19:57:17 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Graham Subject: Re: multiple atom:author elements? Cc: Robert Sayre , atom-syntax In-Reply-To: <095615CE-38B5-4AE8-9BD6-3AA479A03FF0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> <6A7B964F-A816-4D92-ABF6-59B90BA318BB@mac.com> <68fba5c505052008122d7b57e6@mail.gmail.com> <095615CE-38B5-4AE8-9BD6-3AA479A03FF0@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHvPmO021430 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Graham wrote: > Does anyone remember the reason we have atom:contributor? I say drop it. Good question (I can't remember - was feed-level attribution a consideration?). Looking at it now the primary author/secondary contributors thing seems open to technical clunkiness and human discomfort. If we do allow multiple s, we could ditch and at the same time lessen the likelihood of ugliness like: Raggett, D, Hors, A, and I Jacobs I would think the need to assign different statuses to the author/contributors (and corresponding labelling) will be a rarity compared to what's covered by allowing multiple authors. so - allowing mutiple s: +1 removing : +1 Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Fri May 20 14:13:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19035 for ; Fri, 20 May 2005 14:13: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 j4KHwElw021495; Fri, 20 May 2005 10:58: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 j4KHwE8F021494; Fri, 20 May 2005 10:58:14 -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 j4KHwCLo021484 for ; Fri, 20 May 2005 10:58:14 -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); Sat, 21 May 2005 03:58:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 03:58:11 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050520174135.GA12093@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHwELo021489 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 21/5/05 3:41 AM, "A. Pagaltzis" wrote: > However, it does pose a problem of default semantics. Do we > define particular categories in the spec? If we dont, do we > define a default category to be assumed in absence of explicit > category elements in the document? If we do, do we define such > a default? The simplest thing that could possibly work is to say that if there is no element inside the then assume a default of @term="author" with unspecified @scheme and unspecified @label. Covers 99% of use cases, I should think. No need to explain what the string "author" means, surely? e. From owner-atom-syntax@mail.imc.org Fri May 20 14:28:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20469 for ; Fri, 20 May 2005 14:28: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 j4KIIbBL024129; Fri, 20 May 2005 11: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 j4KIIbRj024128; Fri, 20 May 2005 11:18:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KIIacP024119 for ; Fri, 20 May 2005 11:18:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4KIHTnE019151; Fri, 20 May 2005 19:17:40 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: multiple atom:author elements? Date: Fri, 20 May 2005 19:17:29 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 May 2005, at 6:19 pm, Eric Scheid wrote: > actually, I'm liking this more and more, because... > > > Barnable Foo > > > > <.../> > Well unless we make category/term machine readable, we might as well just have a plain text blob. Graham From owner-atom-syntax@mail.imc.org Fri May 20 14:29:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20514 for ; Fri, 20 May 2005 14:29: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 j4KIIMrL024111; Fri, 20 May 2005 11:18: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 j4KIIMjR024110; Fri, 20 May 2005 11:18: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 j4KIIEUh024096 for ; Fri, 20 May 2005 11:18:17 -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); Sat, 21 May 2005 04:18:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 04:18:15 +1000 Subject: Re: multiple atom:author elements? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f2ed5cd050520105725540e15@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 >> Does anyone remember the reason we have atom:contributor? I say drop it. this is instructive reading... http://www.intertwingly.net/wiki/pie/NumberOfAuthorsDiscussion > If we do allow multiple s, we could ditch and at > the same time lessen the likelihood of ugliness like: > > Raggett, D, Hors, A, and I Jacobs that string inside is ugly. that string inside is desired* e. * by some publishers, who by convention have the requirement that contributors be listed in some proper order. From owner-atom-syntax@mail.imc.org Fri May 20 14:29:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20624 for ; Fri, 20 May 2005 14:29: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 j4KIKUih024343; Fri, 20 May 2005 11:20: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 j4KIKUGY024339; Fri, 20 May 2005 11:20: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KIKTlt024310 for ; Fri, 20 May 2005 11:20:29 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2177645wra for ; Fri, 20 May 2005 11:20: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=i/VmjuiVAExkAQ3DrpwAXtppcLXI5pXEeuhn+F9ROeTKiRKC38/PqEntZ4mbx2U9fjx+vadXSrwbbSQHGPta7gFujcJUk6uxXmva7+tsFmGrHayvFOiBKXJzhXD5c92GTCV4/fsStviyhPwZOaWO4yg4ih+4lBuSPNuNxw2yChg= Received: by 10.54.10.61 with SMTP id 61mr1840576wrj; Fri, 20 May 2005 11:20:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 11:20:23 -0700 (PDT) Message-ID: <68fba5c50505201120a2acf2@mail.gmail.com> Date: Fri, 20 May 2005 14:20:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Danny Ayers Subject: Re: multiple atom:author elements? Cc: Graham , atom-syntax In-Reply-To: <1f2ed5cd050520105725540e15@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052006335328e2bf@mail.gmail.com> <428DEE59.4050709@nature.com> <68fba5c505052007092fe5d0db@mail.gmail.com> <1105766971.20050520153631@djpowell.net> <68fba5c505052007497bfe5996@mail.gmail.com> <6A7B964F-A816-4D92-ABF6-59B90BA318BB@mac.com> <68fba5c505052008122d7b57e6@mail.gmail.com> <095615CE-38B5-4AE8-9BD6-3AA479A03FF0@mac.com> <1f2ed5cd050520105725540e15@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KIKTlt024326 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Danny Ayers wrote: > I would think the need to assign different statuses to the > author/contributors (and corresponding labelling) will be a rarity > compared to what's covered by allowing multiple authors. Here is a new example for the spec. Is there a use case that's not covered? dive into mark A <em>lot</em> of effort went into making this effortless 2005-04-02T12:29:29Z tag:example.org,2003:3 Copyright (c) 2003, Mark Pilgrim Example Toolkit Atom draft-07 snapshot tag:example.org,2003:3.2397 2005-04-02T12:29:29Z 2003-12-13T08:29:29-04:00 Mark Pilgrim, et al. Mark Pilgrim http://example.org/ f8dy@example.com Sam Ruby Joe Gregorio

[Update: The Atom draft-07 snapshot is out.]

 From owner-atom-syntax@mail.imc.org Fri May 20 14:37:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21923 for ; Fri, 20 May 2005 14: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 j4KITnBK025126; Fri, 20 May 2005 11:29: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 j4KITn4v025125; Fri, 20 May 2005 11:29:49 -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 j4KITm1v025106 for ; Fri, 20 May 2005 11:29:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 99598 messnum 7063616 invoked from network[83.70.217.193/unknown]); 20 May 2005 18:29:42 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail01.svc.cra.dublin.eircom.net (qp 99598) with SMTP; 20 May 2005 18:29:42 -0000 Message-ID: <428E2C8E.6050506@dehora.net> Date: Fri, 20 May 2005 19:29:34 +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: Fetch me an author. Now, fetch me another author. 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.franklinmint.fm/blog/archives/000393.html "The Atom author element may be inadequate for scientific journals, legal documents, and legislation. I am shocked, just shocked." Translation: The Atom format mandates you can only have one author, for an entry or a feed. Why is this not a spec bug? Can anyone point to consensus on this decision? cheers Bill From owner-atom-syntax@mail.imc.org Fri May 20 14:40:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22577 for ; Fri, 20 May 2005 14:40: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 j4KIUL29025195; Fri, 20 May 2005 11:30: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 j4KIULSF025194; Fri, 20 May 2005 11:30: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4KIUJ3g025166 for ; Fri, 20 May 2005 11:30:20 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2005 18:30:13 -0000 Received: from xdsl-81-173-173-171.netcologne.de (EHLO klangraum) [81.173.173.171] by mail.gmx.net (mp006) with SMTP; 20 May 2005 20:30:13 +0200 X-Authenticated: #163624 Date: Fri, 20 May 2005 20:33:47 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: multiple atom:author elements? Message-ID: <20050520183347.GA12258@klangraum> Mail-Followup-To: atom-syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Graham [2005-05-20 20:30]: > Well unless we make category/term machine readable, we might as > well just have a plain text blob. But we already did that. There’s an option @scheme attribute for atom:category. That’s part of the elegance of this approach. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri May 20 14:45:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23167 for ; Fri, 20 May 2005 14:45: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 j4KIbilc027661; Fri, 20 May 2005 11:37: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 j4KIbiF3027660; Fri, 20 May 2005 11:37:44 -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 j4KIbhXJ027652 for ; Fri, 20 May 2005 11:37:43 -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); Sat, 21 May 2005 04:37:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 04:37:44 +1000 Subject: Re: multiple atom:author elements? 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 21/5/05 4:17 AM, "Graham" wrote: > Well unless we make category/term machine readable, we might as well > just have a plain text blob. it is machine readable: they also define many more terms... Calligrapher [cll] Cartographer [ctg] Collaborator [clb] Photographer [pht] Author in quotations or text extracts [aqt] Censor [cns] Dubious author [dub] :-) e. From owner-atom-syntax@mail.imc.org Fri May 20 14:46:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23242 for ; Fri, 20 May 2005 14: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 j4KIZjFh026464; Fri, 20 May 2005 11:35: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 j4KIZjBV026463; Fri, 20 May 2005 11:35: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 j4KIZiQx026429 for ; Fri, 20 May 2005 11:35: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 43F0ECE for ; Fri, 20 May 2005 11:35:39 -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 j4KIZYng013987 for ; Fri, 20 May 2005 11:35:39 -0700 (PDT) Date: Fri, 20 May 2005 11:49:04 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: multiple atom:author elements? Message-ID: In-Reply-To: <68fba5c505052006335328e2bf@mail.gmail.com> References: <428DC876.9000200@dehora.net> <68fba5c505052006335328e2bf@mail.gmail.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 Friday, May 20, 2005 09:33:01 AM -0400 Robert Sayre wrote: > > Those are three terrible use cases. Shall we go through every element > in the format and evaluate their fitness for scientific journals, > legal documents, and legislation? Here is a list of 341 scientific journals with RSS feeds. Soem of these use a single author element with multiple authors crammed in, some use multiple author elements. The author elements have other problems, like "Binks, J. J." vs. "Jar Jar Binks", but that is something that the WG has ruled out of scope. http://www.library.unr.edu/ejournals/alphaRSS.aspx We really should use "creator" instead of "author". Author is nonsense for photoblogs. We can do a lot of things with Atom, but reinventing Dublin Core badly should not be one of those. +1 for multiple author elements. +1 for "creator" instead of "author", if anyone wants to go there. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Fri May 20 14:54:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24682 for ; Fri, 20 May 2005 14:54: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 j4KIhBa1029568; Fri, 20 May 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 j4KIhBRc029567; Fri, 20 May 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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4KIh98g029517 for ; Fri, 20 May 2005 11:43:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2005 18:43:03 -0000 Received: from xdsl-81-173-173-171.netcologne.de (EHLO klangraum) [81.173.173.171] by mail.gmx.net (mp012) with SMTP; 20 May 2005 20:43:03 +0200 X-Authenticated: #163624 Date: Fri, 20 May 2005 20:46:37 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: multiple atom:author elements? Message-ID: <20050520184637.GB12258@klangraum> Mail-Followup-To: Atom Syntax References: <20050520174135.GA12093@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Eric Scheid [2005-05-20 20:10]: > On 21/5/05 3:41 AM, "A. Pagaltzis" wrote: > > However, it does pose a problem of default semantics. Do we > > define particular categories in the spec? If we don¹t, do we > > define a default category to be assumed in absence of > > explicit category elements in the document? If we do, do we > > define such a default? > > The simplest thing that could possibly work is to say that if > there is no element inside the then > assume a default of @term="author" with unspecified @scheme and > unspecified @label. > > Covers 99% of use cases, I should think. > > No need to explain what the string "author" means, surely? Sounds fine; but you did not directly address the question of whether we define any default semantics. The absence of atom:category and mean the same thing per your proposal. You did effectively specify a term “author” with particular semantics, if only implicitly. My question is: do we define even as much? Background: we could say something like “The given contributor is to be assumed to be an author of the entry in absence of an atom:category stating otherwise.” which avoids defining any terms at all, even implicitly. To get to the point: if we do define one term, do we define more of them as well? Such as “editor,” “correspondent” or whatever? This is the only reason I’m at all wary of the proposition. The infrastructure it supplies is sound and very elegant, but the infrastructure per se is hollow scaffolding without the semantics it is supposed to carry, and I feel really uncomfortable about the idea of getting into that semantics game. Particular at this so very late stage. If we can find an approach that avoids getting into that can of worms, I’m definitely in support of the idea. If we cannot stay away from it, then allowing multiple atom:author elements and leaving any additional complexities to extension elements would be the simpler thing to do. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri May 20 14:59:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25540 for ; Fri, 20 May 2005 14:59: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 j4KIn2Sb031916; Fri, 20 May 2005 11:49: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 j4KIn2Gd031915; Fri, 20 May 2005 11:49: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 j4KIn0em031755 for ; Fri, 20 May 2005 11:49:01 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2005 18:48:54 -0000 Received: from xdsl-81-173-173-171.netcologne.de (EHLO klangraum) [81.173.173.171] by mail.gmx.net (mp011) with SMTP; 20 May 2005 20:48:54 +0200 X-Authenticated: #163624 Date: Fri, 20 May 2005 20:52:27 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: extension elements anywhere? Message-ID: <20050520185227.GC12258@klangraum> Mail-Followup-To: Atom Syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Eric Scheid [2005-05-20 19:55]: > > 6.4 Extension Elements > > > > Atom allows foreign markup anywhere in an Atom document. > > does this mean this is allowed: > > hello world!<foo:evil>:-)</foo:evil> You request adding “except where they are explicitly forbidden” to that sentence, I suppose. The spec for Text Constructs does so for your example, anyway. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri May 20 15:16:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28210 for ; Fri, 20 May 2005 15: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 j4KJ2wIp035393; Fri, 20 May 2005 12:02: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 j4KJ2wHt035392; Fri, 20 May 2005 12:02:58 -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 j4KJ2vWE035384 for ; Fri, 20 May 2005 12:02:57 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 20 May 2005 12:02:49 -0700 To: Atom WG From: Paul Hoffman Subject: PROCESS QUESTION: are we done yet? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wearing my co-chair hat: We had a WG Last Call. It brought out a lot of issues, and we dealt with each of them (not always to the satisfaction of the person who brought up the issue, of course). We had an IETF-wide Last Call. It brought out a lot of issues, and we dealt with each of them (not always to the satisfaction of the person who brought up the issue, of course). New issues for the format spec are now being brought up, issues that existed *before* the WG Last Call, much less the IETF-wide Last Call. The IETF process allows for this. If we make any technical changes after the IETF last call is over (that is, weeks ago), we will probably have to go through an IETF Last Call again. Good engineering design allows for this. Many of us work for, or have worked for, companies whose product ship dates slipped for months or even years as improvements were made before shipping 1.0. Rob and Mark are nearly done with the version of the draft that answers IETF Last Call issues. Tim and I planned on taking that to the IESG as soon as it was published. HOWEVER, since it is clear that many people in the WG want to continue to add or change technical features in the document, we need to decide NOW what the process should be. Does the WG want to be able to open up new topics, or re-open old topics with a twist? If so, do we all agree to the delay in publication that comes with that? Also, how long should this opening and re-opening last? Are there any limits on which parts of the spec we are willing to change? These are serious questions. No one will be surprised that Tim and I want to follow the normal process and finish with the results of the IETF-wide Last Call, nor that we dread the idea of the WG opening new issues that could have been dealt with long ago and reopening issues that were actively closed. We are here to serve the Working Group, and if the Working Group wants a significant delay in finishing the spec, we can (probably grumpily) ask Scott for that change to our charter if there is rough consensus in the WG that that is what you want. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri May 20 15:55:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07564 for ; Fri, 20 May 2005 15:55: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 j4KJZtxQ045351; Fri, 20 May 2005 12: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 j4KJZttk045350; Fri, 20 May 2005 12:35:55 -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 j4KJZr2w045325 for ; Fri, 20 May 2005 12:35:54 -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); Sat, 21 May 2005 05:35:59 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 05:35:49 +1000 Subject: Re: PROCESS QUESTION: are we done yet? 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 21/5/05 5:02 AM, "Paul Hoffman" wrote: > HOWEVER, since it is clear that many people in the WG want to > continue to add or change technical features in the document, > we need to decide NOW what the process should be. maybe it's time for all of us to take the draft we have, take it away from the table, and do some real-world code implementations with real-world data. take a break to breathe. get some perspective before we lock ourselves in. let the embers die down a bit ;-) e. From owner-atom-syntax@mail.imc.org Fri May 20 16:51:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12869 for ; Fri, 20 May 2005 16:51: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 j4KKdgaM063097; Fri, 20 May 2005 13:39: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 j4KKdgNX063093; Fri, 20 May 2005 13:39:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KKdfhr063077; Fri, 20 May 2005 13:39:41 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4KKclEF016758; Fri, 20 May 2005 21:38:53 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86BFDC9F-52AB-4E72-8CF4-C2DFA7194193@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PROCESS QUESTION: are we done yet? Date: Fri, 20 May 2005 21:38:46 +0100 To: Paul Hoffman X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 May 2005, at 8:02 pm, Paul Hoffman wrote: > Does the WG want to be able to open up new topics, or re-open old > topics with a twist? If so, do we all agree to the delay in > publication that comes with that? Also, how long should this > opening and re-opening last? Are there any limits on which parts of > the spec we are willing to change? I think the last deadline was premature and totally out of sync with the WG, and if anything is responsible for the delay, because of the temporary cessation of new Paces. There probably needs to be one more round of discussion on recent changes like duplicate IDs, but everything else seems finished. I think there will be a natural ending soon enough. Graham From owner-atom-syntax@mail.imc.org Fri May 20 16:53:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13046 for ; Fri, 20 May 2005 16:53: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 j4KKfnEO063359; Fri, 20 May 2005 13:41: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 j4KKfmPr063358; Fri, 20 May 2005 13:41:48 -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 j4KKfmDX063349 for ; Fri, 20 May 2005 13:41:48 -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 3BB3AA9 for ; Fri, 20 May 2005 13:41:43 -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 j4KKfgng015315 for ; Fri, 20 May 2005 13:41:43 -0700 (PDT) Date: Fri, 20 May 2005 13:55:14 -0700 From: Walter Underwood To: Atom Syntax Subject: PaceCaching Message-ID: 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 Tuesday, May 17, 2005 09:13:37 PM -0700 Tim Bray wrote: > > PaceCaching > > Multiple -1's, it fails. I'll address the objections anyway, because I (still) think this is important. 1. This introduces multiple caching schemes. Wrong. Right now we have multiple schemes, with HTTP caching, ad hoc client caching, and ad hoc server-side load shedding. This recommends one consistant scheme, which we know will work. The current multi-scheme approach is a mess, and we can be sure that it will have problems. 2. This applies protocol caching to a client. True, but not really an isssue. HTTP caching does work when used to manage a client cache. Compare a client working through an HTTP cache to one which checks the cache information internally before issuing HTTP requests. The HTTP server will see the same series of requests. Effectively, the client will run a virtual HTTP cache internally. 3. Server-side parsing is too much overhead. Maybe with 90 MHz Pentiums, but XML parsing is really fast these days. Parse the file, cache the values, and toss them if the file has changed when you stat it. Or, the blog server software can set the cache info out-of-band to the server. 4. This requires synchronized clocks. Those are a SHOULD for HTTP, too. And they ought to be a SHOULD for Atom anwyay, because you cannot date-sort entries from two servers with unsynchronized clocks. 5. This is just like HTTP-EQUIV and that has failed. Yes and no. Most HTTP servers ignore HTTP-EQUIV, but it is still useful for passing through things like content-language when there is no HTTP header present. For Atom, the caching info would be valid when there is no HTTP cache header. This is exactly where HTTP-EQUIV is effective today. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Fri May 20 17:23:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15421 for ; Fri, 20 May 2005 17:23: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 j4KL8Z3L068907; Fri, 20 May 2005 14:08: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 j4KL8ZaT068905; Fri, 20 May 2005 14:08: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 [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KL8Yoe068864 for ; Fri, 20 May 2005 14:08:34 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 5BD5E72403C for ; Fri, 20 May 2005 17:08:29 -0400 (EDT) Reply-To: From: "Bob Wyman" To: Subject: Microsoft to support Atom in "any aggregator" they produce Date: Fri, 20 May 2005 17:08: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: AcVdgBCN9bztC9gZSPKaHJclK6fHPQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-Id: <20050520210829.5BD5E72403C@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit FYI: Robert Scoble, a Microsoft employee/insider very familiar with Microsoft's plans for syndication, declares in comments on his blog that "we are supporting Atom in any aggregator we produce." Microsoft's example in supporting Atom should be followed by all other aggregator developers in the future and Microsoft should be commended for supporting the adoption of openly defined standards for syndication. For more info (and some heated comments...) see: http://bobwyman.pubsub.com/main/2005/05/microsoft_to_su.html bob wyman From owner-atom-syntax@mail.imc.org Fri May 20 17:27:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15786 for ; Fri, 20 May 2005 17:27: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 j4KLKaml073910; Fri, 20 May 2005 14:20: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 j4KLKaVn073909; Fri, 20 May 2005 14:20: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KLKZxw073860 for ; Fri, 20 May 2005 14:20:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2290569wra for ; Fri, 20 May 2005 14:20:29 -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=kzK4E/IZ+FoBVwc9RjZOJCHELachFoRbx2aN9tEX3PgwCvVXpkki4v02opuGxdjiYju5HdB5KWgbr0Xx24D3FHYztX5wH7r3thtC8AJ2dLMR2+WukrjaLRBgXVeb3Y7D4yPyIWJb/sxFKBU91REt/Ok2J0R9AqpbHThXqSyn6c4= Received: by 10.54.7.16 with SMTP id 16mr1992059wrg; Fri, 20 May 2005 14:20:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 14:20:29 -0700 (PDT) Message-ID: <68fba5c505052014207c8cb94a@mail.gmail.com> Date: Fri, 20 May 2005 17:20:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PROCESS QUESTION: are we done yet? Cc: Paul Hoffman , atom-syntax In-Reply-To: <86BFDC9F-52AB-4E72-8CF4-C2DFA7194193@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <86BFDC9F-52AB-4E72-8CF4-C2DFA7194193@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KLKZxw073887 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Graham wrote: > > On 20 May 2005, at 8:02 pm, Paul Hoffman wrote: > > > Does the WG want to be able to open up new topics, or re-open old > > topics with a twist? If so, do we all agree to the delay in > > publication that comes with that? Also, how long should this > > opening and re-opening last? Are there any limits on which parts of > > the spec we are willing to change? I think we're done. The multiple IDs issue was raised in last call and we need to resolve the wording. Everything else is fine. Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 20 18:56:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22902 for ; Fri, 20 May 2005 18:56: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 j4KMgLTv097416; Fri, 20 May 2005 15:42: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 j4KMgLvD097415; Fri, 20 May 2005 15:42:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KMgKd0097367; Fri, 20 May 2005 15:42:21 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050520224213.JIGC26549.mta08-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Fri, 20 May 2005 23:42:13 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050520224213.UBBP29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Fri, 20 May 2005 23:42:13 +0100 Date: Fri, 20 May 2005 23:42:10 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <4910561199.20050520234210@djpowell.net> To: Paul Hoffman CC: Atom WG Subject: Re: PROCESS QUESTION: are we done yet? In-Reply-To: References: 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 Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote: > Does the WG want to be able to open up new topics, or re-open old > topics with a twist? If so, do we all agree to the delay in > publication that comes with that? What would the minimum delay be out of interest? 4 weeks? 6 weeks? > Also, how long should this opening > and re-opening last? Are there any limits on which parts of the spec > we are willing to change? I'd be more comfortable with another round. A major motivation of Atom was to avoid the ambiguities of RSS, so we'd better not have any ourselves. I have some concerns about these issues still: a) PaceAllowDuplicateIDs was made after Last Call and is a pretty fundamental change to the Atom model. Its effect, that entries can have multiple instances, is an invention that none of the RSS specs cover. I think that we're rushing this without having time to think what effects it might have. (I'm basically in favour of it, but I think that it needs a bit more thought). I think that the debate on atom:version/atom:modified was curtailed prematurely (within 3 days) and should be re-opened. b) Hopefully we wouldn't try to add new features to Atom if we did another round, but allowing multiple authors seems to have some merit to it. The current text inhibits multiple authors being described even by extensions. Hopefully we can get a minimal base that would allow multiple authors to be described, deferring as much as we can to extensions. Robert Sayer's suggestion looked promising, but inheritance issues would need to be considered. And a few issues that are probably editorial: c) The language introduced by PaceAllowDuplicateIDs implies important properties of entries that ought to be made explicit. Throwing the word "revision/version/whatever" into the spec somewhere would make things clearer, and would be a useful vocabulary term for people who plan to write further specifications for extensions etc. (In the same way that Jeff Mogul's paper, "Clarifying the Fundamentals of HTTP" [1] defines the term "instance" for HTTP in a way that gave a basis for RFC3229 - "Delta encoding in HTTP" [2] d) The MIME specs don't give us very good terminology to describe what is allowed in places that allow "MIME types". I think we should explicitly say that we mean a MIME type to be composed of a main type and subtype with no parameters. It wouldn't do any harm. e) Inheritance of things like atom:copyright and atom:author seems rather subtle. They appear to work in slightly different ways, and I'm not sure that the spec is clear enough on exactly how this inheritance is supposed to work. As Dan Brickley said recently, "Atom's job [...] is to be clear about what the document means." I was planning to methodically enumerate some possible effects of inheritance, and to check whether the spec is ambiguous about any of these (it might all be fine). Eg: should an impeccably behaved Atom implementation treat these two the same (eg should a server record the two differently in its database): David Powell [...] vs: David Powell David Powell [...] Apart from that, I think things are pretty solid. [1] http://research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.pdf [2] http://www.ietf.org/rfc/rfc3229.txt -- Dave From owner-atom-syntax@mail.imc.org Fri May 20 19:48:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27896 for ; Fri, 20 May 2005 19:48: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 j4KNethZ017956; Fri, 20 May 2005 16:40: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 j4KNetMj017955; Fri, 20 May 2005 16:40:55 -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 j4KNesLF017947 for ; Fri, 20 May 2005 16:40:54 -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 j4KNesjO013962 for ; Fri, 20 May 2005 17:40: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 <0IGT0084ZB46SF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 17:40:54 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002JYB45ZZ@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 17:40:54 -0600 (MDT) Date: Fri, 20 May 2005 16:40:56 -0700 From: Tim Bray Subject: Refresher on Updated/Modified To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; delsp=yes; 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'm engaged in trying to convince a large well-known organization to take Atom seriously (I think I'm winning) and we had this email exchange, which I thought might be useful as a refresher for those who have blissfully forgotten the great updated/modified debate. ======================================================================== =========================== > I think the biggest concern right now is that that the LastUpdated > date can be left unchanged even when the post IS changed (e.g. > spelling corrections) What you want is reasonable to want but unfortunately no syndication format can give it to you. Here is the current language: The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. There was a proposal for an "atom:modified" date that was to be updated every time any change no matter how tiny was made but it was shouted down. There were many arguments against, but here are three that I couldn't think of an answer to: 1. The datestamp is inserted by the provider. Thus it could be a lie; this is the Internet, remember. You, the consumer, either trust the publisher or you don't. If you don't, you will ignore the datestamp and check the content. If you do, you will believe the datestamp. Thus, "modified" buys you nothing. 2. There's endless room for argument as to what constitutes an update: change in the stylesheet for background colors, change from a unicode combined char to single + combining diacritic, change in paragraph 27 of an article that doesn't show up in a summaries-only feed, change from UTF-8 to UTF-16 encoding, there were more examples too, some of them scary-subtle. 3. Several publishers on the list asserted that they needed the right to make trivial spelling-correction-level changes without having a zillion literal-minded feed-reading clients re-fetch the material, and that they would simply refuse to update an atom:modified date if they didn't feel like it. Objectively, the upstream information provider controls the datestamps. If you can think of a way to write a syndication format that will function across the Internet and reliably force providers to provide accurate "modified" indicators, there are a lot of people who would like to hear about it. From owner-atom-syntax@mail.imc.org Sat May 21 07:28:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02934 for ; Sat, 21 May 2005 07:27: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 j4LBEsZV014614; Sat, 21 May 2005 04:14: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 j4LBEsjS014613; Sat, 21 May 2005 04:14:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LBErga014542 for ; Sat, 21 May 2005 04:14:53 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LBEAKg014719; Sat, 21 May 2005 12:14:16 +0100 (BST) In-Reply-To: References: <428E2C8E.6050506@dehora.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 12:14:09 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 1:59 am, Tim Bray wrote: > Let me speak as a victim of a few years in the publishing-software > trenches: The semantics of author and contributor are a tangled > mess, a real swamp, and I don't think that Atom is going to do a > very good job of solving them. In particular, I don't think we're > going to a better job than Dublin Core. Why are we using "author" instead of "creator" then? The current setup is a rushed kludge that came about before we started thinking things through, not a conscious decision to echo Dublin Core. > That is to say, if we were to do as some suggest (nuke > atom:contributor and make atom:author repeatable) I'm quite certain > that we could come up with all sorts of corner cases and problems, > probably about as many as with the current setup. You can say that about anything. A flat list of people associated with an entry is infinitely better than the weird one author/multiple contributors model that doesn't offer a clear way to cope with the common model of multiple co-authors. Graham From owner-atom-syntax@mail.imc.org Sat May 21 07:31:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03127 for ; Sat, 21 May 2005 07:31: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 j4LBKvX7021228; Sat, 21 May 2005 04:20: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 j4LBKvcE021227; Sat, 21 May 2005 04:20:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LBKtBJ021171 for ; Sat, 21 May 2005 04:20:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LBJbG5015568; Sat, 21 May 2005 12:19:38 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 12:19:35 +0100 To: Henry Story X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The appropiate answer to this is to say comparing an id from a document retrieved from one URI to an id retrieved from a second URI is not reliable. This makes feed:ids largely useless. The primary use, of comparing with a previous version of a document retrieved from the same URI, is fine. Graham From owner-atom-syntax@mail.imc.org Sat May 21 07:44:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06928 for ; Sat, 21 May 2005 07: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 j4LBSx31026206; Sat, 21 May 2005 04: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 j4LBSxLM026205; Sat, 21 May 2005 04:28:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LBSwOW026134 for ; Sat, 21 May 2005 04:28:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LBRpFf016774; Sat, 21 May 2005 12:27:51 +0100 (BST) In-Reply-To: <68fba5c505052018417c4c9f28@mail.gmail.com> References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> <68fba5c5050520181578705fd5@mail.gmail.com> <39EA2047-EB60-4237-B280-373CD167E65F@mac.com> <68fba5c505052018417c4c9f28@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Refresher on Updated/Modified Date: Sat, 21 May 2005 12:27:48 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 2:41 am, Robert Sayre wrote: > OK. The chairs' latest text reads: > > " If multiple atom:entry elements with the same atom:id value appear > in an Atom Feed document, they describe the same entry and Atom > Processors MUST treat them as such." > > Where does the bad behavior come in, and what can we do to > discourage it? This line: "Their atom:updated timestamps SHOULD be different" What are the allowable exceptions here? If I wanted to store two versions with the same id and updated (say from two different sources, or which non-siginificanr differences, is that allowable. What should a client that implements "the typical behavior ... to display only the entry with the latest atom:updated timestamp" do? Graham From owner-atom-syntax@mail.imc.org Sat May 21 08:00:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08244 for ; Sat, 21 May 2005 08:00: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 j4LBofhE039541; Sat, 21 May 2005 04:50: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 j4LBofni039540; Sat, 21 May 2005 04:50: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 j4LBoex3039499 for ; Sat, 21 May 2005 04:50:40 -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); Sat, 21 May 2005 20:50:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 20:50:00 +1000 Subject: Re: Accidental and intentional atom:id collisions 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 21/5/05 7:47 PM, "Henry Story" wrote: > But perhaps it is not such a problem after all, because perhaps we can have > dereferenceable ids that allow us to move entries around. I can think of a > few: > >1. if an entry moves the old entry position redirects to the new one. not always possible. >2. one creates a special redirect service to redirect ids to their > current location Such things already exist in various forms. There is for example a service which resolves DOI URIs. >3. one creates a new URI to URL mapping protocol blech. e. From owner-atom-syntax@mail.imc.org Sat May 21 08:09:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09857 for ; Sat, 21 May 2005 08:09: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 j4L6VfSR069415; Fri, 20 May 2005 23:31: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 j4L6Vf2k069414; Fri, 20 May 2005 23:31: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 j4L6VdhV069382 for ; Fri, 20 May 2005 23:31:39 -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); Sat, 21 May 2005 16:31:47 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 16:19:48 +1000 Subject: Re: Refresher on Updated/Modified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1f25b3e6b35beb175d86749f8324d89d@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 On 21/5/05 10:48 AM, "Tim Bray" wrote: > I don't see why, if you wanted that kind of archive, you couldn't use > atom:updated for every little change in the archived version but > atom:updated only for the ones you cared about in the published > version. In which case the archived version would be a superset of the > published version. I see nothing wrong with that. -Tim > but how would the publisher signal the particular instances in that archive which are 'significant' while others are not? e. From owner-atom-syntax@mail.imc.org Sat May 21 08:13:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11389 for ; Sat, 21 May 2005 08:13: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 j4L6i3eG077460; Fri, 20 May 2005 23:44: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 j4L6i3uJ077457; Fri, 20 May 2005 23:44:03 -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 j4L6i2Ds077426 for ; Fri, 20 May 2005 23:44:02 -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); Sat, 21 May 2005 16:44:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 16:44:01 +1000 Subject: Re: Accidental and intentional atom:id collisions 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 21/5/05 4:24 PM, "Henry Story" wrote: > So those are just a few thoughts on the topic. It just seems that if one > works with the web these phishing problems seem to disappear. all good stuff, with the exception of making atom:id dereferenceable... once you do that you have to allow it to change (to accommodate changes in server set up etc), and once you allow it to change it is no longer effective as an id :-( So, all the above, but using atom:link[@rel='self'] instead. BTW, /feed/id is useful for other things -- primarily to help big aggregators to realise that they are retrieving the same feed from more than one location (eg. with and without www.) e. From owner-atom-syntax@mail.imc.org Sat May 21 08:13:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11415 for ; Sat, 21 May 2005 08: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 j4L6UjDc068711; Fri, 20 May 2005 23:30: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 j4L6UjFt068710; Fri, 20 May 2005 23:30:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L6Ujnw068700 for ; Fri, 20 May 2005 23:30:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4L6UYTj013587; Sat, 21 May 2005 02:30:40 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFF03270; Sat, 21 May 2005 02:30:33 -0400 (EDT) Message-Id: <200505210630.DFF03270@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Sam Ruby'" Cc: "'Atom Syntax'" Subject: RE: Compulsory feed ID? Date: Sat, 21 May 2005 02:30:30 -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: AcVdnTwhH1gv+PfSSX6PYkwQ5aC4gAAMLGdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <44c2ff27e803181e7a7213e445f09975@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > I think the WG basically decided to punt on the DOS scenario. -Tim I believe you are correct in describing the WG's unfortunate disposition towards this issue. (Naturally, I object...) In any case, given that a significant DOS attack has been identified -- yet not addressed -- I think it would be both wise and appropriate to provide text in a Security Concerns section that describes the vulnerability of systems that rely on Atom documents to this particular attack. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 08:13:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11442 for ; Sat, 21 May 2005 08:13: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 j4L6VhRF069445; Fri, 20 May 2005 23:31: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 j4L6VhpA069442; Fri, 20 May 2005 23:31:43 -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 j4L6Vf5F069413 for ; Fri, 20 May 2005 23:31:42 -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); Sat, 21 May 2005 16:31:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 16:29:39 +1000 Subject: Re: Refresher on Updated/Modified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <540e373205052020267b835937@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 21/5/05 1:26 PM, "Roger B." wrote: >>> change from a unicode combined char to single + combining >>> diacritic, >> >> No. >> >>> change in paragraph 27 of an article that doesn't show up in a >>> summaries-only feed, >> >> No. > > Dave: In my case, and seemingly in the case of most of the tools > surveyed, both of those would get a "yes". I suspect that in many > cases, simply clicking "edit" on an entry and then immediately > clicking "save" will cycle the modified date forward, even if zero > changes were made. I concur -- most tools probably will update on any edit/save cycle. Some tools won't, simply because they disable the "Save" command unless the edit workspace has been dirtied. This is observable practice with lots of desktop apps, but since it's a pain to implement in web apps I doubt we'll see it there anytime soon. On the point of changing a unicode combined char: I thing the Yes/No depends on how the change occurred ... was it an load/edit/save cycle by a user, or was it due to a software upgrade that affected how content is stored or serialised? e. From owner-atom-syntax@mail.imc.org Sat May 21 08:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11464 for ; Sat, 21 May 2005 08: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 j4L6nY31081119; Fri, 20 May 2005 23:49: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 j4L6nYrL081118; Fri, 20 May 2005 23:49:34 -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 j4L6nWGd081088 for ; Fri, 20 May 2005 23:49:33 -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); Sat, 21 May 2005 16:49:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 16:49:31 +1000 Subject: Re: Compulsory feed ID? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200505210630.DFF03270@ms8.netsolmail.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 21/5/05 4:30 PM, "Bob Wyman" wrote: >> I think the WG basically decided to punt on the DOS scenario. -Tim > I believe you are correct in describing the WG's unfortunate > disposition towards this issue. (Naturally, I object...) In any case, given > that a significant DOS attack has been identified -- yet not addressed -- I > think it would be both wise and appropriate to provide text in a Security > Concerns section that describes the vulnerability of systems that rely on > Atom documents to this particular attack. +1 to putting something into Security Concerns. I'm inclined to think the DOS problem is peculiar to super-aggregators - if any of the publishers of the feeds I've individually subscribed to and actively monitor/read were to wake up one day and decide to be a bad actor, I'm sure to notice something wacky and take action (excoriate them on a blog, unsubscribe, etc). In addition to the DOS problem, I believe there are other issues inimical to super-aggregators, especially those that re-publish. Mostly to do with tracking provenance, enveloping and attribution of mid-stream meta-data or meta-content, and so on. It deserves a deeper treatment, but not in the Atom 1.0 core spec. e. From owner-atom-syntax@mail.imc.org Sat May 21 08:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11493 for ; Sat, 21 May 2005 08:13: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 j4L79sqo094651; Sat, 21 May 2005 00: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 j4L79sqp094650; Sat, 21 May 2005 00:09:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L79nbu094527 for ; Sat, 21 May 2005 00:09:53 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050521070943.EFEH20297.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Sat, 21 May 2005 08:09:43 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050521070943.JPEX8884.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Sat, 21 May 2005 08:09:43 +0100 Date: Sat, 21 May 2005 08:09:40 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1116874419.20050521080940@djpowell.net> To: Atom Syntax Subject: Re: Refresher on Updated/Modified (oh the irony!) In-Reply-To: <551297761.20050521020457@djpowell.net> References: <551297761.20050521020457@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 Saturday, May 21, 2005, 2:04:57 AM, I wrote: > [reposted without so many typos and grammatical errors - reply to either] I just noticed some irony in my attempt to repost that mail about atom:modified, with the intention to disclaim that any "significant changes" had been made, thereby saving any readers that had already read and understood the long post from rereading it. Note that the Atom mailing list archive retains both copies, ordered by the Date header. It is a bit borderline in this case, the original post was hard to understand. But, if these had been atom entries rather than mailing list posts, this is the sort of scenario where an archive Feed Document needs to contain both revisions of an entry - in order - even when the publisher doesn't advertise that the update was significant by reving atom:updated. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 08:14:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11627 for ; Sat, 21 May 2005 08:14: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 j4L7iYPm016942; Sat, 21 May 2005 00:44: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 j4L7iYGR016941; Sat, 21 May 2005 00:44:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L7iW7J016867 for ; Sat, 21 May 2005 00:44:33 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 4149 invoked by uid 10); 21 May 2005 07:44:26 -0000 Received: (vexira-qq 04143-6953525D invoked from network) 21 May 2005 09:44:26 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 May 2005 07:44:26 -0000 Message-ID: <428EE6E7.9070502@annevankesteren.nl> Date: Sat, 21 May 2005 09:44:39 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: Tim Bray , Atom Syntax Subject: Re: atom:modified : Reducing the cruft References: <771869789.20050521083258@djpowell.net> In-Reply-To: <771869789.20050521083258@djpowell.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > I detect that a lot of opposition to atom:modified comes from the fact > that it is a REQUIRED element and that many of the publishers actually > putting it in the feed and paying for the bandwidth don't intend using > it frequently? > > Would it help if we said that if the atom:modified element is absent, > its value MAY be taken from the atom:updated element? (or to put it > another way: atom:modified MAY be omitted if its value is equivalent > to the value of atom:updated). I think this will result in people misusing the field. Either giving atom:updated the last modified time or giving it the last significant modification time and simply omitting atom:modified because that is extra work. If it is introduced in some optional fashion it should not relate to another date construct I think. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sat May 21 08:18:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13169 for ; Sat, 21 May 2005 08:18: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 j4L6sAEI084211; Fri, 20 May 2005 23:54: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 j4L6sAM6084210; Fri, 20 May 2005 23:54:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L6s9FG084133 for ; Fri, 20 May 2005 23:54:09 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050521065403.CEAY20297.mta10-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sat, 21 May 2005 07:54:03 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050521065403.HDRP29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 07:54:03 +0100 Date: Sat, 21 May 2005 07:53:59 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <53998802.20050521075359@djpowell.net> To: "Roger B." CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <540e373205052020267b835937@mail.gmail.com> References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@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 Saturday, May 21, 2005, 4:26:13 AM, Roger B. wrote: >> > change from a unicode combined char to single + combining >> > diacritic, >> >> No. >> >> > change in paragraph 27 of an article that doesn't show up in a >> > summaries-only feed, >> >> No. > Dave: In my case, and seemingly in the case of most of the tools > surveyed, both of those would get a "yes". I suspect that in many > cases, simply clicking "edit" on an entry and then immediately > clicking "save" will cycle the modified date forward, even if zero > changes were made. That is ok by PaceDateModified2. The "no" in my response was to the question "Is this an update wrt the rules of atom:modiifed?" PaceDateModified2 doesn't have the clause that PaceDateModifed has: "Publishers SHOULD NOT change the value of atom:modified when no changes in the entry have occurred", because of situations like this, where this clause would be difficult to avoid and unenforceable. It is preferable if publishers don't change atom:modified and/or other elements in a feed document unnecessarily for caching reasons amongst others, but cases like the ones above are likely to be infrequent and harmless. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 08:18:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13193 for ; Sat, 21 May 2005 08:18: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 j4L6iEhL077582; Fri, 20 May 2005 23:44: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 j4L6iEKB077581; Fri, 20 May 2005 23:44: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 j4L6iD21077570 for ; Fri, 20 May 2005 23:44:13 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 56272 invoked by uid 17064); 21 May 2005 06:44:13 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.3.247]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 21 May 2005 06:44:13 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <68fba5c505051914026329eb06@mail.gmail.com> References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> <68fba5c505051914026329eb06@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Compulsory feed ID? Date: Sat, 21 May 2005 08:44:10 +0200 To: Robert Sayre , Atom Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19 May 2005, at 23:02, Robert Sayre wrote: > On 5/19/05, Sam Ruby wrote: > >> Of course, breaking any link in my complicated chain of logic above >> would cause the whole argument to collapse, which would be fine >> with me. >> > > Maybe the requirement is useless. > > "If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry and software MUST > treat them as such." > > "MUST treat them as such" isn't particularly meaningful, and two > atom:entry elements occuring anywhere are supposed to be describing > the same entry. When I get CCed on an atom-syntax message, some of my > email programs show two messages, and some show one. It's a > security/annoyance trade-off, and I don't see why the format should be > making that decision. +1 How you deal with different representations of entries with the same id is up to the software and user's discretion. Some software may want to keep a full history of all the representations, some may only be able to keep the latest. Some users may wish to see all represenations others may wish to see only some of them. The same user may have different preferences at different times. The requirement of treating entries with the same id as the same does not add anything more than saying that the entries are representations of the id resources. Henry Story From owner-atom-syntax@mail.imc.org Sat May 21 08:18:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13205 for ; Sat, 21 May 2005 08:18: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 j4L62Bbn049458; Fri, 20 May 2005 23:02: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 j4L62BiV049457; Fri, 20 May 2005 23:02: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 j4L625wV049375 for ; Fri, 20 May 2005 23:02:10 -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); Sat, 21 May 2005 16:02:08 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 16:01:58 +1000 Subject: Re: Refresher on Updated/Modified 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 21/5/05 9:40 AM, "Tim Bray" wrote: > 1. The datestamp is inserted by the provider. Thus it could be a lie; > this is the Internet, remember. You, the consumer, either trust the > publisher or you don't. If you don't, you will ignore the datestamp > and check the content. If you do, you will believe the datestamp. > Thus, "modified" buys you nothing. I don't believe trust is a matter of "you do or you don't". I trust some people to do some things, but don't trust them on other matters. The more subjective something is, the less I might trust someone. The more objective/automated, the easier it is to trust. Will there be bad actors that will subjectively fiddle with atom:modified? There are always bad actors... however, if they betray their skullduggery nature by fiddling with something as objective as atom:modified why then would I even begin to trust what they say in atom:content? > 2. There's endless room for argument as to what constitutes an update: > change in the stylesheet for background colors, change from a unicode > combined char to single + combining diacritic, change in paragraph 27 > of an article that doesn't show up in a summaries-only feed, change > from UTF-8 to UTF-16 encoding, there were more examples too, some of > them scary-subtle. I still say we need to define/clarify the difference between an "entry" and atom:entry. That might help. > 3. Several publishers on the list asserted that they needed the right > to make trivial spelling-correction-level changes without having a > zillion literal-minded feed-reading clients re-fetch the material, and > that they would simply refuse to update an atom:modified date if they > didn't feel like it. The spec is also silent on whether a publisher must produce a new serialisation of every time there is a change in the back-end resources. The spec does imply that if you do, then atom:modified would be updated ... but if a tree falls on a mime in the From owner-atom-syntax@mail.imc.org Sat May 21 08:18:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13226 for ; Sat, 21 May 2005 08:18: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 j4L6BMYQ054943; Fri, 20 May 2005 23:11: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 j4L6BMoB054942; Fri, 20 May 2005 23:11:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L6BLg1054930 for ; Fri, 20 May 2005 23:11:21 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4L6BATh005687; Sat, 21 May 2005 02:11:10 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFE98234; Sat, 21 May 2005 02:11:09 -0400 (EDT) Message-Id: <200505210611.DFE98234@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Robert Sayre'" Cc: "'Atom Syntax'" Subject: RE: multiple ids Date: Sat, 21 May 2005 02:11: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 Thread-Index: AcVdm0F9bnPyJyhjTrKihD0TxrSWkQALtvnA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray directs the editors to insert the following words: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry and Atom Processors MUST treat them as such." It is a long standing and valued tradition in the IETF that Standards Track RFC's MUST NOT impose constraints on applications unless such constraints relate to issues of interoperability. Thus, while it is entirely appropriate for the specification to state that "multiple atom:entry elements with the same atom:id ... describe the same entry" it is NOT appropriate to state how Atom Processors must treat such elements. The text should read simply: "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry." The appropriate handling of multiple instances of the "same entry" is a matter which is the solely up to the discretion of Atom Processors since variances in such handling do not impact interoperablity. One can imagine that various developers will make different decisions in duplicate handling policies. Some processors might even allow their end-users to decide the handling policies. By making such decisions, developers will either enhance or detract from the utility of the overall solutions they develop -- but, it is not up to the IETF to direct what decisions should be made in this case. Restating this in a manner perhaps more friendly to those who declare themselves as "bits on the wire" people: The specification should specify the meaning of the bits on the wire -- not what one does with the bits after receiving them. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 08:18:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13248 for ; Sat, 21 May 2005 08:18: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 j4L5kSHu040063; Fri, 20 May 2005 22:46: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 j4L5kSak040062; Fri, 20 May 2005 22:46:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L5kSPL040048 for ; Fri, 20 May 2005 22:46:28 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4L5kRgt010978; Sat, 21 May 2005 01:46:27 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFE92951; Sat, 21 May 2005 01:46:25 -0400 (EDT) Message-Id: <200505210546.DFE92951@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Graham'" Cc: "'atom-syntax'" Subject: RE: Refresher on Updated/Modified Date: Sat, 21 May 2005 01:46: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 Thread-Index: AcVdoJ2XW0N/FRKnS8ybkr1+gaPs3gAJmfZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1f25b3e6b35beb175d86749f8324d89d@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > What if someone (either the publisher or someone downstream) > wants to store a history of every revision in an archive > feed? To this, Tim Bray answered: > I don't see why, if you wanted that kind of archive, you couldn't > use atom:updated for every little change in the archived version > but atom:updated only for the ones you cared about in the published > version. In which case the archived version would be a superset > of the published version. I see nothing wrong with that. -Tim Of course, the objections to Tim's position are obvious: 1. The case of "someone downstream" was ignored in the answer. Tim only addresses the issue of what the publisher might do. 2. Given Tim's "solution" to the problem, downstream readers would be incapable of maintaining an accurate archive since only the publisher's unpublished archive would have atom:updated values that change on each modification. 3. The "archive" that Tim describes would not actually be a useful archive for many purposes since it would not be an accurate description of the sequence of entries written to the feed. For instance, such an archive would not satisfy legal rules for logging data in financial applications since such an archive could not be used to determine the value of the atom:updated value in entries that had actually been published. This whole argument is silly. Atom:modified is needed. It should be provided. Nobody has given a decent argument against it. If you insist on objecting to it then let the darn thing be optional -- but instead of trying to impose your personal vision on the process, just let the rest of us get on with doing the work we need to do in the way we know we have to do it. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 08:18:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13266 for ; Sat, 21 May 2005 08:18: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 j4L8LnwX036554; Sat, 21 May 2005 01:21: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 j4L8Lnd1036553; Sat, 21 May 2005 01:21:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L8Ll7O036465 for ; Sat, 21 May 2005 01:21:48 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050521082141.JJMS12530.mta13-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sat, 21 May 2005 09:21:41 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050521082141.NMTV29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 09:21:41 +0100 Date: Sat, 21 May 2005 09:21:38 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <264218739.20050521092138@djpowell.net> To: Anne van Kesteren CC: Tim Bray , Atom Syntax Subject: Re: atom:modified : Reducing the cruft In-Reply-To: <428EE6E7.9070502@annevankesteren.nl> References: <771869789.20050521083258@djpowell.net> <428EE6E7.9070502@annevankesteren.nl> 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 Saturday, May 21, 2005, 8:44:39 AM, Anne van Kesteren wrote: > David Powell wrote: >> I detect that a lot of opposition to atom:modified comes from the fact >> that it is a REQUIRED element and that many of the publishers actually >> putting it in the feed and paying for the bandwidth don't intend using >> it frequently? >> >> Would it help if we said that if the atom:modified element is absent, >> its value MAY be taken from the atom:updated element? (or to put it >> another way: atom:modified MAY be omitted if its value is equivalent >> to the value of atom:updated). > I think this will result in people misusing the field. It is hard to predict, but: > Either giving atom:updated the last modified time I think that these publishers will implement atom:updated incorrectly regardless of whether atom:modified is defined, and whether it is optional or not. If atom:modified isn't defined at all, then this would be quite a significant risk. > or giving it the last significant modification time and simply > omitting atom:modified because that is extra work. Yes, this sounds like a risk. We could add a warning about what the consequences might be: "The modified date MAY be used by processors to select the latest revision of an entry. If multiple revisions of an entry exist with the same atom:modified value, then processors MAY select any available revision as the latest." This would act as a good replacement for the contentious paragraph about atom:updated that was dropped from PaceAllowDuplicateIDs. > If it is introduced in some optional fashion it should not relate to > another date construct I think. I support atom:modified whether it is syntactically mandatory, or whether its value is implied if absent. As an alternative, I'm also open to suggestions of a sequential revision id element, but I prefer atom:modified. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 08:18:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13283 for ; Sat, 21 May 2005 08:18: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 j4L6PFBo065092; Fri, 20 May 2005 23: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 j4L6PFvu065091; Fri, 20 May 2005 23:25:15 -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 j4L6PEo5065065 for ; Fri, 20 May 2005 23:25:14 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 48407 invoked by uid 17064); 21 May 2005 06:25:00 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.3.247]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 21 May 2005 06:25:00 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Antone Roundy Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 08:24:52 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 May 2005, at 17:30, Antone Roundy wrote: > On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote: > >> I supposed the surest way to make it impossible to fake the id, is >> to specify that >> by dereferencing the id and doing a GET (whatever the correct >> method of doing that for the >> protocol happens to be) one should be able to retrieve the entry. >> > The unlikelihood of anyone actually retrieving each entry to verify > that it's accurate would make this method only trivially effective. Perhaps not. There was a long thread a few months ago about how to deal with the growing size of feeds. Using a restful method, one simple solution to the problem would have been to have minimal feeds of the following form: http://a.com/feeda http://a.com/feeda/entry1 2005-01-01T05:00+00:00 http://a.com/feeda/entry2 2005-01-02T06:00+00:00 http://a.com/feeda/entry3 2005-01-03T07:00+00:00 Clearly feeds like the above would only be useful if one dereferenced the entry ids. A consumer of an atom feed would thus read a feed, then work out which of the entries it had not yet seen or which had been modified, and then go and fetch the content of those entries by dereferencing the id. In the above case this could be done by doing a GET on for example and retrieving http://a.com/feeda/entry1 2005-01-01T05:00+00:00 I am the legitimate entry <a href="https://a.com/ feedback.php">Use this form to submit your credit card number</ a> Of course the above saves a lot more bandwidth the larger the entry becomes. >>> An oddity this language introduces is that if the entries don't >>> appear in the same Atom Feed Document, they apparently don't have >>> to be treated as the same entry, but if they're aggregated >>> together, they do. Going a little further, if I'm subscribed to >>> both original feeds and an aggregation that includes both, then I >>> have potentially four s with the same id. Which are the >>> same entry and which aren't? Only the two in the aggregation, >>> which really aren't, are required to be treated as the same. >>> >> >> I always thought that two entries with the same id should be >> treated as the same entry. >> What makes you thing otherwise? >> >> > Consider the following three simplified feed documents (or any two > of them, or just the last one): > > // this is the legitimate one Yes but now imagine the same thing written in the minimal format menitoned above: > > http://a.com/feeda > > http://a.com/feeda/entry1 > 2005-01-01T05:00+00:00 > I am the legitimate entry > <a href="https://a.com/ > feedback.php">Use this form to submit your credit card > number</a> > > http://a.com/feeda http://a.com/feeda/entry1 2005-01-01T05:00+00:00 > // this one is phishing > > http://b.com/feedb > > http://a.com/feeda/entry1 > 2005-01-01T10:00+00:00 > I am the legitimate entry > <a href="https://b.com/ > feedback.php">Use this form to submit your credit card > number</a> > > http://a.com/feedb http://a.com/feeda/entry1 2005-01-01T05:00+00:00 > > // this is an aggregation > > http://c.com/feedc > > > http://a.com/feeda > > http://a.com/feeda/entry1 > 2005-01-01T05:00+00:00 > I am the legitimate entry > <a href="https://a.com/ > feedback.php">Use this form to submit your credit card > number</a> > > > > http://b.com/feedb > > http://a.com/feeda/entry1 > 2005-01-01T10:00+00:00 > I am the legitimate entry > <a href="https://b.com/ > feedback.php">Use this form to submit your credit card > number</a> > > http://a.com/feedc http://a.com/feeda http://a.com/feeda/entry1 2005-01-01T05:00+00:00 http://a.com/feedb http://a.com/feeda/entry1 2005-01-01T05:00+00:00 Notice that the source of an entry is much less important in this situation - it does not carry the heavy role of conveying trust. Trust is carried simply by the structure of the http protocol. Also it is clear that there is not much room for phishing here. The content of the entry is retrieved in both cases by GETing So here we have a solution that: > This is already bad enough. Now how about if the phishing feed > claims that it's atom:id is http://a.com/feeda. Worse still. With > the current spec text, an Atom consumer that does a little extra > work, somehow figures out that the phishing version of the entry is > not the same as the legitimate version, and tells the user that > would be violating the spec. In the above case changing the id of a feed would not be very interesting. The content is always fetched by dereferencing the atom id. So a phishing feed that faked its id would not achieve very much. But just to deal with this issue, let us go a little further then and make the id of a feed also dereferenceable. If the id of a feed is the url at which its (head) can be fetched, then there is no way to do much harm by faking the id of one's feed. In conclusion a minimal feed format has the following advantages: - saves heavily on bandwidth (because of its RESTful nature) - removes the whole phishing problem - make it very easy to understand how to generate ids So those are just a few thoughts on the topic. It just seems that if one works with the web these phishing problems seem to disappear. Henry Story From owner-atom-syntax@mail.imc.org Sat May 21 08:20:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13613 for ; Sat, 21 May 2005 08:20: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 j4L3QKhV086821; Fri, 20 May 2005 20:26: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 j4L3QKZ0086820; Fri, 20 May 2005 20:26:20 -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 j4L3QJ7B086773 for ; Fri, 20 May 2005 20:26:19 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so1516011wri for ; Fri, 20 May 2005 20:26: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X759KudJL0Zx2pAdbRdDz2BrB3LuoKZB4nluU9XHOtpVPfuB2xRdqqdqISR2GoPRxvfo9YckFXIpjIwsWrul/UGPDm6l+pcN2Nve9epRRm3G3+nwyxwoTi7TVLCJh3PGn3wOBhy2MKmQNCaNoh2YqXIB6bHRc4z1A7d+6mUeuho= Received: by 10.54.21.39 with SMTP id 39mr2128328wru; Fri, 20 May 2005 20:26:13 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Fri, 20 May 2005 20:26:13 -0700 (PDT) Message-ID: <540e373205052020267b835937@mail.gmail.com> Date: Fri, 20 May 2005 22:26:13 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <605006053.20050521013328@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <605006053.20050521013328@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4L3QJ7B086806 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > > change from a unicode combined char to single + combining > > diacritic, > > No. > > > change in paragraph 27 of an article that doesn't show up in a > > summaries-only feed, > > No. Dave: In my case, and seemingly in the case of most of the tools surveyed, both of those would get a "yes". I suspect that in many cases, simply clicking "edit" on an entry and then immediately clicking "save" will cycle the modified date forward, even if zero changes were made. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Sat May 21 08:24:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13800 for ; Sat, 21 May 2005 08:24: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 j4L1Tp4M052349; Fri, 20 May 2005 18:29: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 j4L1Tp61052348; Fri, 20 May 2005 18:29:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L1To4K052279 for ; Fri, 20 May 2005 18:29:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4L1T9iH004320; Sat, 21 May 2005 02:29:09 +0100 (BST) In-Reply-To: <68fba5c5050520181578705fd5@mail.gmail.com> References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> <68fba5c5050520181578705fd5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39EA2047-EB60-4237-B280-373CD167E65F@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Refresher on Updated/Modified Date: Sat, 21 May 2005 02:29:04 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 2:15 am, Robert Sayre wrote: > > On 5/20/05, Graham wrote: > >> Say I'm aggregating feeds into a search results feed, and I get the >> same entry twice (with the same atom:id and atom:updated), from >> different sources. Would it be acceptable to me to adjust the >> atom:updated by one second and put both in the results, to show the >> end user the entry was available from two places? >> > > I think you are conflating timestamps and version identifiers. Just to be clear then, my example was meant to be of the sort of bad behavior PaceDuplicateIds encourages, not of something I'd want to do. It's the Pace that'd doing the conflating. Graham From owner-atom-syntax@mail.imc.org Sat May 21 08:24:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13807 for ; Sat, 21 May 2005 08:24: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 j4L18Mpn044662; Fri, 20 May 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 j4L18Mxi044661; Fri, 20 May 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 brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L18LwP044628 for ; Fri, 20 May 2005 18:08:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4L16geZ001131; Sat, 21 May 2005 02:06:48 +0100 (BST) In-Reply-To: <1f25b3e6b35beb175d86749f8324d89d@sun.com> References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Refresher on Updated/Modified Date: Sat, 21 May 2005 02:06:40 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 1:48 am, Tim Bray wrote: > I don't see why, if you wanted that kind of archive, you couldn't > use atom:updated for every little change in the archived version > but atom:updated only for the ones you cared about in the published > version. In which case the archived version would be a superset of > the published version. I see nothing wrong with that. -Tim That's exactly my problem. You're having to hack the dates to make it work. Would you encourage hacking in other ways? Say I'm aggregating feeds into a search results feed, and I get the same entry twice (with the same atom:id and atom:updated), from different sources. Would it be acceptable to me to adjust the atom:updated by one second and put both in the results, to show the end user the entry was available from two places? If that's the intention, then I guess it's OK, but it certainly isn't elegant. Graham From owner-atom-syntax@mail.imc.org Sat May 21 08:24:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13822 for ; Sat, 21 May 2005 08:24: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 j4L1FdNP047111; Fri, 20 May 2005 18:15: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 j4L1Fcap047110; Fri, 20 May 2005 18:15: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L1Fbpd047069 for ; Fri, 20 May 2005 18:15:38 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2376490wra for ; Fri, 20 May 2005 18:15:32 -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=GDicvJvzdLI2dBZ2NNWTw28I7PQt4QVAFc4d2t0radQ0CTlfQgAE3+wMcaGI6507eNc9dTVIucNzDI+eK3GZJ4PE2/8ypyjepmqfpRLdFDx7GMw7WD2FYAuwG8xymbox1O8apE3WaFNxiSHLOHAlCOLkUQOR+Lbr1TLxuZLTMII= Received: by 10.54.10.61 with SMTP id 61mr2012706wrj; Fri, 20 May 2005 18:15:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Fri, 20 May 2005 18:15:31 -0700 (PDT) Message-ID: <68fba5c5050520181578705fd5@mail.gmail.com> Date: Fri, 20 May 2005 21:15:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Refresher on Updated/Modified Cc: Tim Bray , atom-syntax In-Reply-To: <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4L1Fcpd047105 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Graham wrote: > Say I'm aggregating feeds into a search results feed, and I get the > same entry twice (with the same atom:id and atom:updated), from > different sources. Would it be acceptable to me to adjust the > atom:updated by one second and put both in the results, to show the > end user the entry was available from two places? I think you are conflating timestamps and version identifiers. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 08:24:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13840 for ; Sat, 21 May 2005 08:24: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 j4L0x3DU041563; Fri, 20 May 2005 17:59: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 j4L0x3JX041562; Fri, 20 May 2005 17:59:03 -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 j4L0x2HN041555 for ; Fri, 20 May 2005 17:59:02 -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 j4L0x2jO013004 for ; Fri, 20 May 2005 18:59:02 -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 <0IGT007Q2EQDLR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:59:02 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002HQEQCUG@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:59:01 -0600 (MDT) Date: Fri, 20 May 2005 17:59:03 -0700 From: Tim Bray Subject: Re: Fetch me an author. Now, fetch me another author. In-reply-to: <428E2C8E.6050506@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <428E2C8E.6050506@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4L0x2HN041556 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On May 20, 2005, at 11:29 AM, Bill de hra wrote: > http://www.franklinmint.fm/blog/archives/000393.html > > "The Atom author element may be inadequate for scientific journals, > legal documents, and legislation. I am shocked, just shocked." > > Translation: The Atom format mandates you can only have one author, > for an entry or a feed. > > Why is this not a spec bug? Can anyone point to consensus on this > decision? A scan of the archives reveals no discussion; i.e. this rule is something that predates the move to the IETF. I believe that (with a bit of offline help) I can explain the reasoning though. We were trying to borrow the Dublin Core semantics, wherein there is the notion of an "Entity Primarily Responsible", dc:creator. So, Atom gives you that with atom:author and the notion of a contributor in atom:contributor. Let me speak as a victim of a few years in the publishing-software trenches: The semantics of author and contributor are a tangled mess, a real swamp, and I don't think that Atom is going to do a very good job of solving them. In particular, I don't think we're going to a better job than Dublin Core. That is to say, if we were to do as some suggest (nuke atom:contributor and make atom:author repeatable) I'm quite certain that we could come up with all sorts of corner cases and problems, probably about as many as with the current setup. So, bearing that in mind, and also bearing in mind Paul's recent essay on process, I'm strongly -1 on any change whatsoever to the current definition of author and contributor. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:24:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13874 for ; Sat, 21 May 2005 08:24: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 j4L158Hp043576; Fri, 20 May 2005 18:05: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 j4L158Sf043575; Fri, 20 May 2005 18:05:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L157W4043530 for ; Fri, 20 May 2005 18:05:07 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050521010501.QDRK9046.mta09-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Sat, 21 May 2005 02:05:01 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050521010501.NHTU242.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 02:05:01 +0100 Date: Sat, 21 May 2005 02:04:57 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <551297761.20050521020457@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: References: 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 [reposted without so many typos and grammatical errors - reply to either] As I was the last person to mention atom:modified, I'll refer to my proposal as an example in this reply. > 1. The datestamp is inserted by the provider. Thus it could be a lie; > this is the Internet, remember. You, the consumer, either trust the > publisher or you don't. If you don't, you will ignore the datestamp > and check the content. If you do, you will believe the datestamp. > Thus, "modified" buys you nothing. The rationale for PaceDateModified2 was to enable multiple revisions of entries to exist in the same Atom Feed Document. This usage doesn't require trust relationships to be set up. Cross-feed duplicate detection is a useful feature that requires a web of trust to work reliably. Atom doesn't provide this natively, but future companion specifications could provide a framework, just as DomainKeys and other specifications are trying to do for SMTP. Hopefully Atom deployments will be a bit more agile than SMTP, so this wouldn't be such a slow process. > 2. There's endless room for argument as to what constitutes an update: The text of PaceDateModified2 is looser than most of the previous proposals that were made, it is actually rather similar to the mandatory atom:modified element in Atom 0.3. It is updated when information in the entry (not the physical atom:entry element), which is reflected in the document is changed. Given that definition, I think that whether atom:modified needs to be updated can reasonably answered: > change in the stylesheet for background colors No: On the web you don't update the Last-Modified date for a web page when a linked style-sheet has changed, nor would you update atom:modified when documents linked to an Atom entry change. It is implicit in any specifications which uses URIs to reference related documents, that the representations are subject to change over time. HTTP's extensive cache-control mechanisms deal with this. > change from a unicode combined char to single + combining > diacritic, No. > change from UTF-8 to UTF-16 encoding No. > change in paragraph 27 of an article that doesn't show up in a > summaries-only feed, No. > 3. Several publishers on the list asserted that they needed the right > to make trivial spelling-correction-level changes without having a > zillion literal-minded feed-reading clients re-fetch the material, and > that they would simply refuse to update an atom:modified date if they > didn't feel like it. Re-fetch? If they know that the atom:modified date has changed, then they already have the entry don't they? Do you mean that they want to discourage clients from re-fetching linked images etc? HTTP cache control mechanisms are the way to do this. Most aggregators defer image retrieval to a browser widget, so whether the document has changed or not will have no effect on whether the linked documents are refetched for these implementations. The Atom police wouldn't be able to stop people from ignoring the specification and faking atom:modified to a fixed value, but the effect for the subscriber would be similar to if a server operator faked Last-Modified to a fixed value in HTTP. The wide deployment of Atom 0.3 suggests that support for atom:modified wouldn't be an unsurmountable burden for implementations, but anyway, there is another alternative: I proposed PaceDateModified2 to address the issue that feeds containing multiple revisions of an entry would not be able to distinguish which revision is the latest. (Remember the entries are unordered). Some sort of atom:revision-count element would work too. Its value could even be defaulted to 0 in its absence for minimal intrusiveness. I think that atom:modified is a better option though, because it has uses beyond revision sorting within a document, and it is probably easiest for implementations to implement given the widespread support for a similar element shown in BlogToolDateSurvey. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 08:24:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13905 for ; Sat, 21 May 2005 08:24: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 j4L0m8Jl037779; Fri, 20 May 2005 17:48: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 j4L0m8Z5037777; Fri, 20 May 2005 17:48:08 -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 j4L0m86k037771 for ; Fri, 20 May 2005 17:48:08 -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 j4L0m70R020335 for ; Fri, 20 May 2005 18:48:08 -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 <0IGT00711E87LR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:48:07 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002OTE86ZZ@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:48:07 -0600 (MDT) Date: Fri, 20 May 2005 17:48:09 -0700 From: Tim Bray Subject: Re: Refresher on Updated/Modified In-reply-to: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> To: Graham Cc: atom-syntax Message-id: <1f25b3e6b35beb175d86749f8324d89d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 20, 2005, at 5:07 PM, Graham wrote: > Tim, can I ask about your thinking regarding the use of atom:updated > in PaceDuplicateIDs. What if someone (either the publisher or someone > downstream) wants to store a history of every revision in an archive > feed? atom:updates forces one to choose only one version per > "significant" change. The mechanism it affords (being able to > automatically display the newest version) is vital, but it doesn't > seem like the best way to do it. I don't see why, if you wanted that kind of archive, you couldn't use atom:updated for every little change in the archived version but atom:updated only for the ones you cared about in the published version. In which case the archived version would be a superset of the published version. I see nothing wrong with that. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13936 for ; Sat, 21 May 2005 08:25: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 j4L07hOR024388; Fri, 20 May 2005 17:07: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 j4L07h0F024387; Fri, 20 May 2005 17:07:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L07g20024378 for ; Fri, 20 May 2005 17:07:42 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4L071vN022466; Sat, 21 May 2005 01:07:07 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Refresher on Updated/Modified Date: Sat, 21 May 2005 01:07:01 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim, can I ask about your thinking regarding the use of atom:updated in PaceDuplicateIDs. What if someone (either the publisher or someone downstream) wants to store a history of every revision in an archive feed? atom:updates forces one to choose only one version per "significant" change. The mechanism it affords (being able to automatically display the newest version) is vital, but it doesn't seem like the best way to do it. Graham From owner-atom-syntax@mail.imc.org Sat May 21 08:25:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13950 for ; Sat, 21 May 2005 08:25: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 j4L08gSw024430; Fri, 20 May 2005 17: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 j4L08g4Z024429; Fri, 20 May 2005 17:08: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-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 j4L08fbS024423 for ; Fri, 20 May 2005 17:08:41 -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 j4L08fjO004817 for ; Fri, 20 May 2005 18:08: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 <0IGT0091VCEG1S@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:08:41 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002LWCEGZZ@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:08:40 -0600 (MDT) Date: Fri, 20 May 2005 17:08:43 -0700 From: Tim Bray Subject: Re: multiple ids In-reply-to: <68fba5c50505191243ba68053@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c50505191243ba68053@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 12:43 PM, Robert Sayre wrote: > > --------------- > The editors are directed to modify > the phrase which starts "If multiple atom:entry elements..." as > follows: > > "If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry and software MUST > treat them as such." > --------------- > > We don't use the word 'software' in the draft. The editors request > replacement text. s/software/Atom Processors/ for consistency with the rest of the draft. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13966 for ; Sat, 21 May 2005 08:25: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 j4L0RRvu030690; Fri, 20 May 2005 17:27: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 j4L0RRct030688; Fri, 20 May 2005 17:27:27 -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 j4L0RQGG030676 for ; Fri, 20 May 2005 17:27:26 -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 j4L0RQjO018098 for ; Fri, 20 May 2005 18:27:26 -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 <0IGT008FVD9PSF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:27:25 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT009X5D9O8J@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:27:25 -0600 (MDT) Date: Fri, 20 May 2005 17:27:27 -0700 From: Tim Bray Subject: Re: Editorial: rules based on MIME media types in @type attributes In-reply-to: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> To: Thomas Broyer Cc: atom-syntax@imc.org Message-id: <360dfb5a01eb1358c7f70968aa87894a@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 20, 2005, at 12:00 AM, Thomas Broyer wrote: > In 4.1.3.2: > [ > If the value of type begins with "text/" or ends with "+xml", the > content SHOULD be local; that is to say, no "src" attribute should > be > provided. > ] > > Replace with: > [ > If the value of type is a text or XML media type, that is, if it > begins > with "text/", is one the XML Media Types [XMLMIME] or ends with > "+xml", > the content SHOULD be local; that is to say, no "src" attribute > should > be provided. > ] I believe that Thomas is right and this is an editorial change, because as written it wouldn't apply to application/xml. You could either do it Thomas' way or simply rewrite to say "... or ends with either '+xml' or '/xml'", either works. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13981 for ; Sat, 21 May 2005 08:25: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 j4L0NK1Y029346; Fri, 20 May 2005 17:23: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 j4L0NKZf029345; Fri, 20 May 2005 17:23: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 j4L0NJxp029339 for ; Fri, 20 May 2005 17:23: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 j4L0NJjO014817 for ; Fri, 20 May 2005 18:23: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 <0IGT0092ND2V1S@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:23:19 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT009WVD1M8J@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:23:19 -0600 (MDT) Date: Fri, 20 May 2005 17:23:22 -0700 From: Tim Bray Subject: Re: Compulsory feed ID? In-reply-to: <428CF963.50609@intertwingly.net> To: Sam Ruby Cc: Atom Syntax Message-id: <44c2ff27e803181e7a7213e445f09975@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <428CF963.50609@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 1:38 PM, Sam Ruby wrote: ... MUCH text elided ... > This proposal seemed to have enjoyed some support, yet it did not seem > to have made it into the current draft, despite being crucial to the > solving the issue that PaceDuplicateIDs was designed to address. > However, for it to work, the re-aggregator would need to have access > to a "self" link, which is not required by the current draft. I do not agree that PaceDuplicateIDs was primarily designed to address the DOS-attack scenario, or even pretends to ameliorate that situation. I think it primarily exists to support a bunch of scenarios where, for different reasons, people wanted to be able to generate feeds where entries might appear more than once. I think the WG basically decided to punt on the DOS scenario. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13993 for ; Sat, 21 May 2005 08:25: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 j4L0Ga4D026101; Fri, 20 May 2005 17:16: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 j4L0GXvw026021; Fri, 20 May 2005 17:16:33 -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 j4L0GRfD025913; Fri, 20 May 2005 17:16: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 j4L0GPjO010339; Fri, 20 May 2005 18:16:25 -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 <0IGT009JECRC1S@edgemail1.Central.Sun.COM>; Fri, 20 May 2005 18:16:24 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002EMCRBUG@mail.sun.net>; Fri, 20 May 2005 18:16:24 -0600 (MDT) Date: Fri, 20 May 2005 17:16:26 -0700 From: Tim Bray Subject: Re: remote content? In-reply-to: <68fba5c505051912583ff9d5c8@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax , Paul Hoffman Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c505051912583ff9d5c8@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 12:58 PM, Robert Sayre wrote: > I don't think we ever resolved this last call issue. > > http://www.imc.org/atom-syntax/mail-archive/msg14383.html > > Tim Bray wrote: >> OK, WG, what do you think? I have long supported the SHOULD here, but >> I can't help observing that a lot of different parties have >> questioned it, I'm not 100% sure it really has consensus support, >> even rough. Rob & John's alternative, as outlined above, seems like a >> fair trade-off that would better reflect the community consensus and >> not really harm interoperability. Anybody want to disagree? Correct, good catch. I issued that call-for-disagreements on April 22nd and there was only one quibble (http://www.imc.org/atom-syntax/mail-archive/msg14384.html), which was quite moderate. I think it's clear that we have rough consensus that we should update the draft as suggested in the following posts: http://www.imc.org/atom-syntax/mail-archive/msg14373.html (last para) http://www.imc.org/atom-syntax/mail-archive/msg14378.html -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14010 for ; Sat, 21 May 2005 08:25: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 j4L0Mbrs029030; Fri, 20 May 2005 17: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 j4L0MbKN029029; Fri, 20 May 2005 17:22:37 -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 j4L0Malm029021 for ; Fri, 20 May 2005 17:22:36 -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 j4L0Ma0R000767 for ; Fri, 20 May 2005 18:22:36 -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 <0IGT007H1D1NLR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 18:22:35 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT009WVD1M8J@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 18:22:35 -0600 (MDT) Date: Fri, 20 May 2005 17:22:37 -0700 From: Tim Bray Subject: Re: Non-empty elements In-reply-to: <68fba5c505051912402e5b0995@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: <5ca60683999580f4877030efdba88599@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c5050518100320204d77@mail.gmail.com> <428BA124.7060409@intertwingly.net> <68fba5c50505181336296efc83@mail.gmail.com> <50aa7629d51ddcdfeb4a10cbd60ae06d@sun.com> <68fba5c505051912402e5b0995@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 12:40 PM, Robert Sayre wrote: >> >> Paul and I consider that the following text has consensus support of >> the WG and the editors are directed to include it in the format draft >> (editorial judgment call on where to insert): >> >> Some applications (one example is full-text indexers) require a >> minimum >> amount of text or (X)HTML to function reliably and predictably. For >> that reason, it is advisable that each atom:entry element contain a >> non-empty atom:title element, a non-empty atom:summary element when >> the >> entry contains no atom:content element, and a non-empty atom:content >> element when that element is present. >> > > Is this text intended to replace the paragraph the editors were > previously directed to insert? Nope, can't do that, because there's stuff in that paragraph that's not here. Here's my best effort at combining the original consensus call with the above paragraph: Experience teaches that feeds which contain textual content are in general more useful than those which do not. Some applications (one example is full-text indexers) require a minimum amount of text or (X)HTML to function reliably and predictably. Feed producers should be aware of these issues. It is advisable that each atom:entry element contain a non-empty atom:title element, a non-empty atom:summary element when the entry contains no atom:content element, and a non-empty atom:content element when that element is present. However, the absence of atom:summary is not an error and Atom Processors MUST NOT fail to function correctly as a consequence of such an absence. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:25:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14030 for ; Sat, 21 May 2005 08:25: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 j4L0XdnT032752; Fri, 20 May 2005 17:33: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 j4L0Xd6O032751; Fri, 20 May 2005 17:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L0Xcw5032708 for ; Fri, 20 May 2005 17:33:38 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050521003332.KOHI23015.mta05-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Sat, 21 May 2005 01:33:32 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050521003332.DDAB18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 01:33:32 +0100 Date: Sat, 21 May 2005 01:33:28 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <605006053.20050521013328@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: References: 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 As I was the last person to mention atom:modified, I'll refer to my proposal as an example in this reply. > 1. The datestamp is inserted by the provider. Thus it could be a lie; > this is the Internet, remember. You, the consumer, either trust the > publisher or you don't. If you don't, you will ignore the datestamp > and check the content. If you do, you will believe the datestamp. > Thus, "modified" buys you nothing. The rationale for PaceDateModified2 was to enable multiple revisions of entries to exist in the same Atom Feed Document. This usage doesn't require trust relationships to be set up. Cross-feed duplicate detection is a useful feature that requries a web of trust to work reliably. Atom doesn't provide this natively, but future companion specifications could provide a framework, just as DomainKeys and other specifications are trying to do for SMTP. Hopefully Atom deployments will be a bit more agile than SMTP, so this wouldn't be such a slow process. > 2. There's endless room for argument as to what constitutes an update: The text of PaceDateModified2 is looser from most of the previous proposals that were made, it is actually rather similar to the mandatory atom:modified element in Atom 0.3. It is updated when changes to information in the entry (not the physical atom:entry element), that are reflected in the document are changed. Given that definition, I think that whether atom:modified needs to be updated can reasonably answered: > change in the stylesheet for background colors No: On the web you don't update the Last-Modified date for a web page when a linked style-sheet has changed, nor would you update atom:modified when documents linked to an Atom entry change. It is implicit in any specifications which uses URIs to reference related documents, that the representations are subject to change over time. HTTP's extensive cache-control mechansisms deal with this. > change from a unicode combined char to single + combining > diacritic, No. > change from UTF-8 to UTF-16 encoding No. > change in paragraph 27 of an article that doesn't show up in a > summaries-only feed, No. > 3. Several publishers on the list asserted that they needed the right > to make trivial spelling-correction-level changes without having a > zillion literal-minded feed-reading clients re-fetch the material, and > that they would simply refuse to update an atom:modified date if they > didn't feel like it. Re-fetch? If they know that the atom:modified date has changed, then they already have the entry don't they? Do you mean that they want to discourage clients from re-fetching linked images etc? HTTP cache control mechanisms are the way to do this. Most aggregators defer image retreival to a browser widgit, so whether the document has changed or not will have no effect on whether the linked documents are refetched for these implementations. The Atom police wouldn't be able to stop people from ignoring the specification and faking atom:modified to a fixed value, but the effect for the subscriber would be similar to if a server operator faked Last-Modified to a fixed value in HTTP. The wide deployment of Atom 0.3 suggests that support for atom:modified wouldn't be an unsurmountable burden for implementations, but anyway, there is another alternative: I proposed PaceDateModified2 to address the issue that feeds containing multiple revisions of an entry would not be able to distinguish which revision is the latest. (Remember the entries are unordered). Some sort of atom:revision-count element would work too. Its value could even be defaulted to 0 in it's absense for minimal intrusiveness. I think that atom:modified is a better option though, because it has uses beyond revision sorting within a document, and it is probably easiest for implementations to implement given the widespread support for a similar element shown in BlogToolDateSurvey. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 08:27:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14232 for ; Sat, 21 May 2005 08:27: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 j4L8bn3H044339; Sat, 21 May 2005 01: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 j4L8bn40044337; Sat, 21 May 2005 01:37: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 j4L8bl78044312 for ; Sat, 21 May 2005 01:37:48 -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); Sat, 21 May 2005 18:37:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 21 May 2005 18:37:43 +1000 Subject: Re: atom:modified : Reducing the cruft From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <771869789.20050521083258@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 21/5/05 5:32 PM, "David Powell" wrote: > Would it help if we said that if the atom:modified element is absent, > its value MAY be taken from the atom:updated element? (or to put it > another way: atom:modified MAY be omitted if its value is equivalent > to the value of atom:updated). I'm not opposed to the idea, but I will note that early on the WG really disliked the idea of establishing precedence/default/fall-back rules for dates. e. From owner-atom-syntax@mail.imc.org Sat May 21 08:27:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14261 for ; Sat, 21 May 2005 08:27: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 j4KNpD0f021459; Fri, 20 May 2005 16: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 j4KNpDh0021458; Fri, 20 May 2005 16:51:13 -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 j4KNpCiC021452 for ; Fri, 20 May 2005 16:51:12 -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 j4KNpCjO021687 for ; Fri, 20 May 2005 17:51:12 -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 <0IGT009RZBLB1S@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 20 May 2005 17:51:12 -0600 (MDT) Received: from [192.168.102.101] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGT002KIBLAZZ@mail.sun.net> for atom-syntax@imc.org; Fri, 20 May 2005 17:51:11 -0600 (MDT) Date: Fri, 20 May 2005 16:51:14 -0700 From: Tim Bray Subject: Re: Compulsory feed ID? In-reply-to: <68fba5c505051912364be862e4@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax , Sam Ruby Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <7518fb35fb3952de6590df9581989685@sun.com> <428ACD94.4070108@intertwingly.net> <428B692B.9060704@intertwingly.net> <68fba5c505051912364be862e4@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 12:36 PM, Robert Sayre wrote: > On 5/19/05, Tim Bray wrote: > >> >> (Text not >> provided, we trust the editors to figure out the correct way to say >> this). > > The editors request that text be provided. In section 4.1.1, change the bullet point that reads atom:feed elements MUST NOT contain more than one atom:id element. to read atom:feed elements MUST contain exactly one atom:id element. Plus, take the ? off the atomId in the RNC immediately above. Editorial oversight from anyone is welcome, I'm kind of tired. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 08:30:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15090 for ; Sat, 21 May 2005 08: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 j4L9ld4I074741; Sat, 21 May 2005 02:47: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 j4L9ldea074740; Sat, 21 May 2005 02:47:39 -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 j4L9laCg074720 for ; Sat, 21 May 2005 02:47:36 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 41641 invoked by uid 17064); 21 May 2005 09:47:36 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.3.247]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 21 May 2005 09:47:36 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) 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: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 11:47:32 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 08:44, Eric Scheid wrote: > On 21/5/05 4:24 PM, "Henry Story" wrote: >> So those are just a few thoughts on the topic. It just seems that >> if one >> works with the web these phishing problems seem to disappear. > > all good stuff, with the exception of making atom:id > dereferenceable... once > you do that you have to allow it to change (to accommodate changes > in server > set up etc), and once you allow it to change it is no longer > effective as an > id :-( Yes. I like the idea of being able to move entries around too. But we do have a dilemma. We have a- non de-referenceable id: - can easily be faked -> lack of trust which undermines its ability to identify anything b- de-referenceable id: - we can't move entries around - but we can trust the id Imagine we have both (as we do, but in a more cumbersome format). If we give the entry a src attribute then we could have a feed such as the following: http://a.com/feeda urn:uuid:1225c695-aaa-4ebb-aaaa-80da344efa6a 2005-01-01T05:00+00:00 urn:uuid:2225c695-bbb-4ebb-aaaa-80da344efa6a 2005-01-02T06:00+00:00 urn:uuid:3225c695-ccc-4ebb-aaaa-80da344efa6a 2005-01-03T07:00+00:00 Then since the ids can be faked and spoofed all over the place, and since there is no way to automatically verify the correct uses, the amount of trust that can be placed in them to identify an entry is minimal, close to 0, certainly a *lot* less than the dereferenceable src uri, which will therefore inevitably take the place of the identifier. So in any case it seems like the dereferenceable id wins. Perhaps this is just something in the architecture of the web that we have to work with. But perhaps it is not such a problem after all, because perhaps we can have dereferenceable ids that allow us to move entries around. I can think of a few: - if an entry moves the old entry position redirects to the new one. - one creates a special redirect service to redirect ids to their current location - one creates a new URI to URL mapping protocol Henry Story > So, all the above, but using atom:link[@rel='self'] instead. > > BTW, /feed/id is useful for other things -- primarily to help big > aggregators to realise that they are retrieving the same feed from > more than > one location (eg. with and without www.) > > e. From owner-atom-syntax@mail.imc.org Sat May 21 08:49:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17499 for ; Sat, 21 May 2005 08: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 j4LCZAWD063232; Sat, 21 May 2005 05:35: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 j4LCZAYi063230; Sat, 21 May 2005 05:35: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 j4LCZ94I063213 for ; Sat, 21 May 2005 05:35:09 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 21205 invoked by uid 17064); 21 May 2005 12:35:09 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.3.247]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 21 May 2005 12:35:09 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49F73D54-9E47-474B-942C-069F459E90E8@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 14:35:05 +0200 To: Eric Scheid , Atom Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 12:50, Eric Scheid wrote: > On 21/5/05 7:47 PM, "Henry Story" wrote: > >> But perhaps it is not such a problem after all, because perhaps we >> can have >> dereferenceable ids that allow us to move entries around. I can >> think of a >> few: >> >> 1. if an entry moves the old entry position redirects to the new one. > not always possible. > > >> 2. one creates a special redirect service to redirect ids to their >> current location > Such things already exist in various forms. There is for example a > service > which resolves DOI URIs. > >> 3. one creates a new URI to URL mapping protocol > blech. > > e. I agree, but the question is whether they do their work better than the one we are trying to give to a non de-refrenceable atom:id. I like the intent behind atom:id. But I don't think one can just hope that things work out the way we would want them to. For the moment there is a worry that the atom:id gear is just decoration, a magical place holder for properties we would like something to have, but have no idea how to achieve. If there are other solutions, it would be nice to hear of them in more detail. I have heard that signatures could help resolve the problem. Perhaps we should get a security expert to give some advice on a solution like that. Henry Story From owner-atom-syntax@mail.imc.org Sat May 21 08:59:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11426 for ; Sat, 21 May 2005 08:13: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 j4L7X8Jg009601; Sat, 21 May 2005 00:33: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 j4L7X8Rr009600; Sat, 21 May 2005 00:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L7X75u009522 for ; Sat, 21 May 2005 00:33:07 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050521073301.RDHZ23015.mta05-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Sat, 21 May 2005 08:33:01 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050521073301.MGZL2626.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 08:33:01 +0100 Date: Sat, 21 May 2005 08:32:58 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <771869789.20050521083258@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: atom:modified : Reducing the cruft In-Reply-To: References: 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 detect that a lot of opposition to atom:modified comes from the fact that it is a REQUIRED element and that many of the publishers actually putting it in the feed and paying for the bandwidth don't intend using it frequently? Would it help if we said that if the atom:modified element is absent, its value MAY be taken from the atom:updated element? (or to put it another way: atom:modified MAY be omitted if its value is equivalent to the value of atom:updated). -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 09:03:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18520 for ; Sat, 21 May 2005 09:03: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 j4LCpcH3073265; Sat, 21 May 2005 05:51: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 j4LCpcla073264; Sat, 21 May 2005 05:51:38 -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 j4LCpcFx073255 for ; Sat, 21 May 2005 05:51:38 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 27596 invoked by uid 17064); 21 May 2005 12:51:38 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.3.247]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 21 May 2005 12:51:38 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <133CEF43-7122-4E4C-A3B1-7F6E692B8694@bblfish.net> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 14:51:34 +0200 To: Graham X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 13:19, Graham wrote: > The appropriate answer to this is to say comparing an id from a > document retrieved from one URI to an id retrieved from a second > URI is not reliable. This makes feed:ids largely useless. The > primary use, of comparing with a previous version of a document > retrieved from the same URI, is fine. > > Graham That makes sense. But then it only gives one a very limited ability to move an entry from one place to another. If the entry has to be located in the same feed, then presumably that means that it would be difficult to move the entry from one domain to another. Or is the following a necessary sequence for moving an entry from one domain to another: 1. Entry e_id1 is referred to in feed f1 on domain d1 where it has location d1:loc1 2. e_id1 is placed on domain d2 at d2:loc2 3. feed f1 now points to d2:loc2 as the new location of e_id1 4. e_id1's new representation in domain d2 somehow points to its new trusted feed f2 also located on d2 It is complicated, but I suppose it could work. Henry Story From owner-atom-syntax@mail.imc.org Sat May 21 09:19:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19715 for ; Sat, 21 May 2005 09:19: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 j4LD6v8N081296; Sat, 21 May 2005 06:06: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 j4LD6vms081295; Sat, 21 May 2005 06:06:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LD6uHS081250 for ; Sat, 21 May 2005 06:06:57 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LD6MfJ004326; Sat, 21 May 2005 14:06:28 +0100 (BST) In-Reply-To: <133CEF43-7122-4E4C-A3B1-7F6E692B8694@bblfish.net> References: <133CEF43-7122-4E4C-A3B1-7F6E692B8694@bblfish.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76F5EB63-7051-417C-B3DA-F3C3FB6444D5@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Accidental and intentional atom:id collisions Date: Sat, 21 May 2005 14:06:22 +0100 To: Henry Story X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 1:51 pm, Henry Story wrote: > That makes sense. But then it only gives one a very limited ability > to move an entry from one place > to another. If the entry has to be located in the same feed, then > presumably that means that it > would be difficult to move the entry from one domain to another. The feed becomes a redirect and the aggregator can reliably compare ids across the old and new addresses. Not hard. Graham From owner-atom-syntax@mail.imc.org Sat May 21 10:18:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24122 for ; Sat, 21 May 2005 10:18: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 j4LA7Qq9086444; Sat, 21 May 2005 03:07: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 j4LA7QHQ086443; Sat, 21 May 2005 03:07:26 -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 j4LA7P4a086381 for ; Sat, 21 May 2005 03:07:26 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 39189 messnum 4213255 invoked from network[83.70.217.193/unknown]); 21 May 2005 10:07:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail13.svc.cra.dublin.eircom.net (qp 39189) with SMTP; 21 May 2005 10:07:19 -0000 Message-ID: <428F0853.60605@dehora.net> Date: Sat, 21 May 2005 11:07: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 Subject: Re: Fetch me an author. Now, fetch me another author. References: <428E2C8E.6050506@dehora.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 Tim Bray wrote: > A scan of the archives reveals no discussion; i.e. this rule is > something that predates the move to the IETF. I believe that (with a > bit of offline help) I can explain the reasoning though. We were trying > to borrow the Dublin Core semantics, wherein there is the notion of an > "Entity Primarily Responsible", dc:creator. So, Atom gives you that > with atom:author and the notion of a contributor in atom:contributor. I also scanned the archives and found no consensus. > Let me speak as a victim of a few years in the publishing-software > trenches: The semantics of author and contributor are a tangled mess, a > real swamp, and I don't think that Atom is going to do a very good job > of solving them. In particular, I don't think we're going to a better > job than Dublin Core. That is to say, if we were to do as some suggest > (nuke atom:contributor and make atom:author repeatable) I'm quite > certain that we could come up with all sorts of corner cases and > problems, probably about as many as with the current setup. I observe this is one of the problems with borrowing semantics without attribution and without consultation. You might be quite certain, but the fact is we don't know. > So, bearing that in mind, and also bearing in mind Paul's recent essay > on process, I'm strongly -1 on any change whatsoever to the current > definition of author and contributor. -Tim As co-chair, please instruct the editors to add spec text mentioning this rationale, it is hardly satisfactory to have that constraint in there as it stands. It's tempting now to perform due diligence, and go through every constraint in the spec and cross-reference consensus. cheers Bill From owner-atom-syntax@mail.imc.org Sat May 21 10:44:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26070 for ; Sat, 21 May 2005 10:44: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 j4LECFTo093788; Sat, 21 May 2005 07:12: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 j4LECFEU093785; Sat, 21 May 2005 07:12: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEC6MA093760 for ; Sat, 21 May 2005 07:12:10 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2585349wra for ; Sat, 21 May 2005 07:11:56 -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=e8h45M2pLp8tDPm7e9IO4aTNX8vk5atN8UZR4eJq4thlErZGXS1VepbiaoHJjkAuSkXqKa33v6BnNunlh5a/fGDsAgReLUgMNrPBGL9NiaEwW4R09sLbO+95IfpgjcTMPzWT6tsVKgQCNP8EFqmAJ8WSPXkki+hqYpEjWTWh9CU= Received: by 10.54.50.46 with SMTP id x46mr2377586wrx; Sat, 21 May 2005 07:11:56 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 07:11:56 -0700 (PDT) Message-ID: <68fba5c505052107115fb14452@mail.gmail.com> Date: Sat, 21 May 2005 10:11:56 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Tim Bray , atom-syntax In-Reply-To: <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LECCMA093773 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Graham wrote: > You can say that about anything. A flat list of people associated > with an entry is infinitely better than the weird one author/multiple > contributors model that doesn't offer a clear way to cope with the > common model of multiple co-authors. Ben Lund is okay with the current draft: http://www.imc.org/atom-syntax/mail-archive/msg15380.html Why aren't you? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 10:45:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26151 for ; Sat, 21 May 2005 10:45: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 j4LEEdhi093940; Sat, 21 May 2005 07:14: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 j4LEEd5J093939; Sat, 21 May 2005 07:14: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEEOBf093898 for ; Sat, 21 May 2005 07:14:38 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2586184wra for ; Sat, 21 May 2005 07:14: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=QoTbLlVcqu79ut9mViZb0kbkHRHM8f68wyJmuRHkUVipJRbiIjMWPwmDy39AAPdOegdNydIfLumS0xqe0StNV9eD9X9Om6hp7oYcIPQ+PrlnHpTZiG5wRxSF+ZIesMswjf211I7LuYOg5e1gbqoVZn6fa6zWdbGsBI7utW4fngI= Received: by 10.54.79.8 with SMTP id c8mr1680104wrb; Sat, 21 May 2005 07:14:09 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 07:14:09 -0700 (PDT) Message-ID: <68fba5c505052107144811f67a@mail.gmail.com> Date: Sat, 21 May 2005 10:14:09 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: Refresher on Updated/Modified Cc: Tim Bray , Graham , atom-syntax In-Reply-To: <200505210546.DFE92951@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1f25b3e6b35beb175d86749f8324d89d@sun.com> <200505210546.DFE92951@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LEEdBf093933 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > This whole argument is silly. Atom:modified is needed. It should be > provided. Nobody has given a decent argument against it. I was deeply -1 and continue to be. Every single problem you're talking about with atom:updated will simply be transferred to atom:modified. Timestamps are not version identifiers. We can't standardize versioning. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 10:46:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26204 for ; Sat, 21 May 2005 10:46: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 j4LEALMS093670; Sat, 21 May 2005 07:10: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 j4LEALRZ093669; Sat, 21 May 2005 07:10: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEA5os093642 for ; Sat, 21 May 2005 07:10:12 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2584705wra for ; Sat, 21 May 2005 07:09: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=tKa67BgN4xZ02m++aESc331L8dzBbf2Lvnx1f7bUrE5PMZGW9/ExjQ+/ql6lpWvRCWQoxKWGZZftlcYrvSQ8W7MxgeHD0SxjbJzYV6cmXyPAeaMODMdOjCdMMzKAHEq1yXv0H94lpU+r/zqdIOCESDboMl5vZ1c+FnGIY5xzXeU= Received: by 10.54.32.4 with SMTP id f4mr2295401wrf; Sat, 21 May 2005 07:09:58 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 07:09:58 -0700 (PDT) Message-ID: <68fba5c50505210709413c0ff6@mail.gmail.com> Date: Sat, 21 May 2005 10:09:58 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Atom Syntax In-Reply-To: <428F0853.60605@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LEAHos093659 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bill de hra wrote: > > Tim Bray wrote: > > > A scan of the archives reveals no discussion; i.e. this rule is > > something that predates the move to the IETF. I believe that (with a > > bit of offline help) I can explain the reasoning though. We were trying > > to borrow the Dublin Core semantics, wherein there is the notion of an > > "Entity Primarily Responsible", dc:creator. So, Atom gives you that > > with atom:author and the notion of a contributor in atom:contributor. > > I also scanned the archives and found no consensus. I can point you to many discussions surrounding atom:author. Here's one: http://www.imc.org/atom-syntax/mail-archive/msg13793.html The requirement made it through nine drafts, much discussion, and two last calls. I don't think you have a consensus argument. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 10:50:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26451 for ; Sat, 21 May 2005 10:50: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 j4LER7vX095519; Sat, 21 May 2005 07:27: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 j4LER7a4095518; Sat, 21 May 2005 07:27:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEQxec095505 for ; Sat, 21 May 2005 07:27:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LEQ0v7016421; Sat, 21 May 2005 15:26:04 +0100 (BST) In-Reply-To: <68fba5c505052107115fb14452@mail.gmail.com> References: <428E2C8E.6050506@dehora.net> <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> <68fba5c505052107115fb14452@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 15:25:58 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 3:11 pm, Robert Sayre wrote: > On 5/21/05, Graham wrote: > >> You can say that about anything. A flat list of people associated >> with an entry is infinitely better than the weird one author/multiple >> contributors model that doesn't offer a clear way to cope with the >> common model of multiple co-authors. >> > > Ben Lund is okay with the current draft: > http://www.imc.org/atom-syntax/mail-archive/msg15380.html > > Why aren't you? Because what you presented to him makes no sense against the current draft. Two problems: - The first is that atom:author is referenced in the singular throughout. I think it's a stretch to say "Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen" is a "person, corporation, or similar entity". I'm not saying it's wrong, but the current wording is inadequate and/or misleading with regards to your usage. 2nd problem: Let's say I write an entry, but a couple of my friends contribute some material (abbreviated syntax): Graham Friend 1 Friend 2 The appropriate way to decode this is "Written by Graham with contributions from Friend 1 and Friend 2" Lets decode your sample in the same way: "Written by Yuri Fialko, David Sandwell, Mark Simons & Paul Rosen with contributions from Yuri Fialko, David Sandwell, Mark Simons and Paul Rosen" Which makes no sense. The two usages are incompatible, and the spec needs to say which is correct. Graham From owner-atom-syntax@mail.imc.org Sat May 21 10:55:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26875 for ; Sat, 21 May 2005 10:55: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 j4LEdCVM096303; Sat, 21 May 2005 07:39: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 j4LEdBSK096301; Sat, 21 May 2005 07:39:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEcwXM096272 for ; Sat, 21 May 2005 07:39:09 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LEcYDD018175; Sat, 21 May 2005 15:38:34 +0100 (BST) In-Reply-To: <68fba5c5050521073064d859f2@mail.gmail.com> References: <428E2C8E.6050506@dehora.net> <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> <68fba5c505052107115fb14452@mail.gmail.com> <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <68fba5c5050521073064d859f2@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <147E03E8-8F9F-4969-B8F8-AC2F603E8272@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 15:38:32 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 3:30 pm, Robert Sayre wrote: > On 5/21/05, Graham wrote: > >> The appropriate way to decode this is "Written by Graham with >> contributions from Friend 1 and Friend 2" >> >> Lets decode your sample in the same way: "Written by Yuri Fialko, >> David Sandwell, Mark Simons & Paul Rosen with contributions from Yuri >> Fialko, David Sandwell, Mark Simons and Paul Rosen" >> >> Which makes no sense. The two usages are incompatible, and the spec >> needs to say which is correct. > > What makes you think 'authorship' is arrived at by composing > atom:author and atom:contributor elements. It's the impression I've had for nearly 2 years. If I'm wrong, then fine, but there's nothing in the spec that says anything either way. Graham From owner-atom-syntax@mail.imc.org Sat May 21 10:56:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26914 for ; Sat, 21 May 2005 10:56: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 j4LEicnC097089; Sat, 21 May 2005 07:44: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 j4LEicPL097087; Sat, 21 May 2005 07:44:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LEiVGf097022 for ; Sat, 21 May 2005 07:44:35 -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 (rwcrmhc11) with SMTP id <2005052114441601300ej82de>; Sat, 21 May 2005 14:44:16 +0000 Date: Sat, 21 May 2005 08:44:14 -0600 Subject: Re: Compulsory feed ID? 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: <200505210630.DFF03270@ms8.netsolmail.com> 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 Saturday, May 21, 2005, at 12:30 AM, Bob Wyman wrote: > Tim Bray wrote: >> I think the WG basically decided to punt on the DOS scenario. -Tim > I believe you are correct in describing the WG's unfortunate > disposition towards this issue. (Naturally, I object...) I've tried to get discussion of this moving a few times with very little success. Honestly, I've been a bit surprised that you haven't been more active in taking the lead on pushing the conversation forward and ensuring that threads addressing the issue don't die out, given the strength of your comments on the issue in the past and the obvious significance to your business. In the flurry of discussion of various issues that's been going on recently, I can't remember whether you've stated a specific opinion on the best way to solve the problem or not, and if so, whether it has been affected at all by discussion or related changes that have occurred since it's original expression. Perhaps you, who are probably in a better position than any of us to speak from experience on how to deal with this, could refresh our memories of specifically what you think the best solution is. From owner-atom-syntax@mail.imc.org Sat May 21 10:57:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26975 for ; Sat, 21 May 2005 10: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 j4LESaUf095626; Sat, 21 May 2005 07:28: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 j4LESad7095625; Sat, 21 May 2005 07:28: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.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LESWdm095612 for ; Sat, 21 May 2005 07:28:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2591579wra for ; Sat, 21 May 2005 07:28:26 -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=YzDoIwPUfI6gUX3u7i+wOpsJ2YxyqzEmrVPiX1AfWcjMkOtrfbPjUE2S+gJ9JI4zVu/cxq+xrZSDnCLHUYYfpj6CTk7gQ0dCZxLqG8wGMVyDsL2d00cYjNld80iL0g53gdJNy0xr27v65EBkpqtv0qGWOeS1slgtk2QoBQX6z+k= Received: by 10.54.50.46 with SMTP id x46mr2385056wrx; Sat, 21 May 2005 07:28:26 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 07:28:26 -0700 (PDT) Message-ID: <68fba5c50505210728537ac61c@mail.gmail.com> Date: Sat, 21 May 2005 10:28:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Refresher on Updated/Modified Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> <68fba5c5050520181578705fd5@mail.gmail.com> <39EA2047-EB60-4237-B280-373CD167E65F@mac.com> <68fba5c505052018417c4c9f28@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LESZdm095620 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Graham wrote: > On 21 May 2005, at 2:41 am, Robert Sayre wrote: > > > OK. The chairs' latest text reads: > > > > " If multiple atom:entry elements with the same atom:id value appear > > in an Atom Feed document, they describe the same entry and Atom > > Processors MUST treat them as such." > > > > Where does the bad behavior come in, and what can we do to > > discourage it? > > This line: > "Their atom:updated timestamps SHOULD be different" Ah. I misread their orders, thinking I was only to include the first sentence. You're 100% right. Note that this does not mean I'm in favor of atom:modified. Versioning problems aren't solved by timestamps. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:02:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27399 for ; Sat, 21 May 2005 11:02: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 j4LEq7IS098118; Sat, 21 May 2005 07:52: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 j4LEq7mn098117; Sat, 21 May 2005 07:52:07 -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 j4LEq5rk098095 for ; Sat, 21 May 2005 07:52:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2599611wra for ; Sat, 21 May 2005 07:51: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=J8NUxrfTwiRQM6DdFZpwSTT7xXdshOvx0icqgM1xQ/5GFO0l27cW04QfZW1ZP+lT1KiS26C8VQ09kFvb+dZkTCJu3eoDoVt+1PYKWFt63GNre3ywJHo9MrekfWS39jtiR6BGamKQp9lAFOTOcArjIv/WEDPy+XAt130JZ9eKzeU= Received: by 10.54.15.15 with SMTP id 15mr2311996wro; Sat, 21 May 2005 07:51:59 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 07:51:59 -0700 (PDT) Message-ID: <68fba5c505052107511175d8fe@mail.gmail.com> Date: Sat, 21 May 2005 10:51:59 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: atom:modified : Reducing the cruft Cc: Tim Bray , Atom Syntax In-Reply-To: <771869789.20050521083258@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <771869789.20050521083258@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LEq6rk098112 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I detect that a lot of opposition to atom:modified comes from the fact A lot of the opposition comes from the fact the WG found it useless, months ago. Allowing multiple atom:ids in a feed doesn't change that. You want to sit here and talk about atom:modified for another month? For an optional element that would be trivial to add as an extension? I will sit here and argue it again, but I will probably just pull pages from the archives where we talked about this months ago. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:11:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28103 for ; Sat, 21 May 2005 11:11: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 j4LF2EPB099476; Sat, 21 May 2005 08:02: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 j4LF2EW0099475; Sat, 21 May 2005 08:02: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 j4LF2DmY099462 for ; Sat, 21 May 2005 08:02:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2602812wra for ; Sat, 21 May 2005 08:02:08 -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=eGTHs/oQNSKKwtv9/RUySxSfqCGV1D3bNVcKWUhH5oU2WX8cpc5MzBo3kn+Q549PVX064dCDzxh1eBYIehFmM7tTftNS2cFEFapsgueA9TeweU+uSumRhZGehfwhL8MPApFKSc5kCNJ/wQ2S3Qnzo+AP3V4CIraJCUIk5ZCJOy0= Received: by 10.54.7.16 with SMTP id 16mr2397388wrg; Sat, 21 May 2005 08:02:08 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 08:02:08 -0700 (PDT) Message-ID: <68fba5c50505210802774eca74@mail.gmail.com> Date: Sat, 21 May 2005 11:02:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Cc: atom-syntax In-Reply-To: <147E03E8-8F9F-4969-B8F8-AC2F603E8272@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> <68fba5c505052107115fb14452@mail.gmail.com> <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <68fba5c5050521073064d859f2@mail.gmail.com> <147E03E8-8F9F-4969-B8F8-AC2F603E8272@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LF2EmY099469 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > It's the impression I've had for nearly 2 years. If I'm wrong, then > fine, but there's nothing in the spec that says anything either way. Well, there's nothing in the spec that explicitly separates atom:author from lots of elements. Your impression is not in the spec. I do think you're right about the wording of atom:author, though. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:12:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28164 for ; Sat, 21 May 2005 11: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 j4LF3FE3099610; Sat, 21 May 2005 08:03: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 j4LF3Fad099609; Sat, 21 May 2005 08:03:15 -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 j4LF3EZS099594 for ; Sat, 21 May 2005 08:03:15 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 93160 messnum 5253867 invoked from network[83.70.217.193/unknown]); 21 May 2005 15:03:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail02.svc.cra.dublin.eircom.net (qp 93160) with SMTP; 21 May 2005 15:03:08 -0000 Message-ID: <428F4DA9.4070806@dehora.net> Date: Sat, 21 May 2005 16:03:05 +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: Fetch me an author. Now, fetch me another author. References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> In-Reply-To: <68fba5c50505210709413c0ff6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > On 5/21/05, Bill de hra wrote: > >>I also scanned the archives and found no consensus. > > > I can point you to many discussions surrounding atom:author. Thanks for the offer, but I've already done that for myself. I don't much care for the number of discussions, I care about this specification and whether it has consensus. Can you find one discussion that addresses cardinality? Most of the ones I saw when I grepped through the archives seemed to focus on feed/entry inheritance. > Here's one: > http://www.imc.org/atom-syntax/mail-archive/msg13793.html > > The requirement made it through nine drafts, much discussion, and two > last calls. I don't think you have a consensus argument. If you don't think I have a consensus argument, you should be able to demonstrate that by pointing me at consensus. Look. I understand the process more or less says we're done, I read Paul's mail, and as the editor I do appreciate your sentiments and opinion on this. If there is consensus and I missed it, I'll withdraw and apologise for distracting the WG. If an IETF process wizard says it's too late now, technically or in the spirit of things, I'll withdraw. If the WG makes it known that at this point in the process, I have to like them apples, we're shipping, I'll withdraw. Otherwise as a WG member I'm of the opinion that letting a specification get through that has no consensus, and that we know has no consensus, is irresponsible. cheers Bill From owner-atom-syntax@mail.imc.org Sat May 21 11:17:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28450 for ; Sat, 21 May 2005 11:17: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 j4LF8f8d099892; Sat, 21 May 2005 08:08: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 j4LF8fLe099891; Sat, 21 May 2005 08:08: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LF8eCw099872 for ; Sat, 21 May 2005 08:08:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2604948wra for ; Sat, 21 May 2005 08:08: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T4Ti3XwBCcgW8rzdY8StRHZ2JIExK2EaNIdbt8BYdJvudMD1EyvDNyqyni9CqrmLdzXiaMJ/eAfbq3KH8JBHfjnv47ytmOqyKKDiFNiD2H6s+Bp2fcc3UrM1n9IzMelg+By6v4R0AxSrbPQ9qODEOK7YDfaQLC2UmX4nAEpO49I= Received: by 10.54.31.70 with SMTP id e70mr2411053wre; Sat, 21 May 2005 08:08:34 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 08:08:34 -0700 (PDT) Message-ID: <68fba5c505052108086cad3806@mail.gmail.com> Date: Sat, 21 May 2005 11:08:34 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: PROCESS QUESTION: are we done yet? 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 j4LF8eCw099877 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > If we make any technical changes > after the IETF last call is over (that is, weeks ago), we will > probably have to go through an IETF Last Call again. Good engineering > design allows for this. Many of us work for, or have worked for, > companies whose product ship dates slipped for months or even years > as improvements were made before shipping 1.0. How long of a delay can we expect? I'm thinking 2 months, minimum. Does that sound about right? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:24:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28756 for ; Sat, 21 May 2005 11:24: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 j4LFD1Pl000266; Sat, 21 May 2005 08:13: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 j4LFD1gZ000265; Sat, 21 May 2005 08:13:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LFCxaA000245 for ; Sat, 21 May 2005 08:13:00 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4LFBlVR023940; Sat, 21 May 2005 16:11:52 +0100 (BST) In-Reply-To: <68fba5c50505210802774eca74@mail.gmail.com> References: <428E2C8E.6050506@dehora.net> <554F891E-6AF1-4BEE-AC23-7B622339227F@mac.com> <68fba5c505052107115fb14452@mail.gmail.com> <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <68fba5c5050521073064d859f2@mail.gmail.com> <147E03E8-8F9F-4969-B8F8-AC2F603E8272@mac.com> <68fba5c50505210802774eca74@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <751D978E-0AC9-4872-9C48-CDC9ADA4A4B3@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 16:11:45 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 4:02 pm, Robert Sayre wrote: >> It's the impression I've had for nearly 2 years. If I'm wrong, then >> fine, but there's nothing in the spec that says anything either way. >> > > Well, there's nothing in the spec that explicitly separates > atom:author from lots of elements. Your impression is not in the spec. I just about grasp what you're saying here. I certainly do not think it's the obvious model from the spec, or an obvious model to most people. > I do think you're right about the wording of atom:author, though. Good. Graham From owner-atom-syntax@mail.imc.org Sat May 21 11:26:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28869 for ; Sat, 21 May 2005 11:26: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 j4LFHtHP000749; Sat, 21 May 2005 08:17: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 j4LFHt3N000748; Sat, 21 May 2005 08:17:55 -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 j4LFHsn3000741 for ; Sat, 21 May 2005 08:17:54 -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); Sun, 22 May 2005 01:18:03 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 01:17:52 +1000 Subject: Re: Refresher on Updated/Modified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505052107144811f67a@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/5/05 12:14 AM, "Robert Sayre" wrote: > >> This whole argument is silly. Atom:modified is needed. It should be >> provided. Nobody has given a decent argument against it. > > I was deeply -1 and continue to be. Every single problem you're > talking about with atom:updated will simply be transferred to > atom:modified. > > Timestamps are not version identifiers. > We can't standardize versioning. atom:modified more than hits the 80:20 mark, especially if we ignore the edge cases of bad actors (which no proposal stands much chance against). e. From owner-atom-syntax@mail.imc.org Sat May 21 11:31:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29217 for ; Sat, 21 May 2005 11:31: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 j4LFGVfC000613; Sat, 21 May 2005 08:16: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 j4LFGV4e000612; Sat, 21 May 2005 08:16:31 -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 j4LFGUvZ000595 for ; Sat, 21 May 2005 08:16:31 -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); Sun, 22 May 2005 01:16:35 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 01:16:25 +1000 Subject: Re: Fetch me an author. Now, fetch me another author. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.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/5/05 12:25 AM, "Graham" wrote: >> Ben Lund is okay with the current draft: >> http://www.imc.org/atom-syntax/mail-archive/msg15380.html >> >> Why aren't you? > > Because what you presented to him makes no sense against the current > draft. > > [...] > > Which makes no sense. The two usages are incompatible, and the spec > needs to say which is correct. what if in that example was renamed to (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the s? using that model (in that message) without renaming the element will only be confusing. e. From owner-atom-syntax@mail.imc.org Sat May 21 11:33:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29302 for ; Sat, 21 May 2005 11:33: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 j4LFN9dU001241; Sat, 21 May 2005 08:23: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 j4LFN9Be001240; Sat, 21 May 2005 08:23: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LFN9Cc001219 for ; Sat, 21 May 2005 08:23:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2610064wra for ; Sat, 21 May 2005 08:23: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=cWTYzu5PEqWwGiJC6QqUWddjGP5afueAU+kXZ32u2RJVn4wyDdoBPe4BLbHepufjouW5sMrYs6TaOE2T7ddPLtXCH5tdtV5Pay18UgPlGvSeicV2qB4hWPiKCCmtM8hqzZERG3VqTgiLPAsBkcbhG1wK2BSgLxvKMqZ+kQSO83E= Received: by 10.54.107.4 with SMTP id f4mr2327964wrc; Sat, 21 May 2005 08:23:03 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 08:23:03 -0700 (PDT) Message-ID: <68fba5c505052108233056469@mail.gmail.com> Date: Sat, 21 May 2005 11:23:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Atom Syntax In-Reply-To: <428F4DA9.4070806@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LFN9Cc001234 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bill de hra wrote: > If there is consensus and I missed it, I'll withdraw and apologise for > distracting the WG. If an IETF process wizard says it's too late now, > technically or in the spirit of things, I'll withdraw. If the WG makes > it known that at this point in the process, I have to like them apples, > we're shipping, I'll withdraw. Otherwise as a WG member I'm of the > opinion that letting a specification get through that has no consensus, > and that we know has no consensus, is irresponsible. Well, this is all process bullshit. What is the technical problem? What document is impossible to express with the current syntax? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:38:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29507 for ; Sat, 21 May 2005 11:38: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 j4LFSN3B002602; Sat, 21 May 2005 08: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 j4LFSNTx002601; Sat, 21 May 2005 08:28:23 -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 j4LFSMjq002498 for ; Sat, 21 May 2005 08:28:23 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2611703wra for ; Sat, 21 May 2005 08:28:17 -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=jQQUSQ6vSRUaZLYciTXJtJC3h6K32IAB5+JPNDm9pd+E1O/2J5ZTERqYHFPj5ZPRmeM+7ReB/VmfWCuEU6MLuRWWjED4oCdEL0ej4Hh3mjxw0ApSFgnVX9GHb+rOdHxMGPBN+FYAdMTXfcNcllvs0XXcmXXgWY0gNgggnXhxfuk= Received: by 10.54.16.60 with SMTP id 60mr2062123wrp; Sat, 21 May 2005 08:28:17 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 08:28:17 -0700 (PDT) Message-ID: <68fba5c50505210828117ed91e@mail.gmail.com> Date: Sat, 21 May 2005 11:28:17 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: Refresher on Updated/Modified Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052107144811f67a@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LFSNjq002594 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Eric Scheid wrote: > atom:modified more than hits the 80:20 mark, especially if we ignore the > edge cases of bad actors (which no proposal stands much chance against). Oh, really? What are you applying that cliche to? What problem does it solve? Maybe a concrete example would help. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 11:39:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29601 for ; Sat, 21 May 2005 11:39: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 j4LBT3tE026251; Sat, 21 May 2005 04:29: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 j4LBT3ok026250; Sat, 21 May 2005 04:29:03 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LBT28L026173 for ; Sat, 21 May 2005 04:29:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.63.217]) by smtp.cegetel.net (Postfix) with ESMTP id 725A21A44CD; Sat, 21 May 2005 13:28:19 +0200 (CEST) Message-ID: <428F1B75.5060903@cegetel.net> Date: Sat, 21 May 2005 13:28:53 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: Editorial: rules based on MIME media types in @type attributes References: <4420.82.127.77.43.1116572410.squirrel@ssl-webmail.sitadelle.com> <360dfb5a01eb1358c7f70968aa87894a@sun.com> In-Reply-To: <360dfb5a01eb1358c7f70968aa87894a@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: > > > On May 20, 2005, at 12:00 AM, Thomas Broyer wrote: > >> In 4.1.3.2: >> [ >> If the value of type begins with "text/" or ends with "+xml", the >> content SHOULD be local; that is to say, no "src" attribute should be >> provided. >> ] >> >> Replace with: >> [ >> If the value of type is a text or XML media type, that is, if it >> begins >> with "text/", is one the XML Media Types [XMLMIME] or ends with >> "+xml", >> the content SHOULD be local; that is to say, no "src" attribute >> should >> be provided. >> ] > > > I believe that Thomas is right and this is an editorial change, > because as written it wouldn't apply to application/xml. You could > either do it Thomas' way or simply rewrite to say "... or ends with > either '+xml' or '/xml'", either works. -Tim > No, because I think the rules should also match application/xml-external-parsed-entity and text/xml-external-parsed-entity. This also needs the following to be dropped or reworded (maybe just drop the word "normally" in "this would normally mean"): [ If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type. ] -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 21 12:37:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04451 for ; Sat, 21 May 2005 12:37: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 j4LGGQCo007006; Sat, 21 May 2005 09:16: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 j4LGGQ9T007005; Sat, 21 May 2005 09:16: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 j4LGGNKw006991 for ; Sat, 21 May 2005 09:16:24 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 May 2005 16:16:17 -0000 Received: from xdsl-213-196-249-186.netcologne.de (EHLO klangraum) [213.196.249.186] by mail.gmx.net (mp007) with SMTP; 21 May 2005 18:16:17 +0200 X-Authenticated: #163624 Date: Sat, 21 May 2005 18:19:51 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. Message-ID: <20050521161951.GA20801@klangraum> Mail-Followup-To: Atom Syntax References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Eric Scheid [2005-05-21 17:30]: > what if in that example was renamed to (and > specced to be something other than a Person Construct), +1, calling it “author” when that sort of usage is expected and encouraged is a lie. > and some mechanism introduced to indicate the nature of the > contribution by each of the s? Allowing atom:category would be nice, though I think we can punt on that. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sat May 21 13:00:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05929 for ; Sat, 21 May 2005 13: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 j4LGp9lA010828; Sat, 21 May 2005 09:51: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 j4LGp9Lv010827; Sat, 21 May 2005 09:51: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LGp8UG010818 for ; Sat, 21 May 2005 09:51:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2639622wra for ; Sat, 21 May 2005 09:51: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RnOtWlU8Qu6a5+YLsMFH72Ek920g6J84M58utff4Y7U1OQJZqMrFXcUEm6kGuQ/oxJnatBijAanHahjrIdatUfA1q8juqasjZj7C0UtAofEnm3yunhlwNDezXKvHAcfLkkR4uyUrS0QhDhi+5koGKQ2VXYCj/bxcMGJF/hWvqsk= Received: by 10.54.7.16 with SMTP id 16mr2443217wrg; Sat, 21 May 2005 09:51:03 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 09:51:03 -0700 (PDT) Message-ID: <68fba5c505052109513598f04@mail.gmail.com> Date: Sat, 21 May 2005 12:51:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. In-Reply-To: <20050521161951.GA20801@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LGp8UG010821 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, A. Pagaltzis wrote: > > * Eric Scheid [2005-05-21 17:30]: > > what if in that example was renamed to (and > > specced to be something other than a Person Construct), What are you talking about? Please refrain from complaining your pet semantics aren't in the draft. Here are some simple questions, which you can answer by reading the example I gave, and reading the draft. http://www.imc.org/atom-syntax/mail-archive/msg15380.html Who is the author of that entry? Who are the contributors? There is no mention of 'byline'. You are complaining that you can't have multiple 'authors' for some definition of 'author', because of element cardinality. I observe that Ben Lund's example, with multiple dc:creator elements, was a failure. Multiple author elements failed the science journal use case, the basis of your original objection. format-08 works. I fully agree that other ways of arranging authors and contributors are possible and reasonable, but no one has demonstrated a document that format-08 can't cover. At this stage, changing the spec to suit religious preferences would be extremely arrogant. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 13:34:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08888 for ; Sat, 21 May 2005 13:34: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 j4LHOH9t013758; Sat, 21 May 2005 10:24: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 j4LHOH4L013757; Sat, 21 May 2005 10:24:17 -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 j4LHOF65013740 for ; Sat, 21 May 2005 10:24: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); Sun, 22 May 2005 03:24:24 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 03:24:14 +1000 Subject: Re: Fetch me an author. Now, fetch me another author. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505052109513598f04@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/5/05 2:51 AM, "Robert Sayre" wrote: >> what if in that example was renamed to (and specced to be >> something other than a Person Construct), and some mechanism introduced to >> indicate the nature of the contribution by each of the s? > What are you talking about? Please refrain from complaining your pet > semantics aren't in the draft. It wasn't a complaint, it was a suggestion, and it was directed more to Graham than to you. Here's a free cluepon: "what if [...]" > Here are some simple questions, which > you can answer by reading the example I gave, and reading the draft. > > http://www.imc.org/atom-syntax/mail-archive/msg15380.html > > Who is the author of that entry? > Who are the contributors? The problem with the example you gave is that it suggests that even entries with just the one author/contributor would need two person constructs in the entry, or maybe just the one ... either way it's confusing. Also, more importantly, how do you then indicate which individuals listed as have an credit and which individuals were only s. Consider this example (and please note that the second line isn't the literal bits on the wire): ##### a list of THREE names ##### Bob BellowsB.html Fred FellowsF.html Jon JelloJ.html Ada AielloA.html [...] Now, this *is* a valid format-08 document, right? BUT can you tell me who the THREE authors are, and who the fourth person is who is only a contributor (and not an author)? So: valid format-08, but junk data. > There is no mention of 'byline'. There most certainly is a mention of the thing I have referred to elsewhere as a "byline". It happens to be serialised within . Instead of the literal element name "byline" I could just as easily use the literal element name of "authorship". > format-08 works. for some definition of "works" ... like "passes the validator", but not "provides meaningful semantics". > I fully agree that other ways of arranging authors and contributors > are possible and reasonable, but no one has demonstrated a document > that format-08 can't cover. can we shoe-horn data into elements? sure. would that document then pass the validator? sure can we extract that data in a meaningful sense? no. > At this stage, changing the spec to suit > religious preferences would be extremely arrogant. Oh, please, stop trolling. e. From owner-atom-syntax@mail.imc.org Sat May 21 13:48:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09690 for ; Sat, 21 May 2005 13:48: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 j4LHcfXt017575; Sat, 21 May 2005 10:38: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 j4LHceIv017573; Sat, 21 May 2005 10:38: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LHcdOD017565 for ; Sat, 21 May 2005 10:38:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2655463wra for ; Sat, 21 May 2005 10:38:34 -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=pbgWks0V6M8j5N0QMs+PocAxyJIJyB32cLCQBF0TCGYtC1QrTWXXRVXSlhxpEyGvXLq174l88H6U3ja0+4DDE0Plw9zbZEFzdOIwFA+L2xcbvkgvea6/RAo2vwtx7bYTacxPxH8BPv3oDhF06iDW9MG8zkqJtVzSle1loqg6tbc= Received: by 10.54.10.61 with SMTP id 61mr2380177wrj; Sat, 21 May 2005 10:38:34 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 10:38:34 -0700 (PDT) Message-ID: <68fba5c505052110387667acd1@mail.gmail.com> Date: Sat, 21 May 2005 13:38:34 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052109513598f04@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LHceOD017568 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Eric Scheid wrote: > > Here are some simple questions, which > > you can answer by reading the example I gave, and reading the draft. > > > > http://www.imc.org/atom-syntax/mail-archive/msg15380.html > > > > Who is the author of that entry? > > Who are the contributors? > > The problem with the example you gave is that it suggests that even entries > with just the one author/contributor would need two person constructs in the > entry, or maybe just the one ... either way it's confusing. No, it doesn't. Why are you saying it suggests that? There are two questions and two answers. I don't see a problem. > > Also, more importantly, how do you then indicate which individuals listed as > have an credit and which individuals were only > s. Why are you mapping elements to types of credit? There is nothing in the spec that suggests they map to types of credit. As I said, please read the draft. > > Consider this example (and please note that the second line isn't the > literal bits on the wire): > > > ##### a list of THREE names ##### > Bob BellowsB.html > Fred FellowsF.html > Jon JelloJ.html > Ada AielloA.html > [...] > > > Now, this *is* a valid format-08 document, right? BUT can you tell me who > the THREE authors are, and who the fourth person is who is only a > contributor (and not an author)? No. Why do you think that's a requirement? Couldn't you add an extension to differentiate them? > > So: valid format-08, but junk data. > > > There is no mention of 'byline'. > > There most certainly is a mention of the thing I have referred to elsewhere > as a "byline". It happens to be serialised within . Instead of > the literal element name "byline" I could just as easily use the literal > element name of "authorship". > > > format-08 works. > > for some definition of "works" ... like "passes the validator", but not > "provides meaningful semantics". > > > I fully agree that other ways of arranging authors and contributors > > are possible and reasonable, but no one has demonstrated a document > > that format-08 can't cover. > > can we shoe-horn data into elements? sure. > would that document then pass the validator? sure > can we extract that data in a meaningful sense? no. > > > At this stage, changing the spec to suit > > religious preferences would be extremely arrogant. > > Oh, please, stop trolling. Seriously, 2 more months of this crap to solve a 'problem' which you can't give an example of. You might have a perfect spec, but no one will care if it is never done. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 14:50:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13949 for ; Sat, 21 May 2005 14:50: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 j4LIbM26022840; Sat, 21 May 2005 11:37: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 j4LIbMKo022839; Sat, 21 May 2005 11:37:22 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LIbL5M022827 for ; Sat, 21 May 2005 11:37:21 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.63.217]) by smtp.cegetel.net (Postfix) with ESMTP id 541823182E1; Sat, 21 May 2005 20:37:15 +0200 (CEST) Message-ID: <428F7FE1.7010402@cegetel.net> Date: Sat, 21 May 2005 20:37:21 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Robert Sayre Cc: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> In-Reply-To: <68fba5c505052109513598f04@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: >I fully agree that other ways of arranging authors and contributors >are possible and reasonable, but no one has demonstrated a document >that format-08 can't cover. > The Atom Syndication Fformat spec has two authors and many contributors. Limiting to one author, you can't distinguish between the authors and contributors. +1 on allowing multiple atom:author -1 to dropping atom:contributor -1 to renaming atom:author (I did already say I was +1 on having deterministic content model and according care to element ordering but that's not really the point here) The Atom Syndication Format draft-ietf-atompub-format-08 Mark Nottingham mnot@pobox.com http://www.mnot.net/ Robert Sayre rfsayre@boswijck.com http://boswijck.com Tim Bray Mark Pilgrim Sam Ruby Norman Walsh -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 21 14:52:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14020 for ; Sat, 21 May 2005 14:52: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 j4LIgNOO023160; Sat, 21 May 2005 11:42: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 j4LIgN6N023159; Sat, 21 May 2005 11:42: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4LIgMAx023113 for ; Sat, 21 May 2005 11:42:22 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 May 2005 18:42:16 -0000 Received: from xdsl-213-196-249-254.netcologne.de (EHLO klangraum) [213.196.249.254] by mail.gmx.net (mp001) with SMTP; 21 May 2005 20:42:16 +0200 X-Authenticated: #163624 Date: Sat, 21 May 2005 20:45:50 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. Message-ID: <20050521184550.GA21525@klangraum> Mail-Followup-To: Atom Syntax References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68fba5c505052109513598f04@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: 8bit * Robert Sayre [2005-05-21 19:05]: > At this stage, changing the spec to suit religious preferences > would be extremely arrogant. Please stop talking to people about “process bullshit” at one occasion and turning around to chide others for “at this stage” at the next. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sat May 21 14:55:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15331 for ; Sat, 21 May 2005 14:55: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 j4LIk9OW023396; Sat, 21 May 2005 11: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 j4LIk9U9023395; Sat, 21 May 2005 11:46:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LIk8DC023387 for ; Sat, 21 May 2005 11:46:09 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 2829 invoked by uid 10); 21 May 2005 18:46:02 -0000 Received: (vexira-qq 02822-33D12497 invoked from network) 21 May 2005 20:46:02 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 May 2005 18:46:02 -0000 Message-ID: <428F81F9.1060603@annevankesteren.nl> Date: Sat, 21 May 2005 20:46:17 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Robert Sayre , Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <428F7FE1.7010402@cegetel.net> In-Reply-To: <428F7FE1.7010402@cegetel.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > +1 on allowing multiple atom:author > -1 to dropping atom:contributor > -1 to renaming atom:author +1 to that. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sat May 21 15:23:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18642 for ; Sat, 21 May 2005 15:23: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 j4LJDKD0026913; Sat, 21 May 2005 12:13: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 j4LJDKt8026912; Sat, 21 May 2005 12:13:20 -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 j4LJDJ5S026881 for ; Sat, 21 May 2005 12:13:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2684257wra for ; Sat, 21 May 2005 12:13: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KcdU1qfNuxRVeyxsiqE01W5AioZs1nmUTDhD+VW7WB6mc6P4qKEzbYtbFAfCIy+7RrxDrrpDxIQpRPdCkPCU9GTkBzygUeof+U+6n1I8U37nt4LUAHPZFHbEmwzHkbTyIX7Bj2lhrN7/BGgQCnM5q9njiHFxOwmHTCmBrCvTE7o= Received: by 10.54.41.54 with SMTP id o54mr1782700wro; Sat, 21 May 2005 12:13:13 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 12:13:13 -0700 (PDT) Message-ID: <68fba5c50505211213808cf70@mail.gmail.com> Date: Sat, 21 May 2005 15:13:13 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. In-Reply-To: <20050521184550.GA21525@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <20050521184550.GA21525@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LJDK5S026907 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, A. Pagaltzis wrote: > > * Robert Sayre [2005-05-21 19:05]: > > At this stage, changing the spec to suit religious preferences > > would be extremely arrogant. > > Please stop talking to people about "process bullshit" at one > occasion and turning around to chide others for "at this stage" > at the next. As I said before, it doesn't matter if the spec is perfect if it takes forever. Making up requirements after last call is out of order. Eric is making up requirements and adding category elements to author elements. It is beyond ridiculous. Pardon me if I'm getting impatient, but I don't think any of the ideas raised in the past few days are critical improvements to the format. In fact, all I see is people twiddling their beanies about semantics, rather than explaining why they need X for their products (Wyman excluded--note that he raised his atom:id issue in last call). Bob's bits-on-the-wire approach to multiple ids is fine. We can put the DOS issue in the security concerns, but it really comes down to "don't believe everything you read on the internet". The current suggested text makes the terrible mistake of conflating atom:id and timestamps. I remember Graham once tried to re-raise the atom:modified idea, and was told that he was very close to being out-of-order. Well, it certainly is now. Not only is it offensive, but there's no reason to expect it will work, and no reason it couldn't be added if it does happen to work. So, really, we have folks who want to delay this spec because they think they've solved Distributed Versioning On The Internet. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 15:26:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18860 for ; Sat, 21 May 2005 15:26: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 j4LJIm7t027399; Sat, 21 May 2005 12:18: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 j4LJImUi027398; Sat, 21 May 2005 12:18:48 -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 j4LJIlLE027390 for ; Sat, 21 May 2005 12:18:47 -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); Sun, 22 May 2005 05:18:55 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 05:18:45 +1000 Subject: extracting authors and contributors from the format 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 Here's an abbreviated feed: Raggett, D, Hors, A, and I Jacobs Dave Raggett Arnaud Le Hors Ian Jacobs Homer Simpson Marge Simpson Barney Rubble, Esq Simpson, H J, and D Raggett Dave Raggett Homer Simpson Raggett, D, and H J Simpson Dave Raggett Homer Simpson The very real task I have is to produce an A-Z index of authors. Is this right: Arnaud Le Hors Barney Rubble, Esq Dave Raggett Dave Raggett Dave Raggett Homer Simpson Homer Simpson Homer Simpson Ian Jacobs Marge Simpson Raggett, D, and H J Simpson Raggett, D, Hors, A, and I Jacobs Simpson, H J, and D Raggett maybe this is better: Arnaud Le Hors Barney Rubble, Esq Dave Raggett Homer Simpson Ian Jacobs Marge Simpson Raggett, D, and H J Simpson Raggett, D, Hors, A, and I Jacobs Simpson, H J, and D Raggett getting closer: Arnaud Le Hors Barney Rubble, Esq Dave Raggett Homer Simpson Ian Jacobs Marge Simpson finally, is this it: Arnaud Le Hors Barney Rubble, Esq Dave Raggett Homer Simpson Ian Jacobs The first list is obviously wrong, and so is the second, and the third list is also wrong (Marge Simpson is a contributor, not an author ... or in the words of the format-08 spec, Marge "contributed to an entry", but was not indicated to be an "author of" that entry). The last list looks correct, right? But there's a problem. Can you spot it? e. From owner-atom-syntax@mail.imc.org Sat May 21 15:27:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18904 for ; Sat, 21 May 2005 15: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 j4LJGirB027223; Sat, 21 May 2005 12:16: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 j4LJGiqU027222; Sat, 21 May 2005 12:16:44 -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 j4LJGh8o027214 for ; Sat, 21 May 2005 12:16: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); Sun, 22 May 2005 05:16:49 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 05:16:39 +1000 Subject: Re: Fetch me an author. Now, fetch me another author. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <428F81F9.1060603@annevankesteren.nl> 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/5/05 4:46 AM, "Anne van Kesteren" wrote: > Thomas Broyer wrote: >> +1 on allowing multiple atom:author >> -1 to dropping atom:contributor >> -1 to renaming atom:author > > +1 to that. I'm +0.5 to all that ... the sticky problem is just how do we insert an authorship string like "Raggett, D, Hors, A, and I Jacobs" into an entry, and I'm -1 on using an extension for that since there is a $17 billion industry already using feeds that really wants to be able to insert that kind of authorship string. No, we can't put that inside for reasons I'll explain in a moment. e. From owner-atom-syntax@mail.imc.org Sat May 21 15:42:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20126 for ; Sat, 21 May 2005 15:42: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 j4LJW68x031059; Sat, 21 May 2005 12:32: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 j4LJW6eA031058; Sat, 21 May 2005 12:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LJW5tO031014 for ; Sat, 21 May 2005 12:32:05 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050521193159.GSON9046.mta09-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sat, 21 May 2005 20:31:59 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050521193159.SXCG29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 20:31:59 +0100 Date: Sat, 21 May 2005 20:31:55 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1427126178.20050521203155@djpowell.net> To: Robert Sayre CC: atom-syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <68fba5c50505210728537ac61c@mail.gmail.com> References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> <68fba5c5050520181578705fd5@mail.gmail.com> <39EA2047-EB60-4237-B280-373CD167E65F@mac.com> <68fba5c505052018417c4c9f28@mail.gmail.com> <68fba5c50505210728537ac61c@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 Saturday, May 21, 2005, 3:28:26 PM, Robert Sayre wrote: >> This line: >> "Their atom:updated timestamps SHOULD be different" > Ah. I misread their orders, thinking I was only to include the first > sentence. You're 100% right. Note that this does not mean I'm in favor > of atom:modified. Versioning problems aren't solved by timestamps. Whoa! I misread that too. (I mentioned the "contentious atom:updated paragraph" that had been removed in an earlier mail - I didn't realize that it was still in) Just to be clear, is this the text that will be included in the next draft? : > If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry and software MUST > treat them as such. > > Their atom:updated timestamps SHOULD be different, and processing > software SHOULD regard entries with duplicate atom:id and atom:updated > values as evidence of an error in the feed generation. If an Atom Feed > Document contains multiple entries with the same atom:id, software MAY > choose to display all of them or some subset of them. One typical > behavior would be to display only the entry with the latest > atom:updated timestamp. This is much worse than I thought. That second paragraph is bad on so many levels.... -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 15:42:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20154 for ; Sat, 21 May 2005 15: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 j4LJYQE6031854; Sat, 21 May 2005 12: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 j4LJYQLj031853; Sat, 21 May 2005 12:34:26 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LJYOMX031809 for ; Sat, 21 May 2005 12:34:25 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.63.217]) by smtp.cegetel.net (Postfix) with ESMTP id 2D92A1A432C; Sat, 21 May 2005 21:33:41 +0200 (CEST) Message-ID: <428F8D43.9010404@cegetel.net> Date: Sat, 21 May 2005 21:34:27 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Eric Scheid Cc: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. 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: >I'm +0.5 to all that ... the sticky problem is just how do we insert an >authorship string like "Raggett, D, Hors, A, and I Jacobs" into an entry, >and I'm -1 on using an extension for that since there is a $17 billion >industry already using feeds that really wants to be able to insert that >kind of authorship string. > > You don't, but it can be built from multiple atom:author elements: Ragget, D Hors, A I Jaccobs ...but we might need atom:author elements to be ordered... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 21 16:01:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21431 for ; Sat, 21 May 2005 16:01: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 j4LJnoDd037229; Sat, 21 May 2005 12:49: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 j4LJno9u037228; Sat, 21 May 2005 12:49:50 -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 j4LJnm0U037213 for ; Sat, 21 May 2005 12:49:49 -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); Sun, 22 May 2005 05:49:57 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 05:49:47 +1000 Subject: Re: PROCESS QUESTION: are we done yet? (was: Fetch me an author) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c50505211213808cf70@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/5/05 5:13 AM, "Robert Sayre" wrote: > Making up requirements after last call is out of order. Not so... Paul Hoffman wrote: > New issues for the format spec are now being brought up, issues that > existed *before* the WG Last Call, much less the IETF-wide Last Call. > The IETF process allows for this. Read that last line again. e. From owner-atom-syntax@mail.imc.org Sat May 21 16:10:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22660 for ; Sat, 21 May 2005 16:10: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 j4LK0JIW040629; Sat, 21 May 2005 13:00: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 j4LK0Jcg040628; Sat, 21 May 2005 13:00: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 j4LK0Hke040561 for ; Sat, 21 May 2005 13:00:18 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2697997wra for ; Sat, 21 May 2005 13:00: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=YpFBYNeSCzRSzLto+7kxuWSJi3bRunL1hBNuFSo6ikUPt9ar9fkKixJnxYnvIlhEe9PfDOkqYBhLtOrvL2nJhZyB5tiRLv4oK+mxezGzMQxHBmTU4NMLN4WbzQiCNdgxgOYSrxQ+KvND1yGGAebTDVRQO8GiyUfxWA5XeaPP3Dg= Received: by 10.54.76.12 with SMTP id y12mr2538367wra; Sat, 21 May 2005 13:00:12 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 13:00:12 -0700 (PDT) Message-ID: <68fba5c5050521130023a3289f@mail.gmail.com> Date: Sat, 21 May 2005 16:00:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Phil Ringnalda Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Thomas Broyer , Atom Syntax In-Reply-To: <428F9162.4070602@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <428F7FE1.7010402@cegetel.net> <428F9162.4070602@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LK0Ike040613 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Phil Ringnalda wrote: > Thomas Broyer wrote: > > The Atom Syndication Fformat spec has two authors and many contributors. > > Limiting to one author, you can't distinguish between the authors and > > contributors. > > Actually, no. It has one author, a "corporation, or similar entity," the > ATOMPUB Working Group, and two editors and many contributors. (Editorial > nit: -08 says it's a product of the Network Working Group, apparently > the xml2rfc default for ). http://www.rfc-editor.org/rfcfaq.html 2) Every RFC is attributed to the "Network Working Group". What working group is that? This label in the heading of every RFC is historical in form and symbolic in content. Historically, "network working group" meant the set of researchers who developed the packet switching protocols for the ARPAnet, beginning in 1969. This label is maintained on RFCs as a reminder of the long and significant technical history that is recorded in the RFC series, and as a reminder that today's technical decisions, wise or not, may be with us for many years. Today, the "Network Working Group" should be interpreted as the set of users, vendors, and researchers who are working to improve and extend the Internet, in particular under the ISOC/IETF umbrella. ------ Of course, the entity primarily responsible for the draft is the IETF, and the internet community. A theory: no one who thought IETF last call meant we were done is reading the list anymore, so all we have left are people intent on descending every rathole and continuing to work on the spec until it becomes a suitably ornate design-by-committee monster. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 16:15:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23003 for ; Sat, 21 May 2005 16:15: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 j4LK3vH8041895; Sat, 21 May 2005 13:03: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 j4LK3v1J041894; Sat, 21 May 2005 13:03: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LK3u9j041857 for ; Sat, 21 May 2005 13:03:56 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2699010wra for ; Sat, 21 May 2005 13:03:50 -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=Q667H1htTKPq81fQFpbInw/3j07/dmxU0zCu6QkrjWmxHKVbP0bjNNU6AwuZCT0hyki9c0IKYn14G7/KKf8xM21z6V7LSAPtZdxz9UkL6Ni3/skB/W5o4yzytAcifwAA1DZLhNILeAT6ClnZK0jxJsqTKzvQYLDHjnkuQrLmxBI= Received: by 10.54.140.3 with SMTP id n3mr2530816wrd; Sat, 21 May 2005 13:03:49 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 13:03:49 -0700 (PDT) Message-ID: <68fba5c50505211303671eb5ff@mail.gmail.com> Date: Sat, 21 May 2005 16:03:49 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: PROCESS QUESTION: are we done yet? (was: Fetch me an author) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505211213808cf70@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LK3u9j041880 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Eric Scheid wrote: > > On 22/5/05 5:13 AM, "Robert Sayre" wrote: > > > Making up requirements after last call is out of order. > > Not so... > > Paul Hoffman wrote: > > New issues for the format spec are now being brought up, issues that > > existed *before* the WG Last Call, much less the IETF-wide Last Call. > > The IETF process allows for this. > > Read that last line again. Paul and Tim are the ones that decide what is out of order. I am just stating my opinion, which is that more work on the format spec is a waste of time. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 16:15:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23033 for ; Sat, 21 May 2005 16:15: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 j4LK5lv7042486; Sat, 21 May 2005 13: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 j4LK5l5i042484; Sat, 21 May 2005 13:05:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LK5kwb042440 for ; Sat, 21 May 2005 13:05:46 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 30934 invoked by uid 10); 21 May 2005 20:05:39 -0000 Received: (vexira-qq 30915-4B291933 invoked from network) 21 May 2005 22:05:39 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 May 2005 20:05:39 -0000 Message-ID: <428F94A2.7030206@annevankesteren.nl> Date: Sat, 21 May 2005 22:05:54 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: 4.2.7.1 Comparing atom:id Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was wondering about: # Likewise, # # http://www.example.com/~bob # http://www.example.com/%7ebob # http://www.example.com/%7Ebob # # are three distinct identifiers, because IRI %-escaping is significant # for the purposes of comparison. s/significant/insignificant/? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sat May 21 16:32:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24906 for ; Sat, 21 May 2005 16:32: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 j4LKMoGK048112; Sat, 21 May 2005 13:22: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 j4LKMoJv048110; Sat, 21 May 2005 13:22: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LKMnVa048067 for ; Sat, 21 May 2005 13:22:50 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2705271wra for ; Sat, 21 May 2005 13: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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GGqTvCM64RLCqTJ9E/EDiF9s+IpiopH+qD8d5cVJuG9PeOOAHrAdWe8UebifaD8D8ylbFJtq8hWw+eTljnSP/t1wvsXwMkdrBuEoclMHCBIpoh5DApZ+nyS/QX/05GymTMCPdeXzjq+Z8yB01SPgziQxSnAhSiqUMayUt6JPQBY= Received: by 10.54.37.78 with SMTP id k78mr2418782wrk; Sat, 21 May 2005 13:22:44 -0700 (PDT) Received: from ?12.45.57.189? ([12.45.57.189]) by mx.gmail.com with ESMTP id 16sm97527wrl.2005.05.21.13.22.42; Sat, 21 May 2005 13:22:44 -0700 (PDT) Message-ID: <428F988E.2070407@gmail.com> Date: Sat, 21 May 2005 13:22:38 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <428F7FE1.7010402@cegetel.net> <428F9162.4070602@gmail.com> <68fba5c5050521130023a3289f@mail.gmail.com> In-Reply-To: <68fba5c5050521130023a3289f@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: > On 5/21/05, Phil Ringnalda wrote: > >>Actually, no. It has one author, a "corporation, or similar entity," the >>ATOMPUB Working Group, and two editors and many contributors. (Editorial >>nit: -08 says it's a product of the Network Working Group, apparently >>the xml2rfc default for ). > > > http://www.rfc-editor.org/rfcfaq.html > > 2) Every RFC is attributed to the "Network Working Group". Bah. I was confused by the way some WGs list themselves while it's still an I-D, and some don't. I'll go back to my corner now. Phil Ringnalda From owner-atom-syntax@mail.imc.org Sat May 21 17:35:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29052 for ; Sat, 21 May 2005 17:35: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 j4LLDOFG054425; Sat, 21 May 2005 14: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 j4LLDOVn054424; Sat, 21 May 2005 14:13:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LLDMGJ054415 for ; Sat, 21 May 2005 14:13:23 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 18246 invoked by uid 10); 21 May 2005 21:13:16 -0000 Received: (vexira-qq 18238-75453368 invoked from network) 21 May 2005 23:13:16 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 May 2005 21:13:16 -0000 Message-ID: <428FA47B.6040707@annevankesteren.nl> Date: Sat, 21 May 2005 23:13:31 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Atom Syntax Subject: Re: 4.2.7.1 Comparing atom:id References: <428F94A2.7030206@annevankesteren.nl> In-Reply-To: <428F94A2.7030206@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > > I was wondering about: > > # Likewise, > # > # http://www.example.com/~bob > # http://www.example.com/%7ebob > # http://www.example.com/%7Ebob > # > # are three distinct identifiers, because IRI %-escaping is significant > # for the purposes of comparison. > > s/significant/insignificant/? I see I might have misinterpreted the prose. If so, I think it is not very clear. Can't we just say something that atom:id IRIs MUST NOT be normalized? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sat May 21 17:46:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00328 for ; Sat, 21 May 2005 17:46: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 j4LLZcgJ056212; Sat, 21 May 2005 14:35: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 j4LLZc3o056210; Sat, 21 May 2005 14:35: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LLZb7p056168 for ; Sat, 21 May 2005 14:35:37 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2725727wra for ; Sat, 21 May 2005 14:35: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=PPVp9kfjYFNkYwlxdg5CYvTiE0c5UhkdTd3HgTmvwhaxAyvKRagikc5u98SRsPxQQz3nOz6UXFXj2C5sAe2WmQejMVKipiU4yKZu9pMsYQUXYm2/ATQhoBfDyFAOTIA/HKGXDrzJKX2DsarAbJfcUoO4DWy5MBwcpqXM60v++vE= Received: by 10.54.16.60 with SMTP id 60mr2200709wrp; Sat, 21 May 2005 14:35:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 14:35:31 -0700 (PDT) Message-ID: <68fba5c50505211435c90d34d@mail.gmail.com> Date: Sat, 21 May 2005 17:35:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: 4.2.7.1 Comparing atom:id Cc: Atom Syntax In-Reply-To: <428FA47B.6040707@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428F94A2.7030206@annevankesteren.nl> <428FA47B.6040707@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LLZb7p056198 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Anne van Kesteren wrote: > > Anne van Kesteren wrote: > > > > > > I was wondering about: > > > > # Likewise, > > # > > # http://www.example.com/~bob > > # http://www.example.com/%7ebob > > # http://www.example.com/%7Ebob > > # > > # are three distinct identifiers, because IRI %-escaping is significant > > # for the purposes of comparison. > > > > s/significant/insignificant/? > > I see I might have misinterpreted the prose. If so, I think it is not > very clear. Can't we just say something that atom:id IRIs MUST NOT be > normalized? I think the last paragraph of RFC3987, section 5.1 already says that :) http://rfc.net/rfc3987.html#s5.1. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 17:55:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01323 for ; Sat, 21 May 2005 17:55: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 j4LLjhEv059784; Sat, 21 May 2005 14:45: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 j4LLjgqm059783; Sat, 21 May 2005 14:45:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LLjgox059777 for ; Sat, 21 May 2005 14:45:42 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LLjdTl006383; Sat, 21 May 2005 17:45:40 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFH82867; Sat, 21 May 2005 17:45:39 -0400 (EDT) Message-Id: <200505212145.DFH82867@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'Graham'" Cc: "'atom-syntax'" Subject: atom:modified indicates temporal ORDER not version.... Date: Sat, 21 May 2005 17:45:36 -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: <68fba5c50505210728537ac61c@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeFdm48/QoVPShSIW0RcwaNHL3OgANNtdQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >Versioning problems aren't solved by timestamps. I don't understand why this "version" issue keeps coming up. It should be apparent to everyone that there is NO relationship between timestamp and version. Timestamps have only two functions: 1. Different timestamps indicate different instances of an entry. 2. Timestamps allow assumptions concerning temporal ORDER or sequence to made It is totally reasonable for me to develop a "V1.0" followed by a "V2.0" which is then followed by a "V1.1" -- if I have a reasonably rich versioning scheme. If I then order-by-version, I would have the ordered set "V1.0," "V1.1," "V2.0". However, if I order-by-time, I have the ordered set "V1.0," V2.0," "V1.1". I believe that atom:modified is intended only to permit order-by-time. Certainly, that is all that is needed to address the vast majority of use cases for which atom:modified has been declared useful. Atom:modified is intended to allow processors to compare two non-identical instances of a single entry and determine the order in which they should be considered to have been created. Atom:modified allows us to say "This entry is considered to have been created after that entry." Atom:modified does not permit us to make any statements concerning "versions" or "variants." It is possible that some confusion is being introduced here since one may notice that if a very simple, single-line-of-descent versioning scheme is used, the time-ordered sequence of instances will be identical to a version-ordered set of instances. However, this is merely an anecdotal observation that applies to only one of many possible classes of versioning policy. There is no general correlation between temporal order and version order that applies across all versioning policies. Any correlation between temporal-order and version-order should generally be considered coincidental and not interesting. Knowledge of temporal order is extremely useful information that can be usefully exploited by Atom Processors to deliver a number of capabilities demanded by a variety of users. However, the current definition of Atom (since it doesn't support atom:modified) does not permit general temporal ordering of entries even when they are all published in a single feed. At best, the current definition only allows us to temporally order sets of entries that have the same atom:updated value. However, we have no means of determining sequence or temporal ordering of the elements of a set whose members share the same atom:updated value. This inability to order elements of such sets is a significant weakness in Atom in that it introduces ambiguity. Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values. This has nothing to do with versioning. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 18:03:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01930 for ; Sat, 21 May 2005 18:03: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 j4LLnUaf061047; Sat, 21 May 2005 14: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 j4LLnUcN061046; Sat, 21 May 2005 14:49: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LLnS8G061003 for ; Sat, 21 May 2005 14:49:29 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2729109wra for ; Sat, 21 May 2005 14:49: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=SgKp3uf5bW8fi56EKdAVuDchS8WumCPVLzJAjQKsVuhfwwaPcWDZcaj1oRfJVQmblMVZijirKrfEOuugUVLUcuILLSa704XCPQEwPOq4ZJZCcFaXBz7lJaToaRcAFtdoWHIqHV1u+ofEltcxPxhq5bmXnZ29XO7kFEh4eRyqo/0= Received: by 10.54.140.3 with SMTP id n3mr2566269wrd; Sat, 21 May 2005 14:49:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 14:49:23 -0700 (PDT) Message-ID: <68fba5c505052114491aca6207@mail.gmail.com> Date: Sat, 21 May 2005 17:49:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: Graham , atom-syntax In-Reply-To: <200505212145.DFH82867@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505210728537ac61c@mail.gmail.com> <200505212145.DFH82867@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LLnT8G061025 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > Robert Sayre wrote: > Atom should support atom:modified to permit the temporal-ordering of > members of sets that share the same atom:id and atom:updated values. This > has nothing to do with versioning. What does atom:id have to do with temporal ordering? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 18:04:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02184 for ; Sat, 21 May 2005 18:04: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 j4LLs1RM062447; Sat, 21 May 2005 14:54: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 j4LLs054062446; Sat, 21 May 2005 14:54:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LLrx6w062397 for ; Sat, 21 May 2005 14:54:00 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050521215353.QWXO20297.mta10-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Sat, 21 May 2005 22:53:53 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050521215353.EUGY2392.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sat, 21 May 2005 22:53:53 +0100 Date: Sat, 21 May 2005 22:53:50 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <8010642384.20050521225350@djpowell.net> To: Robert Sayre CC: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. In-Reply-To: <68fba5c50505211213808cf70@mail.gmail.com> References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <20050521184550.GA21525@klangraum> <68fba5c50505211213808cf70@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 Saturday, May 21, 2005, 8:13:13 PM, Robert Sayre wrote: > So, really, we have folks who want to delay this spec > because they think they've solved Distributed Versioning On The > Internet. This is a straw man argument. PaceDateModified2 was created to allow subscribers to determine the latest revision of an entry within a feed document. Please explain the specific issues that you believe will prevent PaceDateModified2 from meeting its goal. Tim gave some specific issues he had with atom:modified and I addressed them. I need something more than "there's no reason to expect it will work". If the proposal is as doomed as you suggest, then we will be able to drop this quickly and move on. Currently we seem to be just wasting time. > I remember Graham once tried to re-raise the atom:modified idea, and > was told that he was very close to being out-of-order. Well, it > certainly is now. Not only is it offensive, I proposed PaceAllowDuplicateIdsWithModified/PaceDateModified2 to fix a bug in PaceAllowDuplicateIDs, not to add a feature. PaceAllowDuplicateIDs is a major change to Atom. The fact that it was proposed after IETF Last Call suggests that we already had a process problem. The fact that issues have been raised with this proposal, but the debate has been curtailed on proposals to fix it suggests to me that we need another round to clear this up. -- Dave From owner-atom-syntax@mail.imc.org Sat May 21 18:18:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03896 for ; Sat, 21 May 2005 18:18: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 j4LM8vqD064261; Sat, 21 May 2005 15:08: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 j4LM8voD064260; Sat, 21 May 2005 15:08: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LM8ust064254 for ; Sat, 21 May 2005 15:08:56 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2734148wra for ; Sat, 21 May 2005 15:08:50 -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=jY/fPYGIE7EBRnJvQMsKtd5oxlZjj5FL+Pmc+rMyDzTu+EvxNTxwaoq4yJrG6imgZWrrXLV3y4i2lOggdf00YWcWCmCf1P/+M3yh1nuq2ai9dJL31UWyFAyJ+/RHjo6tWbGmy85OhAoYkfIRUYfwqGjlnHWVfQkpl54cXyOaXkk= Received: by 10.54.10.61 with SMTP id 61mr2475536wrj; Sat, 21 May 2005 15:08:50 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 15:08:50 -0700 (PDT) Message-ID: <68fba5c50505211508244e35f9@mail.gmail.com> Date: Sat, 21 May 2005 18:08:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: Fetch me an author. Now, fetch me another author. Cc: Atom Syntax In-Reply-To: <8010642384.20050521225350@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <20050521184550.GA21525@klangraum> <68fba5c50505211213808cf70@mail.gmail.com> <8010642384.20050521225350@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LM8ust064255 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, David Powell wrote: > > Saturday, May 21, 2005, 8:13:13 PM, Robert Sayre wrote: > > > So, really, we have folks who want to delay this spec > > because they think they've solved Distributed Versioning On The > > Internet. > > This is a straw man argument. No, it isn't. You think you'll be able to disambiguate entries by adding a more-specific date field, making for two date fields. I think you can disambiguate entries by adding any number of extension fields. That's great. Add extensions. > > PaceDateModified2 was created to allow subscribers to determine the > latest revision of an entry within a feed document. > > Please explain the specific issues that you believe will prevent > PaceDateModified2 from meeting its goal. Tim gave some specific issues > he had with atom:modified and I addressed them. I need something more > than "there's no reason to expect it will work". The WG disposed of this long ago because atom:modified cannot be operationally distinguished from atom:updated. Obviously, if people start shipping feeds with the same id and atom:updated figure, it will be needed. There's no reason to standardize it, though. We don't know how that would work. So, I can see the rationale for allowing duplicate IDs. Hey, you never know. > If the proposal is as doomed as you suggest, then we will be able to > drop this quickly and move on. Currently we seem to be just wasting > time. > > > > I remember Graham once tried to re-raise the atom:modified idea, and > > was told that he was very close to being out-of-order. Well, it > > certainly is now. Not only is it offensive, > > I proposed PaceAllowDuplicateIdsWithModified/PaceDateModified2 to fix > a bug in PaceAllowDuplicateIDs, not to add a feature. Read Bob's email. atom:modified doesn't help with revisions. Why are timestamps and atom:id related? > > PaceAllowDuplicateIDs is a major change to Atom. The fact that it was > proposed after IETF Last Call suggests that we already had a process > problem. No, WGs deal with issues raised in last call. That's completely appropriate. > The fact that issues have been raised with this proposal, but > the debate has been curtailed on proposals to fix it suggests to me > that we need another round to clear this up. No, it suggests that someone who hasn't read the previous WG discussion is proposing atom:modified Yet Again. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 18:26:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04414 for ; Sat, 21 May 2005 18:26: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 j4LMHcG7064604; Sat, 21 May 2005 15:17: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 j4LMHcuo064603; Sat, 21 May 2005 15:17:38 -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 j4LMHaY0064596 for ; Sat, 21 May 2005 15:17:37 -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); Sun, 22 May 2005 08:17:43 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 08:17:33 +1000 Subject: Re: atom:modified indicates temporal ORDER not version.... From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505052114491aca6207@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/5/05 7:49 AM, "Robert Sayre" wrote: >> Atom should support atom:modified to permit the temporal-ordering of >> members of sets that share the same atom:id and atom:updated values. This >> has nothing to do with versioning. > > What does atom:id have to do with temporal ordering? It is used to select the members of the set which is to be temporally ordered. It's not used in the ordering itself, of course. In other words - if we have a set of entries, all with the same atom:id, then atom:modified can be used to temporally order them. This is particularly pertinent to those subsets which are defined by the entries having the same atom:updated values. e. From owner-atom-syntax@mail.imc.org Sat May 21 18:33:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04751 for ; Sat, 21 May 2005 18:33: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 j4LMOBPg064844; Sat, 21 May 2005 15:24: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 j4LMOBPv064843; Sat, 21 May 2005 15:24: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 j4LMOAnu064834 for ; Sat, 21 May 2005 15:24:11 -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); Sun, 22 May 2005 08:24:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 08:24:08 +1000 Subject: Re: Fetch me an author. Now, fetch me another author. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c505052110387667acd1@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/5/05 3:38 AM, "Robert Sayre" wrote: >> The problem with the example you gave is that it suggests that even entries >> with just the one author/contributor would need two person constructs in the >> entry, or maybe just the one ... either way it's confusing. > > No, it doesn't. Why are you saying it suggests that? OK, answer me this: if an entry has only one person associated with it, do we write it with just a lone element, or do we write it with an element *and* a element? What if there was one person who wrote the text, and two people who provided suggestions or feedback or research (etc) but did not write any of the text, and the publisher wishes to acknowledge their valuable input ... one and two s, or one and three s? >> Also, more importantly, how do you then indicate which individuals listed >> as have an credit and which individuals were only >> s. > > Why are you mapping elements to types of credit? Are you seriously playing these word games for the sheer hell of it? Let me try rephrasing to something more literal: how do you then indicate which individuals listed as a could be referred to as an "author", and which individuals are "contributors" but not "author"? > There is nothing in the spec that suggests they map to types of credit. > As I said, please read the draft. bullshit. format-08 says: The "atom:author" element is a Person construct that indicates the author of the entry or feed. ^^^^^^^^^ and The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed. ^^^^^^^^^^^^^^ Now, unless you can point to the place in the spec which re-defines those two words in the English language, then we must assume they mean what they commonly mean. They *don't* mean the same thing. The *don't* mean the same thing. If they did, we wouldn't need two elements, now would we? > Seriously, 2 more months of this crap to solve a 'problem' which you > can't give an example of. I've previously given examples in a round a bout way. Let me be more explicit for you then: Publish an entry which indicates multiple people who are to be known as an "author" of the entry, and distinguish them from some number of persons who are to be known as a "contributor" to the entry (while not actually being "authors"). Their "contributions" might be background research, for example. Refer to sections 4.2.1 and 4.2.3 for the meanings of "author" and "contributor". > You might have a perfect spec, but no one will care if it is never done. I'm not looking for a perfect spec. I'm hoping for a *useful* spec, one applicable to some very real real-world use cases. Getting a feed document to validate is nice, but it's not the end goal -- we must be able to *extract* the data meaningfully. e. From owner-atom-syntax@mail.imc.org Sat May 21 18:33:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04774 for ; Sat, 21 May 2005 18:33: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 j4LMOdPT064864; Sat, 21 May 2005 15:24: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 j4LMOdZJ064863; Sat, 21 May 2005 15:24:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMOcYe064856 for ; Sat, 21 May 2005 15:24:39 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LMOYeB014251; Sat, 21 May 2005 18:24:34 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFH89943; Sat, 21 May 2005 18:24:33 -0400 (EDT) Message-Id: <200505212224.DFH89943@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , Cc: "'Graham'" , "'atom-syntax'" Subject: RE: atom:modified indicates temporal ORDER not version.... Date: Sat, 21 May 2005 18:24:30 -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: <68fba5c505052114491aca6207@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeTvdWFe/ZDF5ITfyXVRJ42txcSgAAauvQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > What does atom:id have to do with temporal ordering? Absolutely nothing. Atom:id is used to identify sets of entry instances which, according to the Atom specification, should be considered "the same entry". Sets composed of instances of "the same entry" can then be divided into subsets that share a common atom:updated value. After such a division into subsets, some of the subsets may contain multiple elements which cannot be temporally ordered given the current Atom spec draft. atom:modified provides a means to temporally order the elements of sets which contain multiple elements that share common atom:id and atom:updated values. I believe this was communicated when I wrote: "Atom should support atom:modified to permit the temporal-ordering of members of sets that share the same atom:id and atom:updated values." bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 18:37:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04909 for ; Sat, 21 May 2005 18:37: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 j4LMSg7M065207; Sat, 21 May 2005 15:28: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 j4LMSgNZ065205; Sat, 21 May 2005 15:28: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.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMSfLl065193 for ; Sat, 21 May 2005 15:28:41 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2738739wra for ; Sat, 21 May 2005 15:28:36 -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=t8RIcT7l2de+C+ZJUuna9pYjvLWXJtNb72bm9cfFXtt1IoecReXYQ1Z9WLoTQuNeY2DB7j19lrb6o9/LsEM1PlpT7nFWF1rGciNgZ86sBx4Yk3XddFWCZpGGpWbiTTsb3LIyag44VsMYckCtC1wLR4/pXWGATv5kdjeUhnYXQHg= Received: by 10.54.41.54 with SMTP id o54mr1849218wro; Sat, 21 May 2005 15:28:36 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 15:28:36 -0700 (PDT) Message-ID: <68fba5c505052115281a8981f0@mail.gmail.com> Date: Sat, 21 May 2005 18:28:36 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: Graham , atom-syntax In-Reply-To: <200505212224.DFH89943@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052114491aca6207@mail.gmail.com> <200505212224.DFH89943@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LMSfLl065200 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > Robert Sayre wrote: > > What does atom:id have to do with temporal ordering? > Absolutely nothing. > Atom:id is used to identify sets of entry instances which, according > to the Atom specification, should be considered "the same entry". Sets > composed of instances of "the same entry" can then be divided into subsets > that share a common atom:updated value. After such a division into subsets, > some of the subsets may contain multiple elements which cannot be temporally > ordered given the current Atom spec draft. atom:modified provides a means to > temporally order the elements of sets which contain multiple elements that > share common atom:id and atom:updated values. > I believe this was communicated when I wrote: > > "Atom should support atom:modified to permit the temporal-ordering of > members of sets that share the same atom:id and atom:updated values." No, that's not what you communicated. How can I temporally order atom entries with different IDs but the same atom:updated value? atom:id and atom:modified are completely unrelated. I don't know what the problem is, but the answer is atom:modified! Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 18:43:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05301 for ; Sat, 21 May 2005 18:43: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 j4LMYhAK066073; Sat, 21 May 2005 15:34: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 j4LMYhi6066072; Sat, 21 May 2005 15:34:43 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMYgoY066026; Sat, 21 May 2005 15:34:42 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.63.217]) by smtp.cegetel.net (Postfix) with ESMTP id 54B7F1A434E; Sun, 22 May 2005 00:33:58 +0200 (CEST) Message-ID: <428FB78D.9000401@cegetel.net> Date: Sun, 22 May 2005 00:34:53 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Cc: atom-protocol@imc.org Subject: Deterministic content models (conflict with Atom Publishing Protocol?) 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 I'm sorry to raise this "issue" back again but... The Atom Publishing Protocol defines SOAP bindings. This (in my mind) means there will be WSDL files over there. WSDL rely on XML Schema which in turn are limited to deterministic content models. Will the APP limit "Atom entries in SOAP envelopes" content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? I'm personally in favor of the second one, as it also simplifies Atom parser/processor development. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat May 21 18:51:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05737 for ; Sat, 21 May 2005 18:51: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 j4LMfoTm068823; Sat, 21 May 2005 15:41: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 j4LMfoA4068822; Sat, 21 May 2005 15:41: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMfnr1068761 for ; Sat, 21 May 2005 15:41:49 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2741962wra for ; Sat, 21 May 2005 15:41:44 -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=V2Z7Q0S43Cu4z81QBRHSe1bQOBTcyhWQ2cpmZy9UD98ZUsiHehekBhJt1yyfsWpVL/yHJ8VtiZ9XXpbQjjPrSr0nQGrQD55sJdL8gyiDjAClNIayF3YS4cRPX7vSUZKpOlVMQwC+SMjy8AMbS9fwPF7brDLqpVr8l0fvBEm4/uA= Received: by 10.54.35.77 with SMTP id i77mr2461254wri; Sat, 21 May 2005 15:41:44 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 15:41:44 -0700 (PDT) Message-ID: <68fba5c505052115415e3a1be8@mail.gmail.com> Date: Sat, 21 May 2005 18:41:44 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Close the Atompub WG? (was: PROCESS QUESTION: are we done yet?) 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 j4LMfnr1068809 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/20/05, Paul Hoffman wrote: > Does the WG want to be able to open up new topics, or re-open old > topics with a twist? If so, do we all agree to the delay in > publication that comes with that? Also, how long should this opening > and re-opening last? Are there any limits on which parts of the spec > we are willing to change? > > These are serious questions. No one will be surprised that Tim and I > want to follow the normal process and finish with the results of the > IETF-wide Last Call, nor that we dread the idea of the WG opening new > issues that could have been dealt with long ago and reopening issues > that were actively closed. We are here to serve the Working Group, > and if the Working Group wants a significant delay in finishing the > spec, we can (probably grumpily) ask Scott for that change to our > charter if there is rough consensus in the WG that that is what you > want. Discussion since you sent this email indicates that the people who currently think they constitute the Atompub WG don't think they need to respect any previous consensus. The people sending emails after last call are, by and large, not the same people who were posting in October (when we settled the dates issues). I suggest we seriously consider closing the WG if basic decisions cannot respected or declared out of order. Would the WG tolerate another evaluation of RDF? Everyone insists that their pet problem, no matter how divergent from current syndication usage, must be addressed. So, RDF must be allowed as well. That leads me to believe that no useful work has been accomplished in the past year. Our deadlines are passed. Why shouldn't the IETF close this WG down? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 18:57:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06030 for ; Sat, 21 May 2005 18:57: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 j4LMmFKV071010; Sat, 21 May 2005 15:48: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 j4LMmFH4071009; Sat, 21 May 2005 15:48:15 -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 j4LMmF3I070974 for ; Sat, 21 May 2005 15:48:15 -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 <2005052122480801400i9apse>; Sat, 21 May 2005 22:48:09 +0000 Date: Sat, 21 May 2005 16:48:07 -0600 Subject: Re: Fetch me an author. Now, fetch me another author. 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: <68fba5c50505211508244e35f9@mail.gmail.com> Message-Id: <6609286A-CA4A-11D9-BDA9-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 Saturday, May 21, 2005, at 04:08 PM, Robert Sayre wrote: > You think you'll be able to disambiguate entries by > adding a more-specific date field, making for two date fields. I think > you can disambiguate entries by adding any number of extension fields. > That's great. Add extensions. > +1 -- those who need this can use an extension. Those who either don't publish multiple instances of entries with the same atom:updated in the same document or don't care about the ordering among those don't have to bother with it. I'm a little uncomfortable with the idea of introducing a date/time element whose purpose is to convey a sequence rather than a timestamp. It feels like major overkill with respect to what the data really means, which makes me think it's not the right solution. Besides, I want to get Atom 1.0 finished. From owner-atom-syntax@mail.imc.org Sat May 21 18:59:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06122 for ; Sat, 21 May 2005 18:59: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 j4LMpnAq072102; Sat, 21 May 2005 15:51: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 j4LMpnrK072100; Sat, 21 May 2005 15:51:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMpkUv072075 for ; Sat, 21 May 2005 15:51:49 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LMpjeB021917; Sat, 21 May 2005 18:51:45 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFH94268; Sat, 21 May 2005 18:51:44 -0400 (EDT) Message-Id: <200505212251.DFH94268@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" Cc: "'atom-syntax'" Subject: RE: atom:modified indicates temporal ORDER not version.... Date: Sat, 21 May 2005 18:51: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: <68fba5c505052115281a8981f0@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeVHALpahOqdvpQSGStwdowLBd7wAAC5Jg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wrote: >> I believe this was communicated when I wrote: >> "Atom should support atom:modified to permit the temporal-ordering of >> members of sets that share the same atom:id and atom:updated values." Robert Sayre wrote: > No, that's not what you communicated. How can I temporally order atom > entries with different IDs but the same atom:updated value? atom:id > and atom:modified are completely unrelated. > I don't know what the problem is, but the answer is atom:modified! Robert, it is clear that your disdain for the current discussions has driven you to the point where you are no longer even reading the posts to which you respond. This is not productive. I have said *nothing* about the temporal ordering of "atom entries with different IDs". I have only written about the problem of providing temporal ordering of atom entries that "share the same atom:id and atom:updated values." I repeat (with a few added words to make it even more clear): "Atom should support atom:modified to permit the temporal-ordering of members of sets whose members share the same atom:id and atom:updated values." bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 19:07:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06412 for ; Sat, 21 May 2005 19:07: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 j4LMvqpx074038; Sat, 21 May 2005 15:57: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 j4LMvqRZ074037; Sat, 21 May 2005 15:57: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LMvpp9074001 for ; Sat, 21 May 2005 15:57:52 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2746382wra for ; Sat, 21 May 2005 15:57: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=Pk4ZFJ/iIk9DhO6zToN9Zc0urRKcsT/ynWpJMXUWqy8pNo7fHV1Tmkd0TkaUXfiYSWTyM3KPCnyj5Hhi0FmRFVWSkFWxE9RnYwJ9styEV42nZrm+0b/eVPIPozXeNklxntW0uWmEq/5Tn3xiYq1bjiiBxXnm1mx72Tu6I3ChB70= Received: by 10.54.107.4 with SMTP id f4mr2493397wrc; Sat, 21 May 2005 15:57:46 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 15:57:46 -0700 (PDT) Message-ID: <68fba5c50505211557748649aa@mail.gmail.com> Date: Sat, 21 May 2005 18:57:46 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: atom-syntax In-Reply-To: <200505212251.DFH94268@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052115281a8981f0@mail.gmail.com> <200505212251.DFH94268@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LMvqp9074029 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > I wrote: > >> I believe this was communicated when I wrote: > >> "Atom should support atom:modified to permit the temporal-ordering of > >> members of sets that share the same atom:id and atom:updated values." > > Robert Sayre wrote: > > No, that's not what you communicated. How can I temporally order atom > > entries with different IDs but the same atom:updated value? atom:id > > and atom:modified are completely unrelated. > > I don't know what the problem is, but the answer is atom:modified! > > Robert, it is clear that your disdain for the current discussions > has driven you to the point where you are no longer even reading the posts > to which you respond. This is not productive. > I have said *nothing* about the temporal ordering of "atom entries > with different IDs". I have only written about the problem of providing > temporal ordering of atom entries that "share the same atom:id and > atom:updated values." > I repeat (with a few added words to make it even more clear): > > "Atom should support atom:modified to permit the temporal-ordering of > members of sets whose members share the same atom:id and atom:updated > values." So, it's about disambiguating versions of an entry, right? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 19:10:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06505 for ; Sat, 21 May 2005 19:10: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 j4LN19Ih074747; Sat, 21 May 2005 16:01: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 j4LN19vG074746; Sat, 21 May 2005 16:01:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LN18gK074738 for ; Sat, 21 May 2005 16:01:09 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LN15Wj012814; Sat, 21 May 2005 19:01:05 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFH95658; Sat, 21 May 2005 19:01:04 -0400 (EDT) Message-Id: <200505212301.DFH95658@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'David Powell'" Cc: "'Atom Syntax'" Subject: RE: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 19:01:01 -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: <68fba5c50505211508244e35f9@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeVGoV/t4OTaWNRQq5s7las+YWcAAA4XzA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > atom:modified cannot be operationally distinguished from atom:updated. > Obviously, if people start shipping feeds with the same id and > atom:updated figure, it will be needed. There's no reason to > standardize it, though. We don't know how that would work. The definition of atom:updated was explicitly and intentionally crafted to permit the creation of multiple non-identical entries that shared common atom:id and atom:updated values. Clearly, it was the intention of the Working Group to permit this, otherwise the definition of atom:updated would not be as it is. Thus, it is ridiculous to try to suggest that "feeds with the same id and atom:updated" are somehow unanticipated or not-understood. If such feeds are so far outside the ken of what the working group intends, then atom:updated should never have been defined as it is. Additionally, atom:modified is clearly distinguished from atom:updated *by definition!* Atom:modified indicates that last time an entry was modified. Atom:updated indicates the last time it was modified in a way that the publisher considered "significant." This is a very clear distinction. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 19:18:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06872 for ; Sat, 21 May 2005 19:18: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 j4LN8sA4076154; Sat, 21 May 2005 16:08: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 j4LN8sbv076153; Sat, 21 May 2005 16:08: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.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LN8rpc076126 for ; Sat, 21 May 2005 16:08:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2749408wra for ; Sat, 21 May 2005 16:08:47 -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=lyfpIkwY64HvG1Zsd7zmA4DF4Bs/kCtvpT1he20Cr3ZdWKCZ8wDyFv6pnmfjqT3T8ksv67kIuCckvwUZzH+sgBTH/Oq78xdgxUzCsWFhz8QnQHohGJB4a5hAZ0F+kZAeQSO7KQM+a5+ZaRnJFrGAVWehM/GRT39cSwEJ7sH8kjw= Received: by 10.54.117.4 with SMTP id p4mr2500944wrc; Sat, 21 May 2005 16:08:47 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 16:08:47 -0700 (PDT) Message-ID: <68fba5c50505211608281d9c81@mail.gmail.com> Date: Sat, 21 May 2005 19:08:47 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: Fetch me an author. Now, fetch me another author. Cc: David Powell , Atom Syntax In-Reply-To: <200505212301.DFH95658@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505211508244e35f9@mail.gmail.com> <200505212301.DFH95658@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LN8rpc076141 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > The definition of atom:updated was explicitly and intentionally > crafted to permit the creation of multiple non-identical entries that shared > common atom:id and atom:updated values. Clearly, it was the intention of the > Working Group to permit this, otherwise the definition of atom:updated would > not be as it is. Thus, it is ridiculous to try to suggest that "feeds with > the same id and atom:updated" are somehow unanticipated or not-understood. > If such feeds are so far outside the ken of what the working group intends, > then atom:updated should never have been defined as it is. > Additionally, atom:modified is clearly distinguished from > atom:updated *by definition!* Atom:modified indicates that last time an > entry was modified. Atom:updated indicates the last time it was modified in > a way that the publisher considered "significant." This is a very clear > distinction. Bob, that's exactly right. The definitions are very different, and this is not an issue that arises with the allowance for multiple atom:ids in one feed document. Here's the last time this discussion happened: http://www.imc.org/atom-syntax/mail-archive/msg13276.html Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 19:42:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08073 for ; Sat, 21 May 2005 19:42: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 j4LNFxvD077649; Sat, 21 May 2005 16: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 j4LNFxUV077648; Sat, 21 May 2005 16:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LNFwmx077634 for ; Sat, 21 May 2005 16:15:59 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LNFuqp028789; Sat, 21 May 2005 19:15:56 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFH98079; Sat, 21 May 2005 19:15:55 -0400 (EDT) Message-Id: <200505212315.DFH98079@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" Cc: "'atom-syntax'" Subject: RE: atom:modified indicates temporal ORDER not version.... Date: Sat, 21 May 2005 19:15: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: <68fba5c50505211557748649aa@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeWIYb30SRPRNZSp+ISdFnIhnaCwAAOcuw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > So, it's about disambiguating versions of an entry, right? No. It has nothing to do with "versions" or even "variants." I have explained that on numerous occasions. The denial of relevance to the issue of "version" is even in the title of this thread. Read: "atom:modified indicates temporal ORDER not version..." Clearly, you either aren't reading what you're responding to or you simply don't understand what is written. Robert, it is YOU who keeps bringing "version" into this discussion -- not I. Clearly, you are not acquainted with the manner in which the word "version" is used in our industry. Only this could explain why you persist in using the word in the colloquial sense popular to those not schooled in computer science and software engineering. May I suggest that you read some basic software engineering texts that discuss how our industry understands the term "version"? Something that talks about "code management" or "configuration management" might work well for you. There are many very accessible basic introductory texts available that you might be able to understand if you apply yourself and read carefully. If you need any help in understanding what is written in the books, please feel free to send me a mail asking for help deciphering the more difficult parts... bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 19:45:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08295 for ; Sat, 21 May 2005 19:45: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 j4LNRC1v079706; Sat, 21 May 2005 16:27: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 j4LNRC4d079705; Sat, 21 May 2005 16:27: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LNRBsS079684 for ; Sat, 21 May 2005 16:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2754501wra for ; Sat, 21 May 2005 16:27: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=uhmHqAlxUXXjUDmS/QUkm+228bLVI6J18wP+VvSqcYfxiZM/EP5twke7SNhiwM6RSaMJ+B3g7gM5iLUTo1k3qhU3iuI92xuS3is1mvzEzU6+o4l+3dSRRBKt0dxCh+BCeVppbrnmgmatsGKahgUGueeHNqPpj50YjYnD1azWio4= Received: by 10.54.76.12 with SMTP id y12mr2605760wra; Sat, 21 May 2005 16:27:06 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 16:27:06 -0700 (PDT) Message-ID: <68fba5c5050521162720bea73c@mail.gmail.com> Date: Sat, 21 May 2005 19:27:06 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: atom-syntax In-Reply-To: <200505212315.DFH98079@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505211557748649aa@mail.gmail.com> <200505212315.DFH98079@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4LNRCsS079700 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > Robert Sayre wrote: > > So, it's about disambiguating versions of an entry, right? > No. It has nothing to do with "versions" or even "variants." I have > explained that on numerous occasions. The denial of relevance to the issue > of "version" is even in the title of this thread. Read: "atom:modified > indicates temporal ORDER not version..." Clearly, you either aren't reading > what you're responding to or you simply don't understand what is written Temporal order of what? They are all the same entry, so what is it you are temporally ordering? Why is this a new problem that only arises when we allow multiple IDs in the same feed? Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 20:31:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10098 for ; Sat, 21 May 2005 20:31: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 j4LNvdoC082128; Sat, 21 May 2005 16:57: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 j4LNvdKD082127; Sat, 21 May 2005 16:57:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LNvTe8082114 for ; Sat, 21 May 2005 16:57:39 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4LNvLeB009868; Sat, 21 May 2005 19:57:21 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI04745; Sat, 21 May 2005 19:57:20 -0400 (EDT) Message-Id: <200505212357.DFI04745@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , Cc: "'David Powell'" , "'Atom Syntax'" Subject: RE: Fetch me an author. Now, fetch me another author. Date: Sat, 21 May 2005 19:57:17 -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: <68fba5c50505211608281d9c81@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeWg7mNuATVx1gTV2H5IBsHjjhaAAAi59A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Here's the last time this discussion happened: > http://www.imc.org/atom-syntax/mail-archive/msg13276.html Tim's point in the referenced mail supported the current definition of atom:updated which provides a means for publishers to express their own subjective opinions of what is a "significant" change to an entry. However, the solution of one problem does not eliminate the second problem. The second problem is that readers (not publishers) need to be able to distinguish and temporally order entries that have been written by publishers. Because the publishers CANNOT know the detailed needs of all their readers, publishers' subjective input cannot be held to be useful. Objective metrics which can be clearly understood by both publishers and readers must be used. In this case, the best objective measure to use is to say that the change of one of more bits in the encoding or representation of an entry should result in a new atom:modified value. * Atom:updated addresses needs of publishers * Atom:modified addresses needs of readers Both sets of needs, that of publishers as well as readers, must be addressed and dealt with by the Atom format. Atom:updated only addresses the needs of publishers. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 20:37:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10616 for ; Sat, 21 May 2005 20:37: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 j4M05ifq082581; Sat, 21 May 2005 17:05: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 j4M05iJQ082580; Sat, 21 May 2005 17:05:44 -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 j4M05hGb082562 for ; Sat, 21 May 2005 17:05:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2763526wra for ; Sat, 21 May 2005 17:05: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=hjHbp4KjikfmdW062f6+Prii3MLr9uVGUJnrzsrSiuEoLPPICCqWRaIoGGms+PZ5/Z6KvksfZy6NZhuDulamX/KwaPnisYBLGUnAE5K8qqzYjMCgwjfy4Rn7wyhU18pUxzOWDQZjIveke14cGcCVIfWg8PV47SJDxTNLc+1D+FE= Received: by 10.54.26.68 with SMTP id 68mr1483279wrz; Sat, 21 May 2005 17:05:28 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 17:05:28 -0700 (PDT) Message-ID: <68fba5c505052117056b2098a4@mail.gmail.com> Date: Sat, 21 May 2005 20:05:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: Fetch me an author. Now, fetch me another author. Cc: David Powell , Atom Syntax In-Reply-To: <200505212357.DFI04745@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505211608281d9c81@mail.gmail.com> <200505212357.DFI04745@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4M05iGb082575 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > Objective metrics which can be clearly understood by both publishers and > readers must be used. In this case, the best objective measure to use is to > say that the change of one of more bits in the encoding or representation of > an entry should result in a new atom:modified value. > > * Atom:updated addresses needs of publishers > * Atom:modified addresses needs of readers > > Both sets of needs, that of publishers as well as readers, must be > addressed and dealt with by the Atom format. Atom:updated only addresses the > needs of publishers. The WG rejected 'objective dates' with prejudice. I'm reminded of this discussion: http://www.imc.org/atom-syntax/mail-archive/msg10954.html You know, the one where we rejected atom:modified after considering all of the same issues we're discussing now. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 20:41:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10968 for ; Sat, 21 May 2005 20: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 j4M0HiMs083294; Sat, 21 May 2005 17:17: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 j4M0Hitm083293; Sat, 21 May 2005 17:17: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 j4M0HZXP083276 for ; Sat, 21 May 2005 17:17:43 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 21966 invoked by uid 17064); 22 May 2005 00:17:33 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.99.180]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 22 May 2005 00:17:33 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <68fba5c5050521162720bea73c@mail.gmail.com> References: <68fba5c50505211557748649aa@mail.gmail.com> <200505212315.DFH98079@ms8.netsolmail.com> <68fba5c5050521162720bea73c@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5969F34F-3BB6-48ED-94B7-555086FD59DB@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: atom:modified indicates temporal ORDER not version.... Date: Sun, 22 May 2005 02:17:30 +0200 To: Robert Sayre , atom-syntax Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 May 2005, at 01:27, Robert Sayre wrote: > > On 5/21/05, Bob Wyman wrote: > >> Robert Sayre wrote: >> >>> So, it's about disambiguating versions of an entry, right? >>> >> No. It has nothing to do with "versions" or even >> "variants." I have >> explained that on numerous occasions. The denial of relevance to >> the issue >> of "version" is even in the title of this thread. Read: >> "atom:modified >> indicates temporal ORDER not version..." Clearly, you either >> aren't reading >> what you're responding to or you simply don't understand what is >> written >> > > Temporal order of what? They are all the same entry, so what is it you > are temporally ordering? You are temporally ordering states of the entry. Or if you think of the id as the resource for which the ... text is a representation, then you are ordering the representations sequentially/temporally. > Why is this a new problem that only arises > when we allow multiple IDs in the same feed? I don't think this is a problem that only arises when we allow multiple ids in the same feed. Henry > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sat May 21 20:42:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11068 for ; Sat, 21 May 2005 20:42: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 j4M0NNXJ083532; Sat, 21 May 2005 17:23: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 j4M0NNPw083531; Sat, 21 May 2005 17:23:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M0NIU7083522 for ; Sat, 21 May 2005 17:23:18 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M0NEqp016473; Sat, 21 May 2005 20:23:14 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI08727; Sat, 21 May 2005 20:23:13 -0400 (EDT) Message-Id: <200505220023.DFI08727@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" Cc: "'atom-syntax'" Subject: RE: atom:modified indicates temporal ORDER not version.... Date: Sat, 21 May 2005 20:23:10 -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: <68fba5c5050521162720bea73c@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeXJuSkJOUTrAuQK20yqO47dCtqAABE1Vw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Temporal order of what? They are all the same entry, so what is it > you are temporally ordering? We are discussing the temporal ordering of multiple non-identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of "instances." Things are often considered to be simultaneously "different" and "the same". (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... > Why is this a new problem that only arises when we allow multiple > IDs in the same feed? I have been pointing out these issues since long before the issue of "multiple IDs" (multiple instances) recently regained attention. The issue exists even without duplicate id support but is particularly critical once we support multiple instances of an entry in a single feed document. In the absence of "duplicate id" support, a reader can infer the temporal order of entries by simply noticing the order in which the entry instances were read from a feed document. (If duplicate ids are prohibited, then if you have read two entry instances which share a common atom:id, they must have been read from different instances of feeds and at different times. Thus, you can infer in some cases that the temporal ordering of the entry instances approximates the temporal ordering of the read operations which retrieved the entry instances. ) However, if you permit multiple instances of an entry in a single feed document then it is possible that you will read multiple entries whose temporal order cannot be inferred. (Note: Order of appearance in a feed does not imply any inter-entry order and thus cannot be used to infer or discover the temporal ordering of entries.) Thus, this issue *is* related to the "multiple ID" issue in that the problem is exacerbated by permitting multiple instances of a single entry in a single feed document. Whether or not it is relevant in other contexts is largely irrelevant since it appears that addressing the issue in one context will resolve it in other contexts as well. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 20:45:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11158 for ; Sat, 21 May 2005 20:44: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 j4M0RKKa083683; Sat, 21 May 2005 17:27: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 j4M0RKLn083682; Sat, 21 May 2005 17:27:20 -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 j4M0RJpo083670 for ; Sat, 21 May 2005 17:27:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2768381wra for ; Sat, 21 May 2005 17:27:05 -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=Q05BcXm5kZQPQ14H8g2kOJsFgsdiuwfdyEEQn6F3f2gOI28OpcM/b8+6Uhi8tOFg39zlmEqdGT5zJTK/jokSRnd/XrulciKis5uK4RitDERg2akD5dNwE8V1tChWKup2C/B3DJ3AMLKjHtx9ZGWMf4jlrLlnMC6RSev5InxrPMY= Received: by 10.54.140.3 with SMTP id n3mr2615069wrd; Sat, 21 May 2005 17:27:04 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 17:27:04 -0700 (PDT) Message-ID: <68fba5c505052117276887d2f9@mail.gmail.com> Date: Sat, 21 May 2005 20:27:04 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: atom-syntax In-Reply-To: <200505220023.DFI08727@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050521162720bea73c@mail.gmail.com> <200505220023.DFI08727@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4M0RKpo083677 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Bob Wyman wrote: > Robert Sayre wrote: > > Temporal order of what? They are all the same entry, so what is it > > you are temporally ordering? > We are discussing the temporal ordering of multiple non-identical > *instances* of a single Atom entry. It is common in the realm of software > engineering to deal with this concept of "instances." > > Things are often > considered to be simultaneously "different" and "the same". (I am who I am > today -- as I was when I was a child, nonetheless, I am very different today > than I was when I was a child. The instance of me today differs from the > instance of me that you might have come across many years ago.) But, perhaps > this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. Robert Sayre From owner-atom-syntax@mail.imc.org Sat May 21 20:45:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11177 for ; Sat, 21 May 2005 20:45: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 j4LJqFjm037995; Sat, 21 May 2005 12:52: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 j4LJqFCG037994; Sat, 21 May 2005 12:52: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4LJqEdl037956 for ; Sat, 21 May 2005 12:52:14 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so1856160wri for ; Sat, 21 May 2005 12:52: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=NmdbULVIXZ5NaIFIao1VPGKwjpplHu8IF1mbERjNhU8qm2llk/Fji5JdXNm8V+2EOxt9otKiIcuH3QKJvQ2nI4ICl1Q2DpWWjZoBCbfmqsU2RVKarujQs3yM1YNzvQi5ZOs82DlryH1CsFWagvFNRGMlbRGAbB4AFEJEyp+LWYk= Received: by 10.54.118.19 with SMTP id q19mr2766761wrc; Sat, 21 May 2005 12:52:08 -0700 (PDT) Received: from ?12.45.57.189? ([12.45.57.189]) by mx.gmail.com with ESMTP id 6sm960038wrl.2005.05.21.12.52.06; Sat, 21 May 2005 12:52:08 -0700 (PDT) Message-ID: <428F9162.4070602@gmail.com> Date: Sat, 21 May 2005 12:52:02 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Robert Sayre , Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <428F7FE1.7010402@cegetel.net> In-Reply-To: <428F7FE1.7010402@cegetel.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 Thomas Broyer wrote: > The Atom Syndication Fformat spec has two authors and many contributors. > Limiting to one author, you can't distinguish between the authors and > contributors. Actually, no. It has one author, a "corporation, or similar entity," the ATOMPUB Working Group, and two editors and many contributors. (Editorial nit: -08 says it's a product of the Network Working Group, apparently the xml2rfc default for ). Phil Ringnalda From owner-atom-syntax@mail.imc.org Sat May 21 20:49:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11515 for ; Sat, 21 May 2005 20: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 j4M0d50e084263; Sat, 21 May 2005 17:39: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 j4M0d59J084262; Sat, 21 May 2005 17:39:05 -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 j4M0cnWE084250 for ; Sat, 21 May 2005 17:39:04 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 26708 invoked by uid 17064); 22 May 2005 00:38:45 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.99.180]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 22 May 2005 00:38:45 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <68fba5c505052117276887d2f9@mail.gmail.com> References: <68fba5c5050521162720bea73c@mail.gmail.com> <200505220023.DFI08727@ms8.netsolmail.com> <68fba5c505052117276887d2f9@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: atom:modified indicates temporal ORDER not version.... Date: Sun, 22 May 2005 02:38:42 +0200 To: Robert Sayre , atom-syntax Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 May 2005, at 02:27, Robert Sayre wrote: > On 5/21/05, Bob Wyman wrote: >> Robert Sayre wrote: >> >>> Temporal order of what? They are all the same entry, so what is it >>> you are temporally ordering? >>> >> We are discussing the temporal ordering of multiple non- >> identical >> *instances* of a single Atom entry. It is common in the realm of >> software >> engineering to deal with this concept of "instances." >> >> Things are often >> considered to be simultaneously "different" and "the same". (I am >> who I am >> today -- as I was when I was a child, nonetheless, I am very >> different today >> than I was when I was a child. The instance of me today differs >> from the >> instance of me that you might have come across many years ago.) >> But, perhaps >> this concept is too abstract for some readers... >> > > I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Henry > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sat May 21 21:17:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12983 for ; Sat, 21 May 2005 21:17: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 j4M15xES086913; Sat, 21 May 2005 18:05: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 j4M15xZI086910; Sat, 21 May 2005 18:05:59 -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 j4M15wc6086888 for ; Sat, 21 May 2005 18:05:58 -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 j4M15w0R012727 for ; Sat, 21 May 2005 19:05:58 -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 <0IGV00FF29PX0Z@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 19:05:58 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV002LF9PVUG@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 19:05:56 -0600 (MDT) Date: Sat, 21 May 2005 18:05:59 -0700 From: Tim Bray Subject: Re: Refresher on Updated/Modified In-reply-to: <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> To: Graham Cc: atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 20, 2005, at 6:06 PM, Graham wrote: >> I don't see why, if you wanted that kind of archive, you couldn't >> use atom:updated for every little change in the archived version >> but atom:updated only for the ones you cared about in the >> published version. In which case the archived version would be a >> superset of the published version. I see nothing wrong with that. >> -Tim >> > > That's exactly my problem. You're having to hack the dates to make > it work. Would you encourage hacking in other ways? I'm not hacking at all. In this scenario, for archiving purposes I consider all changes no matter how small significant, and thus preserve them all with different values of atom:updated. For publication to the web, I have a different criterion as to what is significant. I fail to see any problem in the archive being a superset of the feed. > Say I'm aggregating feeds into a search results feed, and I get the > same entry twice (with the same atom:id and atom:updated), from > different sources. Would it be acceptable to me to adjust the > atom:updated by one second and put both in the results, to show the > end user the entry was available from two places? There may be a reason to trust one of the sources more than the other. If so, choose that. If not, apply the a policy such as discarding any entries whose ID you've seen unless the atom:updated is later than what you've seen so far. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 21:18:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13031 for ; Sat, 21 May 2005 21: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 j4M18uVE088042; Sat, 21 May 2005 18:08: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 j4M18utQ088041; Sat, 21 May 2005 18:08:56 -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 j4M18tmR088019 for ; Sat, 21 May 2005 18:08:55 -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 j4M18sjO014751 for ; Sat, 21 May 2005 19:08: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 <0IGV00FOY9UUTT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 19:08:54 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV002TZ9UTZZ@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 19:08:54 -0600 (MDT) Date: Sat, 21 May 2005 18:08:57 -0700 From: Tim Bray Subject: Re: Refresher on Updated/Modified In-reply-to: <540e373205052020267b835937@mail.gmail.com> To: "Roger B." Cc: Atom Syntax Message-id: <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 20, 2005, at 8:26 PM, Roger B. wrote: >>> change from a unicode combined char to single + combining >>> diacritic, >> >> No. >> >>> change in paragraph 27 of an article that doesn't show up in a >>> summaries-only feed, >> >> No. > > Dave: In my case, and seemingly in the case of most of the tools > surveyed, both of those would get a "yes". Existence proof, if any were needed, that the notion that there is such a thing as an "objective change" is just silly. Anybody who has worked with the deployment of more than two professional publishing systems knows full well that there is very little agreement on what constitutes a change. Attempting to specify a protocol element to capture a mythological quantity strikes me as bad design. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 22:48:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17656 for ; Sat, 21 May 2005 22:48: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 j4M2a2oo006844; Sat, 21 May 2005 19: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 j4M2a2PH006843; Sat, 21 May 2005 19:36:02 -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 j4M2a1p9006837 for ; Sat, 21 May 2005 19:36:01 -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 j4M2a1jO025224 for ; Sat, 21 May 2005 20:36:01 -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 <0IGV00FYPDW0TT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 20:36:00 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV002WSDUNZZ@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 20:36:00 -0600 (MDT) Date: Sat, 21 May 2005 19:36:05 -0700 From: Tim Bray Subject: Re: Refresher on Updated/Modified In-reply-to: <551297761.20050521020457@djpowell.net> To: David Powell Cc: Atom Syntax Message-id: <06EE4639-E612-482D-B22A-77867F168753@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <551297761.20050521020457@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Summary: David Powell fails to materially address any of the three fatal flaws I pointed out in the notion of atom:modified. I remain firmly at -1. On May 20, 2005, at 6:04 PM, David Powell wrote: >> 1. The datestamp is inserted by the provider. Thus it could be a >> lie; >> this is the Internet, remember. You, the consumer, either trust the >> publisher or you don't. If you don't, you will ignore the datestamp >> and check the content. If you do, you will believe the datestamp. >> Thus, "modified" buys you nothing. > > The rationale for PaceDateModified2 was to enable multiple revisions > of entries to exist in the same Atom Feed Document. This usage doesn't > require trust relationships to be set up. > > Cross-feed duplicate detection is a useful feature that requires a web > of trust to work reliably. Atom doesn't provide this natively, but > future companion specifications could provide a framework, just as > DomainKeys and other specifications are trying to do for SMTP. > Hopefully Atom deployments will be a bit more agile than SMTP, so this > wouldn't be such a slow process. This entirely fails to address my basic point: that if you trust the publisher's judgment as to what's significant, then atom:updated is good enough. If you don't atom:modified doesn't help. >> 2. There's endless room for argument as to what constitutes an >> update: > > The text of PaceDateModified2 is looser than most of the previous > proposals that were made, it is actually rather similar to the > mandatory atom:modified element in Atom 0.3. It is updated when > information in the entry (not the physical atom:entry element), which > is reflected in the document is changed. > > Given that definition, I think that whether atom:modified needs to be > updated can reasonably answered: I entirely disagree, based on years of experience in publishing applications, and there was disagreement with your judgment on these cases posted to the list within 3 hours. The notion that any two organizations can agree on what objectively constitutes an update is unsupported by the evidence. >> 3. Several publishers on the list asserted that they needed the right >> to make trivial spelling-correction-level changes without having a >> zillion literal-minded feed-reading clients re-fetch the material, >> and >> that they would simply refuse to update an atom:modified date if they >> didn't feel like it. >> > > Re-fetch? If they know that the atom:modified date has changed, then > they already have the entry don't they? No. Lots of entries are summary-only, not full-content. In my case, I do some of both, and in the long entries that are summary-only, I regularly make minor changes to the trailing part of long entries and decline to refresh the feed or the atom:updated date, specifically because I do not went each of the ten thousand or so newsreaders who fetch my feed to go and re-get the entry because I fixed a typo in paragraph 11. Q.E.D. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 22:48:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17676 for ; Sat, 21 May 2005 22:48: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 j4M2ZED9006801; Sat, 21 May 2005 19:35: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 j4M2ZErS006800; Sat, 21 May 2005 19:35:14 -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 j4M2ZD8w006794 for ; Sat, 21 May 2005 19:35:13 -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 j4M2ZD0R023256 for ; Sat, 21 May 2005 20:35:13 -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 <0IGV00FXODUOTT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 20:35:12 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV002WSDUNZZ@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 20:35:12 -0600 (MDT) Date: Sat, 21 May 2005 19:35:16 -0700 From: Tim Bray Subject: updated and modified yet again To: Atom Syntax Message-id: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; 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 in particular and others in general have argued eloquently for the utility of atom:modified in managing feeds and distinguishing between temporally-varying instances of the same thing. I agree with the usefulness of doing what Bob and others want to do, and that they need to disambiguate successive versions of entries based on date. I don't think this is controversial or surprising. I do not agree in the slightest that atom:modified is any more useful than atom:updated for these purposes. The only distinction between modified and updated is that there might be changes, not considered significant by the publisher, which occur between atom:updated- timestamped versions. I'll repeat that. The only difference is that there might be changes not considered significant by the publisher. So the only reason why atom:modified can ever be more useful is if you disagree with the publisher's opinion as to what is significant. If you disagree to this extent, what reason is there to believe that you will agree with the publisher as to what constitutes a change? Or that you will trust the publisher to actually insert a changed version in the feed upon a change that is not considered significant? Or that you will trust the publisher not to just lie? And if you don't trust the publisher on these things, then why would you believe atom:modified anyhow? I just don't believe that the difference between updated and published is operationally useful in the slightest. In future argument, please don't argue any more that it's important to maintain successive versions or to track temporal differences. I believe all that. Instead, please explain why you expect to disagree with publishers' opinions as to what is significant and, in the case where you disagree, you feel you would trust atom:modified. Absent such explanation, I am totally -1 on atom:modified. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 22:55:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18165 for ; Sat, 21 May 2005 22:55: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 j4M2kRQd007603; Sat, 21 May 2005 19:46: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 j4M2kR7m007602; Sat, 21 May 2005 19:46:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M2kRPu007593 for ; Sat, 21 May 2005 19:46:27 -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 (rwcrmhc13) with SMTP id <2005052202462001500fvvt0e>; Sun, 22 May 2005 02:46:20 +0000 Date: Sat, 21 May 2005 20:46:19 -0600 Subject: atom:modified (was Re: Fetch me an author. Now, fetch me another author.) 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: <200505212357.DFI04745@ms8.netsolmail.com> 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 Saturday, May 21, 2005, at 05:57 PM, Bob Wyman wrote: > The > second problem is that readers (not publishers) need to be able to > distinguish and temporally order entries that have been written by > publishers. We may not have been discussing exactly the same details before, but when atom:modified was rejected before, I think the WG was saying that either readers don't "need" to be able to do things like this this, or that the "need" wasn't great enough to warrant creation of atom:modified. We didn't all agree then, and we don't all agree now. Unless the "need" for this can be shown, and it can be shown that an extension can't take care of it, I'm -1 on atom:modified. From owner-atom-syntax@mail.imc.org Sat May 21 23:13:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19073 for ; Sat, 21 May 2005 23: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 j4M31Mgh008338; Sat, 21 May 2005 20:01: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 j4M31MX0008337; Sat, 21 May 2005 20:01:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M31Ltd008331 for ; Sat, 21 May 2005 20:01:22 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M31LWj013766; Sat, 21 May 2005 23:01:21 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI32370; Sat, 21 May 2005 23:01:20 -0400 (EDT) Message-Id: <200505220301.DFI32370@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Graham'" Cc: "'atom-syntax'" Subject: RE: Refresher on Updated/Modified Date: Sat, 21 May 2005 23:01:16 -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.2900.2180 Thread-Index: AcVebJzLSiIPm+bgQY6jFpuoQR6pVQADNT+w Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > for archiving purposes I consider all changes no matter how small > significant, and thus preserve them all with different values of > atom:updated. For publication to the web, I have a different > criterion as to what is significant. I fail to see any problem > in the archive being a superset of the feed. The problem is that such an archive would not accurately reflect what you actually published to the web. Thus, for many applications, you would also have to keep a distinct log of what you published. Using your archive you wouldn't be able to meet various legal requirements that apply to a number of businesses which require that you be able to show what you published. The problems get worse if you include signatures in your entries. Using your archiving method, the signatures on your archived entries would be different for the signatures on the entries you published. The "archive" method you describe does not produce a "superset" of what you published; it is a different set of data from that which you published. This is not necessary. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 23:21:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19481 for ; Sat, 21 May 2005 23:21: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 j4M3AHYn008889; Sat, 21 May 2005 20:10: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 j4M3AHdT008888; Sat, 21 May 2005 20:10:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M3AHDM008881 for ; Sat, 21 May 2005 20:10:17 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M3AFqt027191; Sat, 21 May 2005 23:10:15 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI33317; Sat, 21 May 2005 23:10:15 -0400 (EDT) Message-Id: <200505220310.DFI33317@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'David Powell'" Cc: "'Atom Syntax'" Subject: RE: Refresher on Updated/Modified Date: Sat, 21 May 2005 23:10: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 In-Reply-To: <06EE4639-E612-482D-B22A-77867F168753@Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeeViSRu3C8n+MTBOxB/oAoiLtWwAAWqwQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > I regularly make minor changes to the trailing part of long > entries and decline to refresh the feed or the atom:updated date, > specifically because I do not went each of the ten thousand or > so newsreaders who fetch my feed to go and re-get the entry > because I fixed a typo in paragraph 11. It seems like you are concerned that people who see a change in your feed will re-fetch the HTML? If this is your concern, then do as you do now and don't refresh the feed unless you have a change that warrants an update to atom:updated. This is totally up to you and support for atom:modified wouldn't change that. There is no requirement that your feed change whenever you modify your posts. Thus, there is nothing that stops you from pursuing this policy. You are essentially arguing that the standard should force everyone to have a blog that works in the manner that your blog works. That is not reasonable. To argue that the standard should make it possible for you to do things the way you want is quite reasonable. But, you should give to others the same consideration you apparently demand from them. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 23:21:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19510 for ; Sat, 21 May 2005 23:21: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 j4M3D0ar009817; Sat, 21 May 2005 20:13: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 j4M3D0K6009816; Sat, 21 May 2005 20:13:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M3D0Nd009790 for ; Sat, 21 May 2005 20:13:00 -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 <200505220312550140094baae>; Sun, 22 May 2005 03:12:55 +0000 Date: Sat, 21 May 2005 21:12:53 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: I wanna go home From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <63190A9C-CA6F-11D9-BDA9-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'd like to see a fair number of changes from the current draft, but there are very few changes that I want badly enough, and have enough hope of seeing approved to overshadow my desire to finish Atom 1.0 expeditiously. Here's what I'd like to see--small changes that minimally deal with problems and don't close the door to extensions to more comprehensively deal with them: Multiple authors: * Allow multiple atom:author elements per feed/entry * Keep atom:contributor * Leave "byline" or ordering of authors to an extension for those who need it Multiple instances of an entry in a feed document * Allow it * State that multiple entries originating in the same feed with the same atom:id are instances of the same entry [yes, they're SUPPOSED to be, even "REQUIRED" to be universally unique, but let's live in the real world] * Leave determination of whether entries originate in the same feed or not as an exercise for the reader (I don't see us agreeing on a method anytime in the near future) Ordering of entry instances with the same atom:updated * Leave it to an extension for those who need it Then we check the document to make sure it accurately reflects the decisions of the WG, and with that, let's ship it. Then a bunch of things I certainly don't propose we debate or decide now, but which sound like good ideas to me: we can all watch what happens as we gain real life experience; blog about our unhappiness with this or that if we so desire; keep our own individual lists of: a) things we totally missed that need to be fixed, b) things we wish had been done differently, but the WG voted down, and there are no new arguments for (and therefore should be readdressed--but it's nice to keep your own list of these to point to and say "see, the WG was wrong and I was right"), and c) things we wish had been done differently, but the WG voted down, however, there are new compelling arguments for; try to solve problems using extensions; and after a while, if any significant problems arise that really can't be solved by extensions, get the WG back together to do a revision. At that point, I'd hope that we could come up with a list of issues we'd like to have addressed, decide which to fix, and then work till those are fixed without bringing up a lot more along the way. From owner-atom-syntax@mail.imc.org Sat May 21 23:41:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20478 for ; Sat, 21 May 2005 23:41: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 j4M3K9Fx011963; Sat, 21 May 2005 20:20: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 j4M3K932011962; Sat, 21 May 2005 20:20:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M3K94l011955 for ; Sat, 21 May 2005 20:20:09 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M3K7qr029165; Sat, 21 May 2005 23:20:07 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI34502; Sat, 21 May 2005 23:20:07 -0400 (EDT) Message-Id: <200505220320.DFI34502@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: atom:modified (was Re: Fetch me an author. Now, fetch me another author.) Date: Sat, 21 May 2005 23:20:03 -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.2900.2180 Thread-Index: AcVeemfGPQggQdkfQ8mHIFsikZBZpwAAY4og Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Unless the "need" for this can be shown, and it can be shown that > an extension can't take care of it, I'm -1 on atom:modified. The need is simple and I've stated it dozens of times... Given two non-identical entries that share the same atom:id and the same atom:updated, I need to know which of them is to be presented to the user. The current specification doesn't allow me to do anything other than make a random choice. This is not reasonable. Atom:modified would provide the data needed to determine which was the most recently produced of the two entries. That most recently produced entry is the one that is most often desired by users. On extensions... Virtually anything can be done in extensions. If nothing should be in the core except those things that can be defined by extensions, then nothing would be in the core. It is inevitable that extensions will not be as broadly implemented as elements of the core. The practical implication of forcing something to be an extension is to ensure that it is never broadly implemented. bob wyman From owner-atom-syntax@mail.imc.org Sat May 21 23:42:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20520 for ; Sat, 21 May 2005 23:42: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 j4M3Uja3015481; Sat, 21 May 2005 20:30: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 j4M3UjOf015478; Sat, 21 May 2005 20:30: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 j4M3Uh5I015429 for ; Sat, 21 May 2005 20:30:43 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 May 2005 03:30:35 -0000 Received: from xdsl-213-196-249-254.netcologne.de (EHLO klangraum) [213.196.249.254] by mail.gmx.net (mp015) with SMTP; 22 May 2005 05:30:35 +0200 X-Authenticated: #163624 Date: Sun, 22 May 2005 05:33:58 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: I wanna go home Message-ID: <20050522033358.GA22911@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <63190A9C-CA6F-11D9-BDA9-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63190A9C-CA6F-11D9-BDA9-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: * Antone Roundy [2005-05-22 05:25]: > Multiple authors: > * Allow multiple atom:author elements per feed/entry > * Keep atom:contributor > * Leave "byline" or ordering of authors to an extension for > those who need it +1 > Multiple instances of an entry in a feed document > * Allow it > * State that multiple entries originating in the same feed with > the same atom:id are instances of the same entry [yes, they're > SUPPOSED to be, even "REQUIRED" to be universally unique, but > let's live in the real world] > * Leave determination of whether entries originate in the same > feed or not as an exercise for the reader (I don't see us > agreeing on a method anytime in the near future) +1, particularly on the last issue. > Ordering of entry instances with the same atom:updated > * Leave it to an extension for those who need it +1 > At that point, I'd hope that we could come up with a list of > issues we'd like to have addressed, decide which to fix, and > then work till those are fixed without bringing up a lot more > along the way. +1 Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sat May 21 23:43:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20589 for ; Sat, 21 May 2005 23:42: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 j4M3WGEh015999; Sat, 21 May 2005 20:32: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 j4M3WG88015998; Sat, 21 May 2005 20:32: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-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 j4M3WG9L015992 for ; Sat, 21 May 2005 20:32: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 j4M3WF0R020028 for ; Sat, 21 May 2005 21: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 <0IGV00F8RGHQ0Z@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 21:32:15 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV000C7GHQ8A@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 21:32:14 -0600 (MDT) Date: Sat, 21 May 2005 20:32:18 -0700 From: Tim Bray Subject: Re: Refresher on Updated/Modified In-reply-to: <200505220310.DFI33317@ms8.netsolmail.com> To: bob@wyman.us Cc: "'David Powell'" , "'Atom Syntax'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <200505220310.DFI33317@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 21, 2005, at 8:10 PM, Bob Wyman wrote: > It seems like you are concerned that people who see a change in > your > feed will re-fetch the HTML? If this is your concern, then do as > you do now > and don't refresh the feed unless you have a change that warrants > an update > to atom:updated. No. As a matter of policy, my feed contains the most recent 20 posts. However, if one of those posts is a long post and only the summary is provided, when I make a change, I make a conscious decision whether it's sufficient that I want newsreaders to re-fetch it, and if so I change the datestamp, otherwise not. > This is totally up to you and support for atom:modified > wouldn't change that. Yes, atom:modified would require that I update the date, and have the entry fetched another ten thousand times, even if I made a change that struck me as trivial. Since I'm a good citizen about specs, I would do this wasteful thing. Others would just ignore it. -Tim From owner-atom-syntax@mail.imc.org Sat May 21 23:45:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20745 for ; Sat, 21 May 2005 23:45: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 j4M3b62m017737; Sat, 21 May 2005 20:37: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 j4M3b6hN017736; Sat, 21 May 2005 20:37:06 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M3b5Fm017701 for ; Sat, 21 May 2005 20:37:06 -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 <20050522033659016004qgk6e>; Sun, 22 May 2005 03:36:59 +0000 Date: Sat, 21 May 2005 21:36:58 -0600 Subject: Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.) 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: <200505220320.DFI34502@ms8.netsolmail.com> 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 Saturday, May 21, 2005, at 09:20 PM, Bob Wyman wrote: > Antone Roundy wrote: >> Unless the "need" for this can be shown, and it can be shown that >> an extension can't take care of it, I'm -1 on atom:modified. > The need is simple and I've stated it dozens of times... ...but is it a need or a want? That was the point "need" in quotes was attempting to make. I agree it is preferred to be able to reliably pick the last one, but I disagree that it's a particularly important preference. Common practice is, and will probably continue to be, to include only one instance of a particular entry in a particular feed document. Only in the unusual cases will there be any difficulty in determining which instance came last. > On extensions... Virtually anything can be done in extensions. Many things can, but not all. An extension can't say "I'm not going to publish a title, because I have roundy:title++, which is better". atom:title is required. Also, an extension won't be able to allow multiple atom:author elements if we don't amend the spec to allow them. It will be able to define an alternative way of expressing authorship, and allow multiple of those, but a single author will continue to be required, either at the feed level or in the entry. What I meant was "particularly without duplicating the function of a core element", which just makes things sloppy. > It is inevitable that > extensions will not be as broadly implemented as elements of the core. > The > practical implication of forcing something to be an extension is to > ensure > that it is never broadly implemented. It makes it more rare, certainly, but there are extensions which are broadly implemented, and I'm sure there will be more, if the need is significant enough to enough people. From owner-atom-syntax@mail.imc.org Sun May 22 00:02:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21206 for ; Sun, 22 May 2005 00:02: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 j4M3pqEU023153; Sat, 21 May 2005 20:51: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 j4M3pqJo023150; Sat, 21 May 2005 20:51: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 (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4M3poWW023100 for ; Sat, 21 May 2005 20:51:51 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 May 2005 03:51:44 -0000 Received: from xdsl-213-196-249-254.netcologne.de (EHLO klangraum) [213.196.249.254] by mail.gmx.net (mp029) with SMTP; 22 May 2005 05:51:44 +0200 X-Authenticated: #163624 Date: Sun, 22 May 2005 05:55:15 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Fetch me an author. Now, fetch me another author. Message-ID: <20050522035515.GA23855@klangraum> Mail-Followup-To: Atom Syntax References: <2978B2EF-B594-4F8A-A2EC-F18FF154C830@mac.com> <20050521161951.GA20801@klangraum> <68fba5c505052109513598f04@mail.gmail.com> <20050521184550.GA21525@klangraum> <68fba5c50505211213808cf70@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68fba5c50505211213808cf70@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: 8bit * Robert Sayre [2005-05-21 21:25]: > On 5/21/05, A. Pagaltzis wrote: > > * Robert Sayre [2005-05-21 19:05]: > > > At this stage, changing the spec to suit religious > > > preferences would be extremely arrogant. > > > > Please stop talking to people about "process bullshit" at one > > occasion and turning around to chide others for "at this > > stage" at the next. > > As I said before, it doesn't matter if the spec is perfect if > it takes forever. […] > > Pardon me if I'm getting impatient, but I don't think any of > the ideas raised in the past few days are critical improvements > to the format. […] > > I remember Graham once tried to re-raise the atom:modified > idea, […] And all of these of these are good points, but none of this is what I’m talking about. What I’m talking about is is merely that you keep using the process argument in whichever way will most likely lead to the result you’re in favour of. It’s irritating and detracts from your factual arguments, which are consistent. That is all. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 22 00:02:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21270 for ; Sun, 22 May 2005 00:02: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 j4M3rgBa023667; Sat, 21 May 2005 20: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 j4M3rgX6023666; Sat, 21 May 2005 20:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M3rgHp023660 for ; Sat, 21 May 2005 20:53:42 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M3rfgv022820; Sat, 21 May 2005 23:53:41 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI38435; Sat, 21 May 2005 23:53:40 -0400 (EDT) Message-Id: <200505220353.DFI38435@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Atom Syntax'" Subject: RE: updated and modified yet again Date: Sat, 21 May 2005 23:53:37 -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: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeeUKFe7V6UvKOTXecD9Vx+LvLvwABAYPA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > So the only reason why atom:modified can ever be more useful is if > you disagree with the publisher's opinion as to what is significant. If this "framing" of the issue was valid, then there would be no reason to support atom:modified. However, the framing is NOT valid. It is not necessary for an Atom processor to "disagree with the publisher's opinion" in order to be interested in what atom:modified would provide. If I have two non-identical entries, each with the same atom:id and the same atom:updated, I need an algorithm that can be used to determine which of the two entry instances should be presented to a consumer who only wishes to see one entry. It would be desirable if the decision could be made in a non-random fashion. If asked, I think 99% of consumers will say that they would prefer if I present them with which ever of the two entries was "most recently" created. The problem is that Atom does not permit me to satisfy this user request. Without atom:modified, I can't determine which of the two entry instances was "most recently" created. Not being able to satisfy a consumer request is, in my business, considered a bad thing. Without atom:modified, the best I can do is tell the user: "Sometimes I'll give you the latest entry, but at other times, I'll just randomly pick one of several instances. If you object, it is simply because you are either ignorant or because you disagree with the publisher. It's not my problem..." I don't think I'll win any customer service awards with an attitude like that... > what reason is there to believe that you will agree with the publisher > as to what constitutes a change? I have no intention of disagreeing with the publisher. Atom:updated clearly identifies when the item has, in the opinion of the publisher, changed "significantly." However, by allowing multiple entry instances that share a common atom:updated value Atom explicitly provides for communicating "non-significant" changes and the WG apparently expects publishers to put entries which have been modified in non-significant ways into their feeds. Customers may be perfectly willing to accept the publisher's statements concerning the significance of changes. Nonetheless, they will still typically wish to see which ever instance was most recently published. In order to meet consumer requirements, we need to be able to determine which one of multiple instances of an entry is the "most recent." I am not looking to disagree with the publisher -- I only want to know the order in which changes, significant or not, have been made so that I can satisfy the readers' desires. > Or that you will trust the publisher to actually insert a changed > version in the feed upon a change that is not considered significant? If it ain't in the feed, who cares? The only thing that matters when discussing Atom is what's in an Atom feed or entry document. Any concerns for "trusting" that the content of an Atom feed actually reflect resources that are not defined by Atom is simply outside the scope of this Working Group. > Or that you will trust the publisher not to just lie? Publishers can lie in any element. The fact that they might lie about atom:modified is neither shocking nor relevant. > And if you don't trust the publisher on these things, then why would > you believe atom:modified anyhow? As said before, I fully intend to "trust" publishers and fully expect that if people produce entries that don't have the correct data in any element that those entries will get treated in potentially unexpected ways. I expect to conform to the specification. Others who wish to have their data processed in a predictable way should also conform. Those who don't conform -- screw 'em. bob wyman From owner-atom-syntax@mail.imc.org Sun May 22 00:10:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21834 for ; Sun, 22 May 2005 00: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 j4M0pEfj085239; Sat, 21 May 2005 17:51: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 j4M0pE43085238; Sat, 21 May 2005 17:51: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M0pDEx085228 for ; Sat, 21 May 2005 17:51:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2773560wra for ; Sat, 21 May 2005 17:51:07 -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=axjY8fsTT/aPi6mjhMaYyRd42MLOgEpWGhh6oH+qgRvBzDKNczM2/04TZiTJp+jKX1kpZreo3m7ASXGHy6HhRvLwXHaBq9UNx8weO8qOBb0brSFVCD2Ox/Z3tpWkjooeVuCCgckKZI4njToZEJjjnubBlTM409yw6pyyJd/9gBY= Received: by 10.54.37.78 with SMTP id k78mr2502167wrk; Sat, 21 May 2005 17:51:07 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 17:51:05 -0700 (PDT) Message-ID: <68fba5c5050521175149846465@mail.gmail.com> Date: Sat, 21 May 2005 20:51:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Henry Story Subject: Re: atom:modified indicates temporal ORDER not version.... Cc: atom-syntax Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c5050521162720bea73c@mail.gmail.com> <200505220023.DFI08727@ms8.netsolmail.com> <68fba5c505052117276887d2f9@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4M0pDEx085233 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/21/05, Henry Story wrote: > > On 22 May 2005, at 02:27, Robert Sayre wrote: > > On 5/21/05, Bob Wyman wrote: > >> Robert Sayre wrote: > >> > >>> Temporal order of what? They are all the same entry, so what is it > >>> you are temporally ordering? > >>> > >> We are discussing the temporal ordering of multiple non- > >> identical > >> *instances* of a single Atom entry. It is common in the realm of > >> software > >> engineering to deal with this concept of "instances." > >> > >> Things are often > >> considered to be simultaneously "different" and "the same". (I am > >> who I am > >> today -- as I was when I was a child, nonetheless, I am very > >> different today > >> than I was when I was a child. The instance of me today differs > >> from the > >> instance of me that you might have come across many years ago.) > >> But, perhaps > >> this concept is too abstract for some readers... > >> > > > > I'm unconvinced. Have a giant -1. > > How can you be unconvinced about something so fundamentally basic > to human thought? People change over time. When you clip your nails > your body is not the same as it was before, yet as far as the law is > concerned, you are the same person who went to whatever school you > went to. > Change over time exists. For something to be able to change there has to > be something that is the thing that changes. > > Really you can't get more basic than this. If you are left to argument > over this, I would suggest moving your discussion over to a philosophy > forum. Gee, Henry, maybe you should draw us a UML diagram to explain all this. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 00:24:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22428 for ; Sun, 22 May 2005 00:24: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 j4M48beS024975; Sat, 21 May 2005 21:08: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 j4M48bcp024974; Sat, 21 May 2005 21:08: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M48ano024947 for ; Sat, 21 May 2005 21:08:36 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2818193wra for ; Sat, 21 May 2005 21:08: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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pKHPTq/bepH4t0K3CqG94l4ht/8x+4jkGVfz8Y6BRPF5BMn9nRnKsl97v8DETA+5LL/OmB0NJ9gIBOmHXynPSTkH7fwvetqDJ+shZSu6Jbhk+4+HKUH9B0WUZvhbgMpLn2A0CE3DvBdz5HvZZwn1qp7yPF5b3v0oXGvVmVRK98w= Received: by 10.54.140.3 with SMTP id n3mr2678675wrd; Sat, 21 May 2005 21:08:30 -0700 (PDT) Received: from ?12.45.57.193? ([12.45.57.193]) by mx.gmail.com with ESMTP id d7sm957964wra.2005.05.21.21.08.29; Sat, 21 May 2005 21:08:30 -0700 (PDT) Message-ID: <429005B8.2010300@gmail.com> Date: Sat, 21 May 2005 21:08:24 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom Syntax'" Subject: Re: Refresher on Updated/Modified References: <200505220310.DFI33317@ms8.netsolmail.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 Tim Bray wrote: > Yes, atom:modified would require that I update the date, and have the > entry fetched another ten thousand times, even if I made a change that > struck me as trivial. Since I'm a good citizen about specs, I would do > this wasteful thing. Others would just ignore it. -Tim No, not at all. With only atom:updated, you either say "everyone must re-read this" or you don't. With both atom:updated and atom:modified, you can either say that, or you can say "only obsessives running BrayWatcher need to notice that two letters of this have changed." At least to me, that was the whole point: I am going to replace my current RCS-based "show me every trivial edit" system with an Atom-based one, while still being able to tell aggregators that they don't need to bother their users when I just fix a typo. The only question is if I do it with atom:modified, which will let me also do it for my Blogger-produced feeds, where I don't control the output, and do it so other people can use it too, or if I do it with phil:modified, and it only works for me, and only with some of the tools I use to publish. Phil Ringnalda From owner-atom-syntax@mail.imc.org Sun May 22 00:24:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22455 for ; Sun, 22 May 2005 00:24: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 j4M47Jmf024820; Sat, 21 May 2005 21:07: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 j4M47JdE024818; Sat, 21 May 2005 21:07:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M47Ial024811 for ; Sat, 21 May 2005 21:07:19 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M47Hqp008612; Sun, 22 May 2005 00:07:18 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI40109; Sun, 22 May 2005 00:07:16 -0400 (EDT) Message-Id: <200505220407.DFI40109@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: atom:modified (was Re: Fetch me an author. Now, fetch me another author.) Date: Sun, 22 May 2005 00:07:13 -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.2900.2180 Thread-Index: AcVegWDvH0GH5gYTREOdkc1cTTNKkQAAQsfA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Only in the unusual cases will there be any difficulty in determining > which instance came last. "Unusual" is a relative term... I read over 10 million feeds every day, many of them multiple times each day. I intend to read every public feed that gets created. Thus, I'll be reading at least 100 million feeds by the end of this year. I currently maintain several hundred thousand Atom feeds. That will grow to millions. Thus, I will see every one of those "unusual cases." What may be rare to the vast majority of participants in this conversation, who only maintain one or a handful of feeds, will not be "unusual" to me... Can you tell me, in those "unusual cases" when there is "difficulty in determining which instance came last," what the heck am I supposed to do if the users expect to always see the "most recent" instance? bob wyman From owner-atom-syntax@mail.imc.org Sun May 22 00:25:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22524 for ; Sun, 22 May 2005 00: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 j4M4BZcs025495; Sat, 21 May 2005 21: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 j4M4BZBt025494; Sat, 21 May 2005 21:11:35 -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 j4M4BZQm025452 for ; Sat, 21 May 2005 21:11:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2818896wra for ; Sat, 21 May 2005 21:11:29 -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=KSqY6oohtzEd3bB9t9DWOegYW9/q4+KBol8GmLGYBPckEaLEWJkUQYgjv/eQQ5871AyrwEuZvH81ugRi42d6TbU9f/x0zRWE8XoTxuiC0CoLfuDvA2lf7TGAvFZCROE6OKTuU0O2dp5EByPbst9u09hnoR2QMbfCuP0i2AEM27Q= Received: by 10.54.23.26 with SMTP id 26mr2585637wrw; Sat, 21 May 2005 21:11:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sat, 21 May 2005 21:11:29 -0700 (PDT) Message-ID: <68fba5c505052121111a20bf3d@mail.gmail.com> Date: Sun, 22 May 2005 00:11:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax@imc.org Subject: Re: I wanna go home In-Reply-To: <20050522033358.GA22911@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <63190A9C-CA6F-11D9-BDA9-003065EA6144@geckotribe.com> <20050522033358.GA22911@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4M4BZQm025489 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sounds like a good way to scope the discussion. All of this sounds reasonable. On 5/21/05, A. Pagaltzis wrote: > > * Antone Roundy [2005-05-22 05:25]: > > Multiple authors: > > * Allow multiple atom:author elements per feed/entry > > * Keep atom:contributor > > * Leave "byline" or ordering of authors to an extension for > > those who need it > > +1 > > > Multiple instances of an entry in a feed document > > * Allow it > > * State that multiple entries originating in the same feed with > > the same atom:id are instances of the same entry [yes, they're > > SUPPOSED to be, even "REQUIRED" to be universally unique, but > > let's live in the real world] > > * Leave determination of whether entries originate in the same > > feed or not as an exercise for the reader (I don't see us > > agreeing on a method anytime in the near future) > > +1, particularly on the last issue. > > > Ordering of entry instances with the same atom:updated > > * Leave it to an extension for those who need it > > +1 > > > At that point, I'd hope that we could come up with a list of > > issues we'd like to have addressed, decide which to fix, and > > then work till those are fixed without bringing up a lot more > > along the way. > > +1 > > Regards, > -- > Aristotle > > From owner-atom-syntax@mail.imc.org Sun May 22 00:32:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22908 for ; Sun, 22 May 2005 00:32: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 j4M4Ih6D025821; Sat, 21 May 2005 21:18: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 j4M4Ih4a025820; Sat, 21 May 2005 21:18:43 -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 j4M4Ifmh025811 for ; Sat, 21 May 2005 21:18:42 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 May 2005 04:18:35 -0000 Received: from xdsl-213-196-249-254.netcologne.de (EHLO klangraum) [213.196.249.254] by mail.gmx.net (mp010) with SMTP; 22 May 2005 06:18:35 +0200 X-Authenticated: #163624 Date: Sun, 22 May 2005 06:22:10 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: updated and modified yet again Message-ID: <20050522042210.GB23855@klangraum> Mail-Followup-To: Atom Syntax References: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@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: 8bit * Tim Bray [2005-05-22 04:50]: > I do not agree in the slightest that atom:modified is any more > useful than atom:updated for these purposes. The only > distinction between modified and updated is that there might be > changes, not considered significant by the publisher, which > occur between atom:updated-timestamped versions. I don’t think this is the only purpose. I can see a case mainly for archival. Another use case might be RecentChanges newsfeeds for wikis, where there generally is a concept of minor and major edits that are nonetheless all considered to have significance, just of different levels. I can certainly see these use cases to an extension element and I don’t think it would hurt much to do so. I wonder, though, if it would hurt anything to introduce an OPTIONAL atom:modified element for those cases where the publisher wants it, and that it only means something when provided? In particular, publishers would not be required to provide it and would certainly not be required to change it for “every change to an entry.” It would be nice for use cases such as wikis if clients could be relied upon to understand such an element when present. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 22 00:45:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23640 for ; Sun, 22 May 2005 00: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 j4M4TESo028205; Sat, 21 May 2005 21:29: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 j4M4TEri028204; Sat, 21 May 2005 21:29:14 -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 j4M4TDoE028197 for ; Sat, 21 May 2005 21:29:13 -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 j4M4TD0R020244 for ; Sat, 21 May 2005 22: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 <0IGV00FNUJ4O0Z@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 21 May 2005 22:29:13 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGV000DSJ4O8A@mail.sun.net> for atom-syntax@imc.org; Sat, 21 May 2005 22:29:12 -0600 (MDT) Date: Sat, 21 May 2005 21:29:16 -0700 From: Tim Bray Subject: Re: updated and modified yet again In-reply-to: <200505220353.DFI38435@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Atom Syntax'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <200505220353.DFI38435@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT New flash! Bob and I agree! On May 21, 2005, at 8:53 PM, Bob Wyman wrote: > If I have two non-identical entries, each with the same atom:id > and > the same atom:updated, I need an algorithm that can be used to > determine > which of the two entry instances should be presented to a consumer > who only > wishes to see one entry. It would be desirable if the decision > could be made > in a non-random fashion. If asked, I think 99% of consumers will > say that > they would prefer if I present them with which ever of the two > entries was > "most recently" created. The problem is that Atom does not permit > me to > satisfy this user request. Without atom:modified, I can't determine > which of > the two entry instances was "most recently" created. Bob is right. IF you find an two entries with the same atom:id and the same atom:updated AND IF you are inclined to believe that the difference will be interesting AND IF you believe that date-stamping is a useful way to resolve this issue THEN atom:modified gives you a decision procedure. However, I believe that this kind of collision is an anomalous rare case, and I believe that most times it happens they're going to be actual duplicates that are exactly the same, and I believe that if there are differences, if the publisher is to be trusted the differences are not going to be interesting, and I believe that if they are interesting, there's a chance you're looking at the potential DOS attack that Bob highlighted, which case atom:modified is not much (any?) help. Plus, atom:modified is actively harmful because it encourages people to believe (falsely) that there is consensus on what an "update" means (remember the thousands of messages we invested chewing this over because certain WG members from Norway had a violently incompatible mental image-entirely correct for their app-of what a "change" was?), and also to believe (falsely) that they don't have to worry about whether to trust a feed provider. -1 on atom:modified. My opinion on this is not weakening. -Tim From owner-atom-syntax@mail.imc.org Sun May 22 01:05:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24802 for ; Sun, 22 May 2005 01:05: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 j4M4s09n036649; Sat, 21 May 2005 21:54: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 j4M4s0EC036648; Sat, 21 May 2005 21:54:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M4rx4l036642 for ; Sat, 21 May 2005 21:53:59 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M4rvWj017806; Sun, 22 May 2005 00:53:57 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI52301; Sun, 22 May 2005 00:53:56 -0400 (EDT) Message-Id: <200505220453.DFI52301@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Cc: "'David Powell'" , "'Atom Syntax'" Subject: RE: Refresher on Updated/Modified Date: Sun, 22 May 2005 00:53: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.2900.2180 Thread-Index: AcVeft3Mxaqc8cv9Qd+b7g8ecKlmPgAB5xyg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > As a matter of policy, my feed contains the most recent 20 > posts. However, if one of those posts is a long post and only the > summary is provided, when I make a change, I make a conscious > decision whether it's sufficient that I want newsreaders to re-fetch > it, and if so I change the datestamp, otherwise not. Finally, your true motivations appear. It is now clear that you're not talking about Atom itself. Rather, you are trying to regulate the behavior of Atom Processors who will be using Atom feeds somewhat like "ping" feeds that tell them which entries to fetch. Your concerns are easily addressed by providing text in the specification that makes clear what you want. I therefore propose the following text: To the discussion of both atom:updated and atom:modified add: "[Non-Normative: In order to preserve network bandwidth and reduce the load on hosts of resources linked to Atom feeds or entries, Atom Processors which fetch the contents of alternate links are advised that they should not re-fetch such contents unless atom:updated changes.]" To the discussion of atom:modified add this normative text: "The value of atom:modified MUST only be changed when some other element (including atom:updated) of the same Atom entry has changed. Changes which are limited to resources linked to the Atom Entry MUST NOT trigger changes to atom:modified." > Since I'm a good citizen about specs, I would do this wasteful thing. If the spec were written as I have proposed above, then you -- as a "good citizen" -- would never re-fetch the alternate linked resources unless atom:updated changed. The difference here is that my comments have been solely focused on the contents of the Atom feed -- which is all that PubSub is concerned with. Nonetheless, the proposed texts should resolve your issues while allowing PubSub to do its job. bob wyman From owner-atom-syntax@mail.imc.org Sun May 22 01:16:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25482 for ; Sun, 22 May 2005 01: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 j4M54FBd041320; Sat, 21 May 2005 22:04: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 j4M54Frr041314; Sat, 21 May 2005 22:04:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M54EUX041256 for ; Sat, 21 May 2005 22:04:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4M53gm4026301; Sun, 22 May 2005 06:03:48 +0100 (BST) In-Reply-To: References: <6E690309-571D-41FD-B45A-C916287EBC94@mac.com> <1f25b3e6b35beb175d86749f8324d89d@sun.com> <22BF7866-038E-4A04-B93A-5C159A8296F6@mac.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87271839-82A9-42F4-A020-7D5F2208BFD4@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Refresher on Updated/Modified Date: Sun, 22 May 2005 06:03:41 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 May 2005, at 2:05 am, Tim Bray wrote: > I'm not hacking at all. In this scenario, for archiving purposes I > consider all changes no matter how small significant, and thus > preserve them all with different values of atom:updated. For > publication to the web, I have a different criterion as to what is > significant. I fail to see any problem in the archive being a > superset of the feed. It's not a superset, or an archive. The details of the atom:updated value that each revision was published with have been lost. >> Say I'm aggregating feeds into a search results feed, and I get >> the same entry twice (with the same atom:id and atom:updated), >> from different sources. Would it be acceptable to me to adjust the >> atom:updated by one second and put both in the results, to show >> the end user the entry was available from two places? > > There may be a reason to trust one of the sources more than the > other. If so, choose that. If not, apply the a policy such as > discarding any entries whose ID you've seen unless the atom:updated > is later than what you've seen so far. -Tim Yes, but why? Why not allow both versions to travel downstream? Graham From owner-atom-syntax@mail.imc.org Sun May 22 01:17:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25509 for ; Sun, 22 May 2005 01: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 j4M56EsL042605; Sat, 21 May 2005 22:06: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 j4M56EHM042601; Sat, 21 May 2005 22:06:14 -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 j4M56CXH042546 for ; Sat, 21 May 2005 22:06:12 -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); Sun, 22 May 2005 15:06:17 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 14:39:00 +1000 Subject: Re: Refresher on Updated/Modified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200505220310.DFI33317@ms8.netsolmail.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/5/05 1:10 PM, "Bob Wyman" wrote: > There is no requirement that your feed change whenever > you modify your posts. +1 From owner-atom-syntax@mail.imc.org Sun May 22 01:18:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25587 for ; Sun, 22 May 2005 01:18: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 j4M56EMR042604; Sat, 21 May 2005 22:06: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 j4M56DFs042600; Sat, 21 May 2005 22:06:13 -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 j4M56CtY042553 for ; Sat, 21 May 2005 22:06:12 -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); Sun, 22 May 2005 15:06:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 15:01:04 +1000 Subject: Re: I wanna go home - process questions 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 Paul/Tim, please advise: (1) if the format spec succeeds last call, will it not sit in limbo until the other specs which it relies upon also go into last call? (2) if, in wrangling the protocol spec, we realise that something is broken in the format spec, does IETF process allow us to recall the format spec or are we stuck with it and have to hack some workaround in the protocol spec? e. From owner-atom-syntax@mail.imc.org Sun May 22 02:03:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00566 for ; Sun, 22 May 2005 02:03: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 j4M5qtl5078840; Sat, 21 May 2005 22:52: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 j4M5qtaF078839; Sat, 21 May 2005 22:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M5qs9p078817 for ; Sat, 21 May 2005 22:52:54 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4M5qrqp021157 for ; Sun, 22 May 2005 01:52:54 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFI67138; Sun, 22 May 2005 01:52:53 -0400 (EDT) Message-Id: <200505220552.DFI67138@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: How is Atom superior to RSS? Date: Sun, 22 May 2005 01:52:48 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0257_01C55E70.F59296A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVeknuMF0P8KQEIQhKqFyds9AMUzg== 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_0257_01C55E70.F59296A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'll be making a presentation on Tuesday which will include a slide on how Atom improves on RSS. If you have any thoughts on this subject, I would appreciate hearing them. bob wyman ------=_NextPart_000_0257_01C55E70.F59296A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I’ll be making a presentation on Tuesday which = will include a slide on how Atom improves on RSS. If you have any thoughts on = this subject, I would appreciate hearing = them…

 

bob = wyman

 

------=_NextPart_000_0257_01C55E70.F59296A0-- From owner-atom-syntax@mail.imc.org Sun May 22 03:00:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21421 for ; Sun, 22 May 2005 03:00: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 j4M6lFEi009319; Sat, 21 May 2005 23:47: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 j4M6lFQk009316; Sat, 21 May 2005 23:47:15 -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 j4M6lDY6009235 for ; Sat, 21 May 2005 23:47:14 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 22 May 2005 06:47:07 -0000 Received: from xdsl-213-196-254-43.netcologne.de (EHLO klangraum) [213.196.254.43] by mail.gmx.net (mp019) with SMTP; 22 May 2005 08:47:07 +0200 X-Authenticated: #163624 Date: Sun, 22 May 2005 08:50:42 +0200 From: "A. Pagaltzis" To: "'Atom Syntax'" Subject: Re: How is Atom superior to RSS? Message-ID: <20050522065042.GA24614@klangraum> Mail-Followup-To: 'Atom Syntax' References: <200505220552.DFI67138@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200505220552.DFI67138@ms8.netsolmail.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: 8bit * Bob Wyman [2005-05-22 08:05]: > I'll be making a presentation on Tuesday which will include a > slide on how Atom improves on RSS. If you have any thoughts on > this subject, I would appreciate hearing them. I think the main attractions are pretty clear: • Thoroughly specified • Well-defined content model • Entry IDs • Mandatory timestamps There are also many other valuable features (I like the explicit summary vs content distinction, f.ex) which wouldn’t sell the format on their own. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 22 03:23:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22641 for ; Sun, 22 May 2005 03:23: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 j4M7Bdk3026090; Sun, 22 May 2005 00: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 j4M7Bdo9026089; Sun, 22 May 2005 00:11: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M7BccA026018 for ; Sun, 22 May 2005 00:11:39 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so2046535wri for ; Sun, 22 May 2005 00:11: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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dftWs6YwkPQOJeg73nXIWcQy37BTzSrTFV3EJTLFegx4YY2ZtBiLyIi9rPY7S/A4oxBW0GfeCzAewamn2PILRHCZThts6+NYQoJFZ/SV3whg4gTFXyEIEg3BQpyz7CCUXaBN4+PtDhfQ5w6qGCrjCWX9VHD4752DYuXQWQ7uBdw= Received: by 10.54.61.12 with SMTP id j12mr2244032wra; Sun, 22 May 2005 00:11:33 -0700 (PDT) Received: from ?192.168.1.102? ([67.181.223.222]) by mx.gmail.com with ESMTP id 7sm1038678wrl.2005.05.22.00.11.33; Sun, 22 May 2005 00:11:33 -0700 (PDT) Message-ID: <42903095.90309@gmail.com> Date: Sun, 22 May 2005 00:11:17 -0700 From: James M Snell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us, atom-syntax@imc.org Subject: Re: How is Atom superior to RSS? References: <200505220552.DFI67138@ms8.netsolmail.com> <20050522065042.GA24614@klangraum> In-Reply-To: <20050522065042.GA24614@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Off the top of my head.... * Less ambiguous * Broader solution space * Defined extensibility model * Defined encryption and digital signature support * Support for additional content types and scenarios (e.g. linked content as opposed to embedded) Will be interested in seeing the final list you come up with. A. Pagaltzis wrote: >* Bob Wyman [2005-05-22 08:05]: > > >>I'll be making a presentation on Tuesday which will include a >>slide on how Atom improves on RSS. If you have any thoughts on >>this subject, I would appreciate hearing them. >> >> > >I think the main attractions are pretty clear: > >• Thoroughly specified >• Well-defined content model >• Entry IDs >• Mandatory timestamps > >There are also many other valuable features (I like the explicit >summary vs content distinction, f.ex) which wouldn’t sell the >format on their own. > >Regards, > > From owner-atom-syntax@mail.imc.org Sun May 22 03:23:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22659 for ; Sun, 22 May 2005 03:23: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 j4M79l86024804; Sun, 22 May 2005 00:09: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 j4M79lG8024803; Sun, 22 May 2005 00:09:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M79jPh024720 for ; Sun, 22 May 2005 00:09:46 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 4198 invoked by uid 10); 22 May 2005 07:09:39 -0000 Received: (vexira-qq 04182-7E0358CF invoked from network) 22 May 2005 09:09:39 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 22 May 2005 07:09:39 -0000 Message-ID: <42903044.2090805@annevankesteren.nl> Date: Sun, 22 May 2005 09:09:56 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: 4.2.7.1 Comparing atom:id References: <428F94A2.7030206@annevankesteren.nl> <428FA47B.6040707@annevankesteren.nl> <68fba5c50505211435c90d34d@mail.gmail.com> In-Reply-To: <68fba5c50505211435c90d34d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > I think the last paragraph of RFC3987, section 5.1 already says that :) > > http://rfc.net/rfc3987.html#s5.1. That also says that fragment components should be excluded. Is that true for Atom? Are we going to refer to that specification and that section from 4.2.7.1 in a future draft? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sun May 22 05:34:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00273 for ; Sun, 22 May 2005 05:34: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 j4M9MF9J001960; Sun, 22 May 2005 02:22: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 j4M9MFJ7001959; Sun, 22 May 2005 02:22:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4M9ME2Z001910 for ; Sun, 22 May 2005 02:22:14 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 12930 invoked by uid 10); 22 May 2005 09:22:08 -0000 Received: (vexira-qq 12924-66FD5D7A invoked from network) 22 May 2005 11:22:08 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 22 May 2005 09:22:08 -0000 Message-ID: <42904F50.3020404@annevankesteren.nl> Date: Sun, 22 May 2005 11:22:24 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: some small comments on 08 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit * 2. Atom Documents # This includes such elements and attributes as specified by Atom # itself, as well as those specified by extensions to Atom. Doesn't this also apply to HTML and XHTML content when applicable? And to any type of content in atom:content? (For example, relative SVG references. XLinks, et cetera.) # Any element defined by this specification MAY have an xml:lang # attribute, whose content indicates the natural language for the # element and its children. s/children/descendents/? * 3.1.1 The "type" Attribute Are the values it can take case-sensitive or case-insensitive? * 3.1.1.1 Text # If the value is "text", the content of the Text construct MUST NOT # contain child elements. Such text is intended to be presented to # humans in a readable fashion. Thus, Atom Processors MAY collapse # white-space (including line-breaks), and display the text using # typographic techniques such as justification and proportional fonts. What happens when it does contain child elements? I think we should define that for interoperability. (See HTML for what happens when you don't.) This question also applies to the next section. For white-space significance text I need to use 'html' or 'xhtml' instead using PRE or xhtml:pre? * 3.1.1.3 XHTML I know this has been discussed before but the required DIV makes it more trivial to use type 'html' instead. I would like to see "valid XHTML" more clearly defined. There are a lot of different XHTML versions I know of and some might not include a DIV element at all... You have XHTML 1 (in three versions), XHTML 1.1, XHTML Basic, HTML5 (Web Applications 1.0). (Web Forms 2.0 extends XHTML 1...) Et cetera. * 4.1.1 The "atom:feed" Element I wonder why different phrases are chosen here. Examples: 1. atom:feed elements MUST contain exactly one atom:author element 2. atom:feed elements MUST NOT contain more than one atom:icon element. Can't we make the second: # atom:feed elements MAY contain exactly one atom:icon element. * 4.1.3.1 The "type" attribute Can I circumvent the DIV element by using the media type of XHTML? (I really dislike this combined construct by the way.) * 4.1.3.2 The "src" attribute Shouldn't it be subtype that ends in '+xml'? Also, I'm not really sure why it is useful to say that it SHOULD be local. What if I want to show a SVG graphic? Perhaps we can exclude 'image' from type? Are feed readers supposed to be able to render Atom documents within atom:content? This is theoretically possible at the moment. # If the value of "type" begins with "text/" (case-insensitive), the # content of atom:content MUST NOT contain child elements. This means basically text/xml is out? Sounds like a good idea. What happens with text/html? Are authors expected to apply the same rules as with 'html'? * 4.2.2 The "atom:category" Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example. * Links I don't understand why we have so many different link constructs. , iri, iri, . Can't we name them consistently? I'd suggest 'href' or 'url'. ('url' is used in CSS and extensions of HTML and XHTML 1 made by the WHATWG.) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sun May 22 07:30:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07506 for ; Sun, 22 May 2005 07: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 j4MBHQU2073413; Sun, 22 May 2005 04:17: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 j4MBHQwr073412; Sun, 22 May 2005 04:17:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MBHOee073341 for ; Sun, 22 May 2005 04:17:25 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4MBGI51020812; Sun, 22 May 2005 12:16:23 +0100 (BST) In-Reply-To: <68fba5c505052108233056469@mail.gmail.com> References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> <68fba5c505052108233056469@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sun, 22 May 2005 12:16:16 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21 May 2005, at 4:23 pm, Robert Sayre wrote: > What document is impossible to express with the current syntax? At this point, it's impossible to express anything, since several of us are no longer sure what the meanings of atom:author and atom:contributor are meant to be. (And no, Robert, it doesn't matter that you apparently are sure) Graham From owner-atom-syntax@mail.imc.org Sun May 22 07:44:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08254 for ; Sun, 22 May 2005 07:44: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 j4MBTvdv081221; Sun, 22 May 2005 04:29: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 j4MBTv0O081220; Sun, 22 May 2005 04:29: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MBTtPr081146 for ; Sun, 22 May 2005 04:29:56 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2930364wra for ; Sun, 22 May 2005 04:29:50 -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=aDMHRE82w/sqypXOBLYdK+okBwJVZQuqWCB4JQMpOV3Z51bJ+KkMyH3a4RIVIdqFbkorbkPUdzF/OYaG7a5A/jO+L+tEwav9x6iE8k3GILStwu7p+OHNV5qQQ6D0HhEYOW6/SLF7/w1pEdufTKYeCm4FimgWgQS2CyXPtfmH7Vo= Received: by 10.54.41.42 with SMTP id o42mr2114312wro; Sun, 22 May 2005 04:29:50 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 04:29:50 -0700 (PDT) Message-ID: <68fba5c505052204295dc786b8@mail.gmail.com> Date: Sun, 22 May 2005 07:29:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: 4.2.7.1 Comparing atom:id Cc: Atom Syntax In-Reply-To: <42903044.2090805@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428F94A2.7030206@annevankesteren.nl> <428FA47B.6040707@annevankesteren.nl> <68fba5c50505211435c90d34d@mail.gmail.com> <42903044.2090805@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MBTvPr081212 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Anne van Kesteren wrote: > Robert Sayre wrote: > > I think the last paragraph of RFC3987, section 5.1 already says that :) > > > > http://rfc.net/rfc3987.html#s5.1. > > That also says that fragment components should be excluded. Is that true > for Atom? Where does is say that? > Are we going to refer to that specification and that section > from 4.2.7.1 in a future draft? From owner-atom-syntax@mail.imc.org Sun May 22 08:20:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11063 for ; Sun, 22 May 2005 08:20: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 j4MC9hw5098842; Sun, 22 May 2005 05:09: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 j4MC9hSs098841; Sun, 22 May 2005 05:09:43 -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 j4MC9g0m098804 for ; Sun, 22 May 2005 05:09:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2939869wra for ; Sun, 22 May 2005 05:09:37 -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=S97+fqBmsqGFPX5lLMLIQ6U3TPFQtySlfxBoiKxhh8amlanjfBq7nJD8I23Of4TP7DQiM0QCqKyustwqpMKW3GXOy1reXAwlbRYGylSvJ3VYeFhhtiTLLHKqsB70yb5z6mneHl3BuljUL5zfel3QRuYEAll9RqMHc31EMXA6bRU= Received: by 10.54.41.54 with SMTP id o54mr2116748wro; Sun, 22 May 2005 05:09:37 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 05:09:37 -0700 (PDT) Message-ID: <68fba5c5050522050947359b9a@mail.gmail.com> Date: Sun, 22 May 2005 08:09:37 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Cc: atom-syntax In-Reply-To: <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> <68fba5c505052108233056469@mail.gmail.com> <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MC9h0m098834 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Graham wrote: > On 21 May 2005, at 4:23 pm, Robert Sayre wrote: > > > What document is impossible to express with the current syntax? > > At this point, it's impossible to express anything, since several of > us are no longer sure what the meanings of atom:author and > atom:contributor are meant to be. No longer sure? I suggest you never will be, since the meanings of the elements are right there in the draft, as is the cardinality. It seems reasonable to conclude you people can't read. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 08:22:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11114 for ; Sun, 22 May 2005 08: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 j4MC8A9l098339; Sun, 22 May 2005 05: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 j4MC8A3u098338; Sun, 22 May 2005 05:08:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MC88qS098294 for ; Sun, 22 May 2005 05:08:09 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050522120758.IECJ9046.mta09-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sun, 22 May 2005 13:07:58 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050522120758.LDCP29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 13:07:58 +0100 Date: Sun, 22 May 2005 13:07:56 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <92108736.20050522130756@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: updated and modified yet again In-Reply-To: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@Sun.COM> References: <284EB9B7-502D-49D0-9D99-3A6C214EFA1B@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 Sunday, May 22, 2005, 3:35:16 AM, Tim Bray wrote: > I'll repeat that. The only difference is that there might be changes > not considered significant by the publisher. > So the only reason why atom:modified can ever be more useful is if > you disagree with the publisher's opinion as to what is significant. > If you disagree to this extent, what reason is there to believe that > you will agree with the publisher as to what constitutes a change? > Or that you will trust the publisher to actually insert a changed > version in the feed upon a change that is not considered > significant? Or that you will trust the publisher not to just lie? > And if you don't trust the publisher on these things, then why would > you believe atom:modified anyhow? > I just don't believe that the difference between updated and > published is operationally useful in the slightest. > In future argument, please don't argue any more that it's important > to maintain successive versions or to track temporal differences. I > believe all that. Instead, please explain why you expect to disagree > with publishers' opinions as to what is significant and, in the case > where you disagree, you feel you would trust atom:modified. > Absent such explanation, I am totally -1 on atom:modified. -Tim Let's assume first, that you aren't deliberately putting false data in your own feed: When you post an entry to a feed it is a subjective decision whether you change the atom:updated element based on your opinion of whether the change is significant. If I want to keep an archive of your feed, then I trust that atom:updated 100% reflects your opinion on significance. But it doesn't mean that I share that opinion. I may have a more discerning criteria, so I want to represent a copy of all instances. It isn't a question of trust, in this case I trust that you have used a truthful value of atom:updated. A modified date is not subjective. When you post an entry to a feed, this communicates to the subscriber the modified date, nothing more. An archiver can use this to preserve the temporal ordering of entry instances. (Perhaps a better use case, would be to replace "I" in that explanation with "The archiving feature of your posting software or provider") On the other hand, if you are deliberately putting false data in your own feed, Atom does not attempt to deal with this situation, whether atom:modified is included or not. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 08:33:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11967 for ; Sun, 22 May 2005 08:33: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 j4MCNP2J006322; Sun, 22 May 2005 05:23: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 j4MCNPjT006321; Sun, 22 May 2005 05:23:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MCNOTN006244 for ; Sun, 22 May 2005 05:23:25 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4MCMUud001764; Sun, 22 May 2005 13:22:31 +0100 (BST) In-Reply-To: <68fba5c5050522050947359b9a@mail.gmail.com> References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> <68fba5c505052108233056469@mail.gmail.com> <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> <68fba5c5050522050947359b9a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57EEE120-4771-4B82-B2E7-1A1A6EBDD5B1@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Date: Sun, 22 May 2005 13:22:30 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 May 2005, at 1:09 pm, Robert Sayre wrote: > No longer sure? I suggest you never will be, since the meanings of the > elements are right there in the draft, as is the cardinality. It seems > reasonable to conclude you people can't read. No, we just read it a different way to what you do, the obvious way. The idea that atom:autho and atom:contributor are independent is just about a valid reading but completely counter-intuitive. There is a problem here. Graham From owner-atom-syntax@mail.imc.org Sun May 22 08:36:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12172 for ; Sun, 22 May 2005 08:36: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 j4MCLOhU005013; Sun, 22 May 2005 05:21: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 j4MCLO0h005012; Sun, 22 May 2005 05:21:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MCLNE3004947 for ; Sun, 22 May 2005 05:21:24 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050522122117.GCHO26549.mta08-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sun, 22 May 2005 13:21:17 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050522122117.MFIR29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 13:21:17 +0100 Date: Sun, 22 May 2005 13:21:16 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <9710484656.20050522132116@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@sun.com> References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@mail.gmail.com> <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@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 Sunday, May 22, 2005, 2:08:57 AM, Tim Bray wrote: >>>> change from a unicode combined char to single + combining >>>> diacritic, >>> >>> No. >>> >>>> change in paragraph 27 of an article that doesn't show up in a >>>> summaries-only feed, >>> >>> No. >> >> Dave: In my case, and seemingly in the case of most of the tools >> surveyed, both of those would get a "yes". > Existence proof, if any were needed, that the notion that there is > such a thing as an "objective change" is just silly. Anybody who has > worked with the deployment of more than two professional publishing > systems knows full well that there is very little agreement on what > constitutes a change. Attempting to specify a protocol element to > capture a mythological quantity strikes me as bad design. -Tim Did you get my response to Rogers' mail? I said that atom:modified "does not need" to be updated in these cases. However, if a publishing client has made the effort to post the changes to a server, and a server has made an effort to commit these changes to the database, then as with the case of a publisher committing a null change, it is not expected that the implementation makes a judgement call over whether there was really an update. atom:modified is much simpler than that. PaceDateModified2 deliberately doesn't prohibit this, nor does this prevent the proposal from fulfilling its goal to provide a temporal ordering for entry instances. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 08:47:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12896 for ; Sun, 22 May 2005 08:47: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 j4MCYkeN014043; Sun, 22 May 2005 05: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 j4MCYkIU014042; Sun, 22 May 2005 05:34:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4MCYiV2013991 for ; Sun, 22 May 2005 05:34:45 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000419432 for ; Sun, 22 May 2005 22:34:40 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 22 May 2005 22:23:55 +1000 Subject: Re: Fetch me an author. Now, fetch me another author. From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c5050522050947359b9a@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/5/05 10:09 PM, "Robert Sayre" wrote: >>> What document is impossible to express with the current syntax? >> >> At this point, it's impossible to express anything, since several of >> us are no longer sure what the meanings of atom:author and >> atom:contributor are meant to be. > > No longer sure? I suggest you never will be, since the meanings of the > elements are right there in the draft, as is the cardinality. It seems > reasonable to conclude you people can't read. Robert, humour us, please express the following use case in format-08 syntax... Publish an entry which indicates multiple people who are to be known as an "author" of the entry, and distinguish them from some number of persons who are to be known as a "contributor" to the entry (while not actually being "authors"). Their "contributions" might be background research, for example. Refer to sections 4.2.1 and 4.2.3 for the meanings of "author" and "contributor". e. From owner-atom-syntax@mail.imc.org Sun May 22 09:08:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14367 for ; Sun, 22 May 2005 09: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 j4MCu5Zd024079; Sun, 22 May 2005 05:56: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 j4MCu5Gv024078; Sun, 22 May 2005 05:56:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MCu4jx024030 for ; Sun, 22 May 2005 05:56:04 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 10235 invoked by uid 10); 22 May 2005 12:55:58 -0000 Received: (vexira-qq 10229-4849A756 invoked from network) 22 May 2005 14:55:57 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 22 May 2005 12:55:57 -0000 Message-ID: <4290816E.1040603@annevankesteren.nl> Date: Sun, 22 May 2005 14:56:14 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: 4.2.7.1 Comparing atom:id References: <428F94A2.7030206@annevankesteren.nl> <428FA47B.6040707@annevankesteren.nl> <68fba5c50505211435c90d34d@mail.gmail.com> <42903044.2090805@annevankesteren.nl> <68fba5c505052204295dc786b8@mail.gmail.com> In-Reply-To: <68fba5c505052204295dc786b8@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >>>I think the last paragraph of RFC3987, section 5.1 already says that :) >>> >>>http://rfc.net/rfc3987.html#s5.1. >> >>That also says that fragment components should be excluded. Is that true >>for Atom? > > Where does is say that? Sorry about that. I should read better before sending in questions. As you've probably noticed I referred to paragraph three of that section, but it talks about network retrieval. Paragraph four really applies to what we are talking about here... -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Sun May 22 09:17:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14910 for ; Sun, 22 May 2005 09:17: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 j4MD2RxU026319; Sun, 22 May 2005 06:02: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 j4MD2RKO026318; Sun, 22 May 2005 06:02:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MD2QgP026268 for ; Sun, 22 May 2005 06:02:26 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050522130220.VDXN12530.mta13-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Sun, 22 May 2005 14:02:20 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050522130220.PRHS10462.aamta02-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 14:02:20 +0100 Date: Sun, 22 May 2005 14:02:19 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <163574183.20050522140219@djpowell.net> To: Tim Bray CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <06EE4639-E612-482D-B22A-77867F168753@Sun.COM> References: <551297761.20050521020457@djpowell.net> <06EE4639-E612-482D-B22A-77867F168753@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 Sunday, May 22, 2005, 3:36:05 AM, Tim Bray wrote: > Summary: David Powell fails to materially address any of the three > fatal flaws I pointed out in the notion of atom:modified. I remain > firmly at -1. Tim, thanks for taking the time to make specific points discuss this in detail, despite your opposition to it. This is productive route to progressing the debate towards the rejection or approval of these proposals. >>> 1. The datestamp is inserted by the provider. Thus it could be a >>> lie; >>> this is the Internet, remember. You, the consumer, either trust the >>> publisher or you don't. If you don't, you will ignore the datestamp >>> and check the content. If you do, you will believe the datestamp. >>> Thus, "modified" buys you nothing. >> >> The rationale for PaceDateModified2 was to enable multiple revisions >> of entries to exist in the same Atom Feed Document. This usage doesn't >> require trust relationships to be set up. >> >> Cross-feed duplicate detection is a useful feature that requires a web >> of trust to work reliably. Atom doesn't provide this natively, but >> future companion specifications could provide a framework, just as >> DomainKeys and other specifications are trying to do for SMTP. >> Hopefully Atom deployments will be a bit more agile than SMTP, so this >> wouldn't be such a slow process. > This entirely fails to address my basic point: that if you trust the > publisher's judgment as to what's significant, then atom:updated is > good enough. If you don't atom:modified doesn't help. I've addressed this in "Re: updated and modified yet again". The value of atom:updated is specified as author's opinion. I trust that it is your opinion, but I'd like the option of forming my own. For users reading your feed, your opinion is likely to be accurate; for archivers reading your feed, it is not. It depends on the purpose on the purpose of the processor - Here is an example: Your publishing provider provides a feature which allows you to download an archive of the entries that you posted. Would you expect the archive to contain all of the instances of entries that you posted and were visible for t seconds/days/weeks/years on the Internet - or would you expect the archive to discard the instances with the same atom:updated value? My expectation of an archive, is that it would record everything that had been posted and had been live on the Internet at any point in time. >>> 2. There's endless room for argument as to what constitutes an >>> update: >> >> The text of PaceDateModified2 is looser than most of the previous >> proposals that were made, it is actually rather similar to the >> mandatory atom:modified element in Atom 0.3. It is updated when >> information in the entry (not the physical atom:entry element), which >> is reflected in the document is changed. >> >> Given that definition, I think that whether atom:modified needs to be >> updated can reasonably answered: > I entirely disagree, based on years of experience in publishing > applications, and there was disagreement with your judgment on these > cases posted to the list within 3 hours. The notion that any two > organizations can agree on what objectively constitutes an update is > unsupported by the evidence. Roger's cases? Like I said, either option would have satisfied PaceDateModified2, and either option would have satisfied its goal as a temporal ordering of entry instances. >>> 3. Several publishers on the list asserted that they needed the right >>> to make trivial spelling-correction-level changes without having a >>> zillion literal-minded feed-reading clients re-fetch the material, >>> and >>> that they would simply refuse to update an atom:modified date if they >>> didn't feel like it. >>> >> >> Re-fetch? If they know that the atom:modified date has changed, then >> they already have the entry don't they? > No. Lots of entries are summary-only, not full-content. In my case, > I do some of both, and in the long entries that are summary-only, I > regularly make minor changes to the trailing part of long entries and > decline to refresh the feed or the atom:updated date, specifically > because I do not went each of the ten thousand or so newsreaders who > fetch my feed to go and re-get the entry because I fixed a typo in > paragraph 11. Ok - sorry I didn't interpret your argument accurately. You are concerned with aggregators accessing alt links every time an atom:modified date is updated. atom:modified, I'll say it again, provides a temporal ordering of entry instances. Software that uses it to flash "THIS ENTRY HAS CHANGED" messages at users, is not serving the user well, as the atom:updated value provides a more accurate means of doing this, for this set of processors - ie humans reading a feed. Software could adopt an equally paranoid behaviour by hashing the entry contents and using changes in it to communicate that an entry has changed. Neither method would serve the user well. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 09:56:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17220 for ; Sun, 22 May 2005 09:56: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 j4MDj9be042013; Sun, 22 May 2005 06:45: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 j4MDj9V9042012; Sun, 22 May 2005 06:45:09 -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 j4MDj8cE041990 for ; Sun, 22 May 2005 06:45:09 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id D942E4F151; Sun, 22 May 2005 09:45:05 -0400 (EDT) Date: Sun, 22 May 2005 09:45:05 -0400 From: Dan Brickley To: Bob Wyman Cc: "'Atom Syntax'" Subject: Re: How is Atom superior to RSS? Message-ID: <20050522134505.GB20986@homer.w3.org> References: <200505220552.DFI67138@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505220552.DFI67138@ms8.netsolmail.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Bob Wyman [2005-05-22 01:52-0400] > I'll be making a presentation on Tuesday which will include a slide on how > Atom improves on RSS. If you have any thoughts on this subject, I would > appreciate hearing them. Which version of RSS? the RDF and non-RDF strands have pretty different characteristics... The main new interesting thing for me is the protocol aspect. Re format extensibility, Atom's a step back from RSS 1.0, but a step forward from RSS 2.0. Digital signature stuff is exciting. Dan From owner-atom-syntax@mail.imc.org Sun May 22 10:46:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22163 for ; Sun, 22 May 2005 10: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 j4MEbYbC060325; Sun, 22 May 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 j4MEbYok060324; Sun, 22 May 2005 07: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.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MEbXJG060286 for ; Sun, 22 May 2005 07:37:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2980197wra for ; Sun, 22 May 2005 07: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=Na8uX7eC1se+/KF5oo5ecT6wAIvpWTLuCPVBXbM7EScFdl5z4Mwm7TDEiAp4p8mvcZN5OY78tD1dWnzoFgUdsieuRkFKlfCRL+KvloD9eV2G2h6hKvIt5IpcVmH9GlP7y9sD8sV549O15G44+MNNMqJ97tbeUG6Tv71OPvArgzY= Received: by 10.54.23.26 with SMTP id 26mr2819145wrw; Sun, 22 May 2005 07:37:28 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 07:37:28 -0700 (PDT) Message-ID: <68fba5c50505220737d8f469d@mail.gmail.com> Date: Sun, 22 May 2005 10:37:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: Fetch me an author. Now, fetch me another author. Cc: atom-syntax In-Reply-To: <57EEE120-4771-4B82-B2E7-1A1A6EBDD5B1@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> <68fba5c505052108233056469@mail.gmail.com> <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> <68fba5c5050522050947359b9a@mail.gmail.com> <57EEE120-4771-4B82-B2E7-1A1A6EBDD5B1@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MEbYJG060319 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Graham wrote: > On 22 May 2005, at 1:09 pm, Robert Sayre wrote: > > > No longer sure? I suggest you never will be, since the meanings of the > > elements are right there in the draft, as is the cardinality. It seems > > reasonable to conclude you people can't read. > > No, we just read it a different way to what you do, the obvious way. > The idea that atom:autho and atom:contributor are independent is just > about a valid reading but completely counter-intuitive. There is a > problem here. Yes, the problem is that you think you are going to 'get it right' if you continue to work on it. I favor the path suggested by Antone in his excellent thread 'I wanna go home'.[0] I don't agree with all of the resolutions, but they're not so bad, and they could be accomplished quickly. Absurd rehashing of dates and id arguments are not going to be resolved this year. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg15526.html From owner-atom-syntax@mail.imc.org Sun May 22 10:50:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22563 for ; Sun, 22 May 2005 10:50: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 j4MEi9wY062787; Sun, 22 May 2005 07:44: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 j4MEi9aF062786; Sun, 22 May 2005 07:44:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MEi8Zw062730 for ; Sun, 22 May 2005 07:44:08 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050522144402.USLT20297.mta10-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com> for ; Sun, 22 May 2005 15:44:02 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050522144402.UISK18002.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Sun, 22 May 2005 15:44:02 +0100 Date: Sun, 22 May 2005 15:44:01 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1195279560.20050522154401@djpowell.net> To: Atom Syntax Subject: A sample use-case point-by-point 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 thought it would be useful to give a use-case for PaceAllowDuplicateIdsWithModified, so that arguments about the validity of the use-case don't get mixed up with arguments about the mechanics of the proposal. The scenario is that an Atom publishing server wishes to allow publishers to download an archive of their feed. I'll split the use-case up into separate points and then the opposition can reply to tell me which points they disagree with. (a) One of the requirements of Atom Syntax is feed archiving. (b) An archive should be capable of representing everything that as been published in the feed. (Note that some archives may only want to contain a subset of this information, but the point is that the capability should exist.) (c) To fulfil (b), an archive must be capable of representing all entry instances that have been published in the feed at some point. (d) Different entry instances may have the same atom:updated values. If you accept all of the above points, then you may have a problem with the language relating to atom:updated in PaceDuplicateIDs, but lets ignore that for the moment and discuss another requirement : (e) An archive should be able to preserve the order of multiple entry instances that have the same atom:id and atom:updated values. (f) The core of the current draft does not support (e). One way forward that has been proposed as an alternative to atom:modified is for archivers to insert an extension element to preserve the order of instances. If you support this then you believe that core Atom supports archiving, but only for a definition of archiving where the order of some entries may be lost. You admit that this may not be adequate so propose that Atom could be extended to support (e). The ex:archive-support-date element can only be added by a publishing client at the time of publishing, by an atom server at the time of receiving the entries, or by an agent that has somehow received the information necessary to insert this element via some undefined out-of-band mechanism (this third option basically equates to "by a means other than Atom"). Entries which do not fulfil these requirements can not reliably be archived. Standard Atom format documents without the ex:archive-support-date element may not be used as input to an archiver. I believe that the alternative of using an extension is inadequate due to these conditions. The conditions require tight coupling of the publishing process to the archiving process, which to me suggest that Atom is not really supporting archiving. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 11:00:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23122 for ; Sun, 22 May 2005 11:00: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 j4MEtKRA066905; Sun, 22 May 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 j4MEtKWq066904; Sun, 22 May 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 wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MEtJMg066851 for ; Sun, 22 May 2005 07:55:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2986627wra for ; Sun, 22 May 2005 07:55:14 -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=LOpMzPlzq0Onbn3yJekgVWPHApAR1RTyAaMT6CJ4iND/Vaj7nK/19FA45aX2Iv9CV5vsyHoNKMv0TNZXUoFDXMeGG5WMOgcj+7ucjpFy9mmMsbcC9R0RLPiqGHyH7z3aXkcs2oNrpHaW0FuM00XWrLLFSRpQ/Z1Zp7i+0t7onUc= Received: by 10.54.10.61 with SMTP id 61mr2824006wrj; Sun, 22 May 2005 07:55:14 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 07:55:14 -0700 (PDT) Message-ID: <68fba5c50505220755316b3a9@mail.gmail.com> Date: Sun, 22 May 2005 10:55:14 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A sample use-case point-by-point Cc: Atom Syntax In-Reply-To: <1195279560.20050522154401@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1195279560.20050522154401@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MEtJMg066883 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > > I believe that the alternative of using an extension is inadequate due > to these conditions. The conditions require tight coupling of the > publishing process to the archiving process, which to me suggest that > Atom is not really supporting archiving. It supports archiving in the sense that it could be used as a Movable Type export. Adding atom:modified will not make the Atom Syndication Format a suitable format for your goals. For example, the elements of a feed change over time as well. This includes the number of entries in a feed, author metadata, digital signatures, and the location at which one night retrieve the feed. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 12:09:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28652 for ; Sun, 22 May 2005 12:09: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 j4MFu7OG085306; Sun, 22 May 2005 08:56: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 j4MFu7lr085305; Sun, 22 May 2005 08:56: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 j4MFu6Rd085260 for ; Sun, 22 May 2005 08:56:06 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 22 May 2005 15:55:59 -0000 Received: from p508F9828.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.152.40] by mail.gmx.net (mp007) with SMTP; 22 May 2005 17:55:59 +0200 X-Authenticated: #1915285 Message-ID: <4290AB86.1030106@gmx.de> Date: Sun, 22 May 2005 17:55:50 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: I wanna go home - process questions References: In-Reply-To: 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 Eric Scheid wrote: > Paul/Tim, > > please advise: > > (1) if the format spec succeeds last call, will it not sit in limbo until > the other specs which it relies upon also go into last call? > ... Which specs are you talking about? > .. Best regards, Julian From owner-atom-syntax@mail.imc.org Sun May 22 13:31:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06099 for ; Sun, 22 May 2005 13:31: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 j4MHLkj8007594; Sun, 22 May 2005 10:21: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 j4MHLkGL007593; Sun, 22 May 2005 10:21:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MHLjwg007537 for ; Sun, 22 May 2005 10:21:46 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050522172139.EXYJ26549.mta08-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com> for ; Sun, 22 May 2005 18:21:39 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050522172139.LCOT29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Sun, 22 May 2005 18:21:39 +0100 Date: Sun, 22 May 2005 18:21:37 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <866629091.20050522182137@djpowell.net> To: Atom Syntax Subject: A different question about atom:author and inheritance 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 am concerned that the requirement: > atom:feed elements MUST contain exactly one atom:author element, > UNLESS all of the atom:feed element's child atom:entry elements > contain an atom:author element. ...suggests that some sort of inheritance goes on, but such a mechanism isn't obvious and isn't described anywhere. Draft -06 had a comment from Robert in there saying that inheritance needed explaining, but I can't see where this issue was resolved. Are these interpretations correct? They are personal opinions. Does the spec back them up? a) A The author of the feed is "A". (perhaps in some editorial capacity) The author of the entry is "A". b) A The author of the feed is undefined. The author of the entry is "A". c) B The author of the feed is undefined. The author of the entry is "B". The author of the source feed is "B". -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 13:45:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07304 for ; Sun, 22 May 2005 13:45: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 j4MHTMtf010272; Sun, 22 May 2005 10: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 j4MHTM5Q010271; Sun, 22 May 2005 10:29:22 -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 j4MHTLBR010262 for ; Sun, 22 May 2005 10:29:21 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4MHVIE9022051; Sun, 22 May 2005 13:31:18 -0400 Message-ID: <4290C16A.3090506@intertwingly.net> Date: Sun, 22 May 2005 13:29:14 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom Syntax'" Subject: Re: How is Atom superior to RSS? References: <200505220552.DFI67138@ms8.netsolmail.com> In-Reply-To: <200505220552.DFI67138@ms8.netsolmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob Wyman wrote: > Ill be making a presentation on Tuesday which will include a slide on > how Atom improves on RSS. If you have any thoughts on this subject, I > would appreciate hearing them Much of the following is still relevant: http://intertwingly.net/slides/2003/xmlconf/ I'm not certain what topic your presentation is supposed to cover, but hopefully there is room to mention the protocol. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun May 22 14:02:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08758 for ; Sun, 22 May 2005 14:02: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 j4MHro0Y019694; Sun, 22 May 2005 10:53: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 j4MHroQ1019693; Sun, 22 May 2005 10:53: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MHrnNc019649 for ; Sun, 22 May 2005 10:53:49 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3046651wra for ; Sun, 22 May 2005 10:53:43 -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=uj0n1SKqQpX6oXj591tCRMYrleCWboupebNGvdEMM8CrjrbJxS96ZiQrAGld4n4MJb0aa0Yt7DHCRrF9Vup3tCWnM0aaDWIndJeLd0gFECAMWJ5n3cYamcIcOtuSdzjkdn4Y1VQ4GDGTbq0rRr2gmBKa/w9e8nUKR2f6w6Pvy4w= Received: by 10.54.41.42 with SMTP id o42mr2297180wro; Sun, 22 May 2005 10:53:43 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 10:53:43 -0700 (PDT) Message-ID: <68fba5c50505221053120cad78@mail.gmail.com> Date: Sun, 22 May 2005 13:53:43 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <866629091.20050522182137@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MHrnNc019688 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > I am concerned that the requirement: > > > atom:feed elements MUST contain exactly one atom:author element, > > UNLESS all of the atom:feed element's child atom:entry elements > > contain an atom:author element. > > ...suggests that some sort of inheritance goes on, but such a > mechanism isn't obvious and isn't described anywhere. Draft -06 had a > comment from Robert in there saying that inheritance needed > explaining, but I can't see where this issue was resolved. The WG decided it wasn't worth specifying any more tightly. The sentence you quoted states a cardinality requirement. Inheritance was floated around, but the WG ultimately went with the language that's in the draft. It forces you to have an author element in there somewhere, but doesn't make logical assertions in the style of an RDF vocabulary. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 14:17:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10029 for ; Sun, 22 May 2005 14:17: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 j4MI4n68022726; Sun, 22 May 2005 11:04: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 j4MI4nYh022725; Sun, 22 May 2005 11:04:49 -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 j4MI4k9M022676 for ; Sun, 22 May 2005 11:04:48 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3050044wra for ; Sun, 22 May 2005 11:04:41 -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=FmS6Z/qXLxNrYJ3d5WR6u6CsDHdHglapopL85bhm/zkdwKgoBTDyogE0BkK/K8JS5SVNaVPsKkQOppyScNd0JlBdv4xrWmTbIASOEAv3QJY3EWV9e5VixwcIofpayJIHV0DrBLfpl9W84NxlCY+PyJI+ZmFxLGTrYTK1835uFII= Received: by 10.54.15.15 with SMTP id 15mr2920334wro; Sun, 22 May 2005 11:04:41 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 11:04:41 -0700 (PDT) Message-ID: <68fba5c50505221104306a662c@mail.gmail.com> Date: Sun, 22 May 2005 14:04:41 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <866629091.20050522182137@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MI4m9M022708 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > comment from Robert in there saying that inheritance needed > explaining, but I can't see where this issue was resolved. Oops. Here's the discussion: http://www.imc.org/atom-syntax/mail-archive/msg13793.html Here's what the chairs said: http://www.imc.org/atom-syntax/mail-archive/msg13784.html I suppose we could drop some more of that proposed stuff in, but I think the first bullet points of 4.1.1 and 4.1.2 cover it adequately. Besides, no one indicated they were unhappy with that text in WG last call or IETF last call. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 14:55:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14170 for ; Sun, 22 May 2005 14:55: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 j4MIlBek034009; Sun, 22 May 2005 11:47: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 j4MIlBxa034008; Sun, 22 May 2005 11:47:11 -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 j4MIlAnj033973 for ; Sun, 22 May 2005 11:47:10 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3064018wra for ; Sun, 22 May 2005 11:47:05 -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=BHJ4z+JvInuugRAgxEwkEOOeJZf2fZughKabK3rgVc/GZoww6e1dhLGu4TyxECcom5uvHWfYlsYVZ4brOGEfaYon+Vugrn2viUkd1xRb08KinrCFDVGAcI0zyfI30sYBP7qG+BVZ25JJF9rvllYE4C6ia63lq0B84h6WMsNN6yg= Received: by 10.54.41.54 with SMTP id o54mr2311601wro; Sun, 22 May 2005 11:47:05 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 11:47:05 -0700 (PDT) Message-ID: <68fba5c505052211472d755406@mail.gmail.com> Date: Sun, 22 May 2005 14:47:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: some small comments on 08 Cc: Atom Syntax In-Reply-To: <42904F50.3020404@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42904F50.3020404@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MIlAnj033999 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Anne van Kesteren wrote: > > * 2. Atom Documents > > # This includes such elements and attributes as specified by Atom > # itself, as well as those specified by extensions to Atom. > > Doesn't this also apply to HTML and XHTML content when applicable? And > to any type of content in atom:content? (For example, relative SVG > references. XLinks, et cetera.) This issue was brought up during last call (yes, during, not after :), and Tim suggested text covering the issue: http://www.imc.org/atom-syntax/mail-archive/msg14400.html The WG has never intended anything else (AFAIK), so I think its safe for the editors to make this change. > > > # Any element defined by this specification MAY have an xml:lang > # attribute, whose content indicates the natural language for the > # element and its children. > > s/children/descendents/? Someone speak up if there's a preference out there somewhere. > * 3.1.1 The "type" Attribute > > Are the values it can take case-sensitive or case-insensitive? MIME types are case insensitive. The draft specifies only lowercase values in addition to those. > * 3.1.1.1 Text > > # If the value is "text", the content of the Text construct MUST NOT > # contain child elements. Such text is intended to be presented to > # humans in a readable fashion. Thus, Atom Processors MAY collapse > # white-space (including line-breaks), and display the text using > # typographic techniques such as justification and proportional fonts. > > What happens when it does contain child elements? I think we should > define that for interoperability. (See HTML for what happens when you > don't.) This question also applies to the next section. No, that's broken. There can be no expectation of interoperability. > For white-space significance text I need to use 'html' or 'xhtml' > instead using PRE or xhtml:pre? I don't understand what you're saying here, but I'm pretty sure every possible whitespace issue has been debated by Graham, Paul, Martin, etc. Feel free to try and explain this again if I don't get it. > > * 3.1.1.3 XHTML > > I know this has been discussed before but the required DIV makes it more > trivial to use type 'html' instead. > > I would like to see "valid XHTML" more clearly defined. There are a lot > of different XHTML versions I know of and some might not include a DIV > element at all... You have XHTML 1 (in three versions), XHTML 1.1, XHTML > Basic, HTML5 (Web Applications 1.0). (Web Forms 2.0 extends XHTML 1...) > Et cetera. We reference XHTML modularization. We can't say anything about 'valid' because we don't have a DTD. I don't feel there is any value in exploring this issue at a deeper level. We could, but it's not like it would matter to implementors. Pointless legislation, if you will. > * 4.1.1 The "atom:feed" Element > > I wonder why different phrases are chosen here. Examples: > > 1. atom:feed elements MUST contain exactly one atom:author element > 2. atom:feed elements MUST NOT contain more than one atom:icon element. > > Can't we make the second: > > # atom:feed elements MAY contain exactly one atom:icon element. No. It used to be "atom:feed elements MAY contain exactly one atom:icon element, but MUST NOT contain more than one." etc, etc. > > * 4.1.3.1 The "type" attribute > > Can I circumvent the DIV element by using the media type of XHTML? (I > really dislike this combined construct by the way.) I suppose you could. Your likes and dislikes aren't relevant right now, btw. > * 4.1.3.2 The "src" attribute > > Shouldn't it be subtype that ends in '+xml'? Also, I'm not really sure > why it is useful to say that it SHOULD be local. What if I want to show > a SVG graphic? Perhaps we can exclude 'image' from type? John Cowan raised this issue in last call, the appropriate time, and the chairs agreed there was no consensus to keep the SHOULD. > Are feed readers supposed to be able to render Atom documents within > atom:content? This is theoretically possible at the moment. Great. > > # If the value of "type" begins with "text/" (case-insensitive), the > # content of atom:content MUST NOT contain child elements. > > This means basically text/xml is out? Sounds like a good idea. What > happens with text/html? Are authors expected to apply the same rules as > with 'html'? There is nothing in the spec to support that conclusion, and the spec can never define handling for every media type under the sun. > * 4.2.2 The "atom:category" Element > > Why is significant information hidden in attributes? That is bad for > i18n and prevents people from defining the expansion of an abbreviation, > for example. Minor flaw. It happens. > * Links > > I don't understand why we have so many different link constructs. > , iri, > iri, . > > Can't we name them consistently? I'd suggest 'href' or 'url'. ('url' is > used in CSS and extensions of HTML and XHTML 1 made by the WHATWG.) Nope. Too late. bye, Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 15:02:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14838 for ; Sun, 22 May 2005 15:02: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 j4MItXPL036853; Sun, 22 May 2005 11:55: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 j4MItXSg036852; Sun, 22 May 2005 11:55:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MItV7m036806 for ; Sun, 22 May 2005 11:55:32 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050522185525.ZCLR9046.mta09-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Sun, 22 May 2005 19:55:25 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050522185525.UKYA2392.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 19:55:25 +0100 Date: Sun, 22 May 2005 19:55:24 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <326935594.20050522195524@djpowell.net> To: Anne van Kesteren CC: Atom Syntax Subject: Re: some small comments on 08 In-Reply-To: <42904F50.3020404@annevankesteren.nl> References: <42904F50.3020404@annevankesteren.nl> 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, May 22, 2005, 10:22:24 AM, you wrote: > * 4.1.3.1 The "type" attribute > Can I circumvent the DIV element by using the media type of XHTML? (I > really dislike this combined construct by the way.) You can, but you would have to embed a full XHTML document, including and elements. Also I'd suspect that the document might not get treated as well by implementations and stuck in an IFRAME or something. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 15:10:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15944 for ; Sun, 22 May 2005 15:10: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 j4MJ3YeX038753; Sun, 22 May 2005 12:03: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 j4MJ3Y8f038752; Sun, 22 May 2005 12:03:34 -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 j4MJ3WLK038745 for ; Sun, 22 May 2005 12:03:33 -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 j4MJ3WjO026277 for ; Sun, 22 May 2005 13:03:32 -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 <0IGW00GFANLW0X@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 22 May 2005 13:03:32 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGW002PRNLVZZ@mail.sun.net> for atom-syntax@imc.org; Sun, 22 May 2005 13:03:32 -0600 (MDT) Date: Sun, 22 May 2005 12:03:36 -0700 From: Tim Bray Subject: Re: some small comments on 08 In-reply-to: <68fba5c505052211472d755406@mail.gmail.com> To: Robert Sayre Cc: Anne van Kesteren , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 22, 2005, at 11:47 AM, Robert Sayre wrote: >> # Any element defined by this specification MAY have an xml:lang >> # attribute, whose content indicates the natural language for the >> # element and its children. >> >> s/children/descendents/? > > Someone speak up if there's a preference out there somewhere. "descendents" is more accurate. --Tim From owner-atom-syntax@mail.imc.org Sun May 22 15:28:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18051 for ; Sun, 22 May 2005 15:28: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 j4MJLhaU042579; Sun, 22 May 2005 12:21: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 j4MJLh0d042575; Sun, 22 May 2005 12:21:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MJLgic042565 for ; Sun, 22 May 2005 12:21:42 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4MJLbgt021859; Sun, 22 May 2005 15:21:41 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFL26992; Sun, 22 May 2005 15:21:36 -0400 (EDT) Message-Id: <200505221921.DFL26992@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" Cc: "'Atom Syntax'" Subject: RE: How is Atom superior to RSS? Date: Sun, 22 May 2005 15:21: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: <4290C16A.3090506@intertwingly.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVe89Cd16Ymn4ABRtq3u791EDOWkgACJUEg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This has been an experiment... I've got lots of thoughts on why Atom is an improvement over RSS but I am constantly amazed that people are able to continue making the claim that Atom offers little that RSS doesn't already support. Certainly, Winer and the Microsoft crowd make that claim regularly. I've often wondered why people don't see the really important differences between these two. To a certain extent, the answer comes in the replies I've received to my posting. i.e. Not even those most familiar with Atom can present a decent list of clear advantages -- even though they undoubtedly know them. Yes, we all know the advantages of requiring unique atom:id values, writing less ambiguous documentation, etc. However, I wonder why advances like the following don't get more recognition (note: this is not a complete list.) 1. Explicit support for xml:lang rather than the silly tag of RSS V2.0. 2. Explicit support, in the core, for digital signatures and encryption. 3. Atom Entry documents. Thus, support for the protocol as well as for push delivery of Atom feeds via Atom over XMPP and other such protocols. (i.e. Atom is designed to enable a push future rather than only working in the legacy pull-only world of RSS) 4. Atom:source elements which provide robust support, in the core, for attribution on entries that have been copied from one feed to another and for preservation of important feed metadata in copied entries. Atom's source element makes it a superior format for delivering search results, for constructing feeds which aggregate entries from multiple sources, and for push applications. 5. Support for XML content types rather than being limited to RSS's HTML content type. 6. Explicit support for "remote content". We all worked hard in getting these new capabilities and others like them into Atom and properly defined. Why aren't these things given more "press" and attention? They are significant improvements over RSS that will have profound impact on our ability to build better applications for our users. bob wyman From owner-atom-syntax@mail.imc.org Sun May 22 16:33:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23422 for ; Sun, 22 May 2005 16:33: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 j4MK1ukP047453; Sun, 22 May 2005 13: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 j4MK1uff047451; Sun, 22 May 2005 13:01:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MK1p34047437 for ; Sun, 22 May 2005 13:01:54 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050522200145.HRRM26549.mta08-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Sun, 22 May 2005 21:01:45 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050522200145.XUJR18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 21:01:45 +0100 Date: Sun, 22 May 2005 21:01:43 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1857314093.20050522210143@djpowell.net> To: Robert Sayre CC: Atom Syntax Subject: Re: A different question about atom:author and inheritance In-Reply-To: <68fba5c50505221104306a662c@mail.gmail.com> References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@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 Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote: > Besides, no one indicated they were unhappy with that text in WG last > call or IETF last call. Sorry, I was too busy reviewing the 23 additional Paces that were proposed during IETF Last-Call to have time to sufficiently review the specification itself. We may of thought that we were finished, but it is clear that we were not ready for Last-Call: neither the Working Group, nor the IETF had sufficient time to review the specification because it has been in flux with proposals. Major changes such as PaceDuplicateIDs have been added and nobody has seen the draft yet, let alone reviewed it. The fact that both myself and the editor were confused about whether a contentious paragraph had been accepted by the chairs, demonstrates this problem. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 16:33:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23453 for ; Sun, 22 May 2005 16:33: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 j4MK1ucZ047452; Sun, 22 May 2005 13: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 j4MK1tiT047450; Sun, 22 May 2005 13:01:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MK1pWC047436 for ; Sun, 22 May 2005 13:01:54 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050522200139.HRHD26549.mta08-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Sun, 22 May 2005 21:01:39 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050522200139.XUDG18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 21:01:39 +0100 Date: Sun, 22 May 2005 21:01:37 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1695295412.20050522210137@djpowell.net> To: Robert Sayre CC: David Powell , Atom Syntax Subject: Re: A different question about atom:author and inheritance In-Reply-To: <68fba5c50505221104306a662c@mail.gmail.com> References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@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 Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote: > On 5/22/05, David Powell wrote: >> comment from Robert in there saying that inheritance needed >> explaining, but I can't see where this issue was resolved. > Oops. Here's the discussion: > http://www.imc.org/atom-syntax/mail-archive/msg13793.html > Here's what the chairs said: > http://www.imc.org/atom-syntax/mail-archive/msg13784.html > I suppose we could drop some more of that proposed stuff in, but I > think the first bullet points of 4.1.1 and 4.1.2 cover it adequately. Ok - it looks like my interpretations were wrong. The spec doesn't condone any kind of inheritance of atom:author from feeds to entries. The requirement that either the feed or all entries contain atom:author misled me. So would these interpretations be correct: a) A The author of the feed is "A". The author of the entry is undefined. b) A The author of the feed is undefined. The author of the entry is "A". c) B The author of the feed is undefined. The author of the entry is undefined. The author of the source feed is "B". I think that the current text is very misleading. The fact that at one point inheritance has been condoned or suggested by previous drafts (including the widely implemented pre-IETF public draft), but now we have removed the suggestion, but kept the syntactic requirement certainly got me. The fact that the draft conflates the author (editor?) of the feed with the author of the entries increases the confusion. We should add language that specifically states that the value of atom:feed/atom:author is not a shortcut for specifying atom:entry/atom:author - if that is what we mean. (Hopefully, the WG agree that this is the intended meaning of the author element? It would be a hugely embarrassing to define a simple element in a completely ambiguous way, when RSS2.0 is crystal clear on the matter.) -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 17:14:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26154 for ; Sun, 22 May 2005 17:14: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 j4ML5O0H059748; Sun, 22 May 2005 14:05: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 j4ML5Oml059747; Sun, 22 May 2005 14:05:24 -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 j4ML5NAD059695 for ; Sun, 22 May 2005 14:05:23 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3108027wra for ; Sun, 22 May 2005 14:05:18 -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=iLhHDw2ePVU0hXK5PgBF2MvsY39MhCwbwgA8erC2N6/oImaPQEZXRN6WavnJyp54Tl2Qt6H7UBVic+bT46ggvIhMU8vS03I+B7jOE/Rj0tyxY2pfG8LHBE72HljO8IGj9KaMS+zgeO4VJ93+e5sNk+ud1BseiBC6TJl5dLlOJY4= Received: by 10.54.76.12 with SMTP id y12mr3110616wra; Sun, 22 May 2005 14:05:17 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 14:05:17 -0700 (PDT) Message-ID: <68fba5c505052214053498cf6e@mail.gmail.com> Date: Sun, 22 May 2005 17:05:17 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <1857314093.20050522210143@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1857314093.20050522210143@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ML5NAD059734 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > We may of thought that we were finished, but it is clear that we were > not ready for Last-Call: neither the Working Group, nor the IETF had > sufficient time to review the specification because it has been in > flux with proposals. You know, thinking more about this one, it makes me more irritated than I already am. If it's less flux you desire, there's a very easy way to make that happen. The chairs could simply declare paces which revisit issues the group has already decided to be out of order. The fact that they've tolerated yet more discussion on things like atom:modified and archiving, which brought exactly zero bits of new information to the discussion, speaks volumes about their patience. I take a less diplomatic view of the past few days... Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 17:31:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27452 for ; Sun, 22 May 2005 17:31: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 j4MLNOAr065850; Sun, 22 May 2005 14:23: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 j4MLNOoM065849; Sun, 22 May 2005 14:23:24 -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 j4MLNNbc065825 for ; Sun, 22 May 2005 14:23:24 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (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 j4MLPPuB012347; Sun, 22 May 2005 17:25:25 -0400 Message-ID: <4290F848.60407@intertwingly.net> Date: Sun, 22 May 2005 17:23:20 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Atom Syntax'" Subject: Re: How is Atom superior to RSS? References: <200505221921.DFL26992@ms8.netsolmail.com> In-Reply-To: <200505221921.DFL26992@ms8.netsolmail.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: > This has been an experiment... > I've got lots of thoughts on why Atom is an improvement over RSS but > I am constantly amazed that people are able to continue making the claim > that Atom offers little that RSS doesn't already support. Certainly, Winer > and the Microsoft crowd make that claim regularly. I've often wondered why > people don't see the really important differences between these two. To a > certain extent, the answer comes in the replies I've received to my posting. > i.e. Not even those most familiar with Atom can present a decent list of > clear advantages -- even though they undoubtedly know them. > > Yes, we all know the advantages of requiring unique atom:id values, > writing less ambiguous documentation, etc. However, I wonder why advances > like the following don't get more recognition (note: this is not a complete > list.) > 1. Explicit support for xml:lang rather than the silly > tag of RSS V2.0. While your effort to create a concise list is very much appreciated, I would recommend avoiding terms like "silly". > 2. Explicit support, in the core, for digital signatures and > encryption. > 3. Atom Entry documents. Thus, support for the protocol as well as > for push delivery of Atom feeds via Atom over XMPP and other such protocols. > (i.e. Atom is designed to enable a push future rather than only working in > the legacy pull-only world of RSS) > 4. Atom:source elements which provide robust support, in the core, > for attribution on entries that have been copied from one feed to another > and for preservation of important feed metadata in copied entries. Atom's > source element makes it a superior format for delivering search results, for > constructing feeds which aggregate entries from multiple sources, and for > push applications. > 5. Support for XML content types rather than being limited to RSS's > HTML content type. It isn't even clear what RSS's content type is. Particularly for title. Even for RSS 1.0. > 6. Explicit support for "remote content". > > We all worked hard in getting these new capabilities and others like > them into Atom and properly defined. Why aren't these things given more > "press" and attention? They are significant improvements over RSS that will > have profound impact on our ability to build better applications for our > users. Add atom:updated solves exactly this problem: http://www.25hoursaday.com/weblog/CommentView.aspx?guid=4c8d83e9-bc7e-432d-b5b2-07965bd959ad Add multiple "enclosures". http://weblog.burningbird.net/archives/2005/05/03/feeds-fixes/ Add relative URIs: http://intertwingly.net/slides/2003/xmlconf/34.html Add clear distinction between summary and content: http://www.imc.org/atom-syntax/mail-archive/msg15208.html http://www.imc.org/atom-syntax/mail-archive/msg15266.html - Sam Ruby From owner-atom-syntax@mail.imc.org Sun May 22 17:37:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27721 for ; Sun, 22 May 2005 17:37: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 j4MLPZ1c066611; Sun, 22 May 2005 14:25: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 j4MLPZRk066610; Sun, 22 May 2005 14:25:35 -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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MLPYuT066568 for ; Sun, 22 May 2005 14:25:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3114203wra for ; Sun, 22 May 2005 14:25:29 -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=P0Kp48kvmZNuW03ysHOusPROR+IPUTSd3TG7iwc+zGfPyP5cwMWUhl6WNfYRXUixUbpVKdJ03jcJU3HSqNU9lsA/5YdspUHXdAMzI+WMrp5lcxNoDRS2zzlPza6SOj88oh1X9bF0R7L8/7s6/eaWVlLGffbL+ORqqyV2tSzqEpU= Received: by 10.54.107.4 with SMTP id f4mr3017258wrc; Sun, 22 May 2005 14:25:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 14:25:29 -0700 (PDT) Message-ID: <68fba5c50505221425754b24ea@mail.gmail.com> Date: Sun, 22 May 2005 17:25:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <1695295412.20050522210137@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MLPZuT066601 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > I think that the current text is very misleading. The fact that at one > point inheritance has been condoned or suggested by previous drafts > (including the widely implemented pre-IETF public draft), but now we > have removed the suggestion, but kept the syntactic requirement > certainly got me. So, are you saying that we're required to explicitly reverse any requirement present in previous drafts? > The fact that the draft conflates the author > (editor?) of the feed with the author of the entries increases the > confusion. Where does the draft conflate the two? Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 17:45:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28155 for ; Sun, 22 May 2005 17:45: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 j4MLdj1b071241; Sun, 22 May 2005 14:39: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 j4MLdjnv071240; Sun, 22 May 2005 14:39: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MLdiaI071201 for ; Sun, 22 May 2005 14:39:45 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3118238wra for ; Sun, 22 May 2005 14:39: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=CKxvZb84qRjF8UGeNFy4/3XkP4pHTw7AaA3GJI5TXNCld1kOPcuir+v74uf2J+MaX/DLbFo30GQjvLwJE/U3mJTI3OLs9Fc5i5T8RtTr/TXCjcPmGREDhPl7AB0cM8HgB77gclL2xab7+qgN/mN2VOwYdN62EM2DE6hzEB0gqP4= Received: by 10.54.79.8 with SMTP id c8mr2405539wrb; Sun, 22 May 2005 14:39:39 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 14:39:39 -0700 (PDT) Message-ID: <68fba5c5050522143976f7296b@mail.gmail.com> Date: Sun, 22 May 2005 17:39:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: How is Atom superior to RSS? Cc: bob@wyman.us, Atom Syntax In-Reply-To: <4290F848.60407@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505221921.DFL26992@ms8.netsolmail.com> <4290F848.60407@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MLdjaI071233 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Sam Ruby wrote: > > ...your effort to create a concise list is very much appreciated Here's one for RSS1: the Dublin Core "module" required to approach Atom's core capabilities is extremely poorly defined. It doesn't even commit to a string literal for fields like dc:creator. This makes it challenging to fill a text field in an end-user application, even one that actually processes RSS1 with an RDF parser(!). https://bugzilla.mozilla.org/show_bug.cgi?id=287793 Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 18:05:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29846 for ; Sun, 22 May 2005 18:05: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 j4MLvC4M077525; Sun, 22 May 2005 14:57: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 j4MLvCBH077524; Sun, 22 May 2005 14:57: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.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MLvBPa077481 for ; Sun, 22 May 2005 14:57:12 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050522215705.CIGA26549.mta08-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Sun, 22 May 2005 22:57:05 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050522215705.IZXR29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Sun, 22 May 2005 22:57:05 +0100 Date: Sun, 22 May 2005 22:57:03 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <759771712.20050522225703@djpowell.net> To: Robert Sayre CC: Atom Syntax Subject: Re: A different question about atom:author and inheritance In-Reply-To: <68fba5c50505221425754b24ea@mail.gmail.com> References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> <68fba5c50505221425754b24ea@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 Sunday, May 22, 2005, 10:25:29 PM, Robert Sayre wrote: > On 5/22/05, David Powell wrote: >> I think that the current text is very misleading. The fact that at one >> point inheritance has been condoned or suggested by previous drafts >> (including the widely implemented pre-IETF public draft), but now we >> have removed the suggestion, but kept the syntactic requirement >> certainly got me. > So, are you saying that we're required to explicitly reverse any > requirement present in previous drafts? No, we're required to state the situation one way or the other. The current draft doesn't say that author is inherited, so I assumed that my original interpretation was incorrect. If it is intended to be inherited, can we still add text saying that it is inherited as an editorial change? >> The fact that the draft conflates the author >> (editor?) of the feed with the author of the entries increases the >> confusion. > Where does the draft conflate the two? Given this feed, how should it be displayed by an implementation? David Powell An example feed 2005-05-22T21:35:00Z http://example.com/entries/1 Who wrote this? The content should go here... 2005-05-22T21:35:00Z Is this correct: > Who wrote this? > =============== > > The content should go here... > > Last updated: 22nd May 2005 by David Powell Or was "David Powell" only intended to be the author (editor?) of the feed, and has the entry therefore been mis-attributed? -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 18:18:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01644 for ; Sun, 22 May 2005 18:18: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 j4MMAuKi079928; Sun, 22 May 2005 15:10: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 j4MMAuFn079927; Sun, 22 May 2005 15:10:56 -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 j4MMAt5L079902 for ; Sun, 22 May 2005 15:10:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3127772wra for ; Sun, 22 May 2005 15:10:50 -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=UYY1oHNZL8p2P9UjVcEnFALhn52kIW1ZcA6hIaxorLF6b/wv6utG5a5dHvqDVlk2l8SNPGQ1guusvZuDtFVic4QT+TYY7KtO0gxyEJj2EJ0LE8kdxqR6gH/HZEW4jRSF8bOCjlDojYJgUiRvKGjEqjhaugpNKUU85puNIzaP7AU= Received: by 10.54.35.68 with SMTP id i68mr3108768wri; Sun, 22 May 2005 15:10:50 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 15:10:49 -0700 (PDT) Message-ID: <68fba5c5050522151045d79e24@mail.gmail.com> Date: Sun, 22 May 2005 18:10:49 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <759771712.20050522225703@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> <68fba5c50505221425754b24ea@mail.gmail.com> <759771712.20050522225703@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MMAu5L079921 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > > So, are you saying that we're required to explicitly reverse any > > requirement present in previous drafts? > > No, we're required to state the situation one way or the other. The > current draft doesn't say that author is inherited, so I assumed that > my original interpretation was incorrect. > > If it is intended to be inherited, can we still add text saying that > it is inherited as an editorial change? We can clarify and improve the draft to your heart's delight. It's unproductively revisiting old arguments that bothers me. :) > Given this feed, how should it be displayed by an implementation? My problem is that the draft (wisely) doesn't make requirements about what implementations should 'display'. Shrook and PubSub.com are both 'implementations' and both may or may not 'display' authors, either of a feed or an entry. Here is the code that determines what to put in the "From" field when Thunderbird parses an RSS2 feed: item.author = getNodeValue(itemNode.getElementsByTagName("author")[0] || itemNode.getElementsByTagName("creator")[0]) || aFeed.title || item.author; That's not particularly sophisticated. I think the author of that code assumed finding the author would be Really Simple. Are you suggesting we can specify what that code should do, briefly, usefully, and clearly? If so, let's hear it. My personal opinion is that the best way for publishers to ensure their preferred text is displayed is to put an author element in the atom:entry. Of course, code like the stuff above wouldn't pick up multiple atom:author elements (just thought I'd mix it up :) Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 19:00:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04489 for ; Sun, 22 May 2005 19:00: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 j4MMqxIc088173; Sun, 22 May 2005 15:52: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 j4MMqwqj088172; Sun, 22 May 2005 15:52:59 -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 j4MMqwg4088166 for ; Sun, 22 May 2005 15:52:58 -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 j4MMqv0R005067 for ; Sun, 22 May 2005 16:52:57 -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 <0IGW00HEEY89DN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 22 May 2005 16:52:57 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGW002PUY88UG@mail.sun.net> for atom-syntax@imc.org; Sun, 22 May 2005 16:52:56 -0600 (MDT) Date: Sun, 22 May 2005 15:53:00 -0700 From: Tim Bray Subject: Re: A different question about atom:author and inheritance In-reply-to: <68fba5c5050522151045d79e24@mail.gmail.com> To: Robert Sayre Cc: David Powell , Atom Syntax Message-id: <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> <68fba5c50505221425754b24ea@mail.gmail.com> <759771712.20050522225703@djpowell.net> <68fba5c5050522151045d79e24@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 22, 2005, at 3:10 PM, Robert Sayre wrote: >> If it is intended to be inherited, can we still add text saying that >> it is inherited as an editorial change? >> > > We can clarify and improve the draft to your heart's delight. It's > unproductively revisiting old arguments that bothers me. :) Yeah, I was startled just now to realize that there's nothing there to say that the feed-level author applies to entry-level when it's not specified at the entry level. The intent seems pretty clear; entry-level overrides source-level overrides feed-level, but it seems like we should say that. Anybody think this is anything more than an editorial change? -Tim From owner-atom-syntax@mail.imc.org Sun May 22 19:21:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05741 for ; Sun, 22 May 2005 19:21: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 j4MNALNm092121; Sun, 22 May 2005 16:10: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 j4MNALCU092120; Sun, 22 May 2005 16:10:21 -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 j4MNAK5P092072 for ; Sun, 22 May 2005 16:10:21 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 89965 messnum 4213120 invoked from network[83.70.217.193/unknown]); 22 May 2005 23:10:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail13.svc.cra.dublin.eircom.net (qp 89965) with SMTP; 22 May 2005 23:10:12 -0000 Message-ID: <4291114C.2030401@dehora.net> Date: Mon, 23 May 2005 00:10:04 +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: Robert Sayre , David Powell , Atom Syntax Subject: Re: A different question about atom:author and inheritance References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> <68fba5c50505221425754b24ea@mail.gmail.com> <759771712.20050522225703@djpowell.net> <68fba5c5050522151045d79e24@mail.gmail.com> <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> In-Reply-To: <9EAF671F-247C-4143-BDDB-E419A65A5652@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: > Anybody think this is anything more than an editorial change? -Tim Not me (you'd have to tell me that inheritance applies at all, not the other way around). But the rules must be consistent for the elements that appear at both levels. cheers Bill From owner-atom-syntax@mail.imc.org Sun May 22 19:26:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05984 for ; Sun, 22 May 2005 19:26: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 j4MNKVKQ096198; Sun, 22 May 2005 16:20: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 j4MNKVeU096197; Sun, 22 May 2005 16:20:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MNKUtG096189 for ; Sun, 22 May 2005 16:20:30 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4MNKRqp010090; Sun, 22 May 2005 19:20:27 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DFL74221; Sun, 22 May 2005 19:20:26 -0400 (EDT) Message-Id: <200505222320.DFL74221@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Robert Sayre'" Cc: "'David Powell'" , "'Atom Syntax'" Subject: RE: A different question about atom:author and inheritance Date: Sun, 22 May 2005 19:20:21 -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.2180 Thread-Index: AcVfIpv1gyS7ChU5Q8yEqF2dne3yjwAARhCQ In-Reply-To: <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: >The intent seems pretty clear; entry-level overrides source-level > overrides feed-level, but it seems like we should say that. > Anybody think this is anything more than an editorial change? -Tim I believe that this three-level chain of inheritance has always been what we've intended. There was, however, a great deal of discussion at one point about how to actually write the words. Thus, I agree that it is largely an editorial change; however, you might expect some controversy over particular word choices. Give it a shot and let's see how folk respond. Note: There is more to authorship than just the inheritance issue. I think it also makes sense that a "feed-level author" should be considered to be the author of the collection of items which is the feed. This authorship is independent of authorship over any particular entry within the feed. Even if the feed contains no items authored by the feed-level author, the feed-level author is still author of the collection. This distinction would be useful in describing linkblogs, and a variety of other feeds types that are composed of entries collected from other feeds or multiple authors. bob wyman From owner-atom-syntax@mail.imc.org Sun May 22 19:27:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06137 for ; Sun, 22 May 2005 19:27: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 j4MNJEor095724; Sun, 22 May 2005 16:19: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 j4MNJEQt095723; Sun, 22 May 2005 16:19:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4MNJDEL095677 for ; Sun, 22 May 2005 16:19:13 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 10503 messnum 2875470 invoked from network[83.70.217.193/unknown]); 22 May 2005 23:19:07 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail09.svc.cra.dublin.eircom.net (qp 10503) with SMTP; 22 May 2005 23:19:07 -0000 Message-ID: <42911362.7020905@dehora.net> Date: Mon, 23 May 2005 00:18: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: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Tim Bray , Robert Sayre , David Powell , Atom Syntax Subject: Re: A different question about atom:author and inheritance References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1695295412.20050522210137@djpowell.net> <68fba5c50505221425754b24ea@mail.gmail.com> <759771712.20050522225703@djpowell.net> <68fba5c5050522151045d79e24@mail.gmail.com> <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> <4291114C.2030401@dehora.net> In-Reply-To: <4291114C.2030401@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hra wrote: > > Tim Bray wrote: > >> Anybody think this is anything more than an editorial change? -Tim > > > Not me (you'd have to tell me that inheritance applies at all, not the > other way around). But the rules must be consistent for the elements > that appear at both levels. Quick followup: I'll take an action to review the upcoming format draft to see if we need to apply any such wording to feed level extensions. cheers Bill From owner-atom-syntax@mail.imc.org Sun May 22 19:40:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06788 for ; Sun, 22 May 2005 19:40: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 j4MNYZqs001409; Sun, 22 May 2005 16: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 j4MNYZbv001408; Sun, 22 May 2005 16:34:35 -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 j4MNYYAu001364 for ; Sun, 22 May 2005 16:34:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3149820wra for ; Sun, 22 May 2005 16:34:29 -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=P5J65JUZWpk4+G3pQHcRr4jDMkB5kQtit5Oe3aAj5wf92xZF/RaKlJ9CqZk4N52Jny1qliSzdwt9LwHM28pIS1FJS80leOZFPSllYtP4izDbZwVE3JQ957iqRPsVCxyUHoENb15fxcJXygylf1z5zZRI588a9oyENyrvgdj4GgY= Received: by 10.54.117.4 with SMTP id p4mr3077945wrc; Sun, 22 May 2005 16:34:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 16:34:29 -0700 (PDT) Message-ID: <68fba5c50505221634452cb975@mail.gmail.com> Date: Sun, 22 May 2005 19:34:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: A different question about atom:author and inheritance Cc: Tim Bray , David Powell , Atom Syntax In-Reply-To: <200505222320.DFL74221@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> <200505222320.DFL74221@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MNYYAu001389 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Bob Wyman wrote: > Tim Bray wrote: > >The intent seems pretty clear; entry-level overrides source-level > > overrides feed-level, but it seems like we should say that. > > Anybody think this is anything more than an editorial change? -Tim > I believe that this three-level chain of inheritance has always been > what we've intended. There was, however, a great deal of discussion at one > point about how to actually write the words. Thus, I agree that it is > largely an editorial change; Fully agree. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 20:12:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08804 for ; Sun, 22 May 2005 20:12: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 j4N01Qrg011031; Sun, 22 May 2005 17: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 j4N01Qup011028; Sun, 22 May 2005 17:01:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N01OkL010967 for ; Sun, 22 May 2005 17:01:25 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050523000118.UBUL26549.mta08-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Mon, 23 May 2005 01:01:18 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050523000118.PRWN18002.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Mon, 23 May 2005 01:01:18 +0100 Date: Mon, 23 May 2005 01:01:16 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <893254766.20050523010116@djpowell.net> To: "Bob Wyman" CC: "'Atom Syntax'" Subject: Re: A different question about atom:author and inheritance In-Reply-To: <200505222320.DFL74221@ms8.netsolmail.com> References: <9EAF671F-247C-4143-BDDB-E419A65A5652@sun.com> <200505222320.DFL74221@ms8.netsolmail.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 Monday, May 23, 2005, 12:20:21 AM, Bob Wyman wrote: > Tim Bray wrote: >>The intent seems pretty clear; entry-level overrides source-level >> overrides feed-level, but it seems like we should say that. >> Anybody think this is anything more than an editorial change? -Tim > I believe that this three-level chain of inheritance has always been > what we've intended. There was, however, a great deal of discussion at one > point about how to actually write the words. Thus, I agree that it is > largely an editorial change; however, you might expect some controversy over > particular word choices. Give it a shot and let's see how folk respond. +1 > Note: There is more to authorship than just the inheritance issue. I > think it also makes sense that a "feed-level author" should be considered to > be the author of the collection of items which is the feed. This authorship > is independent of authorship over any particular entry within the feed. Even > if the feed contains no items authored by the feed-level author, the > feed-level author is still author of the collection. This distinction would > be useful in describing linkblogs, and a variety of other feeds types that > are composed of entries collected from other feeds or multiple authors. +1 I think it would be best if we stated both of these effects close together in the specification so that it is obvious what the effect of providing atom:feed/atom:author is. We should also do a check on: atom:feed/atom:category atom:feed/atom:contributor atom:feed/atom:copyright to make sure that we are as clear as possible about whether or not they are inherited by entries, and whether or not they apply to the feed as a itself. -- Dave From owner-atom-syntax@mail.imc.org Sun May 22 20:34:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10331 for ; Sun, 22 May 2005 20:34: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 j4N0ReQi019946; Sun, 22 May 2005 17:27: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 j4N0ReY2019944; Sun, 22 May 2005 17:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N0Rcm3019906 for ; Sun, 22 May 2005 17:27:39 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4N0RW702456; Mon, 23 May 2005 09:27:32 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id b2bdabbc_cb21_11d9_807d_0030482533a1_10704; Mon, 23 May 2005 09:29:17 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000038; 23 May 05 09:30:41 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 23 May 05 09:30:08 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.53) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000031; 23 May 05 09:30:06 +0900 Message-Id: <6.0.0.20.2.20050522191246.0881a940@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 22 May 2005 19:13:01 +0900 To: Eric Scheid , Atom Syntax From: Martin Duerst Subject: Re: Compulsory feed ID? 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 At 08:47 05/05/20, Eric Scheid wrote: > >On 19/5/05 10:41 PM, "Tim Bray" wrote: > >> We suggest that there may be WG consensus in favor of changing the >> format spec to make atom:id a required child of atom:feed. (Text not >> provided, we trust the editors to figure out the correct way to say >> this). Please indicate agreement or disagreement with this proposition >> in the next day or two. > >wth, +1 +1 here too. Regards, Martin. From owner-atom-syntax@mail.imc.org Sun May 22 20:44:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14063 for ; Sun, 22 May 2005 20:44: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 j4N0cZN7023926; Sun, 22 May 2005 17:38: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 j4N0cZO3023921; Sun, 22 May 2005 17:38:35 -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 j4N0cX90023879 for ; Sun, 22 May 2005 17:38:34 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 00:38:27 -0000 Received: from xdsl-213-196-226-74.netcologne.de (EHLO klangraum) [213.196.226.74] by mail.gmx.net (mp015) with SMTP; 23 May 2005 02:38:27 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 02:42:03 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: some small comments on 08 Message-ID: <20050523004203.GA30042@klangraum> Mail-Followup-To: Atom Syntax References: <42904F50.3020404@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42904F50.3020404@annevankesteren.nl> 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: 8bit * Anne van Kesteren [2005-05-22 11:35]: > * 4.1.3.1 The "type" attribute > > Can I circumvent the DIV element by using the media type of > XHTML? (I really dislike this combined construct by the way.) I used to find it extremely horrible. Now I’m not sure. There is some symmetry here: with @type="xml", you have to enclose a full XML document, which will always have a root element. The pseudo-XHTML DIV required for @type="xhtml" makes XHTML fragments behave the same way. I don’t know if I like it. I don’t know if it’s a good solution. But it is consistent on some level, at least. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun May 22 21:25:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16074 for ; Sun, 22 May 2005 21: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 j4N1GoQg036028; Sun, 22 May 2005 18:16: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 j4N1GoSS036027; Sun, 22 May 2005 18:16:50 -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 j4N1GgK8035940 for ; Sun, 22 May 2005 18:16:48 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c505052115415e3a1be8@mail.gmail.com> References: <68fba5c505052115415e3a1be8@mail.gmail.com> Date: Sun, 22 May 2005 18:06:27 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Close the Atompub WG? (was: PROCESS QUESTION: are we done yet?) 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 6:41 PM -0400 5/21/05, Robert Sayre wrote: >Discussion since you sent this email indicates that the people who >currently think they constitute the Atompub WG don't think they need >to respect any previous consensus. s/any/some/. Agree. Sometimes people change their mind. (s/Sometimes/Quite often/ ...) > The people sending emails after >last call are, by and large, not the same people who were posting in >October (when we settled the dates issues). I suggest we seriously >consider closing the WG if basic decisions cannot respected or >declared out of order. Fully disagree. This WG has made the basic spec much stronger and more complete than any individually-submitted RFC could possibly be. > Why shouldn't the IETF close this WG down? Because it is still improving on a specification that is important to the IETF. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun May 22 21:25:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16072 for ; Sun, 22 May 2005 21:25: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 j4N1GkpL035977; Sun, 22 May 2005 18:16: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 j4N1GkIA035976; Sun, 22 May 2005 18:16:46 -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 j4N1GgK0035940 for ; Sun, 22 May 2005 18:16:43 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505210611.DFE98234@ms8.netsolmail.com> References: <200505210611.DFE98234@ms8.netsolmail.com> Date: Sun, 22 May 2005 18:14:03 -0700 To: Atom WG From: Paul Hoffman Subject: RE: multiple ids 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:11 AM -0400 5/21/05, Bob Wyman wrote: >Tim Bray directs the editors to insert the following words: > "If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry and Atom Processors > MUST treat them as such." > > It is a long standing and valued tradition in the IETF that >Standards Track RFC's MUST NOT impose constraints on applications unless >such constraints relate to issues of interoperability. Thus, while it is >entirely appropriate for the specification to state that "multiple >atom:entry elements with the same atom:id ... describe the same entry" it is >NOT appropriate to state how Atom Processors must treat such elements. The >text should read simply: > >"If multiple atom:entry elements with the same atom:id value appear in > an Atom Feed document, they describe the same entry." +1. I can live with Tim's original wording because the phrase that Bob removes is impossible to measure or enforce, but Bob's wording is cleaner for the same result. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun May 22 21:25:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16093 for ; Sun, 22 May 2005 21:25: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 j4N1GlXA035988; Sun, 22 May 2005 18:16: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 j4N1GkDr035987; Sun, 22 May 2005 18:16:46 -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 j4N1GgK2035940 for ; Sun, 22 May 2005 18:16:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505210630.DFF03270@ms8.netsolmail.com> References: <200505210630.DFF03270@ms8.netsolmail.com> Date: Sun, 22 May 2005 18:15:38 -0700 To: Atom WG From: Paul Hoffman Subject: RE: Compulsory feed ID? 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:30 AM -0400 5/21/05, Bob Wyman wrote: >I >think it would be both wise and appropriate to provide text in a Security >Concerns section that describes the vulnerability of systems that rely on >Atom documents to this particular attack. That's why we have signed documents, which are described fully in the document already. It is fine to add text to the signatures section explaining why they are useful against this attack, and a short mention in the Security Considerations section pointing back to that one. Please note that every format that the IETF has ever come out with that isn't inherently signed has either this exact problem or one very close to it. The fact that the format document specifies a signing mechanism in the document itself instead of in a companion document that is read by only 25% of the implementers is a giant leap forward. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun May 22 21:40:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16873 for ; Sun, 22 May 2005 21:40: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 j4N1Yi4w042309; Sun, 22 May 2005 18:34: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 j4N1YitL042308; Sun, 22 May 2005 18:34:44 -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 j4N1YhHX042262 for ; Sun, 22 May 2005 18:34:43 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3188123wra for ; Sun, 22 May 2005 18:34:38 -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=jEnAuz4J3xJWn6v7vVMYMwd0lRJbY1Wk9Hkv8n9+LDaOD628/Ssqty9EWAiA49wMbuqUqRt6p4G1CdPZUL8xGjE8mnxboU01S0d1KnQWoxOpb9BRCR4ABiBt2gOU3Z3BO+y4E347tST9LYD3kNhlQC/IKPeVXC5xKuf6bJl/fhI= Received: by 10.54.7.16 with SMTP id 16mr3204902wrg; Sun, 22 May 2005 18:34:38 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 18:34:38 -0700 (PDT) Message-ID: <68fba5c505052218344e328db1@mail.gmail.com> Date: Sun, 22 May 2005 21:34:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax Subject: Sorry. (was: Fetch me an author. Now, fetch me another author.) Cc: Graham In-Reply-To: <68fba5c5050522050947359b9a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428E2C8E.6050506@dehora.net> <428F0853.60605@dehora.net> <68fba5c50505210709413c0ff6@mail.gmail.com> <428F4DA9.4070806@dehora.net> <68fba5c505052108233056469@mail.gmail.com> <6CB1AE02-9144-40B9-A7ED-761A66F4317F@mac.com> <68fba5c5050522050947359b9a@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N1YhHX042303 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Robert Sayre wrote: > It seems reasonable to conclude you people can't read. This statement was completely inappropriate. Everyone will miss requirements when they read a draft. The fact that everyone missed this requirement, no matter how obvious it is under scrutiny, indicates that this editor erred in some way. I'm not sure how it could have been clearer without the benefit of hindsight, but that doesn't justify the quoted sentence above. I apologize. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 21:46:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17276 for ; Sun, 22 May 2005 21:46: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 j4N1e2uw044232; Sun, 22 May 2005 18:40: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 j4N1e2r7044231; Sun, 22 May 2005 18:40:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N1e0xP044199 for ; Sun, 22 May 2005 18:40:01 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000422343 for ; Mon, 23 May 2005 11:39:58 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 May 2005 11:39:54 +1000 Subject: Re: A different question about atom:author and inheritance From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1695295412.20050522210137@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 23/5/05 6:01 AM, "David Powell" wrote: > We should add language that specifically states that the value of > atom:feed/atom:author is not a shortcut for specifying > atom:entry/atom:author - if that is what we mean. +1 for disambiguating either way. e. From owner-atom-syntax@mail.imc.org Sun May 22 21:51:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17469 for ; Sun, 22 May 2005 21:51: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 j4MKrTIw055753; Sun, 22 May 2005 13:53: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 j4MKrTTb055752; Sun, 22 May 2005 13:53: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4MKrSmp055720 for ; Sun, 22 May 2005 13:53:29 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3103807wra for ; Sun, 22 May 2005 13:53: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=QmEikou+shl9doHcix8vLwAeFbcMZ4bcpMvRKX77Cg48yv+PQjJQRZ4m78ID13Z1ni8gF5aRRx12a7TD5i6OZzcoIeXrEdiRpKWKA+MXU+Hv281F/diDSWvIb7AlamRYjMhAi5wA7b0b2CsPgHq37+Acwe6eJmsgk2TtUXF8Rpo= Received: by 10.54.69.16 with SMTP id r16mr2384134wra; Sun, 22 May 2005 13:53:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 13:53:23 -0700 (PDT) Message-ID: <68fba5c505052213537f196a3c@mail.gmail.com> Date: Sun, 22 May 2005 16:53:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: David Powell Subject: Re: A different question about atom:author and inheritance Cc: Atom Syntax In-Reply-To: <1857314093.20050522210143@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1857314093.20050522210143@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4MKrTmp055745 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, David Powell wrote: > We may of thought that we were finished, but it is clear that we were > not ready for Last-Call: neither the Working Group, nor the IETF had > sufficient time to review the specification because it has been in > flux with proposals. I can't agree with that statement. The draft hasn't changed for more than a month, while Tim and Paul have been last-calling this thing for months now, and very little of substance has transpired since then. The document has been quite stable since March 12th, when format-06 was produced. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 22:09:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19830 for ; Sun, 22 May 2005 22: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 j4N20JJ9051197; Sun, 22 May 2005 19:00: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 j4N20J09051196; Sun, 22 May 2005 19:00:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N20FXo051145 for ; Sun, 22 May 2005 19:00:17 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000422398 for ; Mon, 23 May 2005 12:00:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 May 2005 12:00:09 +1000 Subject: Re: A different question about atom:author and inheritance From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <9EAF671F-247C-4143-BDDB-E419A65A5652@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 On 23/5/05 8:53 AM, "Tim Bray" wrote: > Yeah, I was startled just now to realize that there's nothing there > to say that the feed-level author applies to entry-level when it's > not specified at the entry level. The intent seems pretty clear; > entry-level overrides source-level overrides feed-level, but it seems > like we should say that. > > Anybody think this is anything more than an editorial change? -Tim I don't think we ever decided AGAINST inheritance, we only punted on explaining it. Thus, I've assumed that inheritance was implied. That reading the spec in isolation is ambiguous makes it a bad spec. We don't need a Pace, this is an editorial change. The editor might insist on camera ready copy though -- I hear he's a bit curmudgeonly lately. e. From owner-atom-syntax@mail.imc.org Sun May 22 22:13:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22950 for ; Sun, 22 May 2005 22:13: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 j4N24fF7052700; Sun, 22 May 2005 19:04: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 j4N24fP1052699; Sun, 22 May 2005 19:04: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N24epS052654 for ; Sun, 22 May 2005 19:04:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3197023wra for ; Sun, 22 May 2005 19:04: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mwiui2ulgzljZ2SVWv8+DFDhssPdal+YSE+pr8ZeXqM2tTPqFsjN+iRdgRe2FT/1bVHHFBrhr3lryFa67UADMeRyEQNX2OCXJXbhkZMIaaZsysiF9ov/PwBfcAksF5h6GKhGSTGxoSzDtgNg3LbMcQU/fkc6wAOp3m3isEDlPn0= Received: by 10.54.32.4 with SMTP id f4mr3138238wrf; Sun, 22 May 2005 19:04:35 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Sun, 22 May 2005 19:04:35 -0700 (PDT) Message-ID: <68fba5c505052219046bdab480@mail.gmail.com> Date: Sun, 22 May 2005 22:04:35 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: multiple ids Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505210611.DFE98234@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N24epS052677 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/22/05, Paul Hoffman wrote: > > At 2:11 AM -0400 5/21/05, Bob Wyman wrote: > >Tim Bray directs the editors to insert the following words: > > "If multiple atom:entry elements with the same atom:id value appear in > > an Atom Feed document, they describe the same entry and Atom Processors > > MUST treat them as such." > > > > It is a long standing and valued tradition in the IETF that > >Standards Track RFC's MUST NOT impose constraints on applications unless > >such constraints relate to issues of interoperability. Thus, while it is > >entirely appropriate for the specification to state that "multiple > >atom:entry elements with the same atom:id ... describe the same entry" it is > >NOT appropriate to state how Atom Processors must treat such elements. The > >text should read simply: > > > >"If multiple atom:entry elements with the same atom:id value appear in > > an Atom Feed document, they describe the same entry." > > +1. I can live with Tim's original wording because the phrase that > Bob removes is impossible to measure or enforce, but Bob's wording is > cleaner for the same result. +1. Bob wording is better. Robert Sayre From owner-atom-syntax@mail.imc.org Sun May 22 23:37:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23721 for ; Sun, 22 May 2005 23: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 j4N3RUMK072247; Sun, 22 May 2005 20:27: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 j4N3RUdT072246; Sun, 22 May 2005 20:27:30 -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 j4N3RSe0072194 for ; Sun, 22 May 2005 20:27:29 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 03:27:21 -0000 Received: from xdsl-213-196-226-74.netcologne.de (EHLO klangraum) [213.196.226.74] by mail.gmx.net (mp021) with SMTP; 23 May 2005 05:27:21 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 05:30:58 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: some small comments on 08 Message-ID: <20050523033058.GA30202@klangraum> Mail-Followup-To: Atom Syntax References: <42904F50.3020404@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42904F50.3020404@annevankesteren.nl> 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: 8bit * Anne van Kesteren [2005-05-22 11:35]: > * 3.1.1.3 XHTML > > I would like to see "valid XHTML" more clearly defined. There > are a lot of different XHTML versions I know of and some might > not include a DIV element at all... You have XHTML 1 (in three > versions), XHTML 1.1, XHTML Basic, HTML5 (Web Applications > 1.0). (Web Forms 2.0 extends XHTML 1...) Et cetera. I vote for punting the validity issue. I don’t think we can reasonably enforce any stronger restriction that requiring well-formedness here. Browsers which understand application/xhtml+xml behave that way, FWIW. It’s probably best to tell people that they are likely to get inconsistent results at best if they try to stick a frameset document or something equally silly in their feed, but not to prohibit them from doing so. We can’t anticipate what direction XHTML will take. > * 4.2.2 The "atom:category" Element > > Why is significant information hidden in attributes? That is > bad for i18n and prevents people from defining the expansion of > an abbreviation, for example. Struck me as odd as well. > * Links > > I don't understand why we have so many different link > constructs. , > iri, iri, > . > > Can't we name them consistently? I'd suggest 'href' or 'url'. > ('url' is used in CSS and extensions of HTML and XHTML 1 made > by the WHATWG.) +1 I’m pretty sure that the latter two changes are not possible/permissible at this stage of the process, though. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 00:47:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26549 for ; Mon, 23 May 2005 00: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 j4N4cbDg096396; Sun, 22 May 2005 21:38: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 j4N4cb01096395; Sun, 22 May 2005 21:38:37 -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 j4N4cZwR096366; Sun, 22 May 2005 21:38:36 -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 j4N4cZjO013284; Sun, 22 May 2005 22:38:35 -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 <0IGX00HUAE8ADN@edgemail1.Central.Sun.COM>; Sun, 22 May 2005 22:38:35 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGX00AIZE84O6@mail.sun.net>; Sun, 22 May 2005 22:38:34 -0600 (MDT) Date: Sun, 22 May 2005 21:38:33 -0700 From: Tim Bray Subject: Re: multiple ids In-reply-to: <68fba5c505052219046bdab480@mail.gmail.com> To: Robert Sayre Cc: Paul Hoffman , Atom WG Message-id: <99E813B3-1DF6-4A20-8562-6A47B2809B2D@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <200505210611.DFE98234@ms8.netsolmail.com> <68fba5c505052219046bdab480@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 22, 2005, at 7:04 PM, Robert Sayre wrote: >>> "If multiple atom:entry elements with the same atom:id value >>> appear in >>> an Atom Feed document, they describe the same entry and Atom >>> Processors >>> MUST treat them as such." >>> >>> It is a long standing and valued tradition in the IETF that >>> Standards Track RFC's MUST NOT impose constraints on applications >>> unless >>> such constraints relate to issues of interoperability. Thus, >>> while it is >>> entirely appropriate for the specification to state that "multiple >>> atom:entry elements with the same atom:id ... describe the same >>> entry" it is >>> NOT appropriate to state how Atom Processors must treat such >>> elements. The >>> text should read simply: >>> >>> "If multiple atom:entry elements with the same atom:id value >>> appear in >>> an Atom Feed document, they describe the same entry." >> >> +1. I can live with Tim's original wording because the phrase that >> Bob removes is impossible to measure or enforce, but Bob's wording is >> cleaner for the same result. > > +1. Bob wording is better. I agree. The MUST clause was inserted in response to concerns raised by Graham, but it seems clear that it lacks consensus support. -Tim From owner-atom-syntax@mail.imc.org Mon May 23 00:49:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26645 for ; Mon, 23 May 2005 00:49: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 j4N4gLo7097885; Sun, 22 May 2005 21:42: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 j4N4gL5V097884; Sun, 22 May 2005 21:42:21 -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 j4N4gJqV097872 for ; Sun, 22 May 2005 21:42:19 -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 j4N4gJ0R024371 for ; Sun, 22 May 2005 22:42:19 -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 <0IGX00HYGEEIDN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 22 May 2005 22:42:19 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGX00AJJEEIO6@mail.sun.net> for atom-syntax@imc.org; Sun, 22 May 2005 22:42:18 -0600 (MDT) Date: Sun, 22 May 2005 21:42:23 -0700 From: Tim Bray Subject: Re: Compulsory feed ID? In-reply-to: <6.0.0.20.2.20050522191246.0881a940@itmail.it.aoyama.ac.jp> To: Martin Duerst Cc: Eric Scheid , Atom Syntax Message-id: <7BDBAFC7-4BC9-4B7A-BF1F-84F3CC899629@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <6.0.0.20.2.20050522191246.0881a940@itmail.it.aoyama.ac.jp> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 22, 2005, at 3:13 AM, Martin Duerst wrote: > >> We suggest that there may be WG consensus in favor of changing the > >> format spec to make atom:id a required child of atom:feed. > (Text not > >> provided, we trust the editors to figure out the correct way to say > >> this). Please indicate agreement or disagreement with this > proposition > >> in the next day or two. > > > >wth, +1 > > +1 here too. Regards, Martin. Having reviewed the commentary over the last three days, I observe a couple of +1's, a few "not my favorite approach but OK", and no objections. I see rough consensus in favor of making atom:id a compulsory child of atom:feed. -Tim From owner-atom-syntax@mail.imc.org Mon May 23 01:28:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28291 for ; Mon, 23 May 2005 01:28: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 j4N5JLOs008125; Sun, 22 May 2005 22:19: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 j4N5JLqB008124; Sun, 22 May 2005 22:19: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N5JJdt008024 for ; Sun, 22 May 2005 22:19:20 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 05:19:13 -0000 Received: from xdsl-213-196-226-74.netcologne.de (EHLO klangraum) [213.196.226.74] by mail.gmx.net (mp010) with SMTP; 23 May 2005 07:19:13 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 07:22:49 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Author and contributor Message-ID: <20050523052249.GA31955@klangraum> Mail-Followup-To: Atom Syntax References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@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: 8bit * Tim Bray [2005-05-23 07:00]: > Unfortunately, among those who want to change the current > setup, we do not observe consensus on the subject of what to > change them to. Near as we can tell, people want to make > atom:author plural, some want to nuke atom:contributor and > others don't. In <63190A9C-CA6F-11D9-BDA9-003065EA6144@geckotribe.com> (), Antone Roundy suggests: • make atom:author plural • keep atom:contributor • punt bylines to an extension To me that sounds like the simplest thing that can possibly work, and looks like it hits the 80/20 mark. It also requires the least squabbling over its implementation. And Robert has expressed that he is fine with the proposal in that thread. I’ve expressed an affinity for the idea of putting atom:category in atom:contributor, but I see a lot of potential delay in that and no pressing need for it. Again, +1 to Antone’s suggestion. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 01:28:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28316 for ; Mon, 23 May 2005 01:28: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 j4N5J0Ec007888; Sun, 22 May 2005 22:19: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 j4N5J0l6007887; Sun, 22 May 2005 22:19: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N5Ixeq007806 for ; Sun, 22 May 2005 22:18:59 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so2530488wri for ; Sun, 22 May 2005 22:18:53 -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=AfXsJLlMWQJKzBxTASVa5BzzrrML0WFXGPN4B5W1YWklNWFOBrwPVIyR/EqImCzaeeD8CsrAIwDNivWbTckK2wE6pm/HFtFogLG1DFpw6UKmxqwvnNAB5j7+TGvW4X3NlHt8k+QG1zwc3xmFLxvyLQ3/a6C8Cli7lheoXOzqKWs= Received: by 10.54.81.12 with SMTP id e12mr2986285wrb; Sun, 22 May 2005 22:18:53 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Sun, 22 May 2005 22:18:53 -0700 (PDT) Message-ID: <540e373205052222181f1d8e20@mail.gmail.com> Date: Mon, 23 May 2005 00:18:53 -0500 From: "Roger B." Reply-To: "Roger B." To: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <9710484656.20050522132116@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@mail.gmail.com> <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@sun.com> <9710484656.20050522132116@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N5Ixeq007882 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > PaceDateModified2 deliberately doesn't prohibit this, nor does this > prevent the proposal from fulfilling its goal to provide a temporal > ordering for entry instances. Dave: I'm pretty much +0 on PDM2, as I've mentioned previously. Your modifications to the concept address my "this will break stuff" concerns with the original formulation, so I'm okay with however it works out. But I have a question, and I'm asking you specifically because you seem to be approaching your argument in a reasonable tone and fashion. My apologies if I'm pestering. Near as I can tell, folks have modification dates. In my case, that is a date that is updated every time the user clicks "save". In Tim's case, that is a date that he chooses. In other apps, that may be a date that matches when a new comment was added to a blog entry. Nothing in the spec is going to change these realities. And none of these approaches are *wrong*, or invalid. We each get to define "change" in our own apps, so we can approach atom:modified's MUST clause as we see fit. For all practical purposes, it doesn't matter whether folks use atom:updated or atom:modified. You're going to get the same date. With that in mind, what are the actual benefits of atom:modified over atom:updated? The end result will always be identical, unless I'm missing a crucial, well-hidden point. Please note that it has not escaped me that this cuts both ways. Why fight for atom:updated over atom:modified when it is beyond the scope of the Atom spec to define the nature of change in the universe? Hey, if Tim doesn't consider a typo a real modification, then it just isn't. Period. It's his writing, his app, and he defines the rules and the terms. The more I look at this, the more I see people fighting over phantoms. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Mon May 23 01:38:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28902 for ; Mon, 23 May 2005 01:38: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 j4N5UHdI017665; Sun, 22 May 2005 22:30: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 j4N5UHGJ017664; Sun, 22 May 2005 22:30: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N5UGQb017559 for ; Sun, 22 May 2005 22:30:16 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so2534587wri for ; Sun, 22 May 2005 22:30:11 -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=HziutdFUJjI+O186V1mTkjXkLHN70IBHcdQrWwt+NybrgRLrj0uTx35z1urQKEnTKkmUjQNT9BgA0Z4ETfS+iOTvy6IylbOBs1xN3GtZ/L9PtnIbQzyHUZ0/rhhJhZP+yFHasgvgIt1hXbKll2/uUrN1x/qfT16AArNN1Idw+9c= Received: by 10.54.79.16 with SMTP id c16mr3738682wrb; Sun, 22 May 2005 22:30:11 -0700 (PDT) Received: by 10.54.95.17 with HTTP; Sun, 22 May 2005 22:30:09 -0700 (PDT) Message-ID: <540e37320505222230135d6df2@mail.gmail.com> Date: Mon, 23 May 2005 00:30:09 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.) In-Reply-To: <200505220407.DFI40109@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200505220407.DFI40109@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N5UHQb017656 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Can you tell me, in those "unusual cases" when there is "difficulty > in determining which instance came last," what the heck am I supposed to do > if the users expect to always see the "most recent" instance? Bob: The same thing you'd do if you had two entries with matching ids and modified dates. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Mon May 23 01:56:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00017 for ; Mon, 23 May 2005 01:56: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 j4N5mOS2032439; Sun, 22 May 2005 22:48: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 j4N5mOqO032432; Sun, 22 May 2005 22:48:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N5mMke032406 for ; Sun, 22 May 2005 22:48:23 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [210.193.203.50] (HELO [192.168.45.41]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000423105 for ; Mon, 23 May 2005 15:48:22 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 May 2005 15:48:17 +1000 Subject: Re: Author and contributor From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050523052249.GA31955@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N5mOke032425 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 23/5/05 3:22 PM, "A. Pagaltzis" wrote: > Antone Roundy suggests: > +1 make atom:author plural > +1 keep atom:contributor > punt bylines to an extension > > To me that sounds like the simplest thing that can possibly work, > and looks like it hits the 80/20 mark. It also requires the least > squabbling over its implementation. And Robert has expressed that > he is fine with the proposal in that thread. > > Again, +1 to Antones suggestion. +1,+1, and +1 from me too. > Ive expressed an affinity for the idea of putting atom:category > in atom:contributor, but I see a lot of potential delay in that > and no pressing need for it. seeing as that proposal was my idea, and despite no technical objections to it, I'm happy to withdraw it just so atom:author can get through the process hoops. e. From owner-atom-syntax@mail.imc.org Mon May 23 01:58:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00123 for ; Mon, 23 May 2005 01:58: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 j4N5lJBN031764; Sun, 22 May 2005 22:47: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 j4N5lJrZ031763; Sun, 22 May 2005 22:47:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N5lItD031704 for ; Sun, 22 May 2005 22:47:19 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [210.193.203.50] (HELO [192.168.45.41]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000423101 for ; Mon, 23 May 2005 15:47:14 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 May 2005 15:47:10 +1000 Subject: Re: Refresher on Updated/Modified From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <540e373205052222181f1d8e20@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 23/5/05 3:18 PM, "Roger B." wrote: > With that in mind, what are the actual benefits of atom:modified over > atom:updated? The end result will always be identical, unless I'm > missing a crucial, well-hidden point. atom:updated is predicated on a new feature yet to be built into common blogging tools -- the concept of specifying if this change is a "significant" change. Most tools just proffer something approximating atom:modified, some tools provide a user-editable date which could be used as a round about way of signifying a "significant" change. theoretically, we're hoping that people won't just smush atom:modified types of values into atom:updated (since it is a required element), preferring to leave atom:updated with it's initial value (effectively atom:published). If common practice is to dump an automated "last modified" value into atom:updated, then the intent and purpose of atom:updated will have been defeated by all that pollution. Which would be sad. e. From owner-atom-syntax@mail.imc.org Mon May 23 02:59:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24466 for ; Mon, 23 May 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 j4N6oQ4W065327; Sun, 22 May 2005 23:50: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 j4N6oQBg065326; Sun, 22 May 2005 23:50:26 -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 j4N6oPji065311 for ; Sun, 22 May 2005 23:50:25 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 46391 invoked by uid 17064); 23 May 2005 06:50:25 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.139.251]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 23 May 2005 06:50:25 -0000 In-Reply-To: <20050523052249.GA31955@klangraum> References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <643F1422-7439-4BA4-AF72-BA0E4A93D5D5@bblfish.net> Cc: atom-syntax Syntax From: Henry Story Subject: Re: Author and contributor Date: Mon, 23 May 2005 08:50:23 +0200 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N6oPji065317 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 23 May 2005, at 07:22, A. Pagaltzis wrote: > In <63190A9C-CA6F-11D9-BDA9-003065EA6144@geckotribe.com> > (), > Antone Roundy suggests: > make atom:author plural > keep atom:contributor > punt bylines to an extension +1 to all I think that makes sense, especially if one thinks that atom could be used for wiki entries, where there being numerous authors is a fact of daily life. Henry From owner-atom-syntax@mail.imc.org Mon May 23 03:03:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24979 for ; Mon, 23 May 2005 03:03: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 j4N6sKU8067941; Sun, 22 May 2005 23:54: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 j4N6sK98067940; Sun, 22 May 2005 23:54:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N6sIIQ067854 for ; Sun, 22 May 2005 23:54:19 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 7305 invoked by uid 10); 23 May 2005 06:54:12 -0000 Received: (vexira-qq 07296-3FF5F7E1 invoked from network) 23 May 2005 08:54:12 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 May 2005 06:54:12 -0000 Message-ID: <42917E28.9090904@annevankesteren.nl> Date: Mon, 23 May 2005 08:54:32 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: some small comments on 08 References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> In-Reply-To: <68fba5c505052211472d755406@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> What happens when it does contain child elements? I think we should >> define that for interoperability. (See HTML for what happens when >> you don't.) This question also applies to the next section. > > No, that's broken. There can be no expectation of interoperability. I think there should be. Authors will try to do it anyway and defined error handling is better than reverse engineering the market leader's error handling. >> For white-space significance text I need to use 'html' or 'xhtml' >> instead using PRE or xhtml:pre? > > I don't understand what you're saying here, but I'm pretty sure every > possible whitespace issue has been debated by Graham, Paul, Martin, > etc. Feel free to try and explain this again if I don't get it. White-space may be collapsed inside 'text' as currently defined. >> * 4.2.2 The "atom:category" Element >> >> Why is significant information hidden in attributes? That is bad >> for i18n and prevents people from defining the expansion of an >> abbreviation, for example. > > Minor flaw. It happens. I think you are rushing things too fast. It would be much better if we fixed this. >> * Links >> >> I don't understand why we have so many different link constructs. >> , iri, >> iri, . >> >> Can't we name them consistently? I'd suggest 'href' or 'url'. >> ('url' is used in CSS and extensions of HTML and XHTML 1 made by >> the WHATWG.) > > Nope. Too late. And this. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 23 03:10:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25280 for ; Mon, 23 May 2005 03:10: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 j4N71ES5072542; Mon, 23 May 2005 00:01: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 j4N71ETT072541; Mon, 23 May 2005 00:01:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N71Cu8072458 for ; Mon, 23 May 2005 00:01:13 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 18846 invoked by uid 10); 23 May 2005 07:01:06 -0000 Received: (vexira-qq 18839-B3FE3F93 invoked from network) 23 May 2005 09:01:06 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 May 2005 07:01:06 -0000 Message-ID: <42917FC6.8020107@annevankesteren.nl> Date: Mon, 23 May 2005 09:01:26 +0200 From: Anne van Kesteren 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: Author and contributor References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> In-Reply-To: <20050523052249.GA31955@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit A. Pagaltzis wrote: > In <63190A9C-CA6F-11D9-BDA9-003065EA6144@geckotribe.com> > (), > Antone Roundy suggests: > • make atom:author plural > • keep atom:contributor > • punt bylines to an extension > > To me that sounds like the simplest thing that can possibly work, > and looks like it hits the 80/20 mark. It also requires the least > squabbling over its implementation. And Robert has expressed that > he is fine with the proposal in that thread. > > I’ve expressed an affinity for the idea of putting atom:category > in atom:contributor, but I see a lot of potential delay in that > and no pressing need for it. > > Again, +1 to Antone’s suggestion. +1. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 23 03:24:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26165 for ; Mon, 23 May 2005 03:24: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 j4N4qoH7098663; Sun, 22 May 2005 21:52: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 j4N4qok1098662; Sun, 22 May 2005 21:52:50 -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 j4N4qner098656 for ; Sun, 22 May 2005 21:52:49 -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 j4N4qn0R000118 for ; Sun, 22 May 2005 22:52:49 -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 <0IGX00H6CEW0KQ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 22 May 2005 22:52:48 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGX00AKHEVZO6@mail.sun.net> for atom-syntax@imc.org; Sun, 22 May 2005 22:52:48 -0600 (MDT) Date: Sun, 22 May 2005 21:52:53 -0700 From: Tim Bray Subject: Author and contributor To: Atom Syntax Message-id: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; 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 We observe a significant amount of discomfort with the current one-author/multiple-contributors model in atom-format. Despite the mentions that Rob dug up, nobody can claim this has had serious in-depth discussion in the IETF context. On the other hand, we note that the current setup does have a coherent logical grounding, namely adopting Dublin Core semantics by identifying a singular primary-creator role and a plural contributor role. If we leave things the way they are, a pointer to this derivation would improve the draft. However, aside from Rob Sayre, nobody has been particularly militant in defending the current setup. Personally I don't think any of the alternatives proposed are going to have fewer corner cases, but quite likely they won't have more either. Unfortunately, among those who want to change the current setup, we do not observe consensus on the subject of what to change them to. Near as we can tell, people want to make atom:author plural, some want to nuke atom:contributor and others don't. If, in the next couple of days, a large number of people can coalesce behind ONE SPECIFIC change to the spec in this area, and there is no significant body of resistance to this change, Paul and I are prepared to be convinced that rough consensus exists for such a change. From owner-atom-syntax@mail.imc.org Mon May 23 03:43:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27094 for ; Mon, 23 May 2005 03:43: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 j4N7aAut095498; Mon, 23 May 2005 00: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 j4N7aA0j095497; Mon, 23 May 2005 00:36:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N7a8ch095416 for ; Mon, 23 May 2005 00:36:09 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050523073602.YXWF12530.mta13-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Mon, 23 May 2005 08:36:02 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050523073602.WAPK18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Mon, 23 May 2005 08:36:02 +0100 Date: Mon, 23 May 2005 08:36:00 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <687135975.20050523083600@djpowell.net> To: "A. Pagaltzis" CC: Atom Syntax Subject: Re: Author and contributor In-Reply-To: <20050523052249.GA31955@klangraum> References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N7a9ch095490 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Monday, May 23, 2005, 6:22:49 AM, A. Pagaltzis wrote: > make atom:author plural +1 in principle... But has anyone addressed how this will inherit - will atom:entry/atom:author merge with the set of authors defined in atom:feed/atom:author or will it replace them? (FYI: PRISM also suggests using plural dc:creator elements when there are multiple primary creators.) > keep atom:contributor +1 (But we should clarify the inheritance rules - if there are any - to avoid confusion with those of atom:author - if there any) > punt bylines to an extension +1 (It could live happily with dateline, or whatever it gets called) -- Dave From owner-atom-syntax@mail.imc.org Mon May 23 03:48:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27291 for ; Mon, 23 May 2005 03:48: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 j4N7eK8l098211; Mon, 23 May 2005 00:40: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 j4N7eK2Q098208; Mon, 23 May 2005 00:40:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N7eJL3098140 for ; Mon, 23 May 2005 00:40:19 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050523074013.BRNA23015.mta05-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>; Mon, 23 May 2005 08:40:13 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta03-winn.mailhost.ntl.com with ESMTP id <20050523074013.SRD2626.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Mon, 23 May 2005 08:40:13 +0100 Date: Mon, 23 May 2005 08:40:11 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <243369026.20050523084011@djpowell.net> To: Robert Sayre CC: Atom Syntax Subject: Re: A different question about atom:author and inheritance In-Reply-To: <68fba5c505052213537f196a3c@mail.gmail.com> References: <866629091.20050522182137@djpowell.net> <68fba5c50505221104306a662c@mail.gmail.com> <1857314093.20050522210143@djpowell.net> <68fba5c505052213537f196a3c@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 Sunday, May 22, 2005, 9:53:23 PM, Robert Sayre wrote: > The draft hasn't changed for more than a month, while Tim and Paul > have been last-calling this thing for months now, and very little of > substance has transpired since then. The document has been quite > stable since March 12th, when format-06 was produced. No, the draft hasn't changed in the last month, but it will do when draft-09 is released. I was talking about the batch of proposals, including PaceAllowDuplicateIDs (a fundamental change), that were accepted 4 days ago. -- Dave From owner-atom-syntax@mail.imc.org Mon May 23 04:26:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01730 for ; Mon, 23 May 2005 04:26: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 j4N8GBQd012507; Mon, 23 May 2005 01:16: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 j4N8GBmt012506; Mon, 23 May 2005 01:16: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N8GAmI012461 for ; Mon, 23 May 2005 01:16:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 08:16:04 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp032) with SMTP; 23 May 2005 10:16:04 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 10:19:39 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Author and contributor Message-ID: <20050523081939.GA1217@klangraum> Mail-Followup-To: Atom Syntax References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> <687135975.20050523083600@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <687135975.20050523083600@djpowell.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: 8bit * David Powell [2005-05-23 09:45]: > > • make atom:author plural > > +1 in principle... > > But has anyone addressed how this will inherit - will > atom:entry/atom:author merge with the set of authors defined in > atom:feed/atom:author or will it replace them? Merging is easy to express in terms of replacement: you simply repeat the subset of shared authors. Replacement is not expressible in terms of merging; we would need a mechanism to indicate an deviation from merging semantics. Merging would also be inherently slightly more complex to implement in consumers, and would be additionally more complex to implement because it requires support for whichever mechanism indicates replacement. It could also require extra complexity to support at the producer level. So my opinion is clearly: replace. It’s simpler to specify, simpler to implement, and it doesn’t lose any expressiveness. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 04:26:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01756 for ; Mon, 23 May 2005 04:26: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 j4N8E6Ye011769; Mon, 23 May 2005 01:14: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 j4N8E6WY011768; Mon, 23 May 2005 01:14: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.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N8E5N2011731 for ; Mon, 23 May 2005 01:14:06 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so416733nzo for ; Mon, 23 May 2005 01:14:00 -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=sNtHPUdeugs5cAPmHAP0xIvPcT2dspgtX4S7aPzA4ZM0Y+sRW5tw9rfg4Xk2Bo4t2nOV6VI7QLAFTVdXYhXBVXbc2jUo7xzjCo9YSGe+0XUfUdvG3ZWYTutPR1FTGDU5V9/0pa5yyiAoMUrUXol0nCZJumjEEBcewUVwPdvBbhI= Received: by 10.36.109.18 with SMTP id h18mr1241389nzc; Mon, 23 May 2005 01:14:00 -0700 (PDT) Received: by 10.36.50.4 with HTTP; Mon, 23 May 2005 01:14:00 -0700 (PDT) Message-ID: <1f2ed5cd0505230114e3f1382@mail.gmail.com> Date: Mon, 23 May 2005 10:14:00 +0200 From: Danny Ayers Reply-To: Danny Ayers To: atom-syntax@imc.org Subject: atom:type, xsl:output 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 j4N8E6N2011762 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit [forwarding for Jimmy, he's having mail problems] From: Jimmy Cerra I'm a little confused by the type attribute for atom:content and other elements. This the following correct? * When @type="html" then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or "nonstandard" HTML (like with marquee elements)? * When @type="xhtml" then the content of the element is a xhtml:div XML fragment plus optional insignificant whitespace around it. Again which version of XHTML is defined? How do you differentiate between XHTML 1.0, 1.1, or 2.0? Since XHTML 2.0 may have a new namespace, so will you allow that? How does requiring XHTML:div impact which XHTML modules are required (I have a guess)? And what about exotic versions like "XHTML+MathML+SVG" or "XHTML 1.1 plus MathML 2.0"? (Some blogs actually use it "XHTML 1.1 plus MathML 2.0"!) * When @type="text" then the content of the element is a xsd:string of a text/plain document. * When @type="mime/type" [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? What about content that isn't compatible with XML 1.0 (like XML 1.1, Turtle, RTF, PNG); should it be entity encoded/put into cdata section like HTML? What should one do when encountering these situations? Does that mean that if you use "application/xhtml+xml", you can do (rest of feed omitted for brevity): ... ... How do you specify xml-stylesheets processing instructions, doctype and xml declarations, and other data about the content? PIs may be a non-issue if they are not read by the XML processor for the Atom feed; although, that isn't guaranteed. I think you should at least allow @type="xml", as others have suggested for xml 1.0 content, along with adopting XSLT's output attributes (perhaps not using @method or @media-type). This would ease the pain with XML, and all media/types for @type require the content to be xsd:string valid (that is, entity encoded or using CDATA sections). Sorry for the boatload of questions. -- Jimmy Cerra http://pawsgroup.blogspot.com [1] That is, a text node in the XML tree. [2] A mime type, noting the exception in 4.1.3.1. From owner-atom-syntax@mail.imc.org Mon May 23 04:31:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01924 for ; Mon, 23 May 2005 04:31: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 j4N8N321015410; Mon, 23 May 2005 01:23: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 j4N8N3Ew015409; Mon, 23 May 2005 01:23:03 -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 j4N8N2XH015362 for ; Mon, 23 May 2005 01:23:02 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 08:22:56 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp025) with SMTP; 23 May 2005 10:22:56 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 10:26:32 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: some small comments on 08 Message-ID: <20050523082632.GB1217@klangraum> Mail-Followup-To: Atom Syntax References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42917E28.9090904@annevankesteren.nl> 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: * Anne van Kesteren [2005-05-23 09:05]: > Robert Sayre wrote: > >>For white-space significance text I need to use 'html' or > >>'xhtml' instead using PRE or xhtml:pre? > > > >I don't understand what you're saying here, but I'm pretty > >sure every possible whitespace issue has been debated by > >Graham, Paul, Martin, etc. Feel free to try and explain this > >again if I don't get it. > > White-space may be collapsed inside 'text' as currently > defined. Last I asked, I understood that whitespace would be preserved if you supply 'text/plain' content; @type='text' is more like inline text in an XML document (or in HTML). Maybe the spec could be more explicit about that, though. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 04:37:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02181 for ; Mon, 23 May 2005 04:37: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 j4N8SFY9018001; Mon, 23 May 2005 01:28: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 j4N8SFGm018000; Mon, 23 May 2005 01:28:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N8SD42017953 for ; Mon, 23 May 2005 01:28:14 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 3011 invoked by uid 10); 23 May 2005 08:28:07 -0000 Received: (vexira-qq 02999-244726E6 invoked from network) 23 May 2005 10:28:07 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 May 2005 08:28:07 -0000 Message-ID: <4291942B.8070308@annevankesteren.nl> Date: Mon, 23 May 2005 10:28:27 +0200 From: Anne van Kesteren 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: some small comments on 08 References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> <20050523082632.GB1217@klangraum> In-Reply-To: <20050523082632.GB1217@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: >> White-space may be collapsed inside 'text' as currently defined. > > Last I asked, I understood that whitespace would be preserved if you > supply 'text/plain' content; @type='text' is more like inline text in > an XML document (or in HTML). Maybe the spec could be more explicit > about that, though. However, text/plain is not allowed everywhere where 'text' is allowed. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon May 23 04:54:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03262 for ; Mon, 23 May 2005 04:54: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 j4N8jCac025710; Mon, 23 May 2005 01:45: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 j4N8jCfm025709; Mon, 23 May 2005 01:45:12 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N8jBjt025635 for ; Mon, 23 May 2005 01:45:11 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-105.dti.cegetel.net [217.19.192.105]) by smtp.cegetel.net (Postfix) with SMTP id 9090C318399; Mon, 23 May 2005 10:45:05 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Mon, 23 May 2005 10:45:05 +0200 (CEST) Message-ID: <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> Date: Mon, 23 May 2005 10:45:05 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: In-Reply-To: <20050523004203.GA30042@klangraum> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> 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 A. Pagaltzis wrote: > > * Anne van Kesteren [2005-05-22 11:35]: >> * 4.1.3.1 The "type" attribute >> >> Can I circumvent the DIV element by using the media type of >> XHTML? (I really dislike this combined construct by the way.) > > I used to find it extremely horrible. Now I’m not sure. > > There is some symmetry here: with @type="xml", you have to Which @type="xml"? Did you mean @type="text/xml"? > enclose a full XML document, which will always have a root > element. The pseudo-XHTML DIV required for @type="xhtml" makes > XHTML fragments behave the same way. With the difference that this div is not part of the content. > I don’t know if I like it. I don’t know if it’s a good solution. > But it is consistent on some level, at least. It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in "Consensus call on last raft of issues" [1] [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 05:27:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07119 for ; Mon, 23 May 2005 05:27: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 j4N9JQcn040610; Mon, 23 May 2005 02:19: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 j4N9JQD5040609; Mon, 23 May 2005 02:19:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N9JNNk040559 for ; Mon, 23 May 2005 02:19:24 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4N9JH709758; Mon, 23 May 2005 18:19:17 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 1c01ed7c_cb6d_11d9_95e1_0030482532aa_2152; Mon, 23 May 2005 18:29:06 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00047E; 23 May 05 18:22:28 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 23 May 05 18:22:13 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.53) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00047D; 23 May 05 18:22:10 +0900 Message-Id: <6.0.0.20.2.20050523181736.0882e030@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 23 May 2005 18:18:42 +0900 To: Anne van Kesteren , Robert Sayre From: Martin Duerst Subject: Re: 4.2.7.1 Comparing atom:id Cc: Atom Syntax In-Reply-To: <42903044.2090805@annevankesteren.nl> References: <428F94A2.7030206@annevankesteren.nl> <428FA47B.6040707@annevankesteren.nl> <68fba5c50505211435c90d34d@mail.gmail.com> <42903044.2090805@annevankesteren.nl> 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 16:09 05/05/22, Anne van Kesteren wrote: > >Robert Sayre wrote: >> I think the last paragraph of RFC3987, section 5.1 already says that :) >> http://rfc.net/rfc3987.html#s5.1. > >That also says that fragment components should be excluded. Is that true for Atom? It says: When IRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison. IDs are just identifiers, not used for network action, so this doesn't apply. Regards, Martin. >Are we going to refer to that specification and that section from 4.2.7.1 in a future draft? > > >-- > Anne van Kesteren > > From owner-atom-syntax@mail.imc.org Mon May 23 05:38:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08364 for ; Mon, 23 May 2005 05:38: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 j4N9WQWK045146; Mon, 23 May 2005 02:32: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 j4N9WQb2045144; Mon, 23 May 2005 02:32: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 j4N9WPE4045095 for ; Mon, 23 May 2005 02:32:25 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 09:32:19 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp026) with SMTP; 23 May 2005 11:32:19 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 11:35:56 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: some small comments on 08 Message-ID: <20050523093556.GA1546@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.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: 8bit * Thomas Broyer [2005-05-23 10:50]: > A. Pagaltzis wrote: > > There is some symmetry here: with @type="xml", you have to > > Which @type="xml"? Did you mean @type="text/xml"? Sorry, I meant any XML media type. > > enclose a full XML document, which will always have a root > > element. The pseudo-XHTML DIV required for @type="xhtml" > > makes XHTML fragments behave the same way. > > With the difference that this div is not part of the content. Ah! Good catch. > > I don’t know if I like it. I don’t know if it’s a good > > solution. But it is consistent on some level, at least. > > It is not, not at all. > > To everyone here: please, comment on PaceOptionalXhtmlDiv, > either +1 or -1, but at least argument. I was leaning +1 and almost voted that way when you posted the Pace, but I was not sure if I had enough of the picture so I abstained at the time. I’m still not firmly convinced (and intermittently thought maybe it was not so bad to keep the DIV, see above), but I’m still don’t see that it really is necessary. In particular, I don’t see why mandating the pseudo-XHTML DIV is a better solution than promoting correct implementation by way of good examples, which you argued in that thread as well. So +1, absent an overwhelming example that people are more likely to get their namespaces wrong than right. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 05:40:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08493 for ; Mon, 23 May 2005 05:40: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 j4N9Vhs2044882; Mon, 23 May 2005 02:31: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 j4N9VhDL044881; Mon, 23 May 2005 02:31:43 -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 j4N9VfUs044841 for ; Mon, 23 May 2005 02:31:42 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 23 May 2005 09:31:35 -0000 Received: from p508F9586.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.149.134] by mail.gmx.net (mp027) with SMTP; 23 May 2005 11:31:35 +0200 X-Authenticated: #1915285 Message-ID: <4291A2F2.6030306@gmx.de> Date: Mon, 23 May 2005 11:31:30 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: pagaltzis@gmx.de, atom-syntax@imc.org Subject: Re: some small comments on 08 References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> In-Reply-To: <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.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 Thomas Broyer wrote: > It is not, not at all. > > To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or > -1, but at least argument. See also further explanation and technical > arguments in "Consensus call on last raft of issues" [1] > ... For the record: I am +1 on . Best regards, Julian From owner-atom-syntax@mail.imc.org Mon May 23 05:47:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09092 for ; Mon, 23 May 2005 05: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 j4N9aUkb046519; Mon, 23 May 2005 02:36: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 j4N9aUmj046516; Mon, 23 May 2005 02:36:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N9aS7Q046475; Mon, 23 May 2005 02:36:29 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j4N9aN711052; Mon, 23 May 2005 18:36:23 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 7f26c790_cb6f_11d9_9a8c_0030482532aa_2151; Mon, 23 May 2005 18:46:11 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00048B; 23 May 05 18:39:33 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 23 May 05 18:39:06 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.53) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000489; 23 May 05 18:38:59 +0900 Message-Id: <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 23 May 2005 18:35:34 +0900 To: Thomas Broyer , atom-syntax@imc.org From: Martin Duerst Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) Cc: atom-protocol@imc.org In-Reply-To: <428FB78D.9000401@cegetel.net> References: <428FB78D.9000401@cegetel.net> 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 Hello Thomas, At 07:34 05/05/22, Thomas Broyer wrote: > >I'm sorry to raise this "issue" back again but... > >The Atom Publishing Protocol defines SOAP bindings. This (in my mind) means there will be WSDL files over there. WSDL rely on XML Schema which in turn are limited to deterministic content models. > >Will the APP limit "Atom entries in SOAP envelopes" content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? > >Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? Are you speaking about potential non-determinism or actual non-determinism? Is such non-determinism in the core of the Atom format, in potential extensions, or in payloads (e.g. XHTML,...)? If there is actual non-determinism now in the Atom core, that would be a reason for concern. If there is potential non-determinism in the payloads or extensions, it should be possible to handle that by a more open content model in XML Schema. Regards, Martin. From owner-atom-syntax@mail.imc.org Mon May 23 05:49:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09209 for ; Mon, 23 May 2005 05:49: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 j4N9Z5BT046034; Mon, 23 May 2005 02:35: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 j4N9Z5C2046033; Mon, 23 May 2005 02:35:05 -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 j4N9Z5Vm046024 for ; Mon, 23 May 2005 02:35:05 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 48343 invoked by uid 17064); 23 May 2005 09:35:04 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.139.251]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 23 May 2005 09:35:04 -0000 In-Reply-To: References: <200505220353.DFI38435@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30E80A7D-A40D-48CE-83EC-28CFE2C070B2@bblfish.net> Cc: Tim Bray , Bob Wyman , "A. Pagaltzis" Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: updated and modified yet again Date: Mon, 23 May 2005 11:35:01 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 May 2005, at 06:29, Tim Bray wrote: > > News flash! Bob and I agree! I have been following this discussion and am finding I am also agreeing with Tim, Bob and Aristotle P. The points are subtle. This made me wonder if the points are not playing themselves out a different level. Perhaps the problem is that we are not clear about the difference between semantics and what is being said. At the level of semantics an entry as identified by its id has a number of dated representations. These representations can be grouped in different ways according to different identity criteria. One very precise such identity criteria would be string identity. Two representations are identical if they are character by character identical. Another identity criteria, lets call it update identity, says that two such representations are equivalent if they have the same atom:updated time stamp. This is a very vague identity criterion, which leaves it up to the interaction between users and consumers to set constraints on the criterion. The user has to face the fact that consumers may drop some of his changes (conceived of as changes under the criterion of string identity) if he does not change the date. So let us think of this from the point of view of the three players in this game: the original publisher, the final consumer, and the intermediary. The original publisher ---------------------- When the publisher is the same person as the person defining the identity criteria, then it makes sense that he should not publish two entries in a feed that are identical according to his own criteria. This can not be conceived to be a restriction on him. The final consumer ------------------ The final consumer may have different identity criteria to the publisher of the feed, but since he is not the one to publish the feed there is not much for him to do. He cannot force the original publisher to be more precise, because that would be to ask the person who is publishing to see a distinction where he sees none. And this does not even take into account that other consumers may disagree with him anyhow. The aggregator -------------- The problematic case comes from those aggregating feeds. And I think here I can identify two different problems: a- The aggregator may say he has different identity criteria from the publisher. If he has then one can simply answer: your business is to be transparent, not to place yourself in between your user and his public. b- The aggregator wants to be completely transparent. But has a problem because he is not sure who to trust, and different people are making different claims about the same thing (the id). In everyday life there is a well known method for doing this honestly: we quote the source of who said what. If Smith says that the red car is his and John says that the car is his, I don't need to say that the car belongs to Smith and to John, I can just say "Smith says that 'the car is his' and John says that 'the car is his'". I just need to quote what others have said. If this is the problem faced by Bob then I don't think atom:modified is going to help. That would be being precise in the wrong place. What would have helped was perhaps the solution proposed by Roy Fielding a few months ago, namely that a feed should be able to contain a feed. Bob's pub sub service would then be just able to quote what others (feeds) have said. It would then have been correct to hold the position currently held that no feed should *directly* contain an entry with the same atom:updated value. It would allow that a feed could contain two feeds each with different entries containing the same id and the same atom:updated time stamp. It would then be up to the consumer to decide which one it trusts. Henry Story From owner-atom-syntax@mail.imc.org Mon May 23 05:50:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09281 for ; Mon, 23 May 2005 05:50: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 j4N9cFUK046914; Mon, 23 May 2005 02:38: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 j4N9cFnW046913; Mon, 23 May 2005 02:38:15 -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 j4N9cE3c046873 for ; Mon, 23 May 2005 02:38:14 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 09:38:08 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp011) with SMTP; 23 May 2005 11:38:08 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 11:41:45 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: some small comments on 08 Message-ID: <20050523094145.GB1546@klangraum> Mail-Followup-To: Atom Syntax References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> <20050523082632.GB1217@klangraum> <4291942B.8070308@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4291942B.8070308@annevankesteren.nl> 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: 8bit * Anne van Kesteren [2005-05-23 10:35]: > A. Pagaltzis wrote: > >Last I asked, I understood that whitespace would be preserved > >if you supply 'text/plain' content; @type='text' is more like > >inline text in an XML document (or in HTML). Maybe the spec > >could be more explicit about that, though. > > However, text/plain is not allowed everywhere where 'text' is > allowed. True. But it seems reasonable to tell people they shouldn’t stick content with significant linebreaks and whitespace into their titles? Not that I have any strong position about this; it just seems to make sense. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 05:53:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09428 for ; Mon, 23 May 2005 05:53: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 j4N9jHRv049327; Mon, 23 May 2005 02:45: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 j4N9jHQ9049326; Mon, 23 May 2005 02:45:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4N9jGDX049289 for ; Mon, 23 May 2005 02:45:17 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4N9hroP021127; Mon, 23 May 2005 10:44:04 +0100 (BST) In-Reply-To: <1f2ed5cd0505230114e3f1382@mail.gmail.com> References: <1f2ed5cd0505230114e3f1382@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: atom:type, xsl:output Date: Mon, 23 May 2005 10:43:53 +0100 To: Danny Ayers X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 9:14 am, Danny Ayers wrote: > * When @type="html" then the content of the element is a xsd:string > [1] of an HTML DIV element plus optional insignificant whitespace > around it. Which version of HTML is defined? How do you > differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or > "nonstandard" HTML (like with marquee elements)? I believe the answer would be "street HTML", not any specific version. > * When @type="mime/type" [2], ONLY for atom:content, then the content > (or src document) is that type of document. Why not allow other > elements to use this? Because the other elements are for purely textual content. > XML 1.1 Not supported. > Turtle Don't know. > RTF It is compatible, as a string, though certain obsolete characters are not. > PNG Should be base64 encoded. > What should one do when encountering these situations? See section 4.1.3.3 Processing Model > Does that mean that if you use "application/xhtml+xml", you can do > (rest of feed omitted for brevity): Yes. This is why we have a special XHTML mode for fragments. Graham From owner-atom-syntax@mail.imc.org Mon May 23 05:53:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09454 for ; Mon, 23 May 2005 05: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 j4N9hgp5048771; Mon, 23 May 2005 02:43: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 j4N9hgxj048770; Mon, 23 May 2005 02:43:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4N9heXa048740 for ; Mon, 23 May 2005 02:43:41 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000423842 for ; Mon, 23 May 2005 19:43:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 23 May 2005 19:43:34 +1000 Subject: spec text regarding feed/entry inheritance From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4N9hfXa048763 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The question of inheritance of author/contributor from feed into entry needs to be disambiguated. I looked from the format-08 text and found that we already have reasonable wording in section 4.2.4 (The "atom:copyright" Element). There is also a hint in section 4.2.11 (The "atom:source" Element) that some other elements should also be inheritable. Proposal: insert text similar to 4.2.4 3 into 4.2.1 The "atom:author" Element 4.2.2The "atom:category" Element 4.2.3 The "atom:contributor" Element ------------------------- some relevant snippets ------------------------- 4.2.4The "atom:copyright" Element > If an atom:entry element does not contain an atom:copyright element, > then the atom:copyright element of the containing atom:feed element's > atom:head element, if present, is considered to apply to the entry. 4.1.2The "atom:entry" Element > atom:entry elements MUST contain exactly one atom:author element, > unless the atom:entry contains an atom:source element which contains > an atom:author element, or, in an Atom Feed Document, the atom:feed > element contains an atom:author element itself. ... but that doesn't explain that the atom:entry inherits the author from the feed. It actually suggests that an entry may be author-less, because the spec text for atom:author only says this: 4.2.11 The "atom:source" Element > Such metadata SHOULD be preserved if the source atom:feed contains any > of the child elements atom:author, atom:contributor, atom:copyright, or > atom:category and those child elements are not present in the source > atom:entry. ... which calls out atom:category in the same sentence as atom:author, atom:contributor, and atom:copyright ... which might suggest that atom:category should also be inherited. I don't recall what the thinking was, but I'd +1 inheritance of atom:category from atom:feed into atom:entry. e. From owner-atom-syntax@mail.imc.org Mon May 23 06:04:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09913 for ; Mon, 23 May 2005 06:04: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 j4N9uLoL053195; Mon, 23 May 2005 02:56: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 j4N9uLdA053194; Mon, 23 May 2005 02:56: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 j4N9uJZq053163 for ; Mon, 23 May 2005 02:56:19 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 495AD4F57E; Mon, 23 May 2005 05:56:18 -0400 (EDT) Date: Mon, 23 May 2005 05:56:18 -0400 From: Dan Brickley To: Eric Scheid Cc: Atom Syntax Subject: Re: Author and contributor Message-ID: <20050523095618.GB4431@homer.w3.org> References: <20050523052249.GA31955@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Eric Scheid [2005-05-23 15:48+1000] > > On 23/5/05 3:22 PM, "A. Pagaltzis" wrote: > > > Antone Roundy suggests: > > +1 make atom:author plural > > +1 keep atom:contributor > > punt bylines to an extension > > > > To me that sounds like the simplest thing that can possibly work, > > and looks like it hits the 80/20 mark. It also requires the least > > squabbling over its implementation. And Robert has expressed that > > he is fine with the proposal in that thread. > > > > Again, +1 to Antones suggestion. > > +1,+1, and +1 from me too. +1, +1, +.5 from me BTW, and aside re Dublin Core semantics, DC allows all DC terms to be repeated, including 'creator'; the definition is given in http://dublincore.org/documents/dcmi-terms/ "An entity primarily responsible for making the content of the resource." with the notes "Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.". It says 'an entity' rather than 'the entity'. 'Primarily' might suggest one rather than many, but the notion of multiple entities being 'jointly first' in their responsibility for making the content seems to sneak us out of that one. Dublin Core has a group on Agents, see http://dublincore.org/groups/agents/ ...at the last Dublin Core Advisory Board meeting I said I'd try to get FOAF measured up against their functional requirements doc, http://rdfweb.org/pipermail/rdfweb-dev/2004-October/013820.html ...probably time to revisit that discussion. Also worth noting in that regard is that there are different idioms for deploying dc:creator (sometimes as a relationship to a string, sometimes as a relationship to an Agent of some kind) in RDF; http://danbri.org/words/?p=63 was an experiment in making explicit rules for mapping between them. Dan > > Ive expressed an affinity for the idea of putting atom:category > > in atom:contributor, but I see a lot of potential delay in that > > and no pressing need for it. > > seeing as that proposal was my idea, and despite no technical objections to > it, I'm happy to withdraw it just so atom:author can get through the process > hoops. > > e. > From owner-atom-syntax@mail.imc.org Mon May 23 06:11:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10457 for ; Mon, 23 May 2005 06:11: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 j4NA5JVD057038; Mon, 23 May 2005 03:05: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 j4NA5J8g057037; Mon, 23 May 2005 03:05:19 -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 j4NA5IB2057027 for ; Mon, 23 May 2005 03:05:18 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id CBC794F635; Mon, 23 May 2005 06:05:17 -0400 (EDT) Date: Mon, 23 May 2005 06:05:17 -0400 From: Dan Brickley To: Eric Scheid Cc: Atom Syntax Subject: Re: spec text regarding feed/entry inheritance Message-ID: <20050523100517.GC4431@homer.w3.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Eric Scheid [2005-05-23 19:43+1000] > > > The question of inheritance of author/contributor from feed into entry needs > to be disambiguated. Yup. Is anybody working on a set of AtomPub test cases? That strikes me as a clear an implementor-friendly way of exploring corner cases here. It really helped us a huge amount at W3C when cleaning up the RDF and RDFS specs in the RDFCore WG, btw --- especially when working out what bits of data we considered as 'implied by the spec' given other data as input. http://www.w3.org/TR/rdf-testcases/ describes the manifest format we used, and the way test cases are linked to the WG's issue list. In Atom, re inheritance, it'd be great just having a collection of pairs of Atom docs, and a flag to say whether the first can be considered implied (eg. by inheritance rules) from the second. Maybe such a thing could live in the Wiki? Dan ps. is it only built-in properties from the Atom ns that can be inherited? Or extensions too? From owner-atom-syntax@mail.imc.org Mon May 23 06:13:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10569 for ; Mon, 23 May 2005 06:13: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 j4NA4YnR056631; Mon, 23 May 2005 03:04: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 j4NA4YYr056625; Mon, 23 May 2005 03:04: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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NA4UXJ056567; Mon, 23 May 2005 03:04:31 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-103.dti.cegetel.net [217.19.192.103]) by smtp.cegetel.net (Postfix) with SMTP id BD8113181B2; Mon, 23 May 2005 12:04:21 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Mon, 23 May 2005 12:04:24 +0200 (CEST) Message-ID: <1325.82.127.77.43.1116842664.squirrel@ssl-webmail.sitadelle.com> Date: Mon, 23 May 2005 12:04:24 +0200 (CEST) Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) From: "Thomas Broyer" To: In-Reply-To: <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> References: <428FB78D.9000401@cegetel.net> <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> 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 Martin Duerst wrote: > At 07:34 05/05/22, Thomas Broyer wrote: > > > >I'm sorry to raise this "issue" back again but... > > > >The Atom Publishing Protocol defines SOAP bindings. This (in my mind) > >means there will be WSDL files over there. WSDL rely on XML Schema > >which in turn are limited to deterministic content models. > > > >Will the APP limit "Atom entries in SOAP envelopes" content model to > >fit WSDL/XML Schema constraints (actually, the APP will already need > >to limit Atom entries to have a mandatory atom:content I think)? > > > >Or should the Atom Syndication Format use deterministic content models > >to allow XML Schema, thus such uses as WSDL for Web Services? > > Are you speaking about potential non-determinism or actual > non-determinism? Atom core uses interleaved content models, which are not "compatible" with XML Schema (or DTD). I call them "non-deterministic". I know that RelaxNG as well as other schema languages have been created partly because of this limitation of XML Schema, though I don't think we need interleaving in the case of Atom. If Atom aim to be used on devices/systems with small capabilities, having a "clear" content model makes the parsing easier, e.g. using a state machine based on SAX. The SOAP->WSDL->XML Schema is another approach of the problem, which is more likely to b a big concern as it is part of Atom (here, the protocol) > Is such non-determinism in the core of the Atom format, > in potential extensions, or in payloads (e.g. XHTML,...)? Payloads will most likely be parsed as "black boxes" to retrieve XML document fragments or the "raw XML" as string. Extensions are a concern but as they're part of core (hey, they are extensions ;o) ) Atom processors might just skip them. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 06:49:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12434 for ; Mon, 23 May 2005 06:49: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 j4NAg2U4070293; Mon, 23 May 2005 03: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 j4NAg21s070292; Mon, 23 May 2005 03:42:02 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NAg1d4070279 for ; Mon, 23 May 2005 03:42:01 -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 1DaANk-0002k7-00; Mon, 23 May 2005 11:42:00 +0100 Date: Mon, 23 May 2005 11:42:00 +0100 From: James Aylett To: Atom Syntax Subject: Re: Author and contributor Message-ID: <20050523104200.GP24523@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <20050523052249.GA31955@klangraum> <20050523095618.GB4431@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050523095618.GB4431@homer.w3.org> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, May 23, 2005 at 05:56:18AM -0400, Dan Brickley wrote: > > > Antone Roundy suggests: > > > +1 make atom:author plural > > > +1 keep atom:contributor > > > punt bylines to an extension > > +1, +1, +.5 from me +1, +.5, +.5 from me. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 06:49:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12480 for ; Mon, 23 May 2005 06: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 j4NAgG9a070405; Mon, 23 May 2005 03:42: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 j4NAgGUK070404; Mon, 23 May 2005 03:42:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NAgFuO070344 for ; Mon, 23 May 2005 03:42:15 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NAdb38026805 for ; Mon, 23 May 2005 11:39:43 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax From: Graham Subject: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 11:39:38 +0100 X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor == Abstract == Allow multiple authors. Clarify relationship between atom:author and atom:contributor. == Status == Open == Rationale == The current draft only allows one atom:author per entry, meaning either: - All authors of a document have to be shoehorned into that atom:author element - One author has to be chosen as primary and the rest are "contributors" Secondly, no explicit relationship is given between author and contributor atom:contributor. The most intuitive approach, and that outlined in this pace, is that each person involved should only appear in one role (as an author, or as a contributor). Also, for the sake of making processing at the display end easier, each person should only be mentioned once. == Notes == Neither bylines nor inheritance are dealt with by this Pace. == Proposal == In 4.1.1, replace: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. with: o atom:feed elements MUST contain one or more atom:author elements, UNLESS all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Remove: o atom:feed elements MUST NOT contain more than one atom:author element. In 4.1.2, replace: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. With: o atom:entry elements MUST contain one or more atom:author elements, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. Remove: o atom:entry elements MUST NOT contain more than one atom:author element. Add: o Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. == Impacts == Listing several people in a single atom:author element and then crediting them individually as atom:contributors is consciously barred by this pace, in anticipation that a separate byline element may be introduced if the functionality is required. ---- CategoryProposals From owner-atom-syntax@mail.imc.org Mon May 23 07:29:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15477 for ; Mon, 23 May 2005 07:29: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 j4NBFIoJ082292; Mon, 23 May 2005 04:15: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 j4NBFIX6082291; Mon, 23 May 2005 04:15: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.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NBFGXF082250 for ; Mon, 23 May 2005 04:15:17 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3394679wra for ; Mon, 23 May 2005 04:15:11 -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=PzH5EOGSj36H4gZzHAAGUfapLj0ZrRwsWGVPEdNdgI+g3luJ7hW+f/BCCPY9Uo5LCWRdk88L5j1XNfS+dxHQ8T8skZmO5AHZ5WDbC+bwA5AxGU/HkDX/3KvXIE2cemaE1jrV7/fNXUL/TjedE0fDPpJOe2c/vU0pfHwjro0LxJs= Received: by 10.54.107.4 with SMTP id f4mr3409590wrc; Mon, 23 May 2005 04:15:10 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 04:15:10 -0700 (PDT) Message-ID: <68fba5c505052304155d352b7e@mail.gmail.com> Date: Mon, 23 May 2005 07:15:10 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: atom-syntax In-Reply-To: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NBFHXF082283 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > Add: > o Within the atom:author and atom:contributor elements an > atom:entry contains, > any single Person SHOULD NOT be mentioned more than once. > > == Impacts == > > Listing several people in a single atom:author element and then > crediting them individually as atom:contributors is consciously > barred by this pace, in anticipation that a separate byline element > may be introduced if the functionality is required. -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. -1 to "atom:byline", should anyone propose it. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 07:31:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15609 for ; Mon, 23 May 2005 07:31: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 j4NBMjXS086579; Mon, 23 May 2005 04: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 j4NBMi23086578; Mon, 23 May 2005 04:22:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NBMhxx086522 for ; Mon, 23 May 2005 04:22:44 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NBKcRe020893; Mon, 23 May 2005 12:20:43 +0100 (BST) In-Reply-To: <68fba5c505052304155d352b7e@mail.gmail.com> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 12:20:38 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 12:15 pm, Robert Sayre wrote: > -1 to this part. Why would you bar it? There is no right answer, so > just let it be looser. Because we have to have this line: > Within the atom:author and atom:contributor elements an atom:entry > contains, any single Person SHOULD NOT be mentioned more than once. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. Please describe a suitable algorithm if you wish to remove this constraint. Graham From owner-atom-syntax@mail.imc.org Mon May 23 07:36:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15974 for ; Mon, 23 May 2005 07:36: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 j4NBMJ2t086333; Mon, 23 May 2005 04:22: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 j4NBMJ9Q086332; Mon, 23 May 2005 04:22:19 -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 j4NBMIg6086275 for ; Mon, 23 May 2005 04:22:18 -0700 (PDT) (envelope-from danny.ayers@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so464892nzo for ; Mon, 23 May 2005 04:22: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QBwnUnlKlpGpFG86u0pTpPwyb76iSMAKM1/mb/8SkMShQ7a+c5Ofomf+4kyKyogCNvyDYX9ETa9frn4oSt30cttuKuzRUYoXQROxsO/fuaUZJvqztNa+Qe3FCsVaoMyLx7jxEw14aN/O1M92bkpbvSEIdqaSiqWIMBtMsHaSrNs= Received: by 10.36.129.12 with SMTP id b12mr19113nzd; Mon, 23 May 2005 04:22:13 -0700 (PDT) Received: by 10.36.50.4 with HTTP; Mon, 23 May 2005 04:22:13 -0700 (PDT) Message-ID: <1f2ed5cd05052304225c93ef93@mail.gmail.com> Date: Mon, 23 May 2005 13:22:13 +0200 From: Danny Ayers Reply-To: Danny Ayers To: Atom Syntax Subject: Re: Author and contributor In-Reply-To: <20050523104200.GP24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050523052249.GA31955@klangraum> <20050523095618.GB4431@homer.w3.org> <20050523104200.GP24523@tartarus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NBMJg6086324 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I'm not 100% convinced of the need for contributor, but in the interests of consensus: +1 make atom:author plural +1 keep atom:contributor +1 punt bylines to an extension Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Mon May 23 07:39:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16109 for ; Mon, 23 May 2005 07:39: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 j4NBScNc089107; Mon, 23 May 2005 04:28: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 j4NBScTP089106; Mon, 23 May 2005 04:28: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.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NBSa3X089006 for ; Mon, 23 May 2005 04:28:36 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3400210wra for ; Mon, 23 May 2005 04:28: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=bkgBLRQcbraXeq2uRnCfeQTrlupTeOjti4GxvDvsy0CehfZFp0u0YvvIvtPWTcng2twAOdISMJX4TajRWSUReIX7C4hDGw92bfFl3MD2gPfD1WdIULW1V2qQcEAG1RYNnA88efnLGQ6g+IDOXvMhpc4NTPNEVDZK1W4+eEDjOpQ= Received: by 10.54.41.42 with SMTP id o42mr2797031wro; Mon, 23 May 2005 04:28:31 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 04:28:31 -0700 (PDT) Message-ID: <68fba5c50505230428172218ed@mail.gmail.com> Date: Mon, 23 May 2005 07:28:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NBSb3X089094 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > On 23 May 2005, at 12:15 pm, Robert Sayre wrote: > > > -1 to this part. Why would you bar it? There is no right answer, so > > just let it be looser. > > Because we have to have this line: > > > Within the atom:author and atom:contributor elements an atom:entry > > contains, any single Person SHOULD NOT be mentioned more than once. That's what I'm -1 on. > Anything looser makes it very hard to interpret the intended meaning > of a set of atom:author and atom:contributor elements > programmatically. What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say "otherwise it would be hard". > Please describe a suitable algorithm if you wish to > remove this constraint. You get N authors and N contributors. The "Person" rule is terrible overspecification. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 07:47:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16716 for ; Mon, 23 May 2005 07:47: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 j4NBfMLh093901; Mon, 23 May 2005 04:41: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 j4NBfLlt093900; Mon, 23 May 2005 04:41:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NBfLa7093860 for ; Mon, 23 May 2005 04:41:21 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NBdheN001733; Mon, 23 May 2005 12:39:43 +0100 (BST) In-Reply-To: <68fba5c50505230428172218ed@mail.gmail.com> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 12:39:41 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 12:28 pm, Robert Sayre wrote: > What is the interop problem you are trying to avoid? You don't just > throw in a SHOULD NOT and say "otherwise it would be hard". With the line in place, generating a basic byline is as simple as: print "by "' foreach (atom:author) print atom:author.name; if (count(atom:contributor)) { print "with contributions from "; foreach (atom:contributor) print atom:contributor.name; } Without that line, the code has to do duplicate detection (including looking for a name in a list of names, that may be formatted differently). It is impossible to do this with 100% reliably. Hence the SHOULD NOT. Graham From owner-atom-syntax@mail.imc.org Mon May 23 07:51:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16984 for ; Mon, 23 May 2005 07:51: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 j4NBf47q093800; Mon, 23 May 2005 04:41: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 j4NBf4GU093798; Mon, 23 May 2005 04:41:04 -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 j4NBf3BH093758 for ; Mon, 23 May 2005 04:41:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3405749wra for ; Mon, 23 May 2005 04:40: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=hXK5txn4AydI2O3RjRJv0+XTmxXMRqnAxFhSKctbVQACjXEczLt2FA+ijW/CUEYJOlUi01YQu1XYUB80DUxruV4414/Fguju5LcvVChhq946NasLmPANFIJ+N19UOD6hJEL3L6UJtooQo97LFT/7F4FiGAF/Z/F8WKXFBd8yePM= Received: by 10.54.31.70 with SMTP id e70mr3513380wre; Mon, 23 May 2005 04:40:57 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 04:40:57 -0700 (PDT) Message-ID: <68fba5c5050523044060c5e949@mail.gmail.com> Date: Mon, 23 May 2005 07:40:57 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Anne van Kesteren Subject: Re: some small comments on 08 Cc: Atom Syntax In-Reply-To: <42917E28.9090904@annevankesteren.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NBf4BH093792 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Anne van Kesteren wrote: > Robert Sayre wrote: > >> What happens when it does contain child elements? I think we should > >> define that for interoperability. (See HTML for what happens when > >> you don't.) This question also applies to the next section. > > > > No, that's broken. There can be no expectation of interoperability. > > I think there should be. Authors will try to do it anyway and defined > error handling is better than reverse engineering the market leader's > error handling. There is no consensus for me to record, AFAIK. > >> For white-space significance text I need to use 'html' or 'xhtml' > >> instead using PRE or xhtml:pre? > > > > I don't understand what you're saying here, but I'm pretty sure every > > possible whitespace issue has been debated by Graham, Paul, Martin, > > etc. Feel free to try and explain this again if I don't get it. > > White-space may be collapsed inside 'text' as currently defined. > > > >> * 4.2.2 The "atom:category" Element > >> > >> Why is significant information hidden in attributes? That is bad > >> for i18n and prevents people from defining the expansion of an > >> abbreviation, for example. > > > > Minor flaw. It happens. > > I think you are rushing things too fast. It would be much better if we > fixed this. I would never describe this process as "too fast". I happen to agree with you here, but I don't think the "problem" you've found is important. Maybe other folks will. *shrugs wrt the atom:uri element, you're ignoring an incredibly unproductive thread that already occurred on this topic. I want you to recite the Atompub Web Address Oath of Silence: "I hereby promise that should I ever again be tempted to raise an issue around the naming of web addresses, I shall strike myself firmly on the head with a heavy blunt object until I come to my senses."[0] Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg13865.html From owner-atom-syntax@mail.imc.org Mon May 23 08:18:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19783 for ; Mon, 23 May 2005 08:18: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 j4NC9Wwl004003; Mon, 23 May 2005 05:09: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 j4NC9WB0004002; Mon, 23 May 2005 05:09: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NC9V4C003965 for ; Mon, 23 May 2005 05:09:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3419189wra for ; Mon, 23 May 2005 05:09:25 -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=Rs5mW5hZpIuvQ9c97vuk3P+pIlIjoIYkYk2oy7yjZmGQnJf+w+Z3YowjuNs6xqanwyaghaeIlVP0ngCkOtA4nVRIA0/rApJQ6CD+znPFjoO7RjeIcJ06m0Blrx1suhzh7ae8hdowF/miEMvO02NPoakX84x3XLvPUEn2n91C1u4= Received: by 10.54.33.73 with SMTP id g73mr2820250wrg; Mon, 23 May 2005 05:09:25 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 05:09:25 -0700 (PDT) Message-ID: <68fba5c505052305098a48f28@mail.gmail.com> Date: Mon, 23 May 2005 08:09:25 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NC9V4C003995 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > On 23 May 2005, at 12:28 pm, Robert Sayre wrote: > > > What is the interop problem you are trying to avoid? You don't just > > throw in a SHOULD NOT and say "otherwise it would be hard". > > With the line in place, generating a basic byline is as simple as: > > print "by "' > foreach (atom:author) print atom:author.name; > if (count(atom:contributor)) { > print "with contributions from "; > foreach (atom:contributor) print atom:contributor.name; > } > > Without that line, the code has to do duplicate detection ... Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. later, Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 08:26:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20246 for ; Mon, 23 May 2005 08:26: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 j4NCGDqf006772; Mon, 23 May 2005 05:16: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 j4NCGDrD006771; Mon, 23 May 2005 05:16:13 -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 j4NCGBv5006729 for ; Mon, 23 May 2005 05:16:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 870 messnum 2896460 invoked from network[83.70.217.193/unknown]); 23 May 2005 12:16:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail07.svc.cra.dublin.eircom.net (qp 870) with SMTP; 23 May 2005 12:16:06 -0000 Message-ID: <4291C974.1090006@dehora.net> Date: Mon, 23 May 2005 13:15:48 +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: Dan Brickley CC: Eric Scheid , Atom Syntax Subject: Re: spec text regarding feed/entry inheritance References: <20050523100517.GC4431@homer.w3.org> In-Reply-To: <20050523100517.GC4431@homer.w3.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 Dan Brickley wrote: > Is anybody working on a set of AtomPub test cases? Not quite; I'm working up some sample documents around authoring in particular to see if the WG could agree on the author/contributors for particular entries. I'm waiting until the next draft ships before raising that here. > In Atom, re inheritance, it'd be great just having a collection of pairs of > Atom docs, and a flag to say whether the first can be considered implied (eg. > by inheritance rules) from the second. That's a good approach. > ps. is it only built-in properties from the Atom ns that can be > inherited? Or extensions too? Again, this will reviewed when the next draft comes around. cheers Bill From owner-atom-syntax@mail.imc.org Mon May 23 08:29:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20381 for ; Mon, 23 May 2005 08:29: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 j4NCJvW5008078; Mon, 23 May 2005 05:19: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 j4NCJvkL008077; Mon, 23 May 2005 05:19:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NCJuL2008031 for ; Mon, 23 May 2005 05:19:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NCI7OO025336; Mon, 23 May 2005 13:18:13 +0100 (BST) In-Reply-To: <68fba5c505052305098a48f28@mail.gmail.com> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <68fba5c505052305098a48f28@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 13:18:06 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 1:09 pm, Robert Sayre wrote: > Fully disagree. Try a record album by the Rolling Stones or > Grandmaster Flash and The Furious 5. OK to list the band members as > contributors? Definitely. Maybe there's a minor bug in the wording here, but the restriction is not intended to block that (mentioning the band and then the member would not count as mentioning someone twice), and the pseudocode I proposed would produce more-or-less sensible results. In any case, the alternative you propose is "no model at all", and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Graham From owner-atom-syntax@mail.imc.org Mon May 23 08:33:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20592 for ; Mon, 23 May 2005 08:33: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 j4NCQ4nU011616; Mon, 23 May 2005 05:26: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 j4NCQ4fS011615; Mon, 23 May 2005 05:26: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NCQ3Lw011534 for ; Mon, 23 May 2005 05:26:03 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 12:25:57 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp025) with SMTP; 23 May 2005 14:25:57 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 14:29:33 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523122933.GA2234@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68fba5c50505230428172218ed@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: 8bit * Robert Sayre [2005-05-23 13:40]: > What is the interop problem you are trying to avoid? You don't > just throw in a SHOULD NOT and say "otherwise it would be > hard". How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought we’d gone over this. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 08:35:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20660 for ; Mon, 23 May 2005 08:35: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 j4NCPZFo011337; Mon, 23 May 2005 05:25: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 j4NCPZJY011336; Mon, 23 May 2005 05:25:35 -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 j4NCPYuH011268 for ; Mon, 23 May 2005 05:25:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3427380wra for ; Mon, 23 May 2005 05:25:29 -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=nOI0drqX4YPPmQ1RghwL6rgQMFwQT+bUmSzXfmb/4gc75Gta4l9aCAcPmdFUF8nQQnzpUsH/v52fCoETYkErrEHnPYKohPTaGSbt23PvTTgXPV1Atbpc3x1JwH8NFDfk1Ao+QbrtZdNK6VOguTdB/eSlLfWuVMyUQs2PXQDOTXk= Received: by 10.54.141.10 with SMTP id o10mr843953wrd; Mon, 23 May 2005 05:25:29 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 05:25:29 -0700 (PDT) Message-ID: <68fba5c50505230525191910@mail.gmail.com> Date: Mon, 23 May 2005 08:25:29 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <68fba5c505052305098a48f28@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NCPZuH011330 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > On 23 May 2005, at 1:09 pm, Robert Sayre wrote: > > > Fully disagree. Try a record album by the Rolling Stones or > > Grandmaster Flash and The Furious 5. OK to list the band members as > > contributors? Definitely. > > Maybe there's a minor bug in the wording here, There's a large bug in the idea, IMO. > > In any case, the alternative you propose is "no model at all", and > anything created under would not be decodeable programatically, > unless you can provide psuedocode that proves otherwise. Fully disagree. I reject the notion that you have generate a complete sentence. You can trivially generate a two lists of strings. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 08:36:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20798 for ; Mon, 23 May 2005 08:36: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 j4NCRmVh012571; Mon, 23 May 2005 05:27: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 j4NCRmCa012570; Mon, 23 May 2005 05:27: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 (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NCRlhV012507 for ; Mon, 23 May 2005 05:27:47 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 12:27:41 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp019) with SMTP; 23 May 2005 14:27:41 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 14:31:18 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523123118.GB2234@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.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: * Graham [2005-05-23 12:50]: > http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor +1 Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 08:37:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20854 for ; Mon, 23 May 2005 08:37: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 j4NCTxGW013835; Mon, 23 May 2005 05:29: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 j4NCTxbu013834; Mon, 23 May 2005 05:29: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 (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NCTwdZ013759 for ; Mon, 23 May 2005 05:29:58 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 12:29:52 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp003) with SMTP; 23 May 2005 14:29:52 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 14:33:29 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523123329.GC2234@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c505052304155d352b7e@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-05-23 13:30]: > -1 to "atom:byline", should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. No need to punch it down here again separately. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 08:41:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21092 for ; Mon, 23 May 2005 08:41: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 j4NCWmiX015553; Mon, 23 May 2005 05:32: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 j4NCWmhd015552; Mon, 23 May 2005 05:32:48 -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 j4NCWmv9015515 for ; Mon, 23 May 2005 05:32:48 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 25779 invoked by uid 17064); 23 May 2005 12:32:45 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.129.28]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 23 May 2005 12:32:45 -0000 In-Reply-To: <68fba5c5050521175149846465@mail.gmail.com> References: <68fba5c5050521162720bea73c@mail.gmail.com> <200505220023.DFI08727@ms8.netsolmail.com> <68fba5c505052117276887d2f9@mail.gmail.com> <68fba5c5050521175149846465@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: atom:modified indicates temporal ORDER not version.... Date: Mon, 23 May 2005 14:32:43 +0200 To: Robert Sayre X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I just found an excellent article on the subject of identity: http://plato.stanford.edu/entries/identity/ It is heavy reading. But it does give an excellent overview of the subject. I can't say that I managed in a couple of hours to fully digest all the information in there. Henry On 22 May 2005, at 02:51, Robert Sayre wrote: > > On 5/21/05, Henry Story wrote: > >> >> On 22 May 2005, at 02:27, Robert Sayre wrote: >> >>> On 5/21/05, Bob Wyman wrote: >>> >>>> Robert Sayre wrote: >>>> >>>> >>>>> Temporal order of what? They are all the same entry, so what is it >>>>> you are temporally ordering? >>>>> >>>>> >>>> We are discussing the temporal ordering of multiple non- >>>> identical >>>> *instances* of a single Atom entry. It is common in the realm of >>>> software >>>> engineering to deal with this concept of "instances." >>>> >>>> Things are often >>>> considered to be simultaneously "different" and "the same". (I am >>>> who I am >>>> today -- as I was when I was a child, nonetheless, I am very >>>> different today >>>> than I was when I was a child. The instance of me today differs >>>> from the >>>> instance of me that you might have come across many years ago.) >>>> But, perhaps >>>> this concept is too abstract for some readers... >>>> >>>> >>> >>> I'm unconvinced. Have a giant -1. >>> >> >> How can you be unconvinced about something so fundamentally basic >> to human thought? People change over time. When you clip your nails >> your body is not the same as it was before, yet as far as the law is >> concerned, you are the same person who went to whatever school you >> went to. >> Change over time exists. For something to be able to change there >> has to >> be something that is the thing that changes. >> >> Really you can't get more basic than this. If you are left to >> argument >> over this, I would suggest moving your discussion over to a >> philosophy >> forum. >> > > > Gee, Henry, maybe you should draw us a UML diagram to explain all > this. > > Robert Sayre > From owner-atom-syntax@mail.imc.org Mon May 23 08:46:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21288 for ; Mon, 23 May 2005 08: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 j4NCZ04p016910; Mon, 23 May 2005 05:35: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 j4NCZ0Pd016909; Mon, 23 May 2005 05:35: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 j4NCYxFO016843 for ; Mon, 23 May 2005 05:34:59 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3432263wra for ; Mon, 23 May 2005 05:34:54 -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=ediFwhR5dvmfucroSv2JFNT9JT/zz0jjo8ZEzQqHK5uhQuebMvhEe0xnfdNexzdOLO4eFX+Ne+rM5T+SOlHNp2bXyxk2ACMlEW4DL+0x8XGBkjSwjzWKHGD3KM0zOg7Mw81rXThkHS5lxP04q9aH1MFiLaHJi+HTklgOU7X3zio= Received: by 10.54.107.4 with SMTP id f4mr3453784wrc; Mon, 23 May 2005 05:34:53 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 05:34:53 -0700 (PDT) Message-ID: <68fba5c5050523053425d42566@mail.gmail.com> Date: Mon, 23 May 2005 08:34:53 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted In-Reply-To: <20050523123329.GC2234@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <20050523123329.GC2234@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NCYxFO016891 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, A. Pagaltzis wrote: > > * Robert Sayre [2005-05-23 13:30]: > > -1 to "atom:byline", should anyone propose it. > > We already have pretty good consensus that bylines, if needed by > anyone, will be implemented in an extension, not in Atom. Is your name Tim or Paul? If not, please avoid declaring what the consensus is. It only causes problems. Trust me on this. > No need > to punch it down here again separately. -1 to atom:byline. :) Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 08:53:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21522 for ; Mon, 23 May 2005 08:53: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 j4NChZBh022235; Mon, 23 May 2005 05:43: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 j4NChZjB022234; Mon, 23 May 2005 05:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.oasis-open.org (office.oasis-open.org [65.211.1.194]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NChYMr022161 for ; Mon, 23 May 2005 05:43:34 -0700 (PDT) (envelope-from robin@oasis-open.org) Received: (qmail 6055 invoked by uid 500); 23 May 2005 13:22:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 May 2005 13:22:02 -0000 Date: Mon, 23 May 2005 09:22:02 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Atom Syntax Subject: Re: Author and contributor Message-ID: 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: +1 make atom:author plural +1 keep atom:contributor - Robin Cover From owner-atom-syntax@mail.imc.org Mon May 23 08:59:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22305 for ; Mon, 23 May 2005 08:59: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 j4NCmfva025173; Mon, 23 May 2005 05:48: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 j4NCmfKs025172; Mon, 23 May 2005 05:48:41 -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 j4NCmd85025103 for ; Mon, 23 May 2005 05:48:39 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 12:48:33 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp011) with SMTP; 23 May 2005 14:48:33 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 14:52:09 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523125209.GD2234@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <20050523123329.GC2234@klangraum> <68fba5c5050523053425d42566@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68fba5c5050523053425d42566@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: 8bit * Robert Sayre [2005-05-23 14:45]: > On 5/23/05, A. Pagaltzis wrote: > > * Robert Sayre [2005-05-23 13:30]: > > > -1 to "atom:byline", should anyone propose it. > > > > We already have pretty good consensus that bylines, if needed > > by anyone, will be implemented in an extension, not in Atom. > > Is your name Tim or Paul? If not, please avoid declaring what > the consensus is. It only causes problems. Trust me on this. Sorry; it is not for me to determine whether the thus far 8 +1 votes in favour of punting any byline element to an extension constitute a consensus. In any case, the point was that it clearly doesn’t look like anyone is trying to propose such a thing, so we should please stick to the points that are actually being discussed. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 09:07:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22933 for ; Mon, 23 May 2005 09:07: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 j4NCv7JB030278; Mon, 23 May 2005 05:57: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 j4NCv705030277; Mon, 23 May 2005 05:57:07 -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 j4NCv6nB030197 for ; Mon, 23 May 2005 05:57:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3445309wra for ; Mon, 23 May 2005 05:57:01 -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=hVNqKliIKSUW2B+nGzjrR3wJrVKqRZkRCN7NgzjcBmvxl83fFIRdel3uKfTgELjvrr4nMcIKsok1BLJDD+UccRjTyLwrK++SdlFPl3aFMEQjbPnCrjKPIR/ktTy7gmZmhKHff0k5upzweq6s1+IdFNHEv9iXaEDsyaJlZuVXRQU= Received: by 10.54.41.42 with SMTP id o42mr2845021wro; Mon, 23 May 2005 05:57:00 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 05:57:00 -0700 (PDT) Message-ID: <68fba5c50505230557784bd992@mail.gmail.com> Date: Mon, 23 May 2005 08:57:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted In-Reply-To: <20050523125209.GD2234@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <20050523123329.GC2234@klangraum> <68fba5c5050523053425d42566@mail.gmail.com> <20050523125209.GD2234@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NCv7nB030270 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, A. Pagaltzis wrote: > In any case, the point was that it clearly doesn't look like > anyone is trying to propose such a thing, so we should please > stick to the points that are actually being discussed. Ah, yes, the point. That would be "banning duplicate 'Persons' will obviate the need for fuzzy logic and constitute a coherent 'model' to program against." YMMV. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 09:12:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23176 for ; Mon, 23 May 2005 09:12: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 j4ND1ZTN033650; Mon, 23 May 2005 06:01: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 j4ND1ZgX033648; Mon, 23 May 2005 06:01:35 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ND1VtX033584 for ; Mon, 23 May 2005 06:01:34 -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 1DaCYk-0007oB-00; Mon, 23 May 2005 14:01:30 +0100 Date: Mon, 23 May 2005 14:01:30 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523130130.GX24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523122933.GA2234@klangraum> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: > * Robert Sayre [2005-05-23 13:40]: > > What is the interop problem you are trying to avoid? You don't > > just throw in a SHOULD NOT and say "otherwise it would be > > hard". > > How else would you present a list of distinct authors for a set > of entries? What is the point of allowing multiple atom:author > elements, if not to require that each of them refer to only a > single person (or entity) so that the data can be extracted > precisely without resorting to fuzzy matching? I thought we???d > gone over this. I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: "The book was written by James Aylett, James Aylett, and James Aylett". I can do so meaning the /same/ James Aylett, using the repetition for effect. Banning this in Atom doesn't actually seem to have any good reason beyond a kind of technical tidying. Surely it's more useful to have the semantics "if you list the same person twice, you mean it" (leaving "mean it" to be a context of the feed; the feed description could explain it, for instance). So I'm -1 on this restriction, as I don't think it actually helps anyone. If you've got a way of displaying a list of people who wrote an article, then you've got a way that will work no matter which people you put in there. If the author of an entry or feed really wants the same person multiple times, who are we to stop them? James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 09:41:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24872 for ; Mon, 23 May 2005 09:41: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 j4NDY7Kf040054; Mon, 23 May 2005 06:34: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 j4NDY7NH040053; Mon, 23 May 2005 06:34: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 j4NDY5g6040038 for ; Mon, 23 May 2005 06:34:06 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 13:33:59 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp012) with SMTP; 23 May 2005 15:33:59 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 15:37:36 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523133736.GE2234@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050523130130.GX24523@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: 8bit * James Aylett [2005-05-23 15:15]: > I think we're trying to do too much here. Why on earth are we > disallowing a list of authors that includes the same person > twice? Why does it actually cause problems? I can write the > following English sentence: > > "The book was written by James Aylett, James Aylett, and James > Aylett". Sorry, I got confused because I read the Impacts section Robert quoted before reading the entire Pace in detail. This is what the Impacts section of the Pace refers to: James Aylett, James Aylett, and James Aylett +1 to forbidding this. This is what the last change directed in the Pace forbids and which the last sentence in the Rationale refers to: James Aylett James Aylett James Aylett -1 to forbidding this. In other words, I am still +1 to most of the Pace, save for the one addition to 4.1.2 which imposes this restriction. Which is actually precisely what Robert objected to – once you see past the irrelevant squabble over his mention of the byline. :-) Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 10:29:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29088 for ; Mon, 23 May 2005 10:29: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 j4NEKElB043661; Mon, 23 May 2005 07:20: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 j4NEKE1V043660; Mon, 23 May 2005 07:20:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from outbound.mailhop.org (mailnull@outbound.mailhop.org [63.208.196.171]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NEKDAj043650 for ; Mon, 23 May 2005 07:20:13 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from p46222.net.upc.nl ([212.142.46.222] helo=localhost) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1DaDmu-0005sH-8J for atom-syntax@imc.org; Mon, 23 May 2005 10:20:12 -0400 Received: from ndw by localhost with local (Exim 4.50) id 1DaDnB-0005SU-N7 for atom-syntax@imc.org; Mon, 23 May 2005 16:20:29 +0200 To: atom-syntax@imc.org Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) References: <428FB78D.9000401@cegetel.net> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Sun, 22 May 2005 18:34:08 +0200 In-Reply-To: <428FB78D.9000401@cegetel.net> (Thomas Broyer's message of "Sun, 22 May 2005 00:34:53 +0200") Message-ID: <871x7zp6db.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 212.142.46.222 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: nwalsh Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: <#secure method=pgpmime mode=sign> --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Thomas Broyer was heard to say: | I'm sorry to raise this "issue" back again but... | | The Atom Publishing Protocol defines SOAP bindings. This (in my mind) | means there will be WSDL files over there. WSDL rely on XML Schema | which in turn are limited to deterministic content models. | | Will the APP limit "Atom entries in SOAP envelopes" content model to | fit WSDL/XML Schema constraints (actually, the APP will already need | to limit Atom entries to have a mandatory atom:content I think)? | | Or should the Atom Syndication Format use deterministic content models | to allow XML Schema, thus such uses as WSDL for Web Services? | | I'm personally in favor of the second one, as it also simplifies Atom | parser/processor development. I'm operating on about two-hours of sleep in the last 48 and time-shifted across six time zones. I say that by way of explanation in case what I'm about to say is more than usually stupid. There is no 1:1 correspondence between schemas and documents. You can have as many schemas as you want. If your application demands additional constraints, such as determinism, you can define your own schema that enforces them. Then your system will reject documents that it can't handle. I would strongly oppose any attempt to make the schema deterministic without simultaneously making the normative prose deterimistic. I didn't make the RELAX NG grammar impossible to translate literally into W3C XML Schemas because I thought it would be fun, I attempted to model the constraints in the normative prose as closely as possible and that was the result. I would prefer to leave things as they are because I think it makes it easier for authors. But you can make a solid argument that determinism is easier for authors too, so I wouldn't object to making Atom deterministic in the normative prose, I suppose. Be seeing you, norm =2D-=20 Norman Walsh | There has never been a perfect http://nwalsh.com/ | government, because men have passions; | and if they did not have passions, | there would be no need for | government.-- Voltaire --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCkLSCOyltUcwYWjsRAgdaAKChBaYdSglBh2c/Nb8JqDGUy2GGMgCfTSiM WIR8FFv3gQgGH77lSmkjheo= =xv1M -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon May 23 10:38:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29805 for ; Mon, 23 May 2005 10: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 j4NEThm6044940; Mon, 23 May 2005 07:29: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 j4NETh4G044939; Mon, 23 May 2005 07:29:43 -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 j4NETgIA044929 for ; Mon, 23 May 2005 07:29:43 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id DA9894F635; Mon, 23 May 2005 10:29:41 -0400 (EDT) Date: Mon, 23 May 2005 10:29:41 -0400 From: Dan Brickley To: James Aylett , atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523142941.GF16894@homer.w3.org> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523130130.GX24523@tartarus.org> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * James Aylett [2005-05-23 14:01+0100] > > On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: > > > * Robert Sayre [2005-05-23 13:40]: > > > What is the interop problem you are trying to avoid? You don't > > > just throw in a SHOULD NOT and say "otherwise it would be > > > hard". > > > > How else would you present a list of distinct authors for a set > > of entries? What is the point of allowing multiple atom:author > > elements, if not to require that each of them refer to only a > > single person (or entity) so that the data can be extracted > > precisely without resorting to fuzzy matching? I thought we???d > > gone over this. > > I think we're trying to do too much here. Why on earth are we > disallowing a list of authors that includes the same person twice? > Why does it actually cause problems? I can write the following English > sentence: > > "The book was written by James Aylett, James Aylett, and James > Aylett". > > I can do so meaning the /same/ James Aylett, using the repetition for > effect. Banning this in Atom doesn't actually seem to have any good > reason beyond a kind of technical tidying. Surely it's more useful to > have the semantics "if you list the same person twice, you mean it" > (leaving "mean it" to be a context of the feed; the feed description > could explain it, for instance). It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Dan From owner-atom-syntax@mail.imc.org Mon May 23 10:44:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00712 for ; Mon, 23 May 2005 10:44: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 j4NEZEkK046579; Mon, 23 May 2005 07:35: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 j4NEZExR046578; Mon, 23 May 2005 07:35: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.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NEZDwu046547 for ; Mon, 23 May 2005 07:35:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3506347wra for ; Mon, 23 May 2005 07:35:07 -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=pE8h8ptnS3+umMDoD5V+aJFGQzpmRdfFM+ANlwzSzI9DJinoqp2NZfw67HJoNskukQ/+Zob3GI5b34BgygeADvh2bEw55xmxpVCv3qOOh2cs8avpYTxn2jfKTWFCVH8G38m2n+hzGTUltu1UPGXFCm0xRq6/4cfuOrnPf3Wbb3Y= Received: by 10.54.79.8 with SMTP id c8mr2900024wrb; Mon, 23 May 2005 07:35:07 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 07:35:07 -0700 (PDT) Message-ID: <68fba5c5050523073535b09326@mail.gmail.com> Date: Mon, 23 May 2005 10:35:07 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Dan Brickley Subject: Re: PaceClarifyAuthorContributor posted Cc: James Aylett , atom-syntax In-Reply-To: <20050523142941.GF16894@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NEZDwu046573 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Dan Brickley wrote: > It would be good if Atom were clear on whether repetition of the > exact same name implies the two authors are distinct (eg. things > written by father/son pairings, where they have same name). Why would that be good? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 10:52:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02541 for ; Mon, 23 May 2005 10:52: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 j4NEhKO7049158; Mon, 23 May 2005 07:43: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 j4NEhKeO049157; Mon, 23 May 2005 07:43:20 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NEhJbh049134 for ; Mon, 23 May 2005 07:43:19 -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 1DaE9G-0003AN-00; Mon, 23 May 2005 15:43:18 +0100 Date: Mon, 23 May 2005 15:43:18 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523144318.GF24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c5050523073535b09326@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 Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: > > It would be good if Atom were clear on whether repetition of the > > exact same name implies the two authors are distinct (eg. things > > written by father/son pairings, where they have same name). > > Why would that be good? I'm -1 on having the spec say anything. I'm +0.5 on the spec explicitly saying that you can't infer anything. I don't see this as something that has any actual technical impact - I think people are trying to clear up a possible ambiguity that is useful to allow. One reason why I think it's not a good idea to restrict this is that if we say "repetition of the same atom:name implies distinct Person referents", we're implying that you shouldn't have the same Person referent using different names (eg: pseudonyms) - something that is impossible to detect, and so can't reasonably be part of a spec. And if we're not trying to disallow the same person being referred to by two distinct textual strings, then why are we disallowing it for two identical textual strings? Seems an arbitrary non-technical semantic to me. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 10:53:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02859 for ; Mon, 23 May 2005 10:53: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 j4NEgQAb048909; Mon, 23 May 2005 07: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 j4NEgQ7C048908; Mon, 23 May 2005 07:42: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 j4NEgQTK048898 for ; Mon, 23 May 2005 07:42:26 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id DBB414F635; Mon, 23 May 2005 10:42:25 -0400 (EDT) Date: Mon, 23 May 2005 10:42:25 -0400 From: Dan Brickley To: Robert Sayre Cc: James Aylett , atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523144225.GJ16894@homer.w3.org> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c5050523073535b09326@mail.gmail.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Robert Sayre [2005-05-23 10:35-0400] > On 5/23/05, Dan Brickley wrote: > > It would be good if Atom were clear on whether repetition of the > > exact same name implies the two authors are distinct (eg. things > > written by father/son pairings, where they have same name). > > Why would that be good? So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors (where two distinct John Smith entries might be needed), or merging against other information about the author(s) (eg. their photo url, lists of interests, posts/comments in other systems, etc). Dan From owner-atom-syntax@mail.imc.org Mon May 23 11:01:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03703 for ; Mon, 23 May 2005 11:01: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 j4NEjrjI049901; Mon, 23 May 2005 07:45: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 j4NEjrU1049900; Mon, 23 May 2005 07:45:53 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NEjqWB049888 for ; Mon, 23 May 2005 07:45:52 -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 1DaEBj-0003Ck-00; Mon, 23 May 2005 15:45:51 +0100 Date: Mon, 23 May 2005 15:45:51 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523144551.GG24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523144225.GJ16894@homer.w3.org> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 10:42:25AM -0400, Dan Brickley wrote: > > > It would be good if Atom were clear on whether repetition of the > > > exact same name implies the two authors are distinct (eg. things > > > written by father/son pairings, where they have same name). > > So we can be clear on the conclusions that can be drawn from an > Atom description of a document, eg. if creating an A-Z index of > authors (where two distinct John Smith entries might be needed), or > merging against other information about the author(s) (eg. their photo url, > lists of interests, posts/comments in other systems, etc). Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. If they'd rather not, they can do the uniqueness filtering on creation. Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 11:01:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03747 for ; Mon, 23 May 2005 11:01: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 j4NEtmhm052631; Mon, 23 May 2005 07:55: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 j4NEtmNK052630; Mon, 23 May 2005 07:55: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.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NEtkTQ052623 for ; Mon, 23 May 2005 07:55:47 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2005 14:55:40 -0000 Received: from xdsl-213-196-242-122.netcologne.de (EHLO klangraum) [213.196.242.122] by mail.gmx.net (mp001) with SMTP; 23 May 2005 16:55:40 +0200 X-Authenticated: #163624 Date: Mon, 23 May 2005 16:59:17 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523145917.GA3119@klangraum> Mail-Followup-To: atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050523142941.GF16894@homer.w3.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: 8bit * Dan Brickley [2005-05-23 16:40]: > It would be good if Atom were clear on whether repetition of > the exact same name implies the two authors are distinct (eg. > things written by father/son pairings, where they have same > name). Doesn’t seem to me like there should be any implication. Any user interface that presents a list of authors which contains identically named, but distinct authors will have to somehow disambiguate them in order to avoid confusing the user sooner or later. If a publisher wants to be certain of a particular interpretation he will need to make the elements distinct anyway. I was going to mention that there are two other elements in atom:author besides atom:name, but now that I think about it I’m not sure if two elements with identical content in the atom:name element but divergent information in the others can automatically be thought of as referring to different authors or not. I think it is intuitive and should be implied that they are different authors, though, even if they are different only in the sense that they refer to the same physical person acting in different roles. I suppose that in this way, a meaningful, though application-specific subset of the semantics offered by allowing atom:category in these elements would be implementable. Whatever it is, I don’t see a strong case for prescribing a any particular interpretation here. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Mon May 23 11:20:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04893 for ; Mon, 23 May 2005 11:19: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 j4NFCZiI054030; Mon, 23 May 2005 08:12: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 j4NFCZxY054029; Mon, 23 May 2005 08:12:35 -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 j4NFCYuC054014 for ; Mon, 23 May 2005 08:12:35 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id E8F884F638; Mon, 23 May 2005 11:12:33 -0400 (EDT) Date: Mon, 23 May 2005 11:12:33 -0400 From: Dan Brickley To: James Aylett , atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523151233.GK16894@homer.w3.org> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144318.GF24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523144318.GF24523@tartarus.org> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * James Aylett [2005-05-23 15:43+0100] > > On Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: > > > > It would be good if Atom were clear on whether repetition of the > > > exact same name implies the two authors are distinct (eg. things > > > written by father/son pairings, where they have same name). > > > > Why would that be good? > > I'm -1 on having the spec say anything. I'm +0.5 on the spec > explicitly saying that you can't infer anything. I don't see this as > something that has any actual technical impact - I think people are > trying to clear up a possible ambiguity that is useful to allow. I'm fine with either design; was just a plea for the chosen design to be documented clearly. "Note: the description of multiple authors of an entry does not in itself imply that each of these descriptions is about a different entity" would be plenty. > One reason why I think it's not a good idea to restrict this is that > if we say "repetition of the same atom:name implies distinct Person > referents", we're implying that you shouldn't have the same Person > referent using different names (eg: pseudonyms) - something that is > impossible to detect, and so can't reasonably be part of a spec. Fair point. Again I'm not arguing that distinctness be part of the spec, just that people have a tendency to assume that distinctness is intended, so a few words to be explicit on Atom's assumptions would be worthwhile. I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption "Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be?" > And if we're not trying to disallow the same person being referred to > by two distinct textual strings, then why are we disallowing it for > two identical textual strings? Seems an arbitrary non-technical > semantic to me. I'm fine with allowing it. But there are two quite different designs here that look the same at the instance level; only the Atom spec can arbitrate between users who take differing interpretations. Dan > James > > -- > /--------------------------------------------------------------------------\ > James Aylett xapian.org > james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 11:20:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04914 for ; Mon, 23 May 2005 11:20: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 j4NF8aP8053660; Mon, 23 May 2005 08:08: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 j4NF8aku053659; Mon, 23 May 2005 08:08:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NF8agM053648 for ; Mon, 23 May 2005 08:08:36 -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 <200505231508300140097u26e>; Mon, 23 May 2005 15:08:30 +0000 Date: Mon, 23 May 2005 09:08:25 -0600 Subject: Re: multiple ids 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: <82B28491-CB9C-11D9-A5DA-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, May 22, 2005, at 07:14 PM, Paul Hoffman wrote: > At 2:11 AM -0400 5/21/05, Bob Wyman wrote: >> "If multiple atom:entry elements with the same atom:id value appear in >> an Atom Feed document, they describe the same entry." > > +1. I can live with Tim's original wording because the phrase that Bob > removes is impossible to measure or enforce, but Bob's wording is > cleaner for the same result. Yeah, I like Bob's better too. And if the word "appear" can be interpreted to refer to the action of first appearing, and not to the state of existing (having been copied from the feed where it "appeared")...yes, I'm totally twisting it to my liking...then consuming apps are free to determine for themselves whether the entries originated ("appeared") in the same feed and are therefore the same entry or whether one of them is trying to DOS the other. ...but I'd rather that we state that "If multiple atom:entry elements originating in the same Atom Feed (document?) have the same atom:id value, they describe the same entry." We MIGHT consider omitting the word "document". It's purpose is of course to speak to multiple instances of an entry within the same document, but the same rule applies to multiple instances appearing in a feed at different times. Removing "document" would change the focus of the sentence, making the fact that multiple instances can appear in the same document less clear...or even totally unclear...so perhaps two sentences or something like this would be even better: "If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the feed document, they describe the same entry." From owner-atom-syntax@mail.imc.org Mon May 23 11:24:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05181 for ; Mon, 23 May 2005 11:24: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 j4NFGVUD054430; Mon, 23 May 2005 08:16: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 j4NFGVxk054428; Mon, 23 May 2005 08:16:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFGTlo054413 for ; Mon, 23 May 2005 08:16:30 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NFEEiR002578; Mon, 23 May 2005 16:14:24 +0100 (BST) In-Reply-To: <20050523144551.GG24523@tartarus.org> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> <20050523144551.GG24523@tartarus.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 16:14:15 +0100 To: James Aylett X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 3:45 pm, James Aylett wrote: > Why can't we just have the semantics that if you have two Person > constructs, you'll get the effects of having two Person constructs? > That way it's up to the producer of the feed - if they want the > semantics that they'll have identical names listed twice in author > lists, indexes or whatever, they can do that. That's the intention of the spec, and the restriction. If you can come up with better wording, then we can go with that. The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Graham From owner-atom-syntax@mail.imc.org Mon May 23 11:30:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05455 for ; Mon, 23 May 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 j4NFNr63055022; Mon, 23 May 2005 08:23: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 j4NFNrEr055020; Mon, 23 May 2005 08:23:53 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFNqMB055004 for ; Mon, 23 May 2005 08:23:52 -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 1DaEmV-0004ni-00; Mon, 23 May 2005 16:23:51 +0100 Date: Mon, 23 May 2005 16:23:51 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523152351.GK24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> <20050523144551.GG24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 04:14:15PM +0100, Graham wrote: > The other intention is that one person shouldn't (and doesn't need to > be) listed as both an author and a contributor (ie a author is by > definition a contributor). Does anyone object to that? If your intention is to disallow "James Aylett" as both contributor and author, I'm -0 (at least, possibly +0). If your intention is to disallow "James Aylett and James Lark" as authors, and "James Aylett" as contributor (with "James Lark" as a second contributor) then I'm -1. Because that's semantically the same as "Funky Group Name" as author, and "James Aylett" and "James Lark" as contributors, which I would find useful. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 11:34:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05931 for ; Mon, 23 May 2005 11:34: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 j4NFR23e055820; Mon, 23 May 2005 08:27: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 j4NFR2hW055819; Mon, 23 May 2005 08:27:02 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFR16V055812 for ; Mon, 23 May 2005 08:27:01 -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 1DaEpZ-0004q4-00; Mon, 23 May 2005 16:27:01 +0100 Date: Mon, 23 May 2005 16:27:01 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523152701.GL24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144318.GF24523@tartarus.org> <20050523151233.GK16894@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523151233.GK16894@homer.w3.org> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 11:12:33AM -0400, Dan Brickley wrote: > I'm fine with either design; was just a plea for the chosen design to > be documented clearly. "Note: the description of multiple authors > of an entry does not in itself imply that each of these descriptions is > about a different entity" would be plenty. I'd be happy with that (particularly as the concept, but I'm happy with it textually as well). James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 11:35:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05975 for ; Mon, 23 May 2005 11: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 j4NFML9H054820; Mon, 23 May 2005 08: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 j4NFMLla054819; Mon, 23 May 2005 08: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFMJW3054808 for ; Mon, 23 May 2005 08:22:20 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3540177wra for ; Mon, 23 May 2005 08:22:14 -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=XQpfnbHMeFpCUZ2ZQeUlZZ5T0/TQQHmj27l0AEiMPFB5S/jH4FjCAWmOK9N8sRa10GAbTpdXYjx611txaFyRkYshl75PYMd8jW9SULB0chFNJtpwl4tanFbzTjtGbpnOypxBqXbjyIH3/q4QqvPDHu4g16LVOLPpGwYdZwavl5w= Received: by 10.54.69.16 with SMTP id r16mr2924094wra; Mon, 23 May 2005 08:22:14 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 08:22:13 -0700 (PDT) Message-ID: <68fba5c50505230822557a99e9@mail.gmail.com> Date: Mon, 23 May 2005 11:22:13 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: James Aylett , atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> <20050523144551.GG24523@tartarus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NFMKW3054814 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > The other intention is that one person shouldn't (and doesn't need to > be) listed as both an author and a contributor (ie a author is by > definition a contributor). Does anyone object to that? Yes. It's a total rathole. Just state the cardinality and be done with it. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 11:39:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06205 for ; Mon, 23 May 2005 11: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 j4NFO3Of055081; Mon, 23 May 2005 08:24: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 j4NFO3Il055080; Mon, 23 May 2005 08:24:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFO2GU055047 for ; Mon, 23 May 2005 08:24:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NFKiTQ007174; Mon, 23 May 2005 16:20:44 +0100 (BST) In-Reply-To: <20050523135515.GC24523@tartarus.org> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 16:20:44 +0100 To: James Aylett X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 2:55 pm, James Aylett wrote: > ---------------------------------------------------------------------- > > Anne Rice > Howard Allen O'Brien atom:person> > > ---------------------------------------------------------------------- > > then I've hacked around your restriction. That's still the same person > listed twice. As I understand your wording, it's violating the spec - > but it's undetectable. No way on earth any Atom processor that isn't a > human being is going to notice, so how can we reasonably put that as a > restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user "This entry was written by Anne Rice and Howard Allen O'Brien". Without the restriction, all it can conclude is "The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry" Graham From owner-atom-syntax@mail.imc.org Mon May 23 11:40:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06315 for ; Mon, 23 May 2005 11: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 j4NFVAf3056145; Mon, 23 May 2005 08:31: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 j4NFVA2L056144; Mon, 23 May 2005 08:31:10 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFV93e056138 for ; Mon, 23 May 2005 08:31:09 -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 1DaEtY-0004td-00; Mon, 23 May 2005 16:31:08 +0100 Date: Mon, 23 May 2005 16:31:08 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523153108.GM24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 04:20:44PM +0100, Graham wrote: > >---------------------------------------------------------------------- > > > > Anne Rice > > Howard Allen O'Brien >atom:person> > > > >---------------------------------------------------------------------- > > > >then I've hacked around your restriction. That's still the same person > >listed twice. As I understand your wording, it's violating the spec - > >but it's undetectable. No way on earth any Atom processor that isn't a > >human being is going to notice, so how can we reasonably put that as a > >restriction in the spec? > > That's exactly why there's a restriction, because the processor can't > tell for itself what's going on, so it needs the publisher to provide > correct data about what's what. With the restriction, the processor > can safely treat them as separate people and tell the end user "This > entry was written by Anne Rice and Howard Allen O'Brien". Without the > restriction, all it can conclude is "The names Anne Rice and Howard > Allen O'Brien are in some way related to the authorship of this entry" Why can't you conclude that the entry was written by Anne Rice and Howard Allen O'Brien? That's what it says (well, "authored"). It's the responsibility of the creator of the feed to ensure it makes sense - our job with Atom isn't really to try to define the semantics of authorship, just to provide a way of expressing authorship (no matter what your semantics are). I don't see a /technical/ reason for prohibiting this. None of the examples given cause me any problems, providing (as danbri says) that the spec makes it clear that we're not imposing these restrictions. Let the publishers decide what to say (because they will anyway, even if only in 0.001% of the cases and by mistake in an undetectable way). James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 11:57:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09054 for ; Mon, 23 May 2005 11:57: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 j4NFoBAA057558; Mon, 23 May 2005 08:50: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 j4NFoB3d057557; Mon, 23 May 2005 08:50:11 -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 j4NFoBk0057551 for ; Mon, 23 May 2005 08:50:11 -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 j4NFoAjO006330 for ; Mon, 23 May 2005 09:50:10 -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 <0IGY00G589BMH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 May 2005 09:50:10 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGY002449BLZZ@mail.sun.net> for atom-syntax@imc.org; Mon, 23 May 2005 09:50:10 -0600 (MDT) Date: Mon, 23 May 2005 08:50:15 -0700 From: Tim Bray Subject: Re: atom:type, xsl:output In-reply-to: To: Graham Cc: Danny Ayers , atom-syntax Message-id: <0C9E15F7-C58A-42F2-90C2-251ECD17C0EC@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <1f2ed5cd0505230114e3f1382@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 23, 2005, at 2:43 AM, Graham wrote: >> * When @type="html" then the content of the element is a xsd:string >> [1] of an HTML DIV element plus optional insignificant whitespace >> around it. Which version of HTML is defined? How do you >> differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or >> "nonstandard" HTML (like with marquee elements)? > > I believe the answer would be "street HTML", not any specific version. Agreed. What it says is "SHOULD be suitable for handling as HTML". I.e. can be passed to your local HTML rendering control, which is doubtless a forgiving tag-soup engine. -Tim From owner-atom-syntax@mail.imc.org Mon May 23 11:58:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09143 for ; Mon, 23 May 2005 11:58: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 j4NFqD5X057701; Mon, 23 May 2005 08:52: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 j4NFqDD0057700; Mon, 23 May 2005 08:52: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NFqBDU057691 for ; Mon, 23 May 2005 08:52:12 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3562044wra for ; Mon, 23 May 2005 08:52: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oQa9DvwS4ujHfrWKsamEoszbXnCVZ+88g03Or5JSAy4ujovod2Ev9EI1xRXJ3JrjgyKIX2gYfUBgp3ok3UUfrDra76V3xcHMbpaD/7FGZ9A+UzKRAyTZ8Ld+g4FOqy4bwoDjCixnx4C7gHnNXjt2ZgbRtyS10GE0dc39FSIWtRE= Received: by 10.54.41.54 with SMTP id o54mr2930112wro; Mon, 23 May 2005 08:52:06 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 08:52:05 -0700 (PDT) Message-ID: <68fba5c505052308522d75f702@mail.gmail.com> Date: Mon, 23 May 2005 11:52:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: James Aylett , atom-syntax Subject: Re: PaceClarifyAuthorContributor posted In-Reply-To: <20050523153108.GM24523@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> <20050523153108.GM24523@tartarus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NFqCDU057695 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, James Aylett wrote: > I don't see a /technical/ reason for prohibiting this. None of the > examples given cause me any problems, providing (as danbri says) that > the spec makes it clear that we're not imposing these > restrictions. Let the publishers decide what to say (because they will > anyway, even if only in 0.001% of the cases and by mistake in an > undetectable way). Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the "Huffington Post", where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 12:08:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09878 for ; Mon, 23 May 2005 12:08: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 j4NFwZ6l058152; Mon, 23 May 2005 08:58: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 j4NFwZFR058151; Mon, 23 May 2005 08:58: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 j4NFwYPF058144 for ; Mon, 23 May 2005 08:58: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 j4NFwY0R013098 for ; Mon, 23 May 2005 09:58: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 <0IGY00HY69PLDN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 May 2005 09:58:34 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGY0026S9PKZZ@mail.sun.net> for atom-syntax@imc.org; Mon, 23 May 2005 09:58:33 -0600 (MDT) Date: Mon, 23 May 2005 08:58:38 -0700 From: Tim Bray Subject: Re: PaceClarifyAuthorContributor posted In-reply-to: To: Graham Cc: Robert Sayre , atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <68fba5c505052305098a48f28@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 23, 2005, at 5:18 AM, Graham wrote: > > On 23 May 2005, at 1:09 pm, Robert Sayre wrote: > > >> Fully disagree. Try a record album by the Rolling Stones or >> Grandmaster Flash and The Furious 5. OK to list the band members as >> contributors? Definitely. >> > > Maybe there's a minor bug in the wording here Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim From owner-atom-syntax@mail.imc.org Mon May 23 12:16:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10483 for ; Mon, 23 May 2005 12:16: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 j4NG5G8h058807; Mon, 23 May 2005 09:05: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 j4NG5G2p058806; Mon, 23 May 2005 09:05: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 j4NG5FEl058799 for ; Mon, 23 May 2005 09:05:15 -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 j4NG5FjO022417 for ; Mon, 23 May 2005 10:05:15 -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 <0IGY00GBWA0QH4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 May 2005 10:05:15 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGY009EPA0Q8J@mail.sun.net> for atom-syntax@imc.org; Mon, 23 May 2005 10:05:14 -0600 (MDT) Date: Mon, 23 May 2005 09:05:20 -0700 From: Tim Bray Subject: Re: PaceClarifyAuthorContributor posted In-reply-to: <20050523144551.GG24523@tartarus.org> To: James Aylett Cc: atom-syntax Message-id: <81662C6D-1CD1-4466-A10A-F98AF2189F1F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> <20050523144551.GG24523@tartarus.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 23, 2005, at 7:45 AM, James Aylett wrote: > Baking it into the > spec strikes me as needlessly creating rules - we can be precise about > what the semantics are without this rule, IMHO. +1 -Tim From owner-atom-syntax@mail.imc.org Mon May 23 12:17:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10583 for ; Mon, 23 May 2005 12:17: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 j4NG6RL8058942; Mon, 23 May 2005 09:06: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 j4NG6R4k058941; Mon, 23 May 2005 09:06:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NG6Q8v058925 for ; Mon, 23 May 2005 09:06:27 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NG3rmn003791; Mon, 23 May 2005 17:03:53 +0100 (BST) In-Reply-To: References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <68fba5c505052305098a48f28@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 17:03:53 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 4:58 pm, Tim Bray wrote: > Uh, Graham, I thought your Pace did a good job of capturing the > consensus that seems to be emerging, and then slipped in just a > little extra with the name-duplication rules. I'm with Rob, that > stuff is past the 80/20 point, I'd suggest you pare down the Pace > as a friendly amendment. -Tim Pared down. Graham From owner-atom-syntax@mail.imc.org Mon May 23 12:21:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10973 for ; Mon, 23 May 2005 12:21: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 j4NGA4W0059292; Mon, 23 May 2005 09: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 j4NGA45I059291; Mon, 23 May 2005 09:10:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGA3l0059275 for ; Mon, 23 May 2005 09:10:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NG8BnW005845; Mon, 23 May 2005 17:08:17 +0100 (BST) In-Reply-To: <68fba5c505052308522d75f702@mail.gmail.com> References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> <20050523153108.GM24523@tartarus.org> <68fba5c505052308522d75f702@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceClarifyAuthorContributor posted Date: Mon, 23 May 2005 17:08:10 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 4:52 pm, Robert Sayre wrote: > Exactly. It's extremely easy to think of cases that don't fit the > model proposed. Consider the "Huffington Post", where the feed might > list Arianna Huffington as the author, and everybody else as a > contributor. But, it would make sense to list her as a contributor as > well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Graham From owner-atom-syntax@mail.imc.org Mon May 23 12:45:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12537 for ; Mon, 23 May 2005 12:45: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 j4NGZ4QJ063242; Mon, 23 May 2005 09:35: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 j4NGZ4XL063241; Mon, 23 May 2005 09:35:04 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGZ3Y1063225 for ; Mon, 23 May 2005 09:35:04 -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 1DaFtN-0007V9-00; Mon, 23 May 2005 17:35:01 +0100 Date: Mon, 23 May 2005 17:34:59 +0100 From: James Aylett To: atom-syntax Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523163459.GO24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax References: <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> <20050523153108.GM24523@tartarus.org> <68fba5c505052308522d75f702@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 05:08:10PM +0100, Graham wrote: > >Exactly. It's extremely easy to think of cases that don't fit the > >model proposed. Consider the "Huffington Post", where the feed might > >list Arianna Huffington as the author, and everybody else as a > >contributor. But, it would make sense to list her as a contributor as > >well. > > Why? She's already credited as the author. If you can explain why > that isn't completely redundant and confusing to software, a gold > star to you. Erm ... it's not redundant, because it's expressing something that a person might want to express. Software can't really be confused by this, providing we make semantics clear - and I don't think people will be confused (unless the feed producer intended them to be confused). However I'm not religious about this particular issue, and I'm +1 on the latest PaceClarifyAuthorContributor. I think we still need a clarification along the lines of what danbri suggested, to make things as obvious as possible. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 12:45:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12562 for ; Mon, 23 May 2005 12:45: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 j4NGaeNq063719; Mon, 23 May 2005 09:36: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 j4NGaej6063718; Mon, 23 May 2005 09:36:40 -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 j4NGaeIY063681 for ; Mon, 23 May 2005 09:36:40 -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 <2005052316363401400ss9rfe>; Mon, 23 May 2005 16:36:35 +0000 Date: Mon, 23 May 2005 10:36:33 -0600 Subject: Re: PaceClarifyAuthorContributor posted 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: <20050523151233.GK16894@homer.w3.org> 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, May 23, 2005, at 09:12 AM, Dan Brickley wrote: > I'm reminded of > http://internetalchemy.org/2005/04/unique-name-assumption > > "Two sons and two fathers went to a pizza restaurant. They ordered > three > pizzas. When they came, everyone had a whole pizza. How can that be?" > Possible answers: * One of them already had a pizza when they entered the restaurant. * They stole a pizza from somebody else in the restaurant before theirs came. * The one that didn't participate in the joint ordering of three pizzas placed a separate order for one pizza, which was filled before the order for three. * "When they came" refers to when the came to the restaurant--they all had pizzas before they arrived, but wanted three more. BTW, +1 to the Pace From owner-atom-syntax@mail.imc.org Mon May 23 12:50:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13227 for ; Mon, 23 May 2005 12:50: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 j4NGgO5r065581; Mon, 23 May 2005 09:42: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 j4NGgO5i065580; Mon, 23 May 2005 09:42:24 -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 j4NGgNJ2065541 for ; Mon, 23 May 2005 09:42:23 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3596595wra for ; Mon, 23 May 2005 09:42:18 -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=pTueGPC3/carptBL6wzkFdTOqa6bMjejVu4c7CQgb62FjLwle7xfoTBbx4ldwLZJG6n2L0fCLE6siAw7QUOK9Q2vh3zm/tF/r6EdZHO4lzNH+0Lub89TNlBJz0hwq2QIvPaqkTfjeSPaP98HNJb0xJ2XVxU6ZE6VNzLEb2XGcaw= Received: by 10.54.26.68 with SMTP id 68mr2550038wrz; Mon, 23 May 2005 09:42:18 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 09:42:17 -0700 (PDT) Message-ID: <68fba5c5050523094256401b27@mail.gmail.com> Date: Mon, 23 May 2005 12:42:17 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceClarifyAuthorContributor posted Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <082D3CCF-797A-405F-857F-C089AF64D53D@mac.com> <20050523135515.GC24523@tartarus.org> <975FB03F-C297-493F-9F88-15AED9435BB0@mac.com> <20050523153108.GM24523@tartarus.org> <68fba5c505052308522d75f702@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NGgNJ2065566 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > On 23 May 2005, at 4:52 pm, Robert Sayre wrote: > > > Exactly. It's extremely easy to think of cases that don't fit the > > model proposed. Consider the "Huffington Post", where the feed might > > list Arianna Huffington as the author, and everybody else as a > > contributor. But, it would make sense to list her as a contributor as > > well. > > Why? She's already credited as the author. If you can explain why > that isn't completely redundant and confusing to software, a gold > star to you. Authorship is confusing to software, silly. ----- In section 4.2.3, append to: The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed. The text: and who is not also a named author. ----- -1. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 13:06:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14714 for ; Mon, 23 May 2005 13:06: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 j4NGuVDP070320; Mon, 23 May 2005 09:56: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 j4NGuVqa070319; Mon, 23 May 2005 09:56: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGuScO070273 for ; Mon, 23 May 2005 09:56:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3605983wra for ; Mon, 23 May 2005 09:56: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=mErAeq9esBG8QD++ycdwwMQ7xgfcdjvTMPreYcMf+evqWGbAl2hPDnvKT3k/0sbsBRhWd08i4pdNxzf2EfMqW8jB1HDvig3o+qwhEfgwmKaeLbWna7ny1a3TcXUIDyL8XDwlVyrOrVYbyybB69qwuE1GUqa/r0d3L4E+QDWLMyI= Received: by 10.54.50.46 with SMTP id x46mr3674466wrx; Mon, 23 May 2005 09:56:23 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 09:56:23 -0700 (PDT) Message-ID: <68fba5c505052309567351f24c@mail.gmail.com> Date: Mon, 23 May 2005 12:56:23 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: posted PaceAuthorContributor 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 j4NGuVcO070313 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit http://www.intertwingly.net/wiki/pie/PaceAuthorContributor == Abstract == Allow multiple authors. == Status == Open == Rationale == The current draft only allows one atom:author per entry, meaning either: - All authors of a document have to be shoehorned into that atom:author element - One author has to be chosen as primary and the rest are "contributors" == Notes == Neither bylines nor inheritance are dealt with by this Pace. == Proposal == In 4.1.1, replace: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. with: o atom:feed elements MUST contain one or more atom:author elements, UNLESS all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Remove: o atom:feed elements MUST NOT contain more than one atom:author element. In 4.1.2, replace: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. With: o atom:entry elements MUST contain one or more atom:author elements, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. Remove: o atom:entry elements MUST NOT contain more than one atom:author element. == Impacts == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Mon May 23 13:12:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15289 for ; Mon, 23 May 2005 13:12: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 j4NH2e9d072436; Mon, 23 May 2005 10:02: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 j4NH2eJF072434; Mon, 23 May 2005 10:02:40 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NH2cAo072415 for ; Mon, 23 May 2005 10:02:38 -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 1DaGK5-0000FW-00; Mon, 23 May 2005 18:02:37 +0100 Date: Mon, 23 May 2005 18:02:37 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: PaceClarifyAuthorContributor posted Message-ID: <20050523170237.GR24523@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <20050523151233.GK16894@homer.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, May 23, 2005 at 10:36:33AM -0600, Antone Roundy wrote: > >I'm reminded of > >http://internetalchemy.org/2005/04/unique-name-assumption > > > > "Two sons and two fathers went to a pizza restaurant. They ordered > > three pizzas. When they came, everyone had a whole pizza. How can > > that be?" > > Possible answer [snip] They participated in collective ownership, "had" being an indication of possession, not of eating. (The question isn't terribly well phrased, because the 'and' in "Two sons and two fathers" strongly suggests, to me at least, that they are distinct sets.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon May 23 13:27:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16484 for ; Mon, 23 May 2005 13:27: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 j4NHKVPf078605; Mon, 23 May 2005 10:20: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 j4NHKVDo078604; Mon, 23 May 2005 10:20:31 -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 j4NHKUwp078585 for ; Mon, 23 May 2005 10:20:30 -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 j4NHKUjO005421 for ; Mon, 23 May 2005 11:20: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 <0IGY004DLDI5RI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 May 2005 11:20:30 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGY002W9DI5ZZ@mail.sun.net> for atom-syntax@imc.org; Mon, 23 May 2005 11:20:29 -0600 (MDT) Date: Mon, 23 May 2005 10:20:35 -0700 From: Tim Bray Subject: Re: posted PaceAuthorContributor In-reply-to: <68fba5c505052309567351f24c@mail.gmail.com> To: Robert Sayre Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c505052309567351f24c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 23, 2005, at 9:56 AM, Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceAuthorContributor > > == Abstract == > > Allow multiple authors. For those whose enquiring minds want to know, the difference between Graham's version and Robert's version is that Graham's version contains: ========================= In section 4.2.3, append to: The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed. The text: and who is not also a named author. ========================== Otherwise, they are pretty well identical as far as I can tell. I mildly prefer Robert's version, this feels like trying to legislate morality. --Tim From owner-atom-syntax@mail.imc.org Mon May 23 13:49:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18694 for ; Mon, 23 May 2005 13:49: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 j4NHeamL086917; Mon, 23 May 2005 10:40: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 j4NHea0P086916; Mon, 23 May 2005 10:40:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NHeZdm086865 for ; Mon, 23 May 2005 10:40:35 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NHcmNv010759; Mon, 23 May 2005 18:38:53 +0100 (BST) In-Reply-To: References: <68fba5c505052309567351f24c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: posted PaceAuthorContributor Date: Mon, 23 May 2005 18:38:47 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 6:20 pm, Tim Bray wrote: > this feels like trying to legislate morality. --Tim If I want to give someone full credit for an entry, do I: a) Just credit them as an author? b) Or do I need to credit them as an author and a contributor? If (a) is enough, what happens when someone does (b)? Or if the answer is (b), does someone else doing (a) imply that that author contributed nothing? Implementers need to know this stuff. Graham From owner-atom-syntax@mail.imc.org Mon May 23 14:03:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20108 for ; Mon, 23 May 2005 14:03: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 j4NHqjgg091101; Mon, 23 May 2005 10: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 j4NHqjrJ091100; Mon, 23 May 2005 10:52: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-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 j4NHqgWT091074 for ; Mon, 23 May 2005 10:52:44 -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 j4NHqgjO006545 for ; Mon, 23 May 2005 11:52:42 -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 <0IGY005TSEZU81@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 23 May 2005 11:52:42 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IGY00970EZT8J@mail.sun.net> for atom-syntax@imc.org; Mon, 23 May 2005 11:52:42 -0600 (MDT) Date: Mon, 23 May 2005 10:52:47 -0700 From: Tim Bray Subject: Re: posted PaceAuthorContributor In-reply-to: <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> To: Graham Cc: atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 23, 2005, at 10:38 AM, Graham wrote: > On 23 May 2005, at 6:20 pm, Tim Bray wrote: > > >> this feels like trying to legislate morality. --Tim >> > > If I want to give someone full credit for an entry, do I: > a) Just credit them as an author? > b) Or do I need to credit them as an author and a contributor? I suspect most people would guess right, and a culture of doing the right thing would develop. If you're worried, one good way to address the issue would be to say that "the semantics of this element are based on the Dublin Core's [dc:creator]", DC is pretty clear as I recall. I've been thinking that would be a good idea anyhow. -Tim From owner-atom-syntax@mail.imc.org Mon May 23 14:17:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23698 for ; Mon, 23 May 2005 14:17: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 j4NI7x8M095390; Mon, 23 May 2005 11: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 j4NI7xDF095389; Mon, 23 May 2005 11:07:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NI7w90095370 for ; Mon, 23 May 2005 11:07:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NI76vr018193; Mon, 23 May 2005 19:07:12 +0100 (BST) In-Reply-To: References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16D110CF-3831-4572-BFEC-7242843460AD@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: posted PaceAuthorContributor Date: Mon, 23 May 2005 19:07:06 +0100 To: Tim Bray X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 6:52 pm, Tim Bray wrote: > I suspect most people would guess right, and a culture of doing the > right thing would develop. Dave, impersonating Tim like this is not on. Graham From owner-atom-syntax@mail.imc.org Mon May 23 14:22:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24119 for ; Mon, 23 May 2005 14: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 j4NIEXQE098136; Mon, 23 May 2005 11:14: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 j4NIEXG2098135; Mon, 23 May 2005 11:14:33 -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 j4NIEWBV098126 for ; Mon, 23 May 2005 11:14:33 -0700 (PDT) (envelope-from gerph@gerph.org) Received: from dynamic-62-56-52-30.park-s46b.dslaccess.co.uk ([62.56.52.30] helo=buttercup.gerph.org) by anchor-post-33.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1DaHRf-00072o-BT for atom-syntax@imc.org; Mon, 23 May 2005 18:14:31 +0000 Received: by buttercup.gerph.org (Postfix, from userid 1001) id 4C81AF4434; Mon, 23 May 2005 19:14:22 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 49DDDEC011 for ; Mon, 23 May 2005 19:14:22 +0100 (BST) Date: Mon, 23 May 2005 19:14:22 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: atom-syntax@imc.org Subject: atom:author clarification Message-ID: 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: Hiya, I'm trying to understand the intention of the draft, together with some of the comments posted here recently. I've only been looking at Atom for a couple of days so I may be misunderstanding. As I understand it, the intention is that atom:author within atom:feed applies to all child atom:entry elements; that is, the value is inherited. This being the case I have a dilemma with a feed I would like to aggregate from others. If I collect the atom:entry elements from those feeds and include them in another feed that I produce, there is no place for my name to appear within the new feed. That is, I am not the author of the entries so I cannot appear as the atom:author of any atom:entry. And if the intention is that the atom:author within atom:feed be inherited then I cannot place my name there. The only other element that seems appropriate is the atom:generator element, however it is implied that this is the tool used to generate it ('the agent used'), rather than the person whose responsibility the feed is. In this case I am not looking for any particular 'advertisement' of name, but a means whereby a reader can examine the feed and know who is responsible (to blame) for it. Is there a suitable place for identifying the feed's author without affecting the entries themselves ? Is the atom:feed/atom:author a suitable place for this ? -- Gerph ... And I'm lonely here inside of me. From owner-atom-syntax@mail.imc.org Mon May 23 14:23:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24293 for ; Mon, 23 May 2005 14:23: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 j4NID3Gb097526; Mon, 23 May 2005 11:13: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 j4NID3X3097525; Mon, 23 May 2005 11:13:03 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NID21l097490 for ; Mon, 23 May 2005 11:13:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id 9A2FA3181A2; Mon, 23 May 2005 20:12:56 +0200 (CEST) Message-ID: <42921D2B.2080403@cegetel.net> Date: Mon, 23 May 2005 20:12:59 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Norman Walsh Cc: atom-syntax@imc.org Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) References: <428FB78D.9000401@cegetel.net> <871x7zp6db.fsf@nwalsh.com> In-Reply-To: <871x7zp6db.fsf@nwalsh.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 Norman Walsh wrote: > There is no 1:1 correspondence between schemas and documents. You can > have as many schemas as you want. If your application demands > additional constraints, such as determinism, you can define your own > schema that enforces them. Then your system will reject documents > that it can't handle. Won't that cause interoperability problems? Well, actually, I misunderstood WSDL a bit: you're actually not forced to use XML Schema in WSLD (would it be 1.0, 1.1 or 2.0), though I think (I have no figure about that) XML Schema is the most widely supported schema language in WSDL implementations, and providing no interop with XML Schema might still cause interop problems. > I would strongly oppose any attempt to make the schema deterministic > without simultaneously making the normative prose deterimistic. Sure! I wasn't actually strictly speaking of schemas. > I would prefer to leave things as they are because I think it makes > it easier for authors. I Agree, though many HTML pages which I've looked at the source has their "HEAD" content in the form: * TITLE * META * LINK * STYLE or SCRIPT * SCRIPT or STYLE so a deterministic content model would be a pain I think... > But you can make a solid argument that > determinism is easier for authors too, so I wouldn't object to making > Atom deterministic in the normative prose, I suppose. Hmm, I can't see any such argument... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 14:26:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24760 for ; Mon, 23 May 2005 14: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 j4NIGHpT098826; Mon, 23 May 2005 11: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 j4NIGHpK098825; Mon, 23 May 2005 11:16:17 -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 j4NIGG8U098777 for ; Mon, 23 May 2005 11:16:16 -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 8FB7BD9 for ; Mon, 23 May 2005 11:16:11 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4NIG9ng026642 for ; Mon, 23 May 2005 11:16:11 -0700 (PDT) Date: Mon, 23 May 2005 11:16:50 -0700 From: Walter Underwood To: atom-syntax Subject: Re: posted PaceAuthorContributor Message-ID: In-Reply-To: References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> X-Mailer: Mulberry/4.0.0b3 (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 May 23, 2005 10:52:47 AM -0700 Tim Bray wrote: > > If you're worried, one good way to address the issue would be to say that > "the semantics of this element are based on the Dublin Core's [dc:creator]", > DC is pretty clear as I recall. I've been thinking that would be a good idea > anyhow. Let's call it atom:creator, then, and actually use the DC definition. Not because DC is better, but because it makes the metadata crosswalks (interoperability) work smoothly. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon May 23 14:53:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27297 for ; Mon, 23 May 2005 14:53: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 j4NIiL1Q004737; Mon, 23 May 2005 11:44: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 j4NIiLfI004736; Mon, 23 May 2005 11:44: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 j4NIiKTD004730 for ; Mon, 23 May 2005 11:44:21 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 031CF4F63A; Mon, 23 May 2005 14:44:19 -0400 (EDT) Date: Mon, 23 May 2005 14:44:19 -0400 From: Dan Brickley To: Walter Underwood Cc: atom-syntax Subject: Re: posted PaceAuthorContributor Message-ID: <20050523184419.GS16894@homer.w3.org> References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Walter Underwood [2005-05-23 11:16-0700] > > --On May 23, 2005 10:52:47 AM -0700 Tim Bray wrote: > > > > If you're worried, one good way to address the issue would be to say that > > "the semantics of this element are based on the Dublin Core's [dc:creator]", > > DC is pretty clear as I recall. I've been thinking that would be a good idea > > anyhow. > > Let's call it atom:creator, then, and actually use the DC definition. +1 > Not because DC is better, but because it makes the metadata crosswalks > (interoperability) work smoothly. FWI the original DC had "Author: The person(s) primarily responsible for the intellectual content of the object" (see http://dublincore.org/workshops/dc1/report.shtml first workshop report). After the 3rd workshop (on DC and images, in 1996) this became http://www.dlib.org/dlib/january97/oclc/01weibel.html#table AUTHOR OR CREATOR The person(s) or organization(s) primarily responsible for the intellectual content of the resource. What we have today is http://dublincore.org/documents/dcmi-terms/#H2 "An entity primarily responsible for making the content of the resource." (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) Aside- the DCMI Localization and Internationalization Working Group, http://dublincore.org/groups/languages/ have been busy getting DC definitions translated into other languages. See the WG homepage for links. I realise it is just one part of Atom, but it is handy at least to have had that part of the translation effort done already. Calling it atom:creator makes sense to me; DC changed to use 'creator' rather than 'author' to accomodate digital image use cases. These also seem appealing w.r.t. Atom; there are a *lot* more digital images being shared and described now than there were back in 1996 when DC made the change. Dan From owner-atom-syntax@mail.imc.org Mon May 23 16:34:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18309 for ; Mon, 23 May 2005 16:34: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 j4NKK9QM032701; Mon, 23 May 2005 13:20: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 j4NKK9t2032700; Mon, 23 May 2005 13:20:09 -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 j4NKK8eh032688 for ; Mon, 23 May 2005 13:20:08 -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 165F04F151 for ; Mon, 23 May 2005 16:20:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "atom-syntax Syntax'" From: Karl Dubost Subject: Atom 08 - HTML Version Date: Mon, 23 May 2005 16:20:07 -0400 X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http:// ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt for something specific. Is it fine, or do people recommend another HTML Version of [[[ Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- format-08.txt -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon May 23 17:01:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20895 for ; Mon, 23 May 2005 17: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 j4NKsOIK045380; Mon, 23 May 2005 13:54: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 j4NKsOWY045379; Mon, 23 May 2005 13:54:24 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NKsHZH045330; Mon, 23 May 2005 13:54:17 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> References: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> Date: Mon, 23 May 2005 13:54:15 -0700 To: Karl Dubost , "atom-syntax Syntax'" From: Paul Hoffman Subject: Re: Atom 08 - HTML Version 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 4:20 PM -0400 5/23/05, Karl Dubost wrote: >Hi, > >I will use the HTML version >http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub-format-08.txt > >for something specific. Is it fine, or do people recommend another >HTML Version of > >[[[ >Expires: October 20, 2005 April 18, 2005 > The Atom Syndication Format > draft-ietf-atompub-format-08 >]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt > The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon May 23 17:21:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22639 for ; Mon, 23 May 2005 17:21: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 j4NLE9fi050325; Mon, 23 May 2005 14:14: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 j4NLE9aW050324; Mon, 23 May 2005 14:14:09 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLE8NX050281 for ; Mon, 23 May 2005 14:14:08 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id 412F71A42E6; Mon, 23 May 2005 23:13:20 +0200 (CEST) Message-ID: <4292479D.5080106@cegetel.net> Date: Mon, 23 May 2005 23:14:05 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Norman Walsh Cc: atom-syntax@imc.org Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) References: <428FB78D.9000401@cegetel.net> <871x7zp6db.fsf@nwalsh.com> <42921D2B.2080403@cegetel.net> In-Reply-To: <42921D2B.2080403@cegetel.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > I Agree, though many HTML pages which I've looked at the source has > their "HEAD" content in the form: > > * TITLE > * META > * LINK > * STYLE or SCRIPT > * SCRIPT or STYLE > > so a deterministic content model would be a pain I think... Wow! Sorry, it would NOT be pain (hey hey you might be the only one needing some rest ;o) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 17:23:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23057 for ; Mon, 23 May 2005 17:23: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 j4NLH4C9051143; Mon, 23 May 2005 14:17: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 j4NLH40D051140; Mon, 23 May 2005 14:17:04 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLH2bB051106; Mon, 23 May 2005 14:17:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id E66CC1A431D; Mon, 23 May 2005 23:16:14 +0200 (CEST) Message-ID: <42924850.2010206@cegetel.net> Date: Mon, 23 May 2005 23:17:04 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paul Hoffman Cc: Karl Dubost , "atom-syntax Syntax'" Subject: Re: Atom 08 - HTML Version References: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> 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: > The latter, definitely. The former makes good guesses about HTMLizing, > but may have errors introduced by the automated guessing process. You might have wanted to point to http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 17:28:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24263 for ; Mon, 23 May 2005 17:28: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 j4NLMmPx053148; Mon, 23 May 2005 14:22: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 j4NLMmub053147; Mon, 23 May 2005 14:22:48 -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 j4NLMl72053137 for ; Mon, 23 May 2005 14:22:47 -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 913314EEBC for ; Mon, 23 May 2005 17:22:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "atom-syntax Syntax'" From: Karl Dubost Subject: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Mon, 23 May 2005 17:22:35 -0400 X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is a review of [[[ Network Working Group M. Nottingham, Ed. Internet-Draft R. Sayre, Ed. Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt against W3C QA Framework: Specification Guidelines. http://www.w3.org/TR/qaframe-spec/ (A new version of Specification Guidelines will be published next week in Proposed Recommendation. This review has been made with the Editor's draft version which is not public yet). Short Intro: W3C QA Specification Guidelines has been designed to help W3C editors write better specifications. It focuses on how to define and specify conformance for a specification. Additionally, it addresses how a specification might allow variation among conforming implementations. I have done the review of Atom 0.8 to test W3C QA Specification Guidelines with an external technical document and I thought it could be also useful to the Atom community. The QA Specification Guidelines Specification is organized with a series of mandatory "Requirements" and optional "Good Practices". For each of them, you will find an explanation and a benefits analysis, plus techniques, examples, and other readings. You might want to read the Test FAQ too. http://www.w3.org/QA/WG/2005/01/test-faq to create a test suite for Atom and shared between developers http://intertwingly.net/wiki/pie/ConformanceTests Best Regards. Requirement 01: Include a conformance clause. NO. There is indeed a section which is an attempt of conformance clause but doesn't fulfill all the requirements that we could expect from such sections. It would be good to have a specific table of content item with the words conformance to help developers to understand right away the conformance model of the specification. Requirement 02: Define the scope. YES. In the introduction of the document are given what the technology is about. Though it could be certainly improved, by giving a more systemic way of describing the scope. Requirement 03: Identify who or what will implement the specification. NO. For example, we can see "Atom Processors" in the specification, but it is defined what's an atom processor. The list of class of products would help to define the conformance model, and then the conformance clause. What about authoring tools? What about validators? etc. Requirement 04: Make a list of normative references. YES. The list of normative references is given. Requirement 05: Define the terms used in the normative parts of the specification. NO. "Atom Processors" is not defined. Atom Feed is defined, Atom Entry as well. Some of the important concept really need more definitions. It's really important because it avoids broad interpretation of some terms. Requirement 06: Create conformance labels for each part of the conformance model. NO. The conformance model being not completely clear. It's very hard to know what are the different type of conformance and then to put labels on them. Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them. YES. the RFC is using a consistent style explained in Notational conventions. Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional. YES/NO. Because of the lack of conformance clause clearly defined, it might be confusing. For example "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)." But a document could be valid against the RELAXNG Schema. Is there any reason to not make the schema normative? Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. N/A. The technology seems to not be modular and then not subdivided. Requirement 10: If the technology is subdivided, then address subdivision constraints. N/A. Requirement 11: Address Extensibility. YES. Perfectly addressed. Requirement 12: Identify deprecated features. N/A. None. Requirement 13: Define how each class of product handles each deprecated feature. N/A. None. List of Good Practices (OPTIONAL): Good Practice 01: Define the specification's conformance model in the conformance clause. NO. Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content. NO. Good Practice 03: Provide the wording for conformance claims. NO. Good Practice 04: Provide an Implementation Conformance Statement Pro Forma. NO. Good Practice 05: Require an Implementation Conformance Statement as part of valid conformance claims. NO. Good Practice 06: Provide examples, use cases, and graphics. YES. Good Practice 07: Write sample code or tests. YES. Good Practice 08: When imposing requirements by normative references, address conformance dependencies. YES. Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section. NO. Good Practice 10: Use terms already defined without changing their definition. YES. Good Practice 11: Use formal languages when possible. NO. You have used a formal language, the RelaxNG Schema but you didn't make it normative. Good Practice 12: Write Test Assertions. NO. Good Practice 13: Create subdivisions of the technology when warranted. N/A. Good Practice 14: If the technology is profiled, define rules for creating new profiles. N/A. Good Practice 15:Use optional features as warranted. YES. It seems it has been clearly defined when something is optional when it's not. Good Practice 16: Clearly identify optional features. YES. but could be better. Good Practice 17: Indicate any limitations or constraints on optional features. YES. Good Practice 18: If extensibility is allowed, define an extension mechanism. YES. A whole section is dedicated to it. Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance. NO. Good Practice 20: Define error-handling for unknown extensions. YES. Good Practice 21: Explain how to avoid using a deprecated feature. N/A. Good Practice 22: Identify obsolete features. N/A. Good Practice 23: Define an error handling mechanism. YES. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon May 23 17:29:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24410 for ; Mon, 23 May 2005 17:29: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 j4NLJKfN051963; Mon, 23 May 2005 14:19: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 j4NLJJ3K051936; Mon, 23 May 2005 14:19:19 -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 j4NLJIiP051859; Mon, 23 May 2005 14:19:18 -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 5784D4EEBC; Mon, 23 May 2005 17:19:10 -0400 (EDT) In-Reply-To: References: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: "atom-syntax Syntax'" From: Karl Dubost Subject: Re: Atom 08 - HTML Version Date: Mon, 23 May 2005 17:18:24 -0400 To: Paul Hoffman X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NLJJiP051928 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-23 16:54, Paul Hoffman a crit : >> ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- >> format-08.txt > > The latter, definitely. The former makes good guesses about > HTMLizing, but may have errors introduced by the automated guessing > process. Thanks. :) The bad thing with IETF specification is that we can't give precise references to the text. I have used the text version instead. I'm sending another mail. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Mon May 23 17:34:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25732 for ; Mon, 23 May 2005 17:34: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 j4NLR5pm054767; Mon, 23 May 2005 14:27: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 j4NLR5tE054766; Mon, 23 May 2005 14:27:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLR4Fj054720 for ; Mon, 23 May 2005 14:27:04 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050523212658.LSEF23015.mta05-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Mon, 23 May 2005 22:26:58 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050523212658.IQTU10462.aamta02-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Mon, 23 May 2005 22:26:58 +0100 Date: Mon, 23 May 2005 22:26:55 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1885851780.20050523222655@djpowell.net> To: Karl Dubost CC: "atom-syntax Syntax'" Subject: Re: Atom 08 - HTML Version In-Reply-To: <7491D09D-49B0-4C69-81A6-19BD1C990217@w3.org> References: <7491D09D-49B0-4C69-81A6-19BD1C990217@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 Monday, May 23, 2005, 9:20:07 PM, Karl Dubost wrote: > Hi, > I will use the HTML version > http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http:// > ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- > format-08.txt Only the text version is normative, but the editor produces an HTML version of the specification here. If you want an HTML version, it is probably what you are looking for. -- Dave From owner-atom-syntax@mail.imc.org Mon May 23 17:54:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00272 for ; Mon, 23 May 2005 17:54: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 j4NLf7NJ056410; Mon, 23 May 2005 14:41: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 j4NLf7LW056409; Mon, 23 May 2005 14:41:07 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLf6vD056396 for ; Mon, 23 May 2005 14:41:06 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id D410E1A41CE; Mon, 23 May 2005 23:40:17 +0200 (CEST) Message-ID: <42924DF4.8060002@cegetel.net> Date: Mon, 23 May 2005 23:41:08 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Dan Brickley Cc: Robert Sayre , James Aylett , atom-syntax Subject: Re: PaceClarifyAuthorContributor posted References: <3346E3CA-9BFF-41C8-95F6-D16D2FE53737@mac.com> <68fba5c505052304155d352b7e@mail.gmail.com> <68fba5c50505230428172218ed@mail.gmail.com> <20050523122933.GA2234@klangraum> <20050523130130.GX24523@tartarus.org> <20050523142941.GF16894@homer.w3.org> <68fba5c5050523073535b09326@mail.gmail.com> <20050523144225.GJ16894@homer.w3.org> In-Reply-To: <20050523144225.GJ16894@homer.w3.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 Dan Brickley wrote: >So we can be clear on the conclusions that can be drawn from an >Atom description of a document, eg. if creating an A-Z index of >authors > You won't be able to produce such an index anyway, because atom:name is "free" text. Names might appear as "John Smith", "J. Smith" and "Smith, J.". Moreover, all these three cases might refer to the same John Smith, or two or three distinct John Smith (well, actually, one might also be James Smith, or Janet Smith ;-) ) I already raised up the "Person identity" [1] matter, I was answered it's not an Atom matter, use an extension (such as FOAF). I agree. [1] http://www.imc.org/atom-syntax/mail-archive/msg13816.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 18:12:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03551 for ; Mon, 23 May 2005 18:12: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 j4NM4jQe058606; Mon, 23 May 2005 15:04: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 j4NM4j1D058605; Mon, 23 May 2005 15:04: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.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NM4iZK058591 for ; Mon, 23 May 2005 15:04:45 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3804900wra for ; Mon, 23 May 2005 15:04: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=kEl0WNLPqXQBjSnWKHvIjLw26iowkGmXDvuRoEWtzBYugiWDGgiUjvu7yohZacJOGk/Z8UX0ZputpOmI+if3dIhpyqC425WZCg3eG5rVM7nT3GooUBXa3p+73XBifKdjXI3AhyaXToKBb8YXBSJ+eCRCtaT4F5AR8y1EUCW4/M8= Received: by 10.54.107.4 with SMTP id f4mr3736579wrc; Mon, 23 May 2005 15:04:39 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 15:04:39 -0700 (PDT) Message-ID: <68fba5c5050523150468d9f7ea@mail.gmail.com> Date: Mon, 23 May 2005 18:04:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Cc: "atom-syntax Syntax'" In-Reply-To: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NM4jZK058599 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi Karl. Thanks for the review. Some thoughts inline. On 5/23/05, Karl Dubost wrote: > Requirement 01: Include a conformance clause. > NO. There is indeed a section which is an attempt of conformance > clause but doesn't fulfill all the requirements that we could expect > from such sections. It would be good to have a specific table of > content item with the words conformance to help developers to > understand right away the conformance model of the specification. I tend to agree with Paul wrt conformance levels: http://www.imc.org/atom-syntax/mail-archive/msg10296.html > Requirement 02: Define the scope. > YES. In the introduction of the document are given what the > technology is about. Though it could be certainly improved, by giving > a more systemic way of describing the scope. > > Requirement 03: Identify who or what will implement the specification. > NO. For example, we can see "Atom Processors" in the > specification, but it is defined what's an atom processor. The list > of class of products would help to define the conformance model, and > then the conformance clause. What about authoring tools? What about > validators? etc. > > Requirement 04: Make a list of normative references. > YES. The list of normative references is given. > > Requirement 05: Define the terms used in the normative parts of the > specification. > NO. "Atom Processors" is not defined. Atom Feed is defined, Atom > Entry as well. Some of the important concept really need more > definitions. It's really important because it avoids broad > interpretation of some terms. Fully agree about "Atom Processors." > Requirement 06: Create conformance labels for each part of the > conformance model. > NO. The conformance model being not completely clear. It's very > hard to know what are the different type of conformance and then to > put labels on them. See comment #1. > Requirement 07: Use a consistent style for conformance requirements > and explain how to distinguish them. > YES. the RFC is using a consistent style explained in Notational > conventions. > > Requirement 08: Indicate which conformance requirements are > mandatory, which are recommended, and which are optional. > YES/NO. Because of the lack of conformance clause clearly > defined, it might be confusing. For example "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)." But a document could be > valid against the RELAXNG Schema. Is there any reason to not make the > schema normative? No consensus to make the schema normative. Everyone had a different reason for opposing it, as I recall. :) > Requirement 09: If the technology is subdivided, then indicate which > subdivisions are mandatory for conformance. > N/A. The technology seems to not be modular and then not > subdivided. > > Requirement 10: If the technology is subdivided, then address > subdivision constraints. > N/A. > > Requirement 11: Address Extensibility. > YES. Perfectly addressed. > > Requirement 12: Identify deprecated features. > N/A. None. > > Requirement 13: Define how each class of product handles each > deprecated feature. > N/A. None. > Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 18:14:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03771 for ; Mon, 23 May 2005 18:14: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 j4NM5lt6058694; Mon, 23 May 2005 15: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 j4NM5lcX058693; Mon, 23 May 2005 15:05:47 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NM5kOK058680 for ; Mon, 23 May 2005 15:05:46 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id 6E08D1A433A for ; Tue, 24 May 2005 00:04:58 +0200 (CEST) Message-ID: <429253BE.8050006@cegetel.net> Date: Tue, 24 May 2005 00:05:50 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Refresher on Updated/Modified References: <200505220453.DFI52301@ms8.netsolmail.com> In-Reply-To: <200505220453.DFI52301@ms8.netsolmail.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: >I therefore propose the following text: > >To the discussion of both atom:updated and atom:modified add: >"[Non-Normative: In order to preserve network bandwidth and reduce the load >on hosts of resources linked to Atom feeds or entries, Atom Processors which >fetch the contents of alternate links are advised that they should not >re-fetch such contents unless atom:updated changes.]" > >To the discussion of atom:modified add this normative text: >"The value of atom:modified MUST only be changed when some other element >(including atom:updated) of the same Atom entry has changed. Changes which >are limited to resources linked to the Atom Entry MUST NOT trigger changes >to atom:modified." > > If I already voted, please consider I've changed my mind to the following: +0.8 to atom:modified, +1 if it is optional +1 to the above quoted text if atom:modified is accepted -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 18:22:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04732 for ; Mon, 23 May 2005 18:22: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 j4NMF58X059340; Mon, 23 May 2005 15:15: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 j4NMF5IR059339; Mon, 23 May 2005 15:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMF4iQ059328 for ; Mon, 23 May 2005 15:15:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NMETAH021399; Mon, 23 May 2005 23:14:35 +0100 (BST) In-Reply-To: <20050523184419.GS16894@homer.w3.org> References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> <20050523184419.GS16894@homer.w3.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: posted PaceAuthorContributor Date: Mon, 23 May 2005 23:14:29 +0100 To: Dan Brickley X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 23 May 2005, at 7:44 pm, Dan Brickley wrote: > What we have today is http://dublincore.org/documents/dcmi-terms/#H2 > "An entity primarily responsible for making the content of the > resource." (Examples of a Creator include a person, an > organisation, or > a service. Typically, the name of a Creator should be used to indicate > the entity.) The WG consensus in supporting multiple atom:authors seems to be against having a singular creator, so -1 on this change. Graham From owner-atom-syntax@mail.imc.org Mon May 23 18:22:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04837 for ; Mon, 23 May 2005 18:22: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 j4NMEfVc059318; Mon, 23 May 2005 15:14: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 j4NMEfWP059317; Mon, 23 May 2005 15:14:41 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMEefm059298 for ; Mon, 23 May 2005 15:14:40 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id 2B8091A41E6 for ; Tue, 24 May 2005 00:13:53 +0200 (CEST) Message-ID: <429255D5.4020309@cegetel.net> Date: Tue, 24 May 2005 00:14:45 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Refresher on Updated/Modified References: <200505220453.DFI52301@ms8.netsolmail.com> <429253BE.8050006@cegetel.net> In-Reply-To: <429253BE.8050006@cegetel.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 Thomas Broyer wrote: > If I already voted, please consider I've changed my mind to the > following: > > +0.8 to atom:modified, +1 if it is optional > > +1 to the above quoted text if atom:modified is accepted > Remove the "+1 if it is optional", I'm rather confused about optionality here... Sorry for Tim and Paul who are trying to count the points :-[ -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 18:41:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07309 for ; Mon, 23 May 2005 18:41: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 j4NMXkSE064718; Mon, 23 May 2005 15:33: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 j4NMXkfU064713; Mon, 23 May 2005 15:33:46 -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 j4NMXhlx064668 for ; Mon, 23 May 2005 15:33:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3823749wra for ; Mon, 23 May 2005 15:33:37 -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=RV+EoqlIVXlzHJSb0Sb3m3xUtp+mqbL5ewWFUhPbeJmIsYc4sMtG4IVoebJNwadhje4tu6WiDgw4MpsPvUYbTEzz3eo6H4Y/bOxpYL29vow/KTBauLjmsr0EXXgDvhOleqsiCUBoaY7p8AyqbXRiOc9m5Evq03X+FthdHZa47kU= Received: by 10.54.15.15 with SMTP id 15mr3745097wro; Mon, 23 May 2005 15:26:55 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 15:26:55 -0700 (PDT) Message-ID: <68fba5c5050523152643627ba2@mail.gmail.com> Date: Mon, 23 May 2005 18:26:55 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: posted PaceAuthorContributor Cc: Dan Brickley , atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> <20050523184419.GS16894@homer.w3.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NMXjlx064696 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Graham wrote: > > On 23 May 2005, at 7:44 pm, Dan Brickley wrote: > > > What we have today is http://dublincore.org/documents/dcmi-terms/#H2 > > "An entity primarily responsible for making the content of the > > resource." (Examples of a Creator include a person, an > > organisation, or > > a service. Typically, the name of a Creator should be used to indicate > > the entity.) > > The WG consensus in supporting multiple atom:authors seems to be > against having a singular creator, so -1 on this change. Dan tells us you can have multiple dc:creators. I didn't know that, but I'd be happy to use Dublin Core if we possibly can. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 18:45:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07892 for ; Mon, 23 May 2005 18:45: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 j4NMZfTc065445; Mon, 23 May 2005 15:35: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 j4NMZfuG065442; Mon, 23 May 2005 15:35:41 -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 j4NMZeNp065403 for ; Mon, 23 May 2005 15:35:40 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from boblaptop (unknown [212.129.242.87]) by mail.pubsub.com (Postfix) with ESMTP id BF3977242D3; Mon, 23 May 2005 18:35:31 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: Compulsory feed ID? Date: Mon, 23 May 2005 18:35:12 -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.2900.2180 Thread-Index: AcVeFcV0sX8rS5DxSYiwMcia+H9JygB0D6AQ Message-Id: <20050523223531.BF3977242D3@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 re the issue of DOS attacks: > I've been a bit surprised that you [Bob Wyman] haven't > been more active in taking the lead on pushing the conversation > forward and ensuring that threads addressing the issue don't die > out, given the strength of your comments on the issue in the past > and the obvious significance to your business. ... Perhaps > you, who are probably in a better position than any of us to speak > from experience on how to deal with this, could refresh our memories > of specifically what you think the best solution is. Yes, this issue is very important to us at PubSub and should be very important to others as well. However, as I've learned from other recent discussions, my viewpoint is not commonly held in this Working Group. Thus, what I've been trying to do is pick carefully the issues that I work on. For instance, I've put a great deal of effort into multiple ids since that allows us the freedom to either work out proprietary solutions to the DOS problem on our own or allows us to punt the problem forward to the end-users' aggregators if we can't come up with a decent solution. Clearly, the best solution here would be for folk to use signatures. But, that is going to take either a great deal of work to get adopted or something really creative (and simple)... The history of attempts to get signatures used does not make pleasant reading... We are putting effort into working out methods to make signatures more acceptable to the community and I hope to have some proposals soon... If we successful (wish us luck!) that will at least provide a solution for some people... Basically, it doesn't make sense for me to keep demanding that people deal with issues that they clearly don't want to address. I've been mentioning the DOS problem for months now and getting nowhere. So, the reason I'm not pushing harder is that it is clear that implementable work-arounds will be more useful than never agreed-to "solutions"... bob wyman From owner-atom-syntax@mail.imc.org Mon May 23 19:11:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12438 for ; Mon, 23 May 2005 19:11: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 j4NN2oZK074315; Mon, 23 May 2005 16:02: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 j4NN2oTa074314; Mon, 23 May 2005 16:02:50 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NN2m0l074288 for ; Mon, 23 May 2005 16:02:49 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.71.191]) by smtp.cegetel.net (Postfix) with ESMTP id 5A09D1A42FF; Tue, 24 May 2005 01:02:00 +0200 (CEST) Message-ID: <4292611B.2010908@cegetel.net> Date: Tue, 24 May 2005 01:02:51 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: David Powell Cc: "A. Pagaltzis" , Atom Syntax Subject: Re: Author and contributor References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> <687135975.20050523083600@djpowell.net> In-Reply-To: <687135975.20050523083600@djpowell.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I already voted but, for the record, I'm +1 on the three bullets. David Powell wrote: >Monday, May 23, 2005, 6:22:49 AM, A. Pagaltzis wrote: > > >>� make atom:author plural >> >> > >+1 in principle... > >But has anyone addressed how this will inherit - will >atom:entry/atom:author merge with the set of authors defined in >atom:feed/atom:author or will it replace them? > > +1 to replace >>� keep atom:contributor >> >> > >+1 > >(But we should clarify the inheritance rules - if there are any - to >avoid confusion with those of atom:author - if there any) > > The problem is mostly when there are author(s) without contributor in the feed (resp. entry) and contributor(s) without author in the entry (resp. feed). Is the entry author-less (resp. contributor-less) or is it inheriting the feed author(s) (resp. contributor(s))? I suggest considering author(s)+contributor(s) as a whole, that is, the entry would be author-less (resp. contributor-less). This issue would not exist if there couldn't be an atom:contributor without at least an atom:author, though I'm not sure this wouldn't bring some more issues... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon May 23 19:20:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13102 for ; Mon, 23 May 2005 19:20: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 j4NNDJAi076683; Mon, 23 May 2005 16:13: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 j4NNDIf0076656; Mon, 23 May 2005 16:13:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NNDEmV076501 for ; Mon, 23 May 2005 16:13:16 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000426111 for ; Tue, 24 May 2005 09:13:10 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 09:13:03 +1000 Subject: Re: atom:author clarification 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 24/5/05 4:14 AM, "Justin Fletcher" wrote: > As I understand it, the intention is that atom:author within atom:feed > applies to all child atom:entry elements; that is, the value is inherited. > This being the case I have a dilemma with a feed I would like to aggregate > from others. The intention has long been that. Text explaining that inheritance has slipped from the spec, and is currently up for discussion. > Is there a suitable place for identifying the feed's author without > affecting the entries themselves ? Is the atom:feed/atom:author a suitable > place for this ? Yes. If you are copying the entries from another feed you could also look at the atom:source element. e. From owner-atom-syntax@mail.imc.org Mon May 23 19:24:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13346 for ; Mon, 23 May 2005 19:24: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 j4NNHefA078164; Mon, 23 May 2005 16:17: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 j4NNHem8078163; Mon, 23 May 2005 16:17:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NNHcpF078153 for ; Mon, 23 May 2005 16:17:39 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050523231733.NQTE20297.mta10-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Tue, 24 May 2005 00:17:33 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050523231732.RJFT18138.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Tue, 24 May 2005 00:17:32 +0100 Date: Tue, 24 May 2005 00:17:30 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1815200729.20050524001730@djpowell.net> To: "Roger B." CC: Atom Syntax Subject: Re: Refresher on Updated/Modified In-Reply-To: <540e373205052222181f1d8e20@mail.gmail.com> References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@mail.gmail.com> <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@sun.com> <9710484656.20050522132116@djpowell.net> <540e373205052222181f1d8e20@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 Monday, May 23, 2005, 6:18:53 AM, Roger B wrote: > I'm asking you specifically because you seem to be approaching your > argument in a reasonable tone and fashion. My apologies if I'm > pestering. No apologies required, I welcome any useful criticism. > Near as I can tell, folks have modification dates. In my case, that is > a date that is updated every time the user clicks "save". In Tim's > case, that is a date that he chooses. In other apps, that may be a > date that matches when a new comment was added to a blog entry. > Nothing in the spec is going to change these realities. > And none of these approaches are *wrong*, or invalid. We each get to > define "change" in our own apps, so we can approach atom:modified's > MUST clause as we see fit. For all practical purposes, it doesn't > matter whether folks use atom:updated or atom:modified. > You're going to get the same date. You may get the same date in some cases, but not all. explained below... > With that in mind, what are the actual benefits of atom:modified over > atom:updated? The end result will always be identical, unless I'm > missing a crucial, well-hidden point. When a publisher updates an existing entry, the value that they put in atom:updated combines three parameters: a) The last modified date of the entry (ie: the value that would go into atom:modified if it existed) b) The atom:updated value of the previous instance. c) Whether the publisher's opinion is that the change is significant. (some publishing systems may not allow the publisher to express this opinion - in that case, this parameter will be hard-coded) The publisher chooses whether the new atom:updated value should be the current modification date, or the previous atom:updated value based on whether, in their opinion the change is significant. If a publisher wants to change an entry, and wants to indicate that in their opinion the change was not significant, the current draft allows them to do this by publishing a new version of the entry with the same value of atom:updated as the previous version. The problem is, for a set of instances of an entry (ie where the entry was modified over time) atom:updated is the only way for a publisher to indicate the order of those instances. So these instances become second-class, in the sense that the publisher is prevented from communicating this information. Given multiple instances of an entry, one original, and one that has been corrected, it is impossible to tell which is which, so any processor has a 50% or greater chance of displaying the wrong version. Fortunately, under typical circumstances, a Feed Document doesn't contain more than one instance of the same entry, so you can work out the order of instances from two separate polls based on when you polled the feed. But under other circumstances this is important. An example - Atom is supposed to support archiving according to the charter, but it isn't possible to archive a feed, unless you don't mind either a) the order of instances of entries that appeared in your feed being lost (so that it is impossible for a reader to tell which of two instances is the later one that incorporates corrections); or b) the archiver stripping out older instances before putting them in the archive - but this means that you only have a partial archive of what was published in your feed. Note that without atom:modified an archiver could only support b) if it was tightly coupled with the publishing process because the current draft of Atom is incapable of representing the modified dates of entry instances necessary for the archiver to strip out the older instances. (see - for more discussion of this example) PubSub is another example of a system where this is a problem - it's probably best to read what Bob Wyman says about that though. The recommendation made by PaceAllowDuplicateIDs to use atom:updated to select the latest instance of an entry, is a completely inappropriate use of atom:updated given its semantics, but unfortunately it is the only course of action unless atom:modified (or something similar) is introduced. > Please note that it has not escaped me that this cuts both ways. Why > fight for atom:updated over atom:modified when it is beyond the scope > of the Atom spec to define the nature of change in the universe? Hey, > if Tim doesn't consider a typo a real modification, then it just > isn't. Period. It's his writing, his app, and he defines the rules and > the terms. It has been suggested that atom:modified is being proposed because the processor mistrusts the publisher, or the publisher's opinion, or because the processor doesn't find the opinion significant. This couldn't be further from the truth. Without atom:modified, the feature of atom:updated that allows a publisher to express their opinion on significance, is a false promise. If publishers don't update atom:updated, the entry becomes second-class. In effect, in your example, if Tim wants to use Atom in certain ways, he won't get the option to express whether his modification is significant or not because the meaning of atom:updated in the spec is distorted by the implications of PaceAllowDuplicateIDs. -- Dave From owner-atom-syntax@mail.imc.org Mon May 23 19:30:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13669 for ; Mon, 23 May 2005 19:30: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 j4NNPjEp078566; Mon, 23 May 2005 16:25: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 j4NNPjS6078565; Mon, 23 May 2005 16:25:45 -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 j4NNPiWN078559 for ; Mon, 23 May 2005 16:25:44 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id CA9524F151; Mon, 23 May 2005 19:25:43 -0400 (EDT) Date: Mon, 23 May 2005 19:25:43 -0400 From: Dan Brickley To: Robert Sayre Cc: Graham , atom-syntax Subject: Re: posted PaceAuthorContributor Message-ID: <20050523232543.GX16894@homer.w3.org> References: <68fba5c505052309567351f24c@mail.gmail.com> <1D167DC9-3CE0-4B50-AC40-A984357C5277@mac.com> <20050523184419.GS16894@homer.w3.org> <68fba5c5050523152643627ba2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c5050523152643627ba2@mail.gmail.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.9i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Robert Sayre [2005-05-23 18:26-0400] > On 5/23/05, Graham wrote: > > > > On 23 May 2005, at 7:44 pm, Dan Brickley wrote: > > > > > What we have today is http://dublincore.org/documents/dcmi-terms/#H2 > > > "An entity primarily responsible for making the content of the > > > resource." (Examples of a Creator include a person, an > > > organisation, or > > > a service. Typically, the name of a Creator should be used to indicate > > > the entity.) > > > > The WG consensus in supporting multiple atom:authors seems to be > > against having a singular creator, so -1 on this change. > > Dan tells us you can have multiple dc:creators. I didn't know that, > but I'd be happy to use Dublin Core if we possibly can. Yep, all the main DC terms are considered optional and repeatable. Dan From owner-atom-syntax@mail.imc.org Mon May 23 19:31:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13696 for ; Mon, 23 May 2005 19:31: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 j4NNNCYZ078463; Mon, 23 May 2005 16:23: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 j4NNNC12078462; Mon, 23 May 2005 16:23: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-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 j4NNNBtU078455 for ; Mon, 23 May 2005 16:23:12 -0700 (PDT) (envelope-from gerph@gerph.org) Received: from dynamic-62-56-52-30.park-s46b.dslaccess.co.uk ([62.56.52.30] helo=buttercup.gerph.org) by anchor-post-33.mail.demon.net with esmtpa (AUTH gerph) (Exim 4.42) id 1DaMGM-0005EM-CP for atom-syntax@imc.org; Mon, 23 May 2005 23:23:10 +0000 Received: by buttercup.gerph.org (Postfix, from userid 1001) id 635C4F4434; Tue, 24 May 2005 00:23:01 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by buttercup.gerph.org (Postfix) with ESMTP id 5D080EC011 for ; Tue, 24 May 2005 00:23:01 +0100 (BST) Date: Tue, 24 May 2005 00:23:01 +0100 (BST) From: Justin Fletcher X-X-Sender: justin@buttercup.gerph.org To: Atom Syntax Subject: Re: atom:author clarification In-Reply-To: Message-ID: References: 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 Tue, 24 May 2005, Eric Scheid wrote: > > On 24/5/05 4:14 AM, "Justin Fletcher" wrote: > > As I understand it, the intention is that atom:author within atom:feed > > applies to all child atom:entry elements; that is, the value is inherited. > > This being the case I have a dilemma with a feed I would like to aggregate > > from others. > > The intention has long been that. Text explaining that inheritance has > slipped from the spec, and is currently up for discussion. > > > Is there a suitable place for identifying the feed's author without > > affecting the entries themselves ? Is the atom:feed/atom:author a suitable > > place for this ? > > Yes. If you are copying the entries from another feed you could also look at > the atom:source element. Ah yes; quite correct and quite clearly stated in the draft. Thanks for pointing that out, sorry for redundant question :-) -- Gerph ... I'm not just deaf and dumb; staring at the sun. From owner-atom-syntax@mail.imc.org Mon May 23 19:38:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14129 for ; Mon, 23 May 2005 19:38: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 j4NNVs61079045; Mon, 23 May 2005 16:31: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 j4NNVsBk079044; Mon, 23 May 2005 16:31:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NNVr7U079031 for ; Mon, 23 May 2005 16:31:53 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000426177 for ; Tue, 24 May 2005 09:31:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 09:31:49 +1000 Subject: Re: inheritance issues (was: Author and contributor) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4292611B.2010908@cegetel.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 24/5/05 9:02 AM, "Thomas Broyer" wrote: > The problem is mostly when there are author(s) without contributor in > the feed (resp. entry) and contributor(s) without author in the entry > (resp. feed). > Is the entry author-less (resp. contributor-less) or is it inheriting > the feed author(s) (resp. contributor(s))? > I suggest considering author(s)+contributor(s) as a whole, that is, the > entry would be author-less (resp. contributor-less). > > This issue would not exist if there couldn't be an atom:contributor > without at least an atom:author, though I'm not sure this wouldn't bring > some more issues... oh darn. This damn inheritance stuff is nasty. Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. e. From owner-atom-syntax@mail.imc.org Mon May 23 19:43:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14463 for ; Mon, 23 May 2005 19:43: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 j4NNZL7b079368; Mon, 23 May 2005 16:35: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 j4NNZLCV079367; Mon, 23 May 2005 16:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4NNZJDB079359 for ; Mon, 23 May 2005 16:35:20 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000426185 for ; Tue, 24 May 2005 09:35:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 09:35:16 +1000 Subject: Re: atom:author clarification 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 24/5/05 9:23 AM, "Justin Fletcher" wrote: > Ah yes; quite correct and quite clearly stated in the draft. Thanks for > pointing that out, sorry for redundant question :-) No, don't be sorry. We all know way too much about the spec text, getting outsiders to interpret what we've written is very important for feedback. Tim/Paul/Others: is there any process or such where we could take the time to get clueful outsiders to read over the spec and relate to us which parts are confusing. Ideally this should happen once we've run out of issues to distract us. e. From owner-atom-syntax@mail.imc.org Mon May 23 20:07:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16467 for ; Mon, 23 May 2005 20:07: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 j4NNwDgI081686; Mon, 23 May 2005 16:58: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 j4NNwDb8081685; Mon, 23 May 2005 16:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NNwBOj081674 for ; Mon, 23 May 2005 16:58:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4NNv15b009637; Tue, 24 May 2005 00:57:07 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54F96238-6C9A-48D4-B5AB-C427957E5A2B@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: inheritance issues (was: Author and contributor) Date: Tue, 24 May 2005 00:56:58 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 12:31 am, Eric Scheid wrote: > Second area of concern with writing the spec text - the atom:source > element > needs to be mentioned in the text about inheritance. My > understanding is > that inheritance draws first from atom:source (if it exists), and then > atom:feed. I'd say it draws from atom:source OR atom:feed. atom:feed should not be used if atom:source exists, even if it doesn't contain an atom:author, which it SHOULD. (unrelated question: what's with this plus sign " & atomLink+" in the atom:source production?) Graham From owner-atom-syntax@mail.imc.org Mon May 23 20:08:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16514 for ; Mon, 23 May 2005 20:08: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 j4O00Z3G081786; Mon, 23 May 2005 17: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 j4O00ZKZ081785; Mon, 23 May 2005 17:00:35 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O00YA6081778 for ; Mon, 23 May 2005 17:00:34 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 23 May 2005 17:00:28 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: atom:author clarification 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 9:35 AM +1000 5/24/05, Eric Scheid wrote: >Tim/Paul/Others: is there any process or such where we could take the time >to get clueful outsiders to read over the spec and relate to us which parts >are confusing. Ideally this should happen once we've run out of issues to >distract us. That was the IETF-wide last call, last month. The announcement was made on the IETF-Announce mailing list, and brought in a few folks. In addition, Tim and I pestered a number of people we know who we thought might not be following the document and asked them to look in. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon May 23 20:12:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16712 for ; Mon, 23 May 2005 20:12: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 j4O02OZ4081855; Mon, 23 May 2005 17:02: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 j4O02Og6081854; Mon, 23 May 2005 17:02:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4O02MOC081848 for ; Mon, 23 May 2005 17:02:23 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000426260 for ; Tue, 24 May 2005 10:02:18 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 10:02:16 +1000 Subject: Re: inheritance issues (was: Author and contributor) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <54F96238-6C9A-48D4-B5AB-C427957E5A2B@mac.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 24/5/05 9:56 AM, "Graham" wrote: > I'd say it draws from atom:source OR atom:feed. > You meant atom:source XOR atom:feed? > atom:feed should not be used if atom:source exists, even if it doesn't > contain an atom:author, which it SHOULD. > (well, it SHOULD, unless atom:entry already contains atom:author, right?) > (unrelated question: what's with this plus sign " & atomLink+" in the > atom:source production?) > well spotted. e. From owner-atom-syntax@mail.imc.org Mon May 23 20:15:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16965 for ; Mon, 23 May 2005 20:15: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 j4O0376E081893; Mon, 23 May 2005 17: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 j4O037K7081892; Mon, 23 May 2005 17:03:07 -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 j4O036Qr081883 for ; Mon, 23 May 2005 17:03:07 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 9082 messnum 5269866 invoked from network[83.70.217.193/unknown]); 24 May 2005 00:03:00 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail04.svc.cra.dublin.eircom.net (qp 9082) with SMTP; 24 May 2005 00:03:00 -0000 Message-ID: <42926F2E.4030700@dehora.net> Date: Tue, 24 May 2005 01:02:54 +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: inheritance issues 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: > oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill From owner-atom-syntax@mail.imc.org Mon May 23 20:45:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18473 for ; Mon, 23 May 2005 20:45: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 j4O0auB1085512; Mon, 23 May 2005 17:36: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 j4O0aupK085511; Mon, 23 May 2005 17:36:56 -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 j4O0atcn085500 for ; Mon, 23 May 2005 17:36:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3884210wra for ; Mon, 23 May 2005 17:36:50 -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=XtvQLYdz4z4zdxTrwFMLN9PO4fCKCdsnUCjFUIWQ8XEhgoZbCB+Mvy+AZDe4J1w0InD4mwuOutnBddvzJhOb+XrHZ+0gLNDn8MvjYxFZ2ommppdeiBlWZv9jaz+Q6+7Svu14IDnwc+8GcR4qq5ZKQ4CA2uK+XKl8VGlbUfOVc/g= Received: by 10.54.107.4 with SMTP id f4mr3811092wrc; Mon, 23 May 2005 17:36:50 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 17:36:50 -0700 (PDT) Message-ID: <68fba5c50505231736501820dd@mail.gmail.com> Date: Mon, 23 May 2005 20:36:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: inheritance issues (was: Author and contributor) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <54F96238-6C9A-48D4-B5AB-C427957E5A2B@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O0atcn085504 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/23/05, Eric Scheid wrote: > On 24/5/05 9:56 AM, "Graham" wrote: > > (unrelated question: what's with this plus sign " & atomLink+" in the > > atom:source production?) > > > well spotted. That means "oneOrMore", while "*" means "zeroOrMore". "+" is accurate for format-08, which requires an alternate link. Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 21:10:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19939 for ; Mon, 23 May 2005 21:10: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 j4O0mrwR086013; Mon, 23 May 2005 17:48: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 j4O0mrlM086012; Mon, 23 May 2005 17:48:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4O0mpfe086006 for ; Mon, 23 May 2005 17:48:52 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000426357 for ; Tue, 24 May 2005 10:48:50 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 10:48:48 +1000 Subject: Re: inheritance issues (was: Author and contributor) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <68fba5c50505231736501820dd@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 24/5/05 10:36 AM, "Robert Sayre" wrote: > On 5/23/05, Eric Scheid wrote: >> On 24/5/05 9:56 AM, "Graham" wrote: >>> (unrelated question: what's with this plus sign " & atomLink+" in the >>> atom:source production?) >>> >> well spotted. > > That means "oneOrMore", while "*" means "zeroOrMore". "+" is accurate > for format-08, which requires an alternate link. and yet atom:source goes at length to say it is optional, and also "some or all" metadata elements could be copied, and while it encourages the copying of atom:author, atom:contributor, atom:copyright, and atom:category, the spec text provides no guidance or requirement that link[@rel=alternate] MUST be copied. The text is normative, the rnc is not, and on that distinction it would be valid to not copy any links. Alternatively, it would also be entirely valid (given the spec text there), to copy some other link (eg. @rel=self) and not copy the @rel=alternate link at all. Is this what we meant the spec to say? e. From owner-atom-syntax@mail.imc.org Mon May 23 21:12:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20028 for ; Mon, 23 May 2005 21:12: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 j4O0wUpg086567; Mon, 23 May 2005 17:58: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 j4O0wUCY086566; Mon, 23 May 2005 17:58: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 j4O0wTGR086558 for ; Mon, 23 May 2005 17:58:29 -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 90472D9 for ; Mon, 23 May 2005 17:58:24 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4O0wNng001505 for ; Mon, 23 May 2005 17:58:24 -0700 (PDT) Date: Mon, 23 May 2005 17:59:04 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: inheritance issues Message-ID: <7A40099C20AA985D7CF5715B@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <42926F2E.4030700@dehora.net> References: <42926F2E.4030700@dehora.net> X-Mailer: Mulberry/4.0.0b3 (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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O0wUGR086561 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit --On May 24, 2005 1:02:54 AM +0100 Bill de hÓra wrote: > > Inheritance suggests a programming model to allow the evaluator to be coded for it. Which is why it shouldn't be called "inheritance". I'd prefer something like "cascading values". wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon May 23 21:34:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21501 for ; Mon, 23 May 2005 21:34: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 j4O1Nun3094994; Mon, 23 May 2005 18:23: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 j4O1NuHU094993; Mon, 23 May 2005 18:23:56 -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 j4O1NtqW094948 for ; Mon, 23 May 2005 18:23:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so3907674wra for ; Mon, 23 May 2005 18:23:49 -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=ZygYd4fOoMSZgtakzDQytv/Oge+AfGpj0GRGKbhrkIyRcNwkhT15wLH3mCl34JuDSg1M/qbYkNtUW7AQuV7XSU0G5HmHkQsR0yBoh1QcH5SFZkJ87INwNENB3AY4n6de8ldPQ4Phrt6+0o1oeiQXEqhcDfrJXwtqjSFCMU9RjFc= Received: by 10.54.15.15 with SMTP id 15mr3834636wro; Mon, 23 May 2005 18:23:49 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Mon, 23 May 2005 18:23:49 -0700 (PDT) Message-ID: <68fba5c5050523182375fc7717@mail.gmail.com> Date: Mon, 23 May 2005 21:23:49 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Eric Scheid Subject: Re: inheritance issues (was: Author and contributor) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c50505231736501820dd@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O1NuqW094986 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit "If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. " On 5/23/05, Eric Scheid wrote: > and yet atom:source goes at length to say it is optional, Disagree, the MAY is about putting atom:source in at all (yes, it's possible to copy entries without using atom:source). The text implies that the source must be an atom:feed element, and those have required elements. The RNC also requires atom:title and atom:updated, etc. I guess we could add "All required feed metadata elements MUST be present". OK? Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 23 22:53:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25706 for ; Mon, 23 May 2005 22:53: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 j4O2YhYU029932; Mon, 23 May 2005 19:34: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 j4O2YhSU029931; Mon, 23 May 2005 19:34:43 -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 j4O2Yfaj029901 for ; Mon, 23 May 2005 19:34:42 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 May 2005 02:34:35 -0000 Received: from xdsl-213-196-225-105.netcologne.de (EHLO klangraum) [213.196.225.105] by mail.gmx.net (mp018) with SMTP; 24 May 2005 04:34:35 +0200 X-Authenticated: #163624 Date: Tue, 24 May 2005 04:38:13 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: inheritance issues (was: Author and contributor) Message-ID: <20050524023813.GA1394@klangraum> Mail-Followup-To: Atom Syntax References: <4292611B.2010908@cegetel.net> 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-05-24 01:40]: > Consider too a feed which has both authors and contributors at > the feed level, an entry with neither authors or contributors > (simple case of inheritance), and another entry with a single > author and no contributors (does the entry inherit the feed > contributors?), and a third entry with no specified author > (inherits, right?), but with contributors (no inheritance, > right?). > > The first case is easy to guess the intention. The third case > is easy to guess the intention. It's the second case which is > the beotch. I think of these things in terms of what is possible to express. a) Any entry always has an author. b) A feed may or may not have an author. c) An entry may or may not have contributors. d) A feed may or may not have contributors. Any solution must not prevent any of these from being expressible. I already discussed why replacement is preferrable to merging when any of these are given at both the feed and entry level. Now with that in mind, c) and d) suggest to me that atom:feed/atom:contributor never inherits to entries. If entries were to inherit from the feed, then in a feed with contributors it is not possible to express that an entry had no contributors. With atom:author we can inherit safely, because a) means that there is no case in which an entry can have no author, which means that specifying an inheritable author at the feed level does not pose a problem in expressing any of the possible cases for an entry. So in summary: The set of atom:entry/atom:author overrides the set of atom:feed/atom:author for a particular entry, should the set be non-empty. [Inheritance with replacement semantics.] The set of atom:feed/atom:contributor applies only to the feed and not to any of its entries. [No inheritance.] Any permissible assertion about the feed and one of its entries is thus possible. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 00:28:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00695 for ; Tue, 24 May 2005 00:28: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 j4O46RkQ055487; Mon, 23 May 2005 21:06: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 j4O46RN5055486; Mon, 23 May 2005 21:06:27 -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 j4O46Q54055455 for ; Mon, 23 May 2005 21:06:26 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 38341 invoked by uid 60001); 24 May 2005 04:06:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=6kYRnHvnZT5n+9MrS7umjsMWO7kehHufFIcPGY0y25Pdvhf9EqjvlfWEoJbLbgfJa/J1lAM2QdpNXFqQWc4lPRSN85qUhNIBFHtBAhfRz5v1cTKGWhWZ0VeefiaVx5fb3wJ12L7B+D8GHkLNKfslJsU3hSDj8OhrZfMqPV3JGMQ= ; Message-ID: <20050524040620.38339.qmail@web42204.mail.yahoo.com> Received: from [4.155.102.57] by web42204.mail.yahoo.com via HTTP; Mon, 23 May 2005 21:06:20 PDT Date: Mon, 23 May 2005 21:06:20 -0700 (PDT) From: James Cerra Subject: Re: atom:type, xsl:output To: Graham Cc: atom-syntax In-Reply-To: 6667 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: Graham, > > * When @type="html" then the content of the element is a xsd:string > > [1] of an HTML DIV element plus optional insignificant whitespace > > around it. Which version of HTML is defined? How do you > > differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or > > "nonstandard" HTML (like with marquee elements)? > > I believe the answer would be "street HTML", not any > specific version. I don't like this, since the behavior of an unknown version of HTML is obviously undefined. You can't expect any HTML processors (used to parse atom content items) to follow the standards when the standard of the instance being used is unknown! There should be a way to identify the version of html used so that the behavior of the processor can be explicitly defined. > > * When @type="mime/type" [2], ONLY for atom:content, then the content > > (or src document) is that type of document. Why > not allow other > > elements to use this? > > Because the other elements are for purely textual > content. I understand. > > XML 1.1 > > Not supported. I'm confused. There is nothing inherent in the spec that prevents XML 1.1 or any future versions from being supported. And why introduce incompatibilities in atom:content that also bork with arbitrary XML 1.0 documents too? I assert this, because the spec says in section 4.1.3.3, "Processing Model," that: ] 4. If the value of "type" ends with "+xml" or "/xml" ] (case-insensitive), the content of atom:content MAY include child ] elements, and SHOULD be suitable for handling as the indicated ] media type. If the "src" attribute is not provided, this would ] normally mean that the "atom:content" element would contain a ] single child element which would serve as the root element of the ] XML document of the indicated type. First off: it is an error to lie about your media-type, so I would change "SHOULD be suitable for handling as the indicated media type" to "MUST be suitable for handling as the indicated media type." Secondly, XML may be entity (or CDATA) encoded like @type="html" or plain xml like @type="xhtml". This is becuase of the "content of atom:content MAY include child elements" phrase. There is no guarantee if an entity escaped passage is xml or a text node example of an xml document (i.e. an example of an xml document), for example. SO the following could legally be interpreted as either a text node or as full-fledged xml: ] <?xml version="1.0?> ] <tag /> There is no way to make even an educated guess in advance without reading the text node with an xml processor and seeing if it is well-formed. This really sucks for processing Atom with XSLT. In any case, the above example could never be "the root element of the XML document of the indicated type" if written as xml instead of entity-escaped either, since there is that pesky XML declaration. Yet it still conforms to what the mime type says it is. That's one reason why I think this is a bug in the Atom spec. It's also a reason why I wish atom:content adopted xslt:output attributes for specifying the doctype/xml declaration and version info of the content. Finally: In general there could also be processing instructions that must be put as children of the atom:content element, but how should they be interpreted? A non-atom aware processor will read those processing instructions as belonging to the ATOM DOCUMENT instead of the atom:content's XML CONTENT! This is a horrible situation, especially when you want the content of a blog to be an actual XML document that uses XML declarations, DOCTYPE declarations, and processing instructions. There needs to be a way to specify these things without using an external file referenced with a @src attribute. > > RTF > > It is compatible, as a string, though certain > obsolete characters are > not. > > > PNG > > Should be base64 encoded. I understand, thanks. > > What should one do when encountering these > situations? > > See section 4.1.3.3 Processing Model Thanks for the pointer. I can't believe I missed that. -- Jimmy Cerra P.S. Thanks you Danny Ayers, wherever you are! __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From owner-atom-syntax@mail.imc.org Tue May 24 02:34:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29735 for ; Tue, 24 May 2005 02:34: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 j4O6IWXP000523; Mon, 23 May 2005 23:18: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 j4O6IWt9000521; Mon, 23 May 2005 23:18:32 -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 j4O6IWVH000514 for ; Mon, 23 May 2005 23:18:32 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 95566 invoked by uid 17064); 24 May 2005 06:18:31 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.129.28]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 May 2005 06:18:31 -0000 In-Reply-To: <1815200729.20050524001730@djpowell.net> References: <605006053.20050521013328@djpowell.net> <540e373205052020267b835937@mail.gmail.com> <2FA710CE-A002-43B5-A7AD-0EAE6BDB8810@sun.com> <9710484656.20050522132116@djpowell.net> <540e373205052222181f1d8e20@mail.gmail.com> <1815200729.20050524001730@djpowell.net> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Refresher on Updated/Modified Date: Tue, 24 May 2005 08:18:28 +0200 To: David Powell , atom-syntax Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My thought currently is that atom:updated by being the sole date in atom is in fact what people are thinking of as atom:modified. It is just specified very flexibly and constrained not by language but by how it will be used. The game of publishing entries will push people to be reasonably precise about what they consider to be a change: - if they don't, their entries may be lost - creating a new time stamp is so easy, there is no reason not to change the time stamp by default So I am in fact -1 on atom:modified. It would be silly to have 2 dates in atom, we would then just have more confusion and corner cases. The more precise date would inevitably be considered the real one, and the other one ignored in any case. Adding a more precise definition of what constitutes a change is beyond the ability of this working group given the way it has to come to an agreement. On 24 May 2005, at 01:17, David Powell wrote: >> > > When a publisher updates an existing entry, the value that they put in > atom:updated combines three parameters: > > a) The last modified date of the entry (ie: the value that would go > into atom:modified if it existed) > > b) The atom:updated value of the previous instance. > > c) Whether the publisher's opinion is that the change is significant. > (some publishing systems may not allow the publisher to express > this opinion - in that case, this parameter will be hard-coded) > > The publisher chooses whether the new atom:updated value should be the > current modification date, or the previous atom:updated value based on > whether, in their opinion the change is significant. > > If a publisher wants to change an entry, and wants to > indicate that in their opinion the change was not significant, the > current draft allows them to do this by publishing a new version of > the entry with the same value of atom:updated as the previous version. From owner-atom-syntax@mail.imc.org Tue May 24 02:42:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00261 for ; Tue, 24 May 2005 02:42: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 j4O6G04W099517; Mon, 23 May 2005 23:16: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 j4O6G0Cl099516; Mon, 23 May 2005 23:16: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O6FxiD099476 for ; Mon, 23 May 2005 23:16:00 -0700 (PDT) (envelope-from jalkanen@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so195425wri for ; Mon, 23 May 2005 23:15:54 -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=lgldwe9R5kZlTdynipXIYoy9KDRGwoTirdy3vYVLGr/Y4S5eIfzV5HSaEbAJ+gwHqsq/4bqvtAk8Muo4HFF9BQQigXHzlMqXFumDzVgdARtPFU8+SA1cbqOW2TO0aZqwwrBda3VASjj8UkGqCI6ogfTMKXHYfO6qPYDTlcqpEz0= Received: by 10.54.83.5 with SMTP id g5mr277617wrb; Mon, 23 May 2005 23:15:54 -0700 (PDT) Received: by 10.54.28.73 with HTTP; Mon, 23 May 2005 23:15:54 -0700 (PDT) Message-ID: <7aebae7d05052323155070b50f@mail.gmail.com> Date: Tue, 24 May 2005 09:15:54 +0300 From: Janne Jalkanen Reply-To: Janne Jalkanen To: Atom Syntax Subject: Re: Author and contributor In-Reply-To: <20050523052249.GA31955@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j4O6G0iD099509 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Antone Roundy suggests: > make atom:author plural > keep atom:contributor > punt bylines to an extension > > To me that sounds like the simplest thing that can possibly work, > and looks like it hits the 80/20 mark. It also requires the least > squabbling over its implementation. And Robert has expressed that > he is fine with the proposal in that thread. +1 from here too; works well for me. /Janne From owner-atom-syntax@mail.imc.org Tue May 24 03:33:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03464 for ; Tue, 24 May 2005 03:33: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 j4O70Cvi025154; Tue, 24 May 2005 00: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 j4O70Cc9025153; Tue, 24 May 2005 00:00:12 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O70AAg025074 for ; Tue, 24 May 2005 00:00:11 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-105.dti.cegetel.net [217.19.192.105]) by smtp.cegetel.net (Postfix) with SMTP id 01CAC1A4441; Tue, 24 May 2005 08:59:21 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 09:00:04 +0200 (CEST) Message-ID: <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 09:00:04 +0200 (CEST) Subject: Re: inheritance issues (was: Author and contributor) From: "Thomas Broyer" To: In-Reply-To: <20050524023813.GA1394@klangraum> References: <4292611B.2010908@cegetel.net> <20050524023813.GA1394@klangraum> 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 A. Pagaltzis wrote: > > * Eric Scheid [2005-05-24 01:40]: >> Consider too a feed which has both authors and contributors at >> the feed level, an entry with neither authors or contributors >> (simple case of inheritance), and another entry with a single >> author and no contributors (does the entry inherit the feed >> contributors?), and a third entry with no specified author >> (inherits, right?), but with contributors (no inheritance, >> right?). >> >> The first case is easy to guess the intention. The third case >> is easy to guess the intention. It's the second case which is >> the beotch. > > I think of these things in terms of what is possible to express. > > a) Any entry always has an author. Right, I forgot that. Actually, I was reading the format-08 "inlined" RNC, which doesn't include the schematron rules. Could there be some "improvement" to the spec? > b) A feed may or may not have an author. > c) An entry may or may not have contributors. > d) A feed may or may not have contributors. > > Any solution must not prevent any of these from being > expressible. > > I already discussed why replacement is preferrable to merging > when any of these are given at both the feed and entry level. > > Now with that in mind, c) and d) suggest to me that > atom:feed/atom:contributor never inherits to entries. If entries > were to inherit from the feed, then in a feed with contributors > it is not possible to express that an entry had no contributors. Not if you consider the "group" formed by the authors and contributors. Hmm, what about that: feed level contributors cascade to the entry level only when there is an atom:author element at the feed level which also cascades. Er, I might be not quite clear, so let's see examples: how would you interpret the following? a) feed: author: A contributor: B entry: no author not contributor b) feed: author: A contributor: B entry: author: C c) feed: author: A contributor: B entry: contributor: C d) feed: contributor: A entry: author: B contributor: C e) feed: contributor: A entry: author: B Other cases don't have any problem (or I missed it) or are invalid (e.g. no author at all) a) The entry inherits both the author and contributor from the feed. b) The entry inherits nothing from the feed. c) The entry inherits the author but overrides the contributor. I'm also open to considering it invalid. d) The entry inherits nothing from the feed. e) The entry inherits nothing from the feed. Let's see what others have to say about this and then find the appropriate wording. > So in summary: > > The set of atom:entry/atom:author overrides the set of > atom:feed/atom:author for a particular entry, should the set > be non-empty. [Inheritance with replacement semantics.] > > The set of atom:feed/atom:contributor applies only to the > feed and not to any of its entries. [No inheritance.] I'm not opposed to that but it might not be obvious in the a) example above. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 04:18:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05976 for ; Tue, 24 May 2005 04:18: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 j4O7qAxO049073; Tue, 24 May 2005 00:52: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 j4O7qAVm049072; Tue, 24 May 2005 00:52: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 j4O7qAGs049065 for ; Tue, 24 May 2005 00:52:10 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 29968 invoked by uid 17064); 24 May 2005 07:52:09 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.129.28]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 24 May 2005 07:52:09 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <42926F2E.4030700@dehora.net> References: <42926F2E.4030700@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3AF9E206-2A05-4FC6-80C9-BEFDB80B1659@bblfish.net> From: Henry Story Subject: Re: inheritance issues Date: Tue, 24 May 2005 09:52:07 +0200 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax Syntax X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O7qAGs049066 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Simplify, simplify. I am for removing all inheritance mechanisms... Henry On 24 May 2005, at 02:02, Bill de hra wrote: > Eric Scheid wrote: >> oh darn. This damn inheritance stuff is nasty. >> > > Inheritance suggests a programming model to allow the evaluator to > be coded for it. It's rarely as simple as it looks to define a > decent model that does what people think it does at first glance. > As things stand, it will be an immense coincidence if we do not end > up dishing out nasty surprises for users. Atom's just not a very > good programming language ;) > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Tue May 24 04:22:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06237 for ; Tue, 24 May 2005 04: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 j4O8AVXe055282; Tue, 24 May 2005 01:10: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 j4O8AVRx055281; Tue, 24 May 2005 01:10: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 j4O8ATdc055241 for ; Tue, 24 May 2005 01:10:30 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 May 2005 08:10:23 -0000 Received: from xdsl-213-196-225-105.netcologne.de (EHLO klangraum) [213.196.225.105] by mail.gmx.net (mp008) with SMTP; 24 May 2005 10:10:23 +0200 X-Authenticated: #163624 Date: Tue, 24 May 2005 10:14:01 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: atom:type, xsl:output Message-ID: <20050524081401.GC2613@klangraum> Mail-Followup-To: atom-syntax References: <20050524040620.38339.qmail@web42204.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050524040620.38339.qmail@web42204.mail.yahoo.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: 8bit * James Cerra [2005-05-24 06:35]: > > > XML 1.1 > > > > Not supported. > > I'm confused. There is nothing inherent in the spec that > prevents XML 1.1 or any future versions from being supported. > And why introduce incompatibilities in atom:content that also > bork with arbitrary XML 1.0 documents too? I assert this, > because the spec says in section 4.1.3.3, "Processing Model," > that: You can only embed XML 1.1 documents directly into another document if that document is also XML 1.1. (Note that I am not talking about transporting XML 1.1 documents as an opaque serialized string.) Embedding XML 1.1 documents inside an XML 1.0 document is not possible, because • XML 1.1 allows control characters to be included as entities which XML 1.0 forbids in any form, • an XML 1.0 processor will not understand an embedded XML 1.1 document, • etc. > ] 4. If the value of "type" ends with "+xml" or "/xml" > ] (case-insensitive), the content of atom:content MAY > ] include child elements, and SHOULD be suitable for > ] handling as the indicated media type. If the "src" > ] attribute is not provided, this would normally mean that > ] the "atom:content" element would contain a single child > ] element which would serve as the root element of the XML > ] document of the indicated type. > > First off: it is an error to lie about your media-type, so I > would change "SHOULD be suitable for handling as the indicated > media type" to "MUST be suitable for handling as the indicated > media type." An Atom processor does not know whether the embedded XML document is a valid document of the given type. Only an attached processor for the given document type will be able to decide. As such, the validity of the Atom feed document is not affected by the media type. It will, of course, cause interop problems if you lie about the media type, hence SHOULD. > Secondly, XML may be entity (or CDATA) encoded like > @type="html" or plain xml like @type="xhtml". This is becuase > of the "content of atom:content MAY include child elements" > phrase. There is no guarantee if an entity escaped passage is > xml or a text node example of an xml document (i.e. an example > of an xml document), for example. No. Wrong. There is nothing saying that the content of atom:content MAY be a text node. It MAY only be a child element. If there is no child element, @src must be set, ie the XML document constituting the content is external to the feed. I will say, though, the the spec could stand to be more explicit in this instance. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 04:35:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07160 for ; Tue, 24 May 2005 04:35: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 j4O7m9pb047865; Tue, 24 May 2005 00:48: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 j4O7m9B1047864; Tue, 24 May 2005 00:48:09 -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 j4O7m7L0047827 for ; Tue, 24 May 2005 00:48:08 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 May 2005 07:48:01 -0000 Received: from xdsl-213-196-225-105.netcologne.de (EHLO klangraum) [213.196.225.105] by mail.gmx.net (mp025) with SMTP; 24 May 2005 09:48:01 +0200 X-Authenticated: #163624 Date: Tue, 24 May 2005 09:51:39 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: inheritance issues (was: Author and contributor) Message-ID: <20050524075139.GB2613@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4292611B.2010908@cegetel.net> <20050524023813.GA1394@klangraum> <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.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: * Thomas Broyer [2005-05-24 09:05]: > a) > feed: > author: A > contributor: B > entry: > no author not contributor > > b) > feed: > author: A > contributor: B > entry: > author: C > > c) > feed: > author: A > contributor: B > entry: > contributor: C > > d) > feed: > contributor: A > entry: > author: B > contributor: C > > e) > feed: > contributor: A > entry: > author: B > > a) The entry inherits both the author and contributor from the feed. > b) The entry inherits nothing from the feed. > c) The entry inherits the author but overrides the contributor. I'm > also open to considering it invalid. > d) The entry inherits nothing from the feed. > e) The entry inherits nothing from the feed. > > Let's see what others have to say about this and then find the > appropriate wording. Thanks for taking the time to spell out combinations; good food for thought. You are right that the entry in a) not inheriting contributors, as per my proposed rules, would be counterintuitive. The rule you propose for contributor semi-inheritance is hard to explain clearly in prose and somewhat convoluted to implement in code though. And while I have not gotten around to learning RELAX NG, it also seems that it would be non-trivial to express as any form of grammar. After looking at all these cases, I would instead suggest that we prohibit atom:contributor in absence of an atom:author at the same level. That would make all of c), d) and e) invalid. Note that the semantics you propose for c), d) and e) are still expressible, they just require more repetition. Effectively, I am proposing: A non-empty set of atom:entry/atom:author overrides any set of atom:feed/atom:author and atom:feed/atom:contributor. atom:contributor may only appear if ../atom:author is also given. That seems like it would isolate the specification of atom:contributor from any inheritance issues, whose discussion could be confined to the specification of atom:author. The only constellation that would have been possible with your proposed set of restrictions, which my set of restrictions no longer allow, is expressing that feed has only contributors, but no authors. If anyone feels that such feeds must be expressible, then the restrictions could be loosened so that only atom:entry/atom:contributor requires an ../atom:author; however, as long as noone feels that way, I suggest that the restriction be symmetric to simplify specification and implementation. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 04:36:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07250 for ; Tue, 24 May 2005 04:36: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 j4O8MZBE059153; Tue, 24 May 2005 01:22: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 j4O8MZxU059152; Tue, 24 May 2005 01:22:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4O8MXog059122 for ; Tue, 24 May 2005 01:22:34 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000427390 for ; Tue, 24 May 2005 18:22:30 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 May 2005 18:22:29 +1000 Subject: extension elements inside link elements? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O8MZog059145 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > 4.2.9The "atom:link" Element > > The "atom:link" element is an empty element that defines a reference from an > entry or feed to a Web resource. did we want to prevent expressions like this: e. From owner-atom-syntax@mail.imc.org Tue May 24 04:44:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08065 for ; Tue, 24 May 2005 04:44: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 j4O8RFi5060743; Tue, 24 May 2005 01:27: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 j4O8RFnf060742; Tue, 24 May 2005 01:27:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O8REIv060686 for ; Tue, 24 May 2005 01:27:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4O8POei020980; Tue, 24 May 2005 09:25:34 +0100 (BST) In-Reply-To: <20050524040620.38339.qmail@web42204.mail.yahoo.com> References: <20050524040620.38339.qmail@web42204.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69978119-0C18-40E0-83A0-EBFF1EFFA732@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: atom:type, xsl:output Date: Tue, 24 May 2005 09:25:27 +0100 To: James Cerra X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 5:06 am, James Cerra wrote: > First off: it is an error to lie about your > media-type, so I would change "SHOULD be suitable for > handling as the indicated media type" to "MUST be > suitable for handling as the indicated media type." +1 > Secondly, XML may be entity (or CDATA) encoded like > @type="html" or plain xml like @type="xhtml". This is > becuase of the "content of atom:content MAY include > child elements" phrase. There is no guarantee if an > entity escaped passage is xml or a text node example > of an xml document (i.e. an example of an xml > document), for example. If I follow you right, you misunderstand. Atom documents are unambiguous. XML has to be inserted literally, with no entity escaping (except for entities that are part of text nodes) allowed. > > <?xml version="1.0?> > <tag /> This is invalid, since it has no root element. It represents the standalone XML document: <?xml version="1.0?> <tag /> This is correct: Graham From owner-atom-syntax@mail.imc.org Tue May 24 04:50:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08579 for ; Tue, 24 May 2005 04:50: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 j4O8TBiX061353; Tue, 24 May 2005 01:29: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 j4O8TBAg061352; Tue, 24 May 2005 01:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O8TAHH061301 for ; Tue, 24 May 2005 01:29:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4O8RklY021972; Tue, 24 May 2005 09:27:46 +0100 (BST) In-Reply-To: <68fba5c5050523182375fc7717@mail.gmail.com> References: <68fba5c50505231736501820dd@mail.gmail.com> <68fba5c5050523182375fc7717@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: atom:source Date: Tue, 24 May 2005 09:27:48 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 2:23 am, Robert Sayre wrote: > Disagree, the MAY is about putting atom:source in at all (yes, it's > possible to copy entries without using atom:source). The text implies > that the source must be an atom:feed element, and those have required > elements. The RNC also requires atom:title and atom:updated, etc. I > guess we could add "All required feed metadata elements MUST be > present". OK? I think the thing it's missing is "All elements MUST be copied when creating an atom:source from an atom:feed" Graham From owner-atom-syntax@mail.imc.org Tue May 24 05:13:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09833 for ; Tue, 24 May 2005 05:13: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 j4O8f0Ec067136; Tue, 24 May 2005 01: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 j4O8f0g7067135; Tue, 24 May 2005 01:41:00 -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 j4O8exfx067118 for ; Tue, 24 May 2005 01:40:59 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:63218 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1229304AbVEXIky (ORCPT ); Tue, 24 May 2005 11:40:54 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <4291A2F2.6030306@gmx.de> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: some small comments on 08 Date: Tue, 24 May 2005 11:40:33 +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 May 23, 2005, at 12:31, Julian Reschke wrote: > For the record: I am +1 on > . +1 from me too. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue May 24 05:35:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10977 for ; Tue, 24 May 2005 05:35: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 j4O9I4Y0082512; Tue, 24 May 2005 02:18: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 j4O9I4ro082511; Tue, 24 May 2005 02:18:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O9I3wP082472 for ; Tue, 24 May 2005 02:18:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4O9GNg0014736 for ; Tue, 24 May 2005 10:16:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: some small comments on 08 Date: Tue, 24 May 2005 10:16:27 +0100 To: atom-syntax X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 9:40 am, Henri Sivonen wrote: > On May 23, 2005, at 12:31, Julian Reschke wrote: > > >> For the record: I am +1 on > PaceOptionalXhtmlDiv>. -1, and additionally I don't think the Pace is even complete or reliably implementable. Graham From owner-atom-syntax@mail.imc.org Tue May 24 06:28:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14188 for ; Tue, 24 May 2005 06:28: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 j4OA7tNu006647; Tue, 24 May 2005 03:07: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 j4OA7tBP006646; Tue, 24 May 2005 03:07:55 -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 j4OA7s2S006636 for ; Tue, 24 May 2005 03:07:55 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4OA7sjO001527 for ; Tue, 24 May 2005 04:07:54 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IGZ00F01NQXNH@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Tue, 24 May 2005 06:07:54 -0400 (EDT) Received: from localhost (vpn-129-150-32-98.Central.Sun.COM [129.150.32.98]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IGZ005NAO54DG@bur-mail1.east.sun.com> for atom-syntax@imc.org; Tue, 24 May 2005 06:07:53 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DaWKg-00073H-9b for atom-syntax@imc.org; Tue, 24 May 2005 12:08:18 +0200 X-URL: http://nwalsh.com/ Date: Tue, 24 May 2005 12:08:17 +0200 From: Norman Walsh Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) In-reply-to: <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> To: atom-syntax@imc.org Message-id: <87y8a5kkby.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <428FB78D.9000401@cegetel.net> <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Martin Duerst was heard to say: | If there is actual non-determinism now in the Atom core, that would be | a reason for concern. If there is potential non-determinism in the Look at the content model for entry: it's a bag o' stuff some of which is required and some of which is optional (and optionally repeatable) and it's all allowed to occur in any order. I've forgotten the details of XSD's support for "&" content models, but I'm pretty sure that's beyond them. Be seeing you, norm =2D-=20 Norman Walsh | We are more ready to try the untried http://nwalsh.com/ | when what we do is inconsequential. | Hence the fact that many inventions had | their birth as toys.--Eric Hoffer --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCkv0ROyltUcwYWjsRAiG4AJ9y75jknL2RSXbx1V96P4ouWqgmGACbBvwR pEFGPaHpEzPo5OCNa3CK2iw= =ogWX -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Tue May 24 06:38:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15155 for ; Tue, 24 May 2005 06:38: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 j4OA6IVM006137; Tue, 24 May 2005 03:06: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 j4OA6Isq006136; Tue, 24 May 2005 03:06:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OA6Hhr006099 for ; Tue, 24 May 2005 03:06:17 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4OA4nGJ010517 for ; Tue, 24 May 2005 11:04:50 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: some small comments on 08 Date: Tue, 24 May 2005 10:16:27 +0100 To: atom-syntax X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 9:40 am, Henri Sivonen wrote: > On May 23, 2005, at 12:31, Julian Reschke wrote: > > >> For the record: I am +1 on > PaceOptionalXhtmlDiv>. -1, and additionally I don't think the Pace is even complete or reliably implementable. Graham From owner-atom-syntax@mail.imc.org Tue May 24 08:50:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26358 for ; Tue, 24 May 2005 08:50: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 j4OCWEJS068195; Tue, 24 May 2005 05: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 j4OCWENI068194; Tue, 24 May 2005 05:32:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OCWBcT068124 for ; Tue, 24 May 2005 05:32:14 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH0001CC0O78140@osl1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 16:38:31 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGZ005RQUZ32SV1@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 14:35:27 +0200 (CEST) Date: Tue, 24 May 2005 14:35:56 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Fetch me an author. Now, fetch me another author. In-reply-to: To: Atom Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid wrote: > what if in that example was renamed to (and specced to > be something other than a Person Construct), and some mechanism > introduced > to indicate the nature of the contribution by each of the s? +1. This makes very much sense to me from a publishing company point of view. -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 24 08:53:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26559 for ; Tue, 24 May 2005 08:53: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 j4OCdAad070581; Tue, 24 May 2005 05:39: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 j4OCdA5O070580; Tue, 24 May 2005 05:39:10 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OCd8Qr070530 for ; Tue, 24 May 2005 05:39:09 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-104.dti.cegetel.net [217.19.192.104]) by smtp.cegetel.net (Postfix) with SMTP id E599B1A4341; Tue, 24 May 2005 14:38:17 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 14:39:01 +0200 (CEST) Message-ID: <1752.82.127.77.43.1116938341.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 14:39:01 +0200 (CEST) Subject: Re: Deterministic content models (conflict with Atom Publishing Protocol?) From: "Thomas Broyer" To: In-Reply-To: <87y8a5kkby.fsf@nwalsh.com> References: <428FB78D.9000401@cegetel.net> <6.0.0.20.2.20050523183128.088b4990@itmail.it.aoyama.ac.jp> <87y8a5kkby.fsf@nwalsh.com> 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 Norman Walsh wrote: > Look at the content model for entry: it's a bag o' stuff some of which > is required and some of which is optional (and optionally repeatable) > and it's all allowed to occur in any order. > > I've forgotten the details of XSD's support for "&" content models, but > I'm pretty sure that's beyond them. From "XML Schema Part 1 : Structures (Second Edition)", section "3.8.1 The Model Group Schema Component" [1]: "(all) contain all and only exactly zero or one of each element specified in {particles}. The elements can occur in any order. In this case, to reduce implementation complexity, {particles} is restricted to contain local and top-level element declarations only, with {min occurs}=0 or 1, {max occurs}=1." [1] http://www.w3.org/TR/xmlschema-1/#Model_Group_details -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 08:53:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26577 for ; Tue, 24 May 2005 08:53: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 j4OCatNr069790; Tue, 24 May 2005 05:36: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 j4OCat6d069789; Tue, 24 May 2005 05:36:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OCashm069751 for ; Tue, 24 May 2005 05:36:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH0001RQ0W37T40@osl1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 16:43:15 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGZ005OZV702Z62@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 14:40:12 +0200 (CEST) Date: Tue, 24 May 2005 14:40:41 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: The atom:uri element To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT I've mentioned this several times before and haven't had time to follow the evolvement of the draft up until now, but as far as I can tell, atom:uri is still in place in the specification... Do we really need a pace to have that element renamed before the spec goes final? Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something making more sense? Even atom:iri is better at this point, imho. -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 24 09:20:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28698 for ; Tue, 24 May 2005 09:20: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 j4OD2AlW080760; Tue, 24 May 2005 06:02: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 j4OD2Amd080759; Tue, 24 May 2005 06:02:10 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OD27X9080621 for ; Tue, 24 May 2005 06:02:08 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id BBEEA1A41C8; Tue, 24 May 2005 15:01:18 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 15:02:02 +0200 (CEST) Message-ID: <1757.82.127.77.43.1116939722.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 15:02:02 +0200 (CEST) Subject: Re: inheritance issues (was: Author and contributor) From: "Thomas Broyer" To: In-Reply-To: <20050524075139.GB2613@klangraum> References: <4292611B.2010908@cegetel.net> <20050524023813.GA1394@klangraum> <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.com> <20050524075139.GB2613@klangraum> 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 A. Pagaltzis wrote: > * Thomas Broyer [2005-05-24 09:05]: >> c) >> feed: >> author: A >> contributor: B >> entry: >> contributor: C [...] >> c) The entry inherits the author but overrides the contributor. I'm >> also open to considering it invalid. [...] > The rule you propose for contributor semi-inheritance is hard to > explain clearly in prose and somewhat convoluted to implement in > code though. And while I have not gotten around to learning RELAX > NG, it also seems that it would be non-trivial to express as any > form of grammar. > > After looking at all these cases, I would instead suggest that > we prohibit atom:contributor in absence of an atom:author at the > same level. That would make all of c), d) and e) invalid. > > Note that the semantics you propose for c), d) and e) are still > expressible, they just require more repetition. > > Effectively, I am proposing: > > A non-empty set of atom:entry/atom:author overrides any set > of atom:feed/atom:author and atom:feed/atom:contributor. > > atom:contributor may only appear if ../atom:author is also > given. If you just consider c) to be invalid, you can go with: A non-empty set of both atom:entry/atom:author and atom:entry/atom:contributor overrides any set of both atom:feed/atom:author and atom:feed/atom:contributor. or If an atom:entry has neither an atom:author nor an atom:contributor child element, the author(s) of and contributor(s) to the entry are those specified at the feed level, that is, those appearing as children of an atom:source or, if the atom:entry contains no atom:source child element, those appearing as children of the atom:feed element. Note that if an entry has no atom:author or atom:contributor child but contains an atom:source child. If the atom:source element contains no atom:author or atom:contributor child, the entry has no author or contributor. In such a case, the atom:author and atom:contributor children of the atom:feed element don't cascade into the atom:entry. (and again, excuse me for my English, it's not my mother tong) Actually, the proposed rule is the same as having an atom:person element with a "role" property (attribute or child element) and a rule which says: A non-empty set of atom:entry/atom:person overrides any set of atom:feed/atom:person. And you replace everywhere in spec "atom:author" with "atom:person with a role equal to 'author'" and "atom:contributor" with "atom:person with a role equal to 'contributor'". Please note that I am not proposing changing atom:author and atom:contributor to atom:person with a role property. This is just to make clearer my proposal of "considering atom:author's and atom:contributor's" as a whole, not atom:author's in one hand and atom:contributor's in the other hand". > That seems like it would isolate the specification of > atom:contributor from any inheritance issues, whose discussion > could be confined to the specification of atom:author. We're talking about authors and contributors but inheritance is to be explicitly defined for (copy)rights, categories, etC. as well. > The only constellation that would have been possible with your > proposed set of restrictions, which my set of restrictions no > longer allow, is expressing that feed has only contributors, but > no authors. If anyone feels that such feeds must be expressible, > then the restrictions could be loosened so that only > atom:entry/atom:contributor requires an ../atom:author; however, > as long as noone feels that way, I suggest that the restriction > be symmetric to simplify specification and implementation. -0 to forbidding contributors without author at the feed level. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 09:20:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28718 for ; Tue, 24 May 2005 09:20: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 j4OD89TA085773; Tue, 24 May 2005 06:08: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 j4OD89fu085772; Tue, 24 May 2005 06:08:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OD89Un085674 for ; Tue, 24 May 2005 06:08:09 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH0001O82C15OC0@osl1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 17:14:25 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGZ005NWWMXFPH1@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 15:11:21 +0200 (CEST) Date: Tue, 24 May 2005 15:11:51 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: some small comments on 08 In-reply-to: <42917E28.9090904@annevankesteren.nl> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: >>> * 4.2.2 The "atom:category" Element >>> Why is significant information hidden in attributes? That is bad >>> for i18n and prevents people from defining the expansion of an >>> abbreviation, for example. >> >> Minor flaw. It happens. > > I think you are rushing things too fast. It would be much better if we > fixed this. I agree. > >>> Can't we name them consistently? I'd suggest 'href' or 'url'. >> >> Nope. Too late. > > And this. +2. -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 24 09:20:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28770 for ; Tue, 24 May 2005 09:20: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 j4ODBES1087024; Tue, 24 May 2005 06:11: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 j4ODBED1087023; Tue, 24 May 2005 06:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODBDG4086992 for ; Tue, 24 May 2005 06:11:13 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH00016X2HV8070@osl1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 17:17:55 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGZ005YWWSSUP20@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 15:14:52 +0200 (CEST) Date: Tue, 24 May 2005 15:15:21 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The atom:uri element In-reply-to: To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Tue, 24 May 2005 14:40:41 +0200, Asbjrn Ulsberg wrote: > Or is it so that the atom:uri element have many proponents on the list > so it can't be renamed or changed to atom:link, atom:email or something > [...] ^^^^^^^^^^ Just so the replies to this e-mail (if any) doesn't get concentrated around my little mishap with the elements here: I didn't mean writing 'atom:email' there since we already have that element. The point I'm trying to make is not the name of the element, but rather its type. I'd like it to be constructed somewhat similar to atom:link, e.g. be an Atom Link Construct. -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Tue May 24 09:26:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29226 for ; Tue, 24 May 2005 09:26: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 j4ODFldh088164; Tue, 24 May 2005 06:15: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 j4ODFlFp088163; Tue, 24 May 2005 06:15:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODFkws088152 for ; Tue, 24 May 2005 06:15:46 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH0001OF2P87S70@osl1smout1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 17:22:20 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGZ005X0X05UP30@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Tue, 24 May 2005 15:19:17 +0200 (CEST) Date: Tue, 24 May 2005 15:19:46 +0200 From: =?utf-8?Q?Asbj=C3=B8rn_Ulsberg?= Subject: Re: Author and contributor In-reply-to: <20050523052249.GA31955@klangraum> To: Atom Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-transfer-encoding: 8BIT References: <86457B2E-F1D7-4D60-BD81-84AD1EF362F3@sun.com> <20050523052249.GA31955@klangraum> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Mon, 23 May 2005 07:22:49 +0200, A. Pagaltzis wrote: > • make atom:author plural > • keep atom:contributor > • punt bylines to an extension It's the best suggestion made so far that has any potential of getting into the spec until christmas, so I'm +1 on this. :-) -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue May 24 09:26:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29347 for ; Tue, 24 May 2005 09: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 j4ODEF53088051; Tue, 24 May 2005 06:14: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 j4ODEFw9088050; Tue, 24 May 2005 06:14:15 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODEERr088042 for ; Tue, 24 May 2005 06:14:14 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id 8AE961A42DB; Tue, 24 May 2005 15:13:25 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 15:14:08 +0200 (CEST) Message-ID: <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 15:14:08 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: In-Reply-To: <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> 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 Graham wrote: > On 24 May 2005, at 9:40 am, Henri Sivonen wrote: >> On May 23, 2005, at 12:31, Julian Reschke wrote: >>> For the record: I am +1 on >> PaceOptionalXhtmlDiv>. > > -1, and additionally I don't think the Pace is even complete or > reliably implementable. FYI, it is not, and I already explained in which extent (first, I forgot to say in the Pace that the same would apply for atom:content with type="xhtml"), that's why I pointed to a mail with some more explanation [1]. I was told not to edit the Pace to reflect it, so... [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 09:48:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00926 for ; Tue, 24 May 2005 09:48: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 j4ODah6D090316; Tue, 24 May 2005 06:36: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 j4ODahsf090314; Tue, 24 May 2005 06:36:43 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODafFr090306 for ; Tue, 24 May 2005 06:36:42 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102]) by smtp.cegetel.net (Postfix) with SMTP id 062F131848E; Tue, 24 May 2005 15:36:35 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 15:36:36 +0200 (CEST) Message-ID: <1817.82.127.77.43.1116941796.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 15:36:36 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: In-Reply-To: References: <42904F50.3020404@annevankesteren.nl> <68fba5c505052211472d755406@mail.gmail.com> <42917E28.9090904@annevankesteren.nl> 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 Asbjrn Ulsberg wrote: > On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: >>>> * 4.2.2 The "atom:category" Element >>>> Why is significant information hidden in attributes? That is bad for >>>> i18n and prevents people from defining the expansion of an >>>> abbreviation, for example. >>> >>> Minor flaw. It happens. >> >> I think you are rushing things too fast. It would be much better if we >> fixed this. > > I agree. +1, drop the "label" attribute and make its value a child of the atom:category element. Some more wording would also be needed to explain the exact role of the "term" attribute. Couldn't its value default to the "label" when not present (this imply making it optional)? >>>> Can't we name them consistently? I'd suggest 'href' or 'url'. >>> >>> Nope. Too late. >> >> And this. > > +2. I have no opinion about atom:uri, it seems find to me but I'm not attached to it. @href gives an Hypertext REFerence to another, related, resource (alternate, related, self, feed, etc.), so -1 to changing its name. @src tells the Atom Processor where the content of the entry is located. I wouldn't be opposed to "href" in this case, but nothing else than "href" or "src". Other listed examples were about attribute vs. text node, I'm +0.5 to moving text nodes into attributes (in atom:logo and atom:icon) These are also common usages in many XML dialects (XHTML, XInclude, XLink, SVG, etc.) Many of these tend to use XLink when linking to or embedding external resources, so using XLink wouldn't bother me either (hey, some are talking about replacing atom:author|atom:contributor with Dublin Core, so why not?) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 09:50:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01028 for ; Tue, 24 May 2005 09:50: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 j4ODfKtl090550; Tue, 24 May 2005 06:41: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 j4ODfKXp090548; Tue, 24 May 2005 06:41:20 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODfJgS090538 for ; Tue, 24 May 2005 06:41:19 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102]) by smtp.cegetel.net (Postfix) with SMTP id 47C013182E6; Tue, 24 May 2005 15:41:14 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 15:41:14 +0200 (CEST) Message-ID: <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 15:41:14 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: In-Reply-To: <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> 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 Thomas Broyer wrote: > Graham wrote: >> -1, and additionally I don't think the Pace is even complete or >> reliably implementable. > > FYI, it is not, Oops, before it'd be misinterpreted: * the Pace is not *complete* * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 09:50:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01055 for ; Tue, 24 May 2005 09:50: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 j4ODdqdS090464; Tue, 24 May 2005 06:39: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 j4ODdqQL090463; Tue, 24 May 2005 06:39:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ODdpw2090456 for ; Tue, 24 May 2005 06:39:52 -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 (rwcrmhc11) with SMTP id <2005052413394201300epb6oe>; Tue, 24 May 2005 13:39:42 +0000 Date: Tue, 24 May 2005 07:39:40 -0600 Subject: Re: inheritance issues 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: <3AF9E206-2A05-4FC6-80C9-BEFDB80B1659@bblfish.net> Message-Id: <47936E52-CC59-11D9-BD25-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 Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: > Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been rejected by the WG. I'm torn on whether to bring this up (I'd like to see it done, but it's getting late), but looking at the reasons given for rejecting PacePersonRef [1][2][3], recent discussion of author, contributor and inheritance suggests that the opposition may have been mistaken. See also [4]. >> Eric Scheid wrote: >>> oh darn. This damn inheritance stuff is nasty. [0] http://www.intertwingly.net/wiki/pie/PacePersonRef [1] http://www.imc.org/atom-syntax/mail-archive/msg09290.html [2] http://www.imc.org/atom-syntax/mail-archive/msg09490.html [3] http://www.imc.org/atom-syntax/mail-archive/msg11531.html [4] http://www.imc.org/atom-syntax/mail-archive/msg11530.html From owner-atom-syntax@mail.imc.org Tue May 24 10:12:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03409 for ; Tue, 24 May 2005 10:12: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 j4OE1wC4092112; Tue, 24 May 2005 07:01: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 j4OE1wPt092111; Tue, 24 May 2005 07:01:58 -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 j4OE1vPp092100 for ; Tue, 24 May 2005 07:01:58 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 16465 messnum 6391587 invoked from network[213.94.211.166/mail.724.ie]); 24 May 2005 14:01:51 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail00.svc.cra.dublin.eircom.net (qp 16465) with SMTP; 24 May 2005 14:01:51 -0000 Message-ID: <429333CC.2000204@dehora.net> Date: Tue, 24 May 2005 15:01:48 +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: some small comments on 08 References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> In-Reply-To: <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.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 Thomas Broyer wrote: > * it is not less reliably implementable than the current draft's mandatory > div element; if we go for a SHOULD or MAY on discarding the div elements, > it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away unconvinced then. Can you present some arguments to back those opinions up? cheers Bill From owner-atom-syntax@mail.imc.org Tue May 24 11:08:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08705 for ; Tue, 24 May 2005 11:08: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 j4OEtZX1099901; Tue, 24 May 2005 07:55: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 j4OEtZMJ099900; Tue, 24 May 2005 07:55:35 -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 j4OEtUO4099822; Tue, 24 May 2005 07:55:31 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 24 May 2005 07:55:30 -0700 To: Eric Scheid , Atom Syntax From: Paul Hoffman Subject: Re: extension elements inside link elements? 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 6:22 PM +1000 5/24/05, Eric Scheid wrote: > > 4.2.9 The "atom:link" Element >> >> The "atom:link" element is an empty element that defines a reference from an >> entry or feed to a Web resource. > >did we want to prevent expressions like this: > > > > I read "empty" as "always empty", so the XML novice in me would say that the above expression in inherently wrong. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 24 11:19:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09631 for ; Tue, 24 May 2005 11:19: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 j4OF9sJY001681; Tue, 24 May 2005 08: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 j4OF9stX001680; Tue, 24 May 2005 08:09:54 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OF9q5v001673 for ; Tue, 24 May 2005 08:09:53 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102]) by smtp.cegetel.net (Postfix) with SMTP id 310323181BE; Tue, 24 May 2005 17:09:46 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Tue, 24 May 2005 17:09:47 +0200 (CEST) Message-ID: <1868.82.127.77.43.1116947387.squirrel@ssl-webmail.sitadelle.com> Date: Tue, 24 May 2005 17:09:47 +0200 (CEST) Subject: Re: inheritance issues From: "Thomas Broyer" To: In-Reply-To: <47936E52-CC59-11D9-BD25-003065EA6144@geckotribe.com> References: <3AF9E206-2A05-4FC6-80C9-BEFDB80B1659@bblfish.net> <47936E52-CC59-11D9-BD25-003065EA6144@geckotribe.com> 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 Antone Roundy wrote: > > On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: >> Simplify, simplify. I am for removing all inheritance mechanisms... > > I would agree if we had a better way to avoid all the repetition that > would lead to. However, the only proposal[0] I can remember that would > have done so has been rejected by the WG. I'm torn on whether to bring > this up (I'd like to see it done, but it's getting late), but looking > at the reasons given for rejecting PacePersonRef [1][2][3], recent > discussion of author, contributor and inheritance suggests that the > opposition may have been mistaken. See also [4]. I wasn't there at the time PacePersonRef was proposed. Here's what I'd have said if I were: -1 to dropping inheritance mechanism, this leads to repetitions of atom:author and atom:contributor in each entry +1 to id references as a way to allow "factorization" of people on one place and thus saves some bytes by preventing the repetition of the Person metadata (it might reveal even much better later when there will be extensions to the Person constructs, e.g. FOAF, which might be quite verbose). +0 on whether to use an atom:people container. I'd way prefer clear and clean inheritance definition to repeating metadata all the way down, even if the metadata uses references to metadata elements defined elsewhere. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 11:20:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09868 for ; Tue, 24 May 2005 11:20: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 j4OF78Ml001384; Tue, 24 May 2005 08:07: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 j4OF78fS001383; Tue, 24 May 2005 08:07:08 -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 j4OF76R6001368 for ; Tue, 24 May 2005 08:07:07 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4339027wra for ; Tue, 24 May 2005 08:07:01 -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=ZUPo06kTfYAJzhNyhkV8dQuLCZ4ENpCiSRYDTC4+2Q+2pcrZ0R/tSuF4ozhRw78tCaQwB7XZh+pLHKLxdZqaPdboab+mDkbxlRYDnEapKAKsaTB8+7GkXx44o9nEKP4vj6Cy42Fg32c3l14TvH+PSJMN/Q6gI84PXIyIoBYnFjM= Received: by 10.54.117.4 with SMTP id p4mr4286960wrc; Tue, 24 May 2005 08:07:01 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 24 May 2005 08:07:01 -0700 (PDT) Message-ID: <68fba5c505052408075404b24f@mail.gmail.com> Date: Tue, 24 May 2005 11:07:01 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Paul Hoffman Subject: Re: extension elements inside link elements? Cc: Eric Scheid , Atom Syntax 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 j4OF77R6001371 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Paul Hoffman wrote: > > I read "empty" as "always empty", so the XML novice in me would say > that the above expression in inherently wrong. 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove "is an empty element that". http://www.imc.org/atom-syntax/mail-archive/msg14365.html Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 24 11:22:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10252 for ; Tue, 24 May 2005 11:22: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 j4OF9Sxh001600; Tue, 24 May 2005 08:09: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 j4OF9SAs001599; Tue, 24 May 2005 08:09: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 j4OF9RZ4001593 for ; Tue, 24 May 2005 08:09:27 -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 1A06C4F054; Tue, 24 May 2005 11:09:26 -0400 (EDT) In-Reply-To: <68fba5c5050523150468d9f7ea@mail.gmail.com> References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: "atom-syntax Syntax'" From: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Tue, 24 May 2005 11:08:26 -0400 To: Robert Sayre X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OF9RZ4001594 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-23 18:04, Robert Sayre a crit : > Hi Karl. Thanks for the review. Some thoughts inline. my pleasure > On 5/23/05, Karl Dubost wrote: >> Requirement 01: Include a conformance clause. > > I tend to agree with Paul wrt conformance levels: > http://www.imc.org/atom-syntax/mail-archive/msg10296.html :))) A conformance clause is helping you to do a bit more than the language used in the specification. RFC 2119 is a good choice to express the requirements of the specification. Nothing wrong with that. But it's a kind of hidden conformance layer and with a lot of regular different interpretation from the community. :) Let's go a bit further though. Let's say I'm a developer who's creating an authoring tool for Atom, so more a producer than a consumer application. "Atom Feed Documents" "Atom Entry Documents" I read "An Atom Entry Document represents exactly one Atom entry, outside of the context of an Atom feed. Its root is the atom:entry element." Nowhere it is said that "the root element of a conformant Atom Entry Document MUST be "atom:entry"." What is a conformant Atom Authoring Tool? The specification says at the start: "This specification describes conformance in terms of two artifacts; Atom Feed Documents and Atom Entry documents. Additionally, it places some requirements on Atom Processors." If I read through the text "Atom Processors" are seen as consumers application, not producers. It means that all XSLTs, Web hosting services, etc can NOT claim conformance to Atom. :) I know it sounds strange. You can decide in the specification to forbid such a claim too, but at least it's better to be explicit than "obvious hidden meaning" which might be misinterpreted. >> Requirement 06: Create conformance labels for each part of the >> conformance model. >> NO. The conformance model being not completely clear. It's very >> hard to know what are the different type of conformance and then to >> put labels on them. >> > > See comment #1. I haven't taken the time :) to put the RFC 2119 together. It would help to understand what are: - conformant "Atom Entry Document" - conformant "Atom Feed Document" - conformant "Atom Processor" (- conformant "Atom Producer") An Atom feed s/validator/conformance checker/ is a processor, though it doesn't have to display or render the "Atom Feed Document". Will it be a problem with regards to the specification? I see also "Atom Processors handle URIs." "handle" is not an RFC 2119. It means that it's not even optional, and not mandatory. Is it ok? Maybe "Atom Processors MUST handle URIs."? In the prose before it is said: "If the "src" attribute is present, Atom Processors MAY use the IRI to retrieve the content. " What is the behavior of the Atom processor when the MAY is not implemented because it's optional and because it's not mandatory for "Atom Processors" to handle URIs or IRIs. I'm not being picky, but just showing that a conformance model tries to tackle all these questions that might arise. It helps to really define how you implement the requirements of the specification. > No consensus to make the schema normative. Everyone had a different > reason for opposing it, as I recall. :) :))) no more feed validator then. :) Hope it helps. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Tue May 24 12:42:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17687 for ; Tue, 24 May 2005 12: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 j4OGJbT1007948; Tue, 24 May 2005 09:19: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 j4OGJbpP007947; Tue, 24 May 2005 09:19:37 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGJaTu007941 for ; Tue, 24 May 2005 09:19:36 -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 1Dac7z-0000dq-00; Tue, 24 May 2005 17:19:35 +0100 Date: Tue, 24 May 2005 17:19:35 +0100 From: James Aylett To: "atom-syntax Syntax'" Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Message-ID: <20050524161935.GZ21277@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax Syntax' References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 24, 2005 at 11:08:26AM -0400, Karl Dubost wrote: > Let's go a bit further though. Let's say I'm a developer who's > creating an authoring tool for Atom, so more a producer than a > consumer application. > > "Atom Feed Documents" > "Atom Entry Documents" > > I read "An Atom Entry Document represents exactly one Atom entry, > outside of the context of an Atom feed. Its root is the atom:entry > element." > > Nowhere it is said that > "the root element of a conformant Atom Entry Document MUST be > "atom:entry"." The implication (and I think it's pretty clear, but perhaps I'm used to IETF documents) is that if we don't talk about MUST and SHOULD and MAY, then a statement is an absolute requirement. We're saying that an Atom Entry Document has a root which is an atom:entry element. So if you have something that has a root that's something else, there's no way it can be an Atom Entry Document. I actually think that having a "conformant" layer is often bad - because it suggests that "nonconformant" Atom Entry Documents might exist and might mean something. By avoiding doing this, we define what an Atom Entry Document is, and if you create something that doesn't follow with that definition, you don't have an Atom Entry Document. > What is a conformant Atom Authoring Tool? An "Atom Authoring Tool" would be an authoring tool (however you want to define it) that in some way uses Atom. Again, I don't see the need for the word 'conformant'. The term "Atom Authoring Tool" isn't in the draft, and it doesn't need to be. > The specification says at the start: "This specification describes > conformance in terms of two artifacts; Atom Feed Documents and Atom > Entry documents. Additionally, it places some requirements on Atom > Processors." > > If I read through the text "Atom Processors" are seen as consumers > application, not producers. It means that all XSLTs, Web hosting > services, etc can NOT claim conformance to Atom. :) Yes they can. They just can't claim to be Atom Processors unless they abide by the rules for Atom Processors (and abide by any definition of Atom Processors). Something that produces an XML document that abides by every normative part of the Atom spec (including honouring every MUST clause) that applies to Atom Feed Documents can be considered something that 'conforms' to the Atom spec for producing such a document. Or, more clearly, it produces Atom Feed Documents. If it produced something it claimed were Atom Feed Documents that weren't conformant, they wouldn't be Atom Feed Documents. > I know it sounds strange. You can decide in the specification to > forbid such a claim too, but at least it's better to be explicit > than "obvious hidden meaning" which might be misinterpreted. How can it be misinterpreted more than by giving the idea there might be 'nonconformant' documents in some way? Can't we just assume that the purpose of the spec is to define a document format (well, two formats) that you (as a producer, consumer or whatever) can conform to if you want? (And if you don't want, go do something else :-) > I see also > "Atom Processors handle URIs." > > "handle" is not an RFC 2119. It means that it's not even optional, > and not mandatory. Is it ok? Maybe "Atom Processors MUST handle URIs."? Why is it not optional or mandatory? It's a declaration of something that an Atom Processor does - I take it as being a "by definition", with reference to earlier statements of RFC 2119 requirement in the document. (I think the earlier statement is in 4.2.7.1 where we find that "processors MUST compare atom:id elements", knowing that (4.2.7) "[the atom:id] content MUST be an IRI".) Actually, since this is in the context of a security consideration, it's not a restriction on the processors AT ALL. It's saying "since Atom Processors are going to have to work with URIs/IRIs - they'll have to handle them - implementors should consult RFC3986 and RFC3987 for security considerations in doing this". > In the prose before it is said: > "If the "src" attribute is present, Atom Processors MAY use the IRI > to retrieve the content. " > > What is the behavior of the Atom processor when the MAY is not > implemented because it's optional and because it's not mandatory for > "Atom Processors" to handle URIs or IRIs. If we assume, as is I think reasonable, that handling URIs/IRIs is something that Atom Processors do by definition, then the last half of that question isn't relevant. The behaviour of the Atom processor when the MAY is not implemented is that the Atom processor doesn't retrieve the content. So it doesn't have the content, which it may not care about. > >No consensus to make the schema normative. Everyone had a different > >reason for opposing it, as I recall. :) > > :))) > no more feed validator then. :) A feed validator doesn't have to use a schema, but it could use it for a non-normative check ("you may have problems" - or even kicking in more lengthy checking code only when the schema is violated). This is up to the validator authors. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Tue May 24 12:43:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17830 for ; Tue, 24 May 2005 12:43: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 j4OGS81S012276; Tue, 24 May 2005 09:28: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 j4OGS84Y012275; Tue, 24 May 2005 09:28:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGS6UR012192 for ; Tue, 24 May 2005 09:28:07 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4OGQc91012737; Tue, 24 May 2005 17:26:38 +0100 (BST) In-Reply-To: <68fba5c505052408075404b24f@mail.gmail.com> References: <68fba5c505052408075404b24f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: extension elements inside link elements? Date: Tue, 24 May 2005 17:26:39 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 4:07 pm, Robert Sayre wrote: > 4.2.9 (editorial): The atom:link element is explicitly described as > empty, which violates the rules in 6 for foreign element extension. > Remove "is an empty element that". That's not an editorial change, that's newly allowing extension elements in a place most people (such as Paul and myself) assumed they weren't. Graham From owner-atom-syntax@mail.imc.org Tue May 24 12:52:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18272 for ; Tue, 24 May 2005 12:52: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 j4OGdicE020188; Tue, 24 May 2005 09:39: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 j4OGdiV4020187; Tue, 24 May 2005 09:39:44 -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 j4OGdh5I020124 for ; Tue, 24 May 2005 09:39:44 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4407322wra for ; Tue, 24 May 2005 09:39:38 -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=Z/xA6gZAY1nZfkuM9E8wWLiwljoq67jnkEcA1LkJWIGhDPDpPbHQ1mST4n24/7d6WUC9Ns5fdE+jxjkqZT67tYRlI1Jud+ImdaVcSABdc//4DqJSLAIxAOCL8TTc7VLYDW9e3sYhz5H+qVYkXGrjNJoICMGmp/amgVOjwQyJZso= Received: by 10.54.36.60 with SMTP id j60mr484983wrj; Tue, 24 May 2005 09:39:38 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 24 May 2005 09:39:38 -0700 (PDT) Message-ID: <68fba5c505052409396427fba@mail.gmail.com> Date: Tue, 24 May 2005 12:39:38 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: extension elements inside link elements? Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052408075404b24f@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OGdi5I020180 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Graham wrote: > On 24 May 2005, at 4:07 pm, Robert Sayre wrote: > > > 4.2.9 (editorial): The atom:link element is explicitly described as > > empty, which violates the rules in 6 for foreign element extension. > > Remove "is an empty element that". > > That's not an editorial change, that's newly allowing extension Fully disagree. The extensibility sectin is quite clear. > elements in a place most people (such as Paul and myself) assumed > they weren't. I don't know anything about "most people" and neither do you. Paul stated the meaning of the text of in question, no his own thoughts on the matter. Why don't you work on the problems in the draft instead of dwelling on this tiny nitpick? Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 24 12:53:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18501 for ; Tue, 24 May 2005 12:53: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 j4OGiHGT023250; Tue, 24 May 2005 09:44: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 j4OGiHbC023248; Tue, 24 May 2005 09:44: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.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGiGqE023175 for ; Tue, 24 May 2005 09:44:16 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4410835wra for ; Tue, 24 May 2005 09:44:11 -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=hDElTSiRHUzeTV21ukIQbleqJfIDwDU6UkiovYeAlv7EIZavzzPwArQQ9BBA5W4buvn3Os6tTI/HPsUiO6QXK3FUTh7qYkBCqzw78452BTGVqrCg93rXEbTUJDb3dwAoJ3Ofuu8gjALEyBqe7+8tW6LeyTcC7UWgT8UmHOL2QP0= Received: by 10.54.7.16 with SMTP id 16mr4420384wrg; Tue, 24 May 2005 09:44:11 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 24 May 2005 09:44:11 -0700 (PDT) Message-ID: <68fba5c5050524094468aa4d0d@mail.gmail.com> Date: Tue, 24 May 2005 12:44:11 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: extension elements inside link elements? Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052408075404b24f@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OGiGqE023233 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Graham wrote: > On 24 May 2005, at 4:07 pm, Robert Sayre wrote: > > > 4.2.9 (editorial): The atom:link element is explicitly described as > > empty, which violates the rules in 6 for foreign element extension. > > Remove "is an empty element that". > > That's not an editorial change FYI: http://www.imc.org/atom-syntax/mail-archive/msg11433.html "But if I encounter a element that's weirdly non-empty and contains markup from some other namespace, that's the kind of situation you're talking about. I think it would be OK to leave behavior undefined as you say." Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 24 13:46:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25864 for ; Tue, 24 May 2005 13:46: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 j4OHdQmn038771; Tue, 24 May 2005 10:39: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 j4OHdQPu038770; Tue, 24 May 2005 10:39:26 -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 j4OHdMcb038685 for ; Tue, 24 May 2005 10:39:26 -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 44417E0 for ; Tue, 24 May 2005 10:39:17 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4OHdGng012072 for ; Tue, 24 May 2005 10:39:16 -0700 (PDT) Date: Tue, 24 May 2005 09:21:58 -0700 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: inheritance issues Message-ID: <18D6D7B27BE57E88F23469F0@Wunders-Computer.local> In-Reply-To: <47936E52-CC59-11D9-BD25-003065EA6144@geckotribe.com> References: <47936E52-CC59-11D9-BD25-003065EA6144@geckotribe.com> X-Mailer: Mulberry/4.0.0b3 (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 May 24, 2005 7:39:40 AM -0600 Antone Roundy wrote: > On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: >> Simplify, simplify. I am for removing all inheritance mechanisms... +1. Inheritance has very minor advantages and very serious disadvantages. Inheriting values saves typing. It does not save bandwidth, because HTTP compression will do nearly as well. It is confusing and tricky to specify and implement. It makes the entry different when it is standalone or in a feed. It multiplies the number of test cases needed for validation. Any one of those problems is serious. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Tue May 24 13:52:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26167 for ; Tue, 24 May 2005 13: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 j4OHiaxI039538; Tue, 24 May 2005 10:44: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 j4OHiaAA039537; Tue, 24 May 2005 10:44:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHiZUC039519 for ; Tue, 24 May 2005 10:44:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4OHhmjQ008137; Tue, 24 May 2005 18:43:57 +0100 (BST) In-Reply-To: <68fba5c5050524094468aa4d0d@mail.gmail.com> References: <68fba5c505052408075404b24f@mail.gmail.com> <68fba5c5050524094468aa4d0d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: extension elements inside link elements? Date: Tue, 24 May 2005 18:43:49 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 5:44 pm, Robert Sayre wrote: > FYI: > http://www.imc.org/atom-syntax/mail-archive/msg11433.html > > "But if I encounter a element that's weirdly non-empty and > contains markup from some other namespace, that's the kind of > situation you're talking about. I think it would be OK to leave > behavior undefined as you say." I'm not sure I object to it in principle, though I think it's a weird place for someone to put extentsions, but I object to it being characterised as an editorial change. I also think removing that piece of text makes it unclear that the element is normally empty. Graham From owner-atom-syntax@mail.imc.org Tue May 24 14:00:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26626 for ; Tue, 24 May 2005 14:00: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 j4OHsMPU040375; Tue, 24 May 2005 10: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 j4OHsMJ9040374; Tue, 24 May 2005 10:54:22 -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 j4OHsLwa040363 for ; Tue, 24 May 2005 10:54:22 -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 C967B4EEBC for ; Tue, 24 May 2005 13:54:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050524161935.GZ21277@tartarus.org> References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: From: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Tue, 24 May 2005 13:54:20 -0400 To: "atom-syntax Syntax'" X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OHsMwa040369 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-24 12:19, James Aylett a crit : > The implication (and I think it's pretty clear, but perhaps I'm used Implication :) You just name it and that's the source of loooong (endless) discussions when specs are released. >> What is a conformant Atom Authoring Tool? > > The term "Atom Authoring Tool" isn't in the draft, and it doesn't > need to be. why? >> It means that all XSLTs, Web hosting >> services, etc can NOT claim conformance to Atom. :) > > Yes they can. no for the reason I gave and no because there's no way to claim conformance to the spec. They are plenty marketing department which will claim conformance to something even if they have a bad support of it :) Which has after implications in the world of markets, business offering and certifications which leads to quagmires. > They just can't claim to be Atom Processors unless they > abide by the rules for Atom Processors (and abide by any definition of > Atom Processors). There's none. > Something that produces an XML document that abides > by every normative part of the Atom spec (including honouring every > MUST clause) that applies to Atom Feed Documents can be considered > something that 'conforms' to the Atom spec for producing such a > document. Conformity of a document is not conformity of a product. Two different classes of products. > Or, more clearly, it produces Atom Feed Documents. If it > produced something it claimed were Atom Feed Documents that weren't > conformant, they wouldn't be Atom Feed Documents. Documents and Softwares are not the same thing. > How can it be misinterpreted more than by giving the idea there might > be 'nonconformant' documents in some way? Can't we just assume that > the purpose of the spec is to define a document format (well, two > formats) that you (as a producer, consumer or whatever) can conform to > if you want? (And if you don't want, go do something else :-) > > >> I see also >> "Atom Processors handle URIs." >> >> "handle" is not an RFC 2119. It means that it's not even optional, >> and not mandatory. Is it ok? Maybe "Atom Processors MUST handle >> URIs."? > > Why is it not optional or mandatory? It's a declaration of something > that an Atom Processor does - I take it as being a "by definition", > with reference to earlier statements of RFC 2119 requirement in the > document. You said it: "You take it" and I take it differently :) Our discussion here exactly shows that there's room for misinterpretation and nothing is obvious in a technical specification. But don't worry I will not insist too much. If the Atom community considers it's enough for a good specification. Why not? The purpose of the exercise was to give help on things that might create troubles. > Actually, since this is in the context of a security consideration, > it's not a restriction on the processors AT ALL. Where what you just said is explained. You said before that everything which is in the spec is normative and now you are saying that this part is not normative? I'm lost or does it show that it's important to know which part of the specifications are informative and which ones are normative? http://atompub.org/2005/04/18/draft-ietf-atompub- format-08.html#rfc.section.8 > It's saying "since > Atom Processors are going to have to work with URIs/IRIs - they'll > have to handle them - implementors should consult RFC3986 and RFC3987 > for security considerations in doing this". where ? >> In the prose before it is said: >> "If the "src" attribute is present, Atom Processors MAY use the IRI >> to retrieve the content. " >> >> What is the behavior of the Atom processor when the MAY is not >> implemented because it's optional and because it's not mandatory for >> "Atom Processors" to handle URIs or IRIs. >> > > If we assume, as is I think reasonable, that handling URIs/IRIs is > something that Atom Processors do by definition, then the last half of > that question isn't relevant. "Assume" MUST not be part of a technical specification. That's the whole problem here ;) > The behaviour of the Atom processor when the MAY is not implemented is > that the Atom processor doesn't retrieve the content. So it doesn't > have the content, which it may not care about. >>> >>> No consensus to make the schema normative. Everyone had a different >>> reason for opposing it, as I recall. :) >>> >> >> :))) >> no more feed validator then. :) > > A feed validator doesn't have to use a schema, but it could use it for > a non-normative check ("you may have problems" - or even kicking in > more lengthy checking code only when the schema is violated). This is > up to the validator authors. Validation is something very precise. It can be validated against a DTD, or against a Schema or another grammar language, etc. At least the "Feed validator" could become a "Feed checker" which develops a heuristic to check if the requirements of the specification are verified. :))) "up to the validator authors" :) Anyway. :))) It was just a message to help. :) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Tue May 24 14:01:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26694 for ; Tue, 24 May 2005 14:01: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 j4OHtLph040456; Tue, 24 May 2005 10:55: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 j4OHtLW9040455; Tue, 24 May 2005 10:55:21 -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 j4OHtLL3040445 for ; Tue, 24 May 2005 10:55:21 -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 <2005052417551301400su7o2e>; Tue, 24 May 2005 17:55:13 +0000 Date: Tue, 24 May 2005 11:55:11 -0600 Subject: Re: inheritance issues 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: <18D6D7B27BE57E88F23469F0@Wunders-Computer.local> 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 Tuesday, May 24, 2005, at 10:21 AM, Walter Underwood wrote: > Inheriting values saves typing. It does not save bandwidth, because > HTTP compression will do nearly as well. 6% of the feeds I subscribe to use compression. I don't think we can depend on that yet. From owner-atom-syntax@mail.imc.org Tue May 24 14:08:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27125 for ; Tue, 24 May 2005 14:08: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 j4OHxe0Y040681; Tue, 24 May 2005 10:59: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 j4OHxeCw040680; Tue, 24 May 2005 10:59: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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHxc2T040672 for ; Tue, 24 May 2005 10:59:39 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.57.19]) by smtp.cegetel.net (Postfix) with ESMTP id BAFBE318C56; Tue, 24 May 2005 19:59:32 +0200 (CEST) Message-ID: <42936B84.7030407@cegetel.net> Date: Tue, 24 May 2005 19:59:32 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: Robert Sayre , atom-syntax Subject: Re: extension elements inside link elements? References: <68fba5c505052408075404b24f@mail.gmail.com> <68fba5c5050524094468aa4d0d@mail.gmail.com> <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> In-Reply-To: <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@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: > > On 24 May 2005, at 5:44 pm, Robert Sayre wrote: > >> FYI: >> http://www.imc.org/atom-syntax/mail-archive/msg11433.html >> >> "But if I encounter a element that's weirdly non-empty and >> contains markup from some other namespace, that's the kind of >> situation you're talking about. I think it would be OK to leave >> behavior undefined as you say." > > > I'm not sure I object to it in principle, though I think it's a weird > place for someone to put extentsions, What about the following extension? image/svg+xml image/png image/jpeg > I also think removing that piece of text makes it unclear that the > element is normally empty. What about: The "atom:link" element defines a reference from an entry or feed to a Web resource. Atom doesn't define any child to the "atom:link", though it might contain extension markup. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 14:15:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27616 for ; Tue, 24 May 2005 14:15: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 j4OI8t7r041247; Tue, 24 May 2005 11:08: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 j4OI8tLL041246; Tue, 24 May 2005 11:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OI8rEq041238 for ; Tue, 24 May 2005 11:08:54 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050524180847.POOY9046.mta09-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Tue, 24 May 2005 19:08:47 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050524180847.HNER242.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Tue, 24 May 2005 19:08:47 +0100 Date: Tue, 24 May 2005 19:08:43 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1601789279.20050524190843@djpowell.net> To: Eric Scheid CC: Atom Syntax Subject: Re: extension elements inside link elements? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OI8sEq041241 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tuesday, May 24, 2005, 9:22:29 AM, Eric Scheid wrote: >> 4.2.9The "atom:link" Element >> >> The "atom:link" element is an empty element that defines a reference from an >> entry or feed to a Web resource. > Subject: Re: extension elements inside link elements? > did we want to prevent expressions like this: > > > > e. Whether the draft allowed it or not, atom:link isn't an extension point. That would be Section 6.3 style "unknown foreign markup". -- Dave From owner-atom-syntax@mail.imc.org Tue May 24 14:48:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00098 for ; Tue, 24 May 2005 14:48: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 j4OIVw7M046817; Tue, 24 May 2005 11:31: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 j4OIVwBh046816; Tue, 24 May 2005 11:31:58 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OIVs15046802; Tue, 24 May 2005 11:31:54 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Date: Tue, 24 May 2005 11:31:52 -0700 To: Karl Dubost From: Paul Hoffman Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines 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: I am completely unclear why this discussion is going on. Is there a desire on the part of the W3C to take the Atom work into the W3C? If so, talking to the W3C/IETF liaison pair would be more appropriate than this mailing list. If not, then suggesting that our document should be more W3C-like seems fairly out-of-scope for an IETF WG. Could you clarify? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 24 14:58:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01033 for ; Tue, 24 May 2005 14:58: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 j4OIpElx047975; Tue, 24 May 2005 11:51: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 j4OIpESO047974; Tue, 24 May 2005 11:51:14 -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 j4OIpDbo047961; Tue, 24 May 2005 11:51:13 -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 79E8B4F02C; Tue, 24 May 2005 14:51:12 -0400 (EDT) In-Reply-To: References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Atom WG From: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Tue, 24 May 2005 14:51:11 -0400 To: Paul Hoffman X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OIpDbo047962 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-24 14:31, Paul Hoffman a crit : > I am completely unclear why this discussion is going on. Is there a > desire on the part of the W3C to take the Atom work into the W3C? Are you insecure? Where did you read, imagine such a thing? The case has been settled for a long time by choice of the Atom Community. No trouble. > If so, talking to the W3C/IETF liaison pair would be more > appropriate than this mailing list. If not, then suggesting that > our document should be more W3C-like seems fairly out-of-scope for > an IETF WG. [I just removed initial thought here.] > Could you clarify? Did you miss an email? [[[I have done the review of Atom 0.8 to ___test___ W3C QA Specification Guidelines with an external technical document and I thought it could be also useful to the Atom community. ]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html and the rest, I'm replying to the questions. :) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Tue May 24 14:59:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01190 for ; Tue, 24 May 2005 14:59: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 j4OIoJoe047889; Tue, 24 May 2005 11:50: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 j4OIoJgi047888; Tue, 24 May 2005 11:50:19 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OIoInF047869 for ; Tue, 24 May 2005 11:50:18 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.57.19]) by smtp.cegetel.net (Postfix) with ESMTP id 28831318090; Tue, 24 May 2005 20:50:13 +0200 (CEST) Message-ID: <42937765.8050507@cegetel.net> Date: Tue, 24 May 2005 20:50:13 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: David Powell Cc: Eric Scheid , Atom Syntax Subject: Re: extension elements inside link elements? References: <1601789279.20050524190843@djpowell.net> In-Reply-To: <1601789279.20050524190843@djpowell.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 David Powell wrote: >Whether the draft allowed it or not, atom:link isn't an extension >point. > > Could you explain why? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 15:28:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04911 for ; Tue, 24 May 2005 15:28: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 j4OJK92A052876; Tue, 24 May 2005 12:20: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 j4OJK92Z052875; Tue, 24 May 2005 12:20:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJK7Ld052769 for ; Tue, 24 May 2005 12:20:08 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050524192001.NFBO20297.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Tue, 24 May 2005 20:20:01 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050524192001.KJDN8884.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Tue, 24 May 2005 20:20:01 +0100 Date: Tue, 24 May 2005 20:19:57 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <907035544.20050524201957@djpowell.net> To: Atom Syntax Subject: Comments about Extensions (1) 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 Section 6.4: The RNGs in this section require Extension Elements to be in a namespace that isn't the Atom namespace. This requirement is missing from the text. Proposal -------- Add to section 6.4.1: > A Simple Extension Element MUST be namespace-qualified. The element > MUST be defined outside of the Atom namespace. Add to section 6.4.2: > The root element of a Structured Extension element MUST be > namespace-qualified. The element MUST be defined outside of the Atom > namespace. -- Dave From owner-atom-syntax@mail.imc.org Tue May 24 15:34:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05309 for ; Tue, 24 May 2005 15:34: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 j4OJPWwO054845; Tue, 24 May 2005 12:25: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 j4OJPW28054844; Tue, 24 May 2005 12:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJPUkf054828 for ; Tue, 24 May 2005 12:25:31 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4OJOERr003479; Tue, 24 May 2005 20:24:24 +0100 (BST) In-Reply-To: <1601789279.20050524190843@djpowell.net> References: <1601789279.20050524190843@djpowell.net> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: extension elements inside link elements? Date: Tue, 24 May 2005 20:24:16 +0100 To: David Powell X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 7:08 pm, David Powell wrote: > Whether the draft allowed it or not, atom:link isn't an extension > point. That would be Section 6.3 style "unknown foreign markup". Unless there's a memo I missed, extensions are a subset of "unknown foreign markup". Graham From owner-atom-syntax@mail.imc.org Tue May 24 15:44:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06611 for ; Tue, 24 May 2005 15:44: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 j4OJZ614055371; Tue, 24 May 2005 12:35: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 j4OJZ6iO055370; Tue, 24 May 2005 12:35:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJZ5gA055345 for ; Tue, 24 May 2005 12:35:06 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050524193459.LIXC26549.mta08-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Tue, 24 May 2005 20:34:59 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050524193459.MFFN8884.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Tue, 24 May 2005 20:34:59 +0100 Date: Tue, 24 May 2005 20:34:55 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <1386531406.20050524203455@djpowell.net> To: Graham CC: atom-syntax Subject: Re: extension elements inside link elements? In-Reply-To: References: <1601789279.20050524190843@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 Tuesday, May 24, 2005, 8:24:16 PM, Graham wrote: > On 24 May 2005, at 7:08 pm, David Powell wrote: >> Whether the draft allowed it or not, atom:link isn't an extension >> point. That would be Section 6.3 style "unknown foreign markup". > Unless there's a memo I missed, extensions are a subset of "unknown > foreign markup". That is what I said isn't it? Some "unknown foreign markup" is an extension. -- Dave From owner-atom-syntax@mail.imc.org Tue May 24 15:54:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09287 for ; Tue, 24 May 2005 15: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 j4OJhOMM055798; Tue, 24 May 2005 12:43: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 j4OJhOWY055797; Tue, 24 May 2005 12:43:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJhNLd055785 for ; Tue, 24 May 2005 12:43:23 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050524194315.NFBU26549.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Tue, 24 May 2005 20:43:17 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050524194314.TGSC242.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Tue, 24 May 2005 20:43:14 +0100 Date: Tue, 24 May 2005 20:43:10 +0100 From: David Powell X-Mailer: The Bat! (v3.5) Professional X-Priority: 3 (Normal) Message-ID: <34428000.20050524204310@djpowell.net> To: Thomas Broyer CC: Eric Scheid , Atom Syntax Subject: Re: extension elements inside link elements? In-Reply-To: <42937765.8050507@cegetel.net> References: <1601789279.20050524190843@djpowell.net> <42937765.8050507@cegetel.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, May 24, 2005, 7:50:13 PM, Thomas Broyer wrote: > David Powell wrote: >>Whether the draft allowed it or not, atom:link isn't an extension >>point. >> >> > Could you explain why? The following are extension points: * Adding additional metadata to atom:feed by using Section 6.4 Extension Elements. * Adding additional metadata to atom:entry by using Section 6.4 Extension Elements. * Adding additional metadata to Person Constructs by using Section 6.4 Extension Elements. * Adding new atom:link types by using new @rel attributes. * Embedding arbitrary data by using atom:content. Atom processors won't fail if you put elements in other places, but I didn't think that they were extension points. -- Dave From owner-atom-syntax@mail.imc.org Tue May 24 16:17:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20540 for ; Tue, 24 May 2005 16:17: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 j4OK9Fac057994; Tue, 24 May 2005 13:09: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 j4OK9Fdc057993; Tue, 24 May 2005 13:09: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 j4OK9ErF057985 for ; Tue, 24 May 2005 13:09: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 j4OK9E0R016385 for ; Tue, 24 May 2005 14:09:14 -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 <0IH000FKKFZD17@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 24 May 2005 14:09:14 -0600 (MDT) Received: from [192.168.1.23] ([64.172.16.237]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH000AW8FZ8O6@mail.sun.net> for atom-syntax@imc.org; Tue, 24 May 2005 14:09:13 -0600 (MDT) Date: Tue, 24 May 2005 07:20:36 -0700 From: Tim Bray Subject: Re: atom:type, xsl:output In-reply-to: <69978119-0C18-40E0-83A0-EBFF1EFFA732@mac.com> To: Graham Cc: James Cerra , atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20050524040620.38339.qmail@web42204.mail.yahoo.com> <69978119-0C18-40E0-83A0-EBFF1EFFA732@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 24, 2005, at 1:25 AM, Graham wrote: >> First off: it is an error to lie about your >> media-type, so I would change "SHOULD be suitable for >> handling as the indicated media type" to "MUST be >> suitable for handling as the indicated media type." >> > > +1 I'm tempted to agree but can't, because the condition of "being suitable for handling as" is not deterministic and testable enough to merit a MUST. -Tim From owner-atom-syntax@mail.imc.org Tue May 24 16:38:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22701 for ; Tue, 24 May 2005 16: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 j4OKS9V5067233; Tue, 24 May 2005 13:28: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 j4OKS9pl067228; Tue, 24 May 2005 13:28:09 -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 j4OKS5IR067149 for ; Tue, 24 May 2005 13:28:06 -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 j4OKS50R007547 for ; Tue, 24 May 2005 14:28:05 -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 <0IH000FTNGUS17@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 24 May 2005 14:28:05 -0600 (MDT) Received: from [192.168.1.23] ([64.172.16.237]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH000AB9GUSO6@mail.sun.net> for atom-syntax@imc.org; Tue, 24 May 2005 14:28:04 -0600 (MDT) Date: Tue, 24 May 2005 13:28:09 -0700 From: Tim Bray Subject: Re: extension elements inside link elements? In-reply-to: To: Graham Cc: Robert Sayre , atom-syntax Message-id: <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c505052408075404b24f@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 24, 2005, at 9:26 AM, Graham wrote: >> 4.2.9 (editorial): The atom:link element is explicitly described as >> empty, which violates the rules in 6 for foreign element extension. >> Remove "is an empty element that". >> > > That's not an editorial change, that's newly allowing extension > elements in a place most people (such as Paul and myself) assumed > they weren't. On the one hand I agree with Graham; this does feel like a substantial change. On the other, it's hard to see that having stuff inside would do any damage; I best most software would never notice it. Having said that, I don't agree that it's editorial change and I'd like to see a couple more voices in favor and give people a chance to shout "No!" before going ahead and doing it. -Tim From owner-atom-syntax@mail.imc.org Tue May 24 16:38:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22724 for ; Tue, 24 May 2005 16:38: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 j4OKTOhE067501; Tue, 24 May 2005 13:29: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 j4OKTOdu067500; Tue, 24 May 2005 13:29: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-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 j4OKTN1b067494 for ; Tue, 24 May 2005 13:29:23 -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 j4OKTN0R009100 for ; Tue, 24 May 2005 14:29:23 -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 <0IH000F41GWY17@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 24 May 2005 14:29:23 -0600 (MDT) Received: from [192.168.1.23] ([64.172.16.237]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH000H75GWYJS@mail.sun.net> for atom-syntax@imc.org; Tue, 24 May 2005 14:29:22 -0600 (MDT) Date: Tue, 24 May 2005 13:29:30 -0700 From: Tim Bray Subject: Re: extension elements inside link elements? In-reply-to: <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> To: Graham Cc: Robert Sayre , atom-syntax Message-id: <5C735021-3083-4AEA-989F-0709C9302ADC@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <68fba5c505052408075404b24f@mail.gmail.com> <68fba5c5050524094468aa4d0d@mail.gmail.com> <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 24, 2005, at 10:43 AM, Graham wrote: > I also think removing that piece of text makes it unclear that the > element is normally empty. +1 -Tim From owner-atom-syntax@mail.imc.org Tue May 24 16:52:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23511 for ; Tue, 24 May 2005 16:52: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 j4OKiOTj068636; Tue, 24 May 2005 13:44: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 j4OKiOqW068635; Tue, 24 May 2005 13:44:24 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OKiIT9068627; Tue, 24 May 2005 13:44:19 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Date: Tue, 24 May 2005 13:44:15 -0700 To: Karl Dubost From: Paul Hoffman Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines 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: At 2:51 PM -0400 5/24/05, Karl Dubost wrote: >Are you insecure? Well, I do sometimes worry my protocols aren't as long as those from other Working Groups, but I try not to think about it. >Where did you read, imagine such a thing? >The case has been settled for a long time by choice of the Atom >Community. No trouble. OK, good. So why are we discussing where the Atom format document doesn't match up to W3C test specification guidelines? >Did you miss an email? No. >[[[I have done the review of Atom 0.8 to ___test___ W3C QA >Specification Guidelines with an external technical document and I >thought it could be also useful to the Atom community. >]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html Right. You didn't say why you thought it would be useful, and then... >and the rest, I'm replying to the questions. :) That's the part that is confusing. Your responses sound a great deal like we should be making changes to our documents based on W3C test guidelines. For what purpose? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 24 17:54:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27244 for ; Tue, 24 May 2005 17:54: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 j4OLgFvj085976; Tue, 24 May 2005 14:42: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 j4OLgFFD085975; Tue, 24 May 2005 14:42:15 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OLgDnZ085967 for ; Tue, 24 May 2005 14:42:14 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.57.19]) by smtp.cegetel.net (Postfix) with ESMTP id 67BE031807C; Tue, 24 May 2005 23:42:07 +0200 (CEST) Message-ID: <42939F9C.9010206@cegetel.net> Date: Tue, 24 May 2005 23:41:48 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: David Powell Cc: Atom Syntax Subject: Re: Comments about Extensions (1) References: <907035544.20050524201957@djpowell.net> In-Reply-To: <907035544.20050524201957@djpowell.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 David Powell wrote: >Section 6.4: > >The RNGs in this section require Extension Elements to be in a >namespace that isn't the Atom namespace. This requirement is missing >from the text. > > It's actually worse than just that. Section 6.1 defines "foreign markup" as being "markup from other vocabularies". WRT section 6.2 describing "extensions to the Atom vocabulary", I understand this definition of "foreign markup" as "markup in a namespace different from the Atom one. Section 6.4 *implies* Extension Elements are foreign markup as the first sentence of that section is "Atom allows foreign markup anywhere in an Atom document" though it's not explicit at all. Having re-read the draft without looking at the RNC excerpts, the whole section 6 with its subsections are totally unclear about what is "foreign markup" (or what is behind "Atom vocabulary"), what are "extensions", what are Simple/Structured Extension Elements and how they relate to foreign markup. Even more, I'm wondering why would there be a need to define Simple/Structured Extension Elements in terms of "constraints". I suppose that it's a way to distinguish extensions in the form text-only from extensions using attributes and/or child elements; and such a distinction is only necessary because we want to provide a hint about how to interpret extensions in the former form (no attribute, text-only content). Wouldn't it be clearer (less obscure) to anyone dropping section 6.4 and just saying something like the following: Elements from foreign markup with no attribute and text-only content MAY be interpreted by an Atom Processor as a property (or name/value pair) of the parent element that encloses it. This specification does not provide an interpretation for other elements. Still about extensions, have I missed something or nowhere the spec allows for "extension attributes" (I mean namespaced attributes appearing on Atom elements)? I suggest such attributes to be interpreted as a property (or name/value pair) of the element on which it appears. Finally, in section 6.2, in the last sentence, "for the purpose of this discussion" applies only to the section 6.3 about how to process them: they obviously aren't "extensions", are they? I suggest moving this sentence into section 6.3. There might be other things I missed this evening... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 24 18:08:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28898 for ; Tue, 24 May 2005 18:08: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 j4OLxghx086987; Tue, 24 May 2005 14:59: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 j4OLxgUW086986; Tue, 24 May 2005 14:59: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.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OLxekG086976 for ; Tue, 24 May 2005 14:59:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4641264wra for ; Tue, 24 May 2005 14:59:34 -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=sa5Pg5KFUlcqrKWoHTCyHFwTXqz1GmANxNS4EhghQkbGInLnK9r0KKROaMqqWF81Q7LVn+uuXL/zdCgcWPD303y0m+RT9a5DHm1dawAkHrhgJ3RoXw/Yw7+kFMM8Xd7k+4hbiRRVqIOqWiqiDlTpLg+ZaFJHzFxPDySACBFF4Po= Received: by 10.54.33.73 with SMTP id g73mr3882557wrg; Tue, 24 May 2005 14:59:34 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 24 May 2005 14:59:34 -0700 (PDT) Message-ID: <68fba5c5050524145954a0134@mail.gmail.com> Date: Tue, 24 May 2005 17:59:34 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Thomas Broyer Subject: Re: Comments about Extensions (1) Cc: David Powell , Atom Syntax In-Reply-To: <42939F9C.9010206@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <907035544.20050524201957@djpowell.net> <42939F9C.9010206@cegetel.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OLxekG086981 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Thomas Broyer wrote: > > David Powell wrote: > > >Section 6.4: > > > >The RNGs in this section require Extension Elements to be in a > >namespace that isn't the Atom namespace. This requirement is missing > >from the text. > > > > > > It's actually worse than just that. Actually, I don't see a problem here. You just don't understand that some extension content has its role defined by the spec ahead of time, and some doesn't ("undefined"). I don't see any reason to revisit this. bye, Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 24 18:18:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00039 for ; Tue, 24 May 2005 18:18: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 j4OHsoP2040413; Tue, 24 May 2005 10:54: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 j4OHsogM040412; Tue, 24 May 2005 10:54: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.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHsn2i040401 for ; Tue, 24 May 2005 10:54:49 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so4464070wra for ; Tue, 24 May 2005 10:54:43 -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=ReUqNx/4lxS1by/VscqFj5NasrEPT4E/E/symsO0a5QLgr3tfkZ+uOJ93nB71Is4U8HyF5uEikfml2jMcXbDZ2IG4Gn4DdJ+eArbK0BOIrxK+zSwQJqsKqvPbwuNKt3kilRuw3Lqs8vwqRCgrt6xkQ/XaLfP2rKzqb7cBYKitaM= Received: by 10.54.41.54 with SMTP id o54mr3750687wro; Tue, 24 May 2005 10:54:43 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Tue, 24 May 2005 10:54:43 -0700 (PDT) Message-ID: <68fba5c505052410543b8ef29e@mail.gmail.com> Date: Tue, 24 May 2005 13:54:43 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: extension elements inside link elements? Cc: atom-syntax In-Reply-To: <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505052408075404b24f@mail.gmail.com> <68fba5c5050524094468aa4d0d@mail.gmail.com> <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OHsn2i040406 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Graham wrote: > On 24 May 2005, at 5:44 pm, Robert Sayre wrote: > > > FYI: > > http://www.imc.org/atom-syntax/mail-archive/msg11433.html > > > > "But if I encounter a element that's weirdly non-empty and > > contains markup from some other namespace, that's the kind of > > situation you're talking about. I think it would be OK to leave > > behavior undefined as you say." > > I'm not sure I object to it in principle, though I think it's a weird > place for someone to put extentsions, but I object to it being > characterised as an editorial change. Well, that's how the reviewer felt, and I though it was a super minor change. Also, I observe that more than 3 or 4 WG members have expressed a desire to extend it that way. I can't think of a problem with that, though I would surely ignore them when processing a link element. > I also think removing that piece of text makes it unclear that the > element is normally empty. I don't think so. There's an example just below, in 4.2.9.2. We could show some more examples. The other element with no defined content is atom:category. Its RNC illustration also shows it as empty, but the text doesn't call it an "empty element." Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 24 20:34:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09857 for ; Tue, 24 May 2005 20:34: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 j4P0QKCA024321; Tue, 24 May 2005 17:26: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 j4P0QKv8024320; Tue, 24 May 2005 17:26: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 j4P0QI0D024232 for ; Tue, 24 May 2005 17:26:19 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 May 2005 00:26:11 -0000 Received: from xdsl-81-173-229-56.netcologne.de (EHLO klangraum) [81.173.229.56] by mail.gmx.net (mp014) with SMTP; 25 May 2005 02:26:11 +0200 X-Authenticated: #163624 Date: Wed, 25 May 2005 02:29:50 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: extension elements inside link elements? Message-ID: <20050525002950.GA8431@klangraum> Mail-Followup-To: atom-syntax References: <68fba5c505052408075404b24f@mail.gmail.com> <68fba5c5050524094468aa4d0d@mail.gmail.com> <18CD9C7B-EC68-4D65-8B59-C4F1EA31CC69@mac.com> <42936B84.7030407@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42936B84.7030407@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-05-24 20:10]: > What about: > > The "atom:link" element defines a reference from an entry or > feed to a Web resource. Atom doesn't define any child to the > "atom:link", though it might contain extension markup. I may be trying to pick a colour for the bikeshed, but is an explicit mention of the possibility of extension elements really necessary? Unnecessary redundancy is an invitation for inconsistencies. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 21:08:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13332 for ; Tue, 24 May 2005 21:08: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 j4P113CI040259; Tue, 24 May 2005 18:01: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 j4P113lX040258; Tue, 24 May 2005 18:01:03 -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 j4P1114h040239 for ; Tue, 24 May 2005 18:01:02 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 May 2005 01:00:55 -0000 Received: from xdsl-81-173-229-56.netcologne.de (EHLO klangraum) [81.173.229.56] by mail.gmx.net (mp008) with SMTP; 25 May 2005 03:00:55 +0200 X-Authenticated: #163624 Date: Wed, 25 May 2005 03:04:33 +0200 From: "A. Pagaltzis" To: "atom-syntax Syntax'" Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Message-ID: <20050525010433.GB8431@klangraum> Mail-Followup-To: atom-syntax Syntax' References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> 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: * Karl Dubost [2005-05-24 20:05]: > > > It means that all XSLTs, Web hosting services, etc can NOT > > > claim conformance to Atom. :) > > > > Yes they can. > > no for the reason I gave and no because there's no way to claim > conformance to the spec. They are plenty marketing department > which will claim conformance to something even if they have a > bad support of it :) Which has after implications in the world > of markets, business offering and certifications which leads > to quagmires. If something produces documents that conform to the rules set out for Atom Documents in the Atom Format specification, then it produces Atom Documents. Are you suggesting that it makes sense to state conformance in any other terms? If so, why? I *could* see an argument for defining when an Atom Processor is conformant; after all, interpreting a document is more ambiguous job than generating one, and many desktop aggregators have poor support for the full link model, f.ex. Your complaints seem to hinge on a belief that the scope of the specification should extend further than to specify exactly what a document means. My understanding is that the WG has decided that the format specification is to say exactly what the bits on the wire mean, but not what how anyone should generate them or what anyone should do with them once they have received them. So it seems to me that your complaint is outside the scope of the specification, and, indeed, this WG. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 21:35:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14621 for ; Tue, 24 May 2005 21:35: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 j4P1PXFh044208; Tue, 24 May 2005 18:25: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 j4P1PXAD044207; Tue, 24 May 2005 18:25: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 j4P1PVWV044198 for ; Tue, 24 May 2005 18:25:32 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 May 2005 01:25:25 -0000 Received: from xdsl-81-173-229-56.netcologne.de (EHLO klangraum) [81.173.229.56] by mail.gmx.net (mp024) with SMTP; 25 May 2005 03:25:25 +0200 X-Authenticated: #163624 Date: Wed, 25 May 2005 03:29:04 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: inheritance issues (was: Author and contributor) Message-ID: <20050525012904.GC8431@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4292611B.2010908@cegetel.net> <20050524023813.GA1394@klangraum> <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.com> <20050524075139.GB2613@klangraum> <1757.82.127.77.43.1116939722.squirrel@ssl-webmail.sitadelle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1757.82.127.77.43.1116939722.squirrel@ssl-webmail.sitadelle.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: 8bit * Thomas Broyer [2005-05-24 15:15]: > A. Pagaltzis wrote: > > * Thomas Broyer [2005-05-24 09:05]: > >> c) > >> feed: > >> author: A > >> contributor: B > >> entry: > >> contributor: C > [...] > >> c) The entry inherits the author but overrides the > >> contributor. I'm also open to considering it invalid. > [...] > > Effectively, I am proposing: > > > > A non-empty set of atom:entry/atom:author overrides any set > > of atom:feed/atom:author and atom:feed/atom:contributor. > > > > atom:contributor may only appear if ../atom:author is also > > given. > > If you just consider c) to be invalid, you can go with: > > A non-empty set of both atom:entry/atom:author and > atom:entry/atom:contributor overrides any set of both > atom:feed/atom:author and atom:feed/atom:contributor. That seems to allow entries with contributors, but no author. You need to be more precise. > or > > If an atom:entry has neither an atom:author nor an > atom:contributor child element, the author(s) of and > contributor(s) to the entry are those specified at the feed > level, that is, those appearing as children of an > atom:source or, if the atom:entry contains no atom:source > child element, those appearing as children of the atom:feed > element. > > Note that if an entry has no atom:author or > atom:contributor child but contains an atom:source child. > If the atom:source element contains no atom:author or > atom:contributor child, the entry has no author or > contributor. In such a case, the atom:author and > atom:contributor children of the atom:feed element don't > cascade into the atom:entry. > > (and again, excuse me for my English, it's not my mother tong) I think this clearly demonstrates why I opted for disallowing atom:contributor in absence of ../atom:author: it is difficult to explain. You need a lot of prose to express it. You also need more code and more grammar rules. To me, that raises flags that it’s too complex. Only the atom:content section of the specification contains restrictions on any single “aspect” which are not expressible in one or two sentences and cannot be understood in near isolation. > Please note that I am not proposing changing atom:author and > atom:contributor to atom:person with a role property. This is > just to make clearer my proposal of "considering atom:author's > and atom:contributor's" as a whole, not atom:author's in one > hand and atom:contributor's in the other hand". It would be much easier to explain your proposal if that were the case; and in that case I would be in favour. But we have two separate elements, and that’s not going to change… I’m not opting for the best possible solution; I’m trying to suggest something that, given the current state of the specification, will require the least changes for the most effect. > -0 to forbidding contributors without author at the feed level. Actually, me too. Banning feeds with only contributors does not make the actual documents any more precise, so conceptually I don’t like the restriction. But it makes everything that deals with the documents simpler, so I accept it. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue May 24 23:39:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24017 for ; Tue, 24 May 2005 23:39: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 j4P3VM73060489; Tue, 24 May 2005 20:31: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 j4P3VMEl060488; Tue, 24 May 2005 20:31:22 -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 j4P3VLsT060481 for ; Tue, 24 May 2005 20:31: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 45EFB4F035 for ; Tue, 24 May 2005 23:31:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050525010433.GB8431@klangraum> References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> <20050525010433.GB8431@klangraum> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2A85F3D3-8086-424A-A2A4-C176C7A6521C@w3.org> From: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Tue, 24 May 2005 23:31:20 -0400 To: "atom-syntax Syntax'" X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4P3VLsT060483 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-24 21:04, A. Pagaltzis a crit : > So it seems to me that your complaint is outside the scope of the > specification, and, indeed, this WG. I had a lengthy discussion with Paul Hoffman out of the list to avoid unnecessary arguments on this list which has suffered it in the past. Just to remind the tone of my messages, it was not "complaints", it was "suggestions". I'm not asking people to do things with it. And I just replied to comments when people were asking about conformance. :) I still don't understand the first message of Paul, but that's another story which has no place on this list. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Tue May 24 23:50:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24956 for ; Tue, 24 May 2005 23:50: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 j4P3hK31061029; Tue, 24 May 2005 20:43: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 j4P3hKcg061028; Tue, 24 May 2005 20:43:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42210.mail.yahoo.com (web42210.mail.yahoo.com [66.218.93.221]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P3hJBo061020 for ; Tue, 24 May 2005 20:43:19 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 67522 invoked by uid 60001); 25 May 2005 03:43:14 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=cForSkTbM6AXzYhmXHZzYcdejuanLc2xTohoVhOq1s49MXiQwRDXHZNx6Dz4wkypEDZ/0G8tTHtVCYOKgLY5TyuwntFp6Em5zpfOYpMgDp7K+9g2LTyglux3ae0qFnK9DU3XG8HhcpJZPOp9px9PKQYYO5R4kf1nRdVGZ82o5iA= ; Message-ID: <20050525034314.67520.qmail@web42210.mail.yahoo.com> Received: from [4.155.69.166] by web42210.mail.yahoo.com via HTTP; Tue, 24 May 2005 20:43:14 PDT Date: Tue, 24 May 2005 20:43:14 -0700 (PDT) From: James Cerra Subject: Re: atom:type, xsl:output To: "A. Pagaltzis" , atom-syntax In-Reply-To: 6667 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: Aristotle, > Embedding XML 1.1 documents inside an XML 1.0 document is not > possible, because... I understand. Thanks. > An Atom processor does not know whether the embedded XML document > is a valid document of the given type. Only an attached processor > for the given document type will be able to decide. As such, the > validity of the Atom feed document is not affected by the media > type. It will, of course, cause interop problems if you lie about > the media type, hence SHOULD. That's convincing. > > Secondly, XML may be entity (or CDATA) encoded like > > @type="html" or plain xml like @type="xhtml". This is becuase > > of the "content of atom:content MAY include child elements" > > phrase. There is no guarantee if an entity escaped passage is > > xml or a text node example of an xml document (i.e. an example > > of an xml document), for example. > > No. Wrong. > > There is nothing saying that the content of atom:content MAY be a > text node. It MAY only be a child element. If it may be an element, then it may be something else too. By the definition in RFC 2119, this behavior (having one or more child elements according to 20050418 revision) is "truly optional." There's three other things it could be (ignoring comments and PIs): a text node, mixed content, no nothing at all. So it is still a valid Atom fragment. > If there is no child element, @src must be set, ie the XML > document constituting the content is external to the feed. > > I will say, though, the the spec could stand to be more explicit > in this instance. I agree with both your commentary on the spec and that your interpretation is mostly what Atom should support. Here's how I would write it: "4. If the value of "type" ends with "+xml" or "/xml" (case-insensitive), the content of atom:content MUST either consist of no children or one or more XML 1.0 elements, comments, processing instructions, an XML 1.0 text node, or mixed content [1]. Any comments, processing instructions, or entities found as children of atom:content MUST be interpreted as being associated with the Atom document itself. If the intended Atom content contains essential comments, processing instructions, entities, DOCTYPE declaration(s), or other properties that make it unable to be valid atom:content content, then it MAY be specified in an external file identified by a URI in the the "src" attribute, which MAY be interpreted by an Atom processor as being associated as the Atom content of the entry. The Atom content of the entry SHOULD be suitable for handling as the indicated media type." I defined a phrase, "Atom content," to represent the content of an entry, that is refernced by atom:content either through its src attribute or literally as its children elements and text nodes. Any comments or processing instructions should be explicitly associated with the Atom document's xml, rather than the "Atom content", so style information can be applied (for viewing the raw Atom XML) and the processing order of processing instructions and comments is well defined (to solve the problem of which ones to read and which ones to pass?) for examples. That paragraph is also very long-winded, but I think it is more precise than the existing paragraph. I don't know if it is deterministic, whatever that is, and I still think some of the attributes of xsl:output should be included as optional metadata about the atom:content child (doctype, xml declaration, etc.) if it is a complete document. -- Jimmy Cerra [1] __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From owner-atom-syntax@mail.imc.org Tue May 24 23:54:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25114 for ; Tue, 24 May 2005 23:54: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 j4P3kqW1061275; Tue, 24 May 2005 20:46: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 j4P3kqmr061274; Tue, 24 May 2005 20:46:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42209.mail.yahoo.com (web42209.mail.yahoo.com [66.218.93.220]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P3kqXM061267 for ; Tue, 24 May 2005 20:46:52 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 49751 invoked by uid 60001); 25 May 2005 03:46:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZwudGJSp9k+e1+Nbu2uanwgtqM7BqWW2gAJKrK2fWrJ1TqZCoCyguodq8ptENSVM754kte0YAV4P5nEZnn+H6se1W4RGghH0Mf/aHS5XaDpPpXKgJkoPHj2EcNYu3z84WLKGHMzcXG3sjZ7ezrzOA7D4orUrE/YdBWgnvNkWJNM= ; Message-ID: <20050525034646.49749.qmail@web42209.mail.yahoo.com> Received: from [4.155.69.166] by web42209.mail.yahoo.com via HTTP; Tue, 24 May 2005 20:46:46 PDT Date: Tue, 24 May 2005 20:46:46 -0700 (PDT) From: James Cerra Subject: Re: atom:type, xsl:output To: Graham Cc: atom-syntax In-Reply-To: 6667 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: Graham, > > Secondly, XML may be entity (or CDATA) encoded like > > @type="html" or plain xml like @type="xhtml". This is > If I follow you right, you misunderstand. Atom documents are > unambiguous. XML has to be inserted literally, with no entity > escaping (except for entities that are part of text nodes) allowed. I'm not so sure. The spec seems to hint at the answer, but provides no cannonical interpretation like it does with @type="html". After being processed by a XML processor, any entites should be dereferenced to their text values and placed into the document tree. So this: > > > > <?xml version="1.0?> > > <tag /> would become the text string: > > > > ; Wed, 25 May 2005 00:43: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 j4P4YHqE066151; Tue, 24 May 2005 21:34: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 j4P4YHQH066150; Tue, 24 May 2005 21:34:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42206.mail.yahoo.com (web42206.mail.yahoo.com [66.218.93.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P4YGTh066137 for ; Tue, 24 May 2005 21:34:16 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 38492 invoked by uid 60001); 25 May 2005 04:34:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=n7kc4iZDuci8sxQDQ4VG4r5+Iv40X+a4O5j/NLloQPLMSiv2PGAxaXsG+Bw5ztt/7WTKj9YKFDuym0VzpidaAMpWQ0rTDRwRVvStgdToeFct7KQNVCMSqTuBaZDwyrEN7+dueIjW/kioXrWVeOinNO+qot3el91UhyNg0aPbd0w= ; Message-ID: <20050525043411.38490.qmail@web42206.mail.yahoo.com> Received: from [4.155.69.166] by web42206.mail.yahoo.com via HTTP; Tue, 24 May 2005 21:34:11 PDT Date: Tue, 24 May 2005 21:34:11 -0700 (PDT) From: James Cerra Subject: Re: The atom:uri element To: "Asbjrn" Ulsberg , Atom-Syntax In-Reply-To: 6667 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: > > Or is it so that the atom:uri element have many proponents on the list > > so it can't be renamed or changed to atom:link, atom:email or something I agree with this. I thought it was unusual to name a tag after a specific technology rather than its intent (atom:email is an exception). In this instance, I think atom:name, atom:resource, or atom:link works better. > Just so the replies to this e-mail (if any) doesn't get concentrated > around my little mishap with the elements here: I didn't mean writing > 'atom:email' there since we already have that element. The point I'm > trying to make is not the name of the element, but rather its type. I'd > like it to be constructed somewhat similar to atom:link, e.g. be an Atom > Link Construct. Good point. I like the idea of adopting atom:link if several identifiers per person is allowed. Or what about an "href" or "ref" attribute on the author element, if only one indentifier is intended per author? Or an "about" or "res" attribute if the uri isn't intended to be dereferenceable? Just brainstorming some alternatives. -- Jimmy Cerra __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs From owner-atom-syntax@mail.imc.org Wed May 25 00:52:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29648 for ; Wed, 25 May 2005 00:52: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 j4P4k5tg067246; Tue, 24 May 2005 21:46: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 j4P4k5IF067245; Tue, 24 May 2005 21:46:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P4k3ns067218 for ; Tue, 24 May 2005 21:46:04 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000430234 for ; Wed, 25 May 2005 14:45:32 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 25 May 2005 14:45:29 +1000 Subject: Re: The atom:uri element From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050525043411.38490.qmail@web42206.mail.yahoo.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 25/5/05 2:34 PM, "James Cerra" wrote: > I agree with this. I thought it was unusual to name a tag after a specific > technology rather than its intent (atom:email is an exception). In this > instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:link e. From owner-atom-syntax@mail.imc.org Wed May 25 01:23:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01272 for ; Wed, 25 May 2005 01:23: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 j4P5GXNc074241; Tue, 24 May 2005 22:16: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 j4P5GX1h074240; Tue, 24 May 2005 22:16: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 (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P5GVTq074180 for ; Tue, 24 May 2005 22:16:31 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 25 May 2005 05:16:24 -0000 Received: from xdsl-213-196-240-186.netcologne.de (EHLO klangraum) [213.196.240.186] by mail.gmx.net (mp014) with SMTP; 25 May 2005 07:16:24 +0200 X-Authenticated: #163624 Date: Wed, 25 May 2005 07:20:04 +0200 From: "A. Pagaltzis" To: Atom-Syntax Subject: Re: The atom:uri element Message-ID: <20050525052004.GB10318@klangraum> Mail-Followup-To: Atom-Syntax References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 8bit * Asbjørn Ulsberg [2005-05-24 14:50]: > I've mentioned this several times before and haven't had time > to follow the evolvement of the draft up until now, but as far > as I can tell, atom:uri is still in place in the > specification... Do we really need a pace to have that element > renamed before the spec goes final? -1 to renaming the element. See http://www.imc.org/atom-syntax/mail-archive/msg13864.html > Or is it so that the atom:uri element have many proponents on > the list so it can't be renamed or changed to atom:link, > atom:email or something making more sense? Even atom:iri is > better at this point, imho. Is there anything for which atom:uri is insufficient, which can plausibly not be done in an extension, and for which there is a pressing need? And if so, how do atom:link semantics apply to person constructs? -1 to atom:link. No need for change for the sake of change. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed May 25 03:12:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13533 for ; Wed, 25 May 2005 03:12: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 j4P741ib045425; Wed, 25 May 2005 00:04: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 j4P741pU045424; Wed, 25 May 2005 00:04:01 -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.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P73ulK045361 for ; Wed, 25 May 2005 00:03:57 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-105.dti.cegetel.net [217.19.192.105]) by smtp.cegetel.net (Postfix) with SMTP id 4C4C01A4770; Wed, 25 May 2005 09:03:06 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Wed, 25 May 2005 09:03:51 +0200 (CEST) Message-ID: <1964.82.127.77.43.1117004631.squirrel@ssl-webmail.sitadelle.com> Date: Wed, 25 May 2005 09:03:51 +0200 (CEST) Subject: Re: inheritance issues (was: Author and contributor) From: "Thomas Broyer" To: In-Reply-To: <20050525012904.GC8431@klangraum> References: <4292611B.2010908@cegetel.net> <20050524023813.GA1394@klangraum> <1561.82.127.77.43.1116918004.squirrel@ssl-webmail.sitadelle.com> <20050524075139.GB2613@klangraum> <1757.82.127.77.43.1116939722.squirrel@ssl-webmail.sitadelle.com> <20050525012904.GC8431@klangraum> 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 A. Pagaltzis wrote: > * Thomas Broyer [2005-05-24 15:15]: >> A. Pagaltzis wrote: >> > * Thomas Broyer [2005-05-24 09:05]: >> >> c) >> >> feed: >> >> author: A >> >> contributor: B >> >> entry: >> >> contributor: C >> [...] >> >> c) The entry inherits the author but overrides the >> >> contributor. I'm also open to considering it invalid. [...] >> If you just consider c) to be invalid, you can go with: >> >> A non-empty set of both atom:entry/atom:author and >> atom:entry/atom:contributor overrides any set of both >> atom:feed/atom:author and atom:feed/atom:contributor. > > That seems to allow entries with contributors, but no author. You > need to be more precise. It doesn't: I didn't say I'd remove the following bullets ;o) in 4.1.1: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. and 4.1.2: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. >> or >> >> If an atom:entry has neither an atom:author nor an >> atom:contributor child element, the author(s) of and >> contributor(s) to the entry are those specified at the feed >> level, that is, those appearing as children of an >> atom:source or, if the atom:entry contains no atom:source >> child element, those appearing as children of the atom:feed >> element. >> >> Note that if an entry has no atom:author or >> atom:contributor child but contains an atom:source child. >> If the atom:source element contains no atom:author or >> atom:contributor child, the entry has no author or >> contributor. In such a case, the atom:author and >> atom:contributor children of the atom:feed element don't >> cascade into the atom:entry. >> >> (and again, excuse me for my English, it's not my mother tong) > > I think this clearly demonstrates why I opted for disallowing > atom:contributor in absence of ../atom:author: it is difficult to > explain. You need a lot of prose to express it. You also need > more code and more grammar rules. To me, that raises flags that > it’s too complex. Actually, only the first paragraph addresses the author/contributor "grouping". The second one might still be necessary to disambiguate the "entry -> (source XOR feed)" inheritance mechanism. Btw, had you seen the above bullet in 4.1.1 doesn't allow for a feed with only "imported" entries (with atom:source) to be author-less? The following feed is invalid per the current draft: ... ... ... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed May 25 03:12:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13553 for ; Wed, 25 May 2005 03:12: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 j4P73k4Z045328; Wed, 25 May 2005 00:03: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 j4P73kJ9045327; Wed, 25 May 2005 00:03:46 -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 j4P73gHL045290 for ; Wed, 25 May 2005 00:03:45 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:57999 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228694AbVEYHDl (ORCPT ); Wed, 25 May 2005 10:03:41 +0300 In-Reply-To: References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> 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 Syntax'" From: Henri Sivonen Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Wed, 25 May 2005 10:03:23 +0300 To: Karl Dubost 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 May 24, 2005, at 20:54, Karl Dubost wrote: >> A feed validator doesn't have to use a schema, but it could use it for >> a non-normative check ("you may have problems" - or even kicking in >> more lengthy checking code only when the schema is violated). This is >> up to the validator authors. > > Validation is something very precise. It can be validated against a > DTD, or against a Schema or another grammar language, etc. At least > the "Feed validator" could become a "Feed checker" which develops a > heuristic to check if the requirements of the specification are > verified. :))) "up to the validator authors" :) The Feed Validator has always been a "Feed Checker" technically. I complained about the naming terminology when the Feed Validator came out. I don't expect the name to change now. Even with validators that perform a precise check using a schema, it is important to know what kind of check the validator performs. In the case of Atom, the schema that ships with the specification is a RELAX NG Compact Syntax schema with embedded Schematron. When used with a RELAX NG validator that does not support embedded Schematron (eg. http://hsivonen.iki.fi/validator/), the validator will precisely ignore the embedded Schematron. A hand-crafted checker can potentially be more useful than a validator that is limited to what is checkable using a given schema language. Case point: DTDs and attribute data types. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 25 03:13:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13611 for ; Wed, 25 May 2005 03:13: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 j4P77xO8047067; Wed, 25 May 2005 00: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 j4P77x8K047066; Wed, 25 May 2005 00:07:59 -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 j4P73gHN045290 for ; Wed, 25 May 2005 00:07:58 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:58274 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228750AbVEYHH6 (ORCPT ); Wed, 25 May 2005 10:07:58 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <103e64b7e3071e8b26255a309a649b1c@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Wed, 25 May 2005 10:07:55 +0300 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 On May 24, 2005, at 23:44, Paul Hoffman wrote: > So why are we discussing where the Atom format document doesn't match > up to W3C test specification guidelines? Atom has been advertised as "thoroughly specified" before it is even known what exactly the upcoming RFC will specify. Assessing the level of thoroughness using an outside metric makes sense to me. Whether the WG wants to act on the assessment is another matter. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 25 03:51:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16256 for ; Wed, 25 May 2005 03:51: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 j4P7hv4h061057; Wed, 25 May 2005 00:43: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 j4P7hvsM061056; Wed, 25 May 2005 00:43:57 -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 j4P7fKfA060050 for ; Wed, 25 May 2005 00:43:57 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:58569 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228693AbVEYHn5 (ORCPT ); Wed, 25 May 2005 10:43:57 +0300 In-Reply-To: <20050525034646.49749.qmail@web42209.mail.yahoo.com> References: <20050525034646.49749.qmail@web42209.mail.yahoo.com> 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: Henri Sivonen Subject: Re: atom:type, xsl:output Date: Wed, 25 May 2005 10:43:54 +0300 To: James Cerra 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 May 25, 2005, at 06:46, James Cerra wrote: > fter being processed by a XML processor, any entites should be > dereferenced to > their text values and placed into the document tree. So this: > >>> >>> <?xml version="1.0?> >>> <tag /> > > would become the text string: > >>> >>> ) by smtp2.dnainternet.net with ESMTP id S1228787AbVEYHlT (ORCPT ); Wed, 25 May 2005 10:41:19 +0300 In-Reply-To: <20050525034314.67520.qmail@web42210.mail.yahoo.com> References: <20050525034314.67520.qmail@web42210.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38ff0c3c3c997910a4177270d8ba3998@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom WG From: Henri Sivonen Subject: Re: atom:type, xsl:output Date: Wed, 25 May 2005 10:41:16 +0300 To: James Cerra 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 May 25, 2005, at 06:43, James Cerra wrote: > If the intended Atom content contains essential comments, There should be no such thing as essential comments. The XML spec does not require XML processors to report comments to the app. Hence, comments are inappropriate for transferring essential data. > processing instructions, These could be supported in embedded content if the Atom spec said PIs in atom:content belong in content and should not be acted upon by the Atom processor. > entities Entities can be flattened. > DOCTYPE declaration(s) If DOCTYPE is essential for the receiving app, you've got bigger problems than Atom. Hardwiring IDness based on namespaces is more practical than relying on DTD-based data typing. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed May 25 05:34:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22407 for ; Wed, 25 May 2005 05:33: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 j4P9OL4J098619; Wed, 25 May 2005 02:24: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 j4P9OLiS098618; Wed, 25 May 2005 02:24:21 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P9OJFl098575 for ; Wed, 25 May 2005 02:24:19 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id 51D8D31838E; Wed, 25 May 2005 11:24:13 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Wed, 25 May 2005 11:24:13 +0200 (CEST) Message-ID: <2075.82.127.77.43.1117013053.squirrel@ssl-webmail.sitadelle.com> Date: Wed, 25 May 2005 11:24:13 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: 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 Bill de hra wrote: > Thomas Broyer wrote: >> * it is not less reliably implementable than the current draft's >> mandatory div element; if we go for a SHOULD or MAY on discarding >> the div elements, it is even *more* reliably implementable. > > We had a discussion about optional div not so long ago, and I came > away unconvinced then. Can you present some arguments to back those > opinions up? As you're quoting the "reliable implementation" sentence, let's start with some code and pseudo code to demonstrate PaceOptionalXhtmlDiv is "reliably implementable": With a "pull" parser (.NET XmlReader, or DOM), using recursivity: function getContent(nodelist) returns nodelist if nodelist.length = 1 then # a single element var element = nodelist[0] if element is xhtml:div and not(element has attributes) then # the single element is a "discardable xhtml:div" # apply the same function on its children (recursivity) return getContent(element.children) else return nodelist end if else return nodelist end if end function ... The above function would be called like this: if element is atom:content and element@type="xhtml" then content = getContent(element.children) end if With a "rule-based" processor (XSLT), only accounting here for atom:content: ============ Btw, from what I found in the archives for the last two months (approximately), it seems that what bothers you is less the "optional div" than linking Atom to XHTML or even more generally use "XML in XML". You're asking for some more arguments, have you read "Re: Consensus call on last raft of issues" [1]? I'm open to discussion if you have a problem with something particular in my proposal, but actually, without some hint, it'd be hard for me to find other arguments. You were pointing the case where "a div is deemed necessary", I explained in [1] that a div (without attribute and without sibling) has no meaning and is never necessary. If it is necessary in the application processing the Atom document, it's the responsibility of that application to add it. If it is necessary in the application producing the Atom document and this one has no mean to strip it, the Pace allows this application to put that div in the Text Construct or atom:content, it just says that such a div has no more meaning than the Atom element containing it (that is, grouping its content altogether) and thus will be discarded by the Atom Processor at the other end of the chain. Note that I'm open to change the "MUST discard" into a SHOULD, as there is no real need for this discarding. Actually, that Pace wouldn't have been necessary if people wanting to produce prefix-free feeds weren't bothered adding a "dummy" div to achieve their "taste" and having it become part of the content. The only reason for PaceOptionalXhtmlDiv beyond that, is for interoperability in the Atom Publishing Protocol: the producer of the Atom document (the client when doing a POST or PUT, the server when doing a GET) is free to add as many "dummy" divs like that without the consumer considering them part of the content. Thus, the following would be OK: Client: PUT ... HTTP/1.1 ... ...
Blabla
... Server: HTTP/1.1 200 OK ... ... Blabla ... In the same way we prevent type="text" to use preformatted text and we enforce type="xhtml" to contain XHTML that could validly appear in a div element, we can say XHTML "real" content cannot consist of a single div with no attribute. We don't forbid Text Construct's and atom:content's content to be such a thing, we just say it is not part of the content (because we have technical arguments, explained in [1], to assure such a div is meaningless and useless and can thus safely be discarded). Moreover, we're saying that Atom Processors MAY use the markup, this means they may also not use it or use only part of it (e.g. discard/ignore some elements or attributes such as script, style, object, applet, etc.), which doesn't prevent it from discarding the div anyway. [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed May 25 07:20:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29547 for ; Wed, 25 May 2005 07:20: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 j4PB9tOh044177; Wed, 25 May 2005 04:09: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 j4PB9tCL044176; Wed, 25 May 2005 04:09:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PB9s0D044120 for ; Wed, 25 May 2005 04:09:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PB8bre026743; Wed, 25 May 2005 12:08:43 +0100 (BST) In-Reply-To: <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A950265-44D0-4928-B157-9034C06D7E94@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: some small comments on 08 Date: Wed, 25 May 2005 12:08:36 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 24 May 2005, at 2:41 pm, Thomas Broyer wrote: > Oops, before it'd be misinterpreted: > * the Pace is not *complete* > * it is not less reliably implementable than the current draft's > mandatory > div element; if we go for a SHOULD or MAY on discarding the div > elements, > it is even *more* reliably implementable. With the current draft, everyone wraps their content, in a single div, and everyone at the other end removes it, producing exactly the same XHTML, always. With the Pace, try transporting this:
Text
Wrap it in a div:
Decode it: Text Oops, we've thrown data away. Whether the change is significant or not isn't important. As a user, I expect to be able to type something in at one end and have it reliably appear in the same form, regardless of what I type, or whether Thomas Broyer thinks the change didn't matter. Graham From owner-atom-syntax@mail.imc.org Wed May 25 08:15:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04767 for ; Wed, 25 May 2005 08:15: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 j4PBWCE6053392; Wed, 25 May 2005 04: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 j4PBWCXu053391; Wed, 25 May 2005 04:32:12 -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 j4PBWBdj053317 for ; Wed, 25 May 2005 04:32:11 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 71864 messnum 7067812 invoked from network[83.70.217.193/unknown]); 25 May 2005 11:32:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail01.svc.cra.dublin.eircom.net (qp 71864) with SMTP; 25 May 2005 11:32:04 -0000 Message-ID: <42946232.7020502@dehora.net> Date: Wed, 25 May 2005 12: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@imc.org Subject: Re: some small comments on 08 References: <2075.82.127.77.43.1117013053.squirrel@ssl-webmail.sitadelle.com> In-Reply-To: <2075.82.127.77.43.1117013053.squirrel@ssl-webmail.sitadelle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thomas Broyer wrote: > Bill de hra wrote: > >>Thomas Broyer wrote: >> >>> * it is not less reliably implementable than the current draft's >>> mandatory div element; if we go for a SHOULD or MAY on discarding >>>the div elements, it is even *more* reliably implementable. >> >>We had a discussion about optional div not so long ago, and I came >>away unconvinced then. Can you present some arguments to back those >>opinions up? > > > As you're quoting the "reliable implementation" sentence, let's start > with some code and pseudo code to demonstrate PaceOptionalXhtmlDiv is > "reliably > implementable": > > With a "pull" parser (.NET XmlReader, or DOM), using recursivity: > function getContent(nodelist) returns nodelist > if nodelist.length = 1 then > # a single element > var element = nodelist[0] > if element is xhtml:div and not(element has attributes) then > # the single element is a "discardable xhtml:div" > # apply the same function on its children (recursivity) > return getContent(element.children) > else > return nodelist > end if > else > return nodelist > end if > end function > ... > The above function would be called like this: > if element is atom:content and element@type="xhtml" then > content = getContent(element.children) > end if if xhtmlTypeContent(element ,'atom:content'): return stripContentFromDiv(element.child[0]) ie, when the @type=xhtml, pull back all the children underneath the xhtml:div child. Done. With less options come less conditionals. What's broken if broken is clearly determinable. There's no need to check for a discardable divs when the first child under content is assured to be. > Btw, from what I found in the archives for the last two months > (approximately), it seems that what bothers you is less the "optional div" > than linking Atom to XHTML or even more generally use "XML in XML". What bothers me is inconsistent document production. Optionality of this feature invites that, ie making it optional defeats its purpose. There's no apparent benefit. > I'm open to discussion if you have a problem with something particular in > my proposal, but actually, without some hint, it'd be hard for me to find > other arguments. I don't buy the rationale for xhtml:div optionality and I've refuted it already. I'll sum up: You said- "I just want the XHTML div to be optional for people that don't need it but still meeting other people's needs of a "dummy container to carry their XHTML namespace declarations"" I said- "If you can't trust people not to need the div, then you can't make it optional. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom." You need to convince me why making this thing optional is beneficial. Thats not happening, what's happening is that you're telling me optionality, if we allow it, can be worked around, as long as everyone works around it the same way. One problem here is that you're assuming that the people who don't need this and the people who do this need won't cross each others paths. They will. If that is not a problem, then we can remove the construct altogether. > I explained in [1] that a div (without attribute and without > sibling) has no meaning and is never necessary. That's refutable - xhtml:div is a lexical scoping mechanism, it doesn't require meaning to be useful, and such a mechanism is clearly neccessary (according to the WG) in the presence of Atom created with default namespaces. What being proposed is not ime a robust solution and I would much rather we take our chances without such a mechanism that make it optional. Unless there are new arguments regarding the benefit of optionality, this is just restating positions and we remain deadlocked. > If it is necessary in the > application processing the Atom document, it's the responsibility of that > application to add it. If it is necessary in the application producing the > Atom document and this one has no mean to strip it, the Pace allows this > application to put that div in the Text Construct or atom:content, it just > says that such a div has no more meaning than the Atom element containing > it (that is, grouping its content altogether) and thus will be discarded > by the Atom Processor at the other end of the chain. > > Note that I'm open to change the "MUST discard" into a SHOULD, as there is > no real need for this discarding. Don't do that. It's enlarging the state space; more conditionals to think about. > Actually, that Pace wouldn't have been necessary if people wanting to > produce prefix-free feeds weren't bothered adding a "dummy" div to achieve > their "taste" and having it become part of the content. I have no idea what you meant there, but it sounded like something you haven't said before- can you clarify? > The only reason for PaceOptionalXhtmlDiv beyond that, is for > interoperability in the Atom Publishing Protocol: the producer of the Atom > document (the client when doing a POST or PUT, the server when doing a > GET) is free to add as many "dummy" divs like that without the consumer > considering them part of the content. Thus, the following would be OK: > >[..] > In the same way we prevent type="text" to use preformatted text and we > enforce type="xhtml" to contain XHTML that could validly appear in a div > element, we can say XHTML "real" content cannot consist of a single div > with no attribute. We don't forbid Text Construct's and atom:content's > content to be such a thing, we just say it is not part of the content > (because we have technical arguments, explained in [1], to assure such a > div is meaningless and useless and can thus safely be discarded). The meaningless thing is starting to sound to me like a red herring. This construct, like any firewalling or defensive mechanism becomes useless the nanosecond it has served its purpose. That doesn't mean you just take it out or make the checks optional. I agree having to put that artefact in there is annoying, but unless you can persuade this WG and the XML community at large to do some root cause analysis so as to conclude that default namespaces are harmful, we're more or less stuck with this thing. Even if you can, I don't think it will be in time for us to ship. The best case scenario here is that we ship with non-optional xhtml:div and that down the line this creates further evidence in the communities that there is a root cause to look at. > Moreover, we're saying that Atom Processors MAY use the markup, this means > they may also not use it or use only part of it (e.g. discard/ignore some > elements or attributes such as script, style, object, applet, etc.), which > doesn't prevent it from discarding the div anyway. Please look at all the qualifications that are been added to make this thing optional, those MAYS and SHOULDs. Add them up. Assess their overall impact. I have, as best I can, and I can't credibly conclude on the balance it's simpler or more robust than what we have. Sans interesting new arguments I'll hold my position. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 25 08:39:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06657 for ; Wed, 25 May 2005 08:39: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 j4P8q1Nq084283; Wed, 25 May 2005 01:52: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 j4P8q1dD084282; Wed, 25 May 2005 01:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P8q14m084240 for ; Wed, 25 May 2005 01:52:01 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH1003ZTL5V2NB0@osl1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 25 May 2005 12:58:43 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH1007N0FGRVRG0@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 25 May 2005 10:55:39 +0200 (CEST) Date: Wed, 25 May 2005 10:57:15 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The atom:uri element In-reply-to: To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 25 May 2005 06:45:29 +0200, Eric Scheid wrote: >> In this instance, I think atom:name, atom:resource, or atom:link works >> better. > > +1 atom:link I think atom:author@href works even better. Thinking of what information is stored in atom:uri and how it is used, why isn't it just an attribute? It's a single value intended for computers, not humans, to parse. The atom:uri element does not have a 'title' attribute or anything else that makes it necessary to keep it as an element, the actual name of the element is awkward in this context and it is not consistent with the rest of the specification to have URI's as text nodes of elements but rather as attribute values (of @src and @href attributes respectively). Consistency makes the format easier to understand and learn. Isn't that something worth stribing (and thus changing) for? -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Wed May 25 08:40:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06724 for ; Wed, 25 May 2005 08:40: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 j4P9sIs5008734; Wed, 25 May 2005 02:54: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 j4P9sIEA008733; Wed, 25 May 2005 02:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4P9sFv1008702 for ; Wed, 25 May 2005 02:54:17 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000430837 for ; Wed, 25 May 2005 19:54:14 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 25 May 2005 19:54:06 +1000 Subject: Re: The atom:uri element From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4P9sIv1008727 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 25/5/05 6:57 PM, "Asbjrn Ulsberg" wrote: > Consistency makes the format easier to understand and learn. Isn't that > something worth stribing (and thus changing) for? +1 From owner-atom-syntax@mail.imc.org Wed May 25 09:01:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08516 for ; Wed, 25 May 2005 09:01: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 j4PCrs9T098161; Wed, 25 May 2005 05:53: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 j4PCrsWM098160; Wed, 25 May 2005 05:53:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCrrid098106 for ; Wed, 25 May 2005 05:53:53 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PCr608017415 for ; Wed, 25 May 2005 13:53:12 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050525052004.GB10318@klangraum> References: <20050525052004.GB10318@klangraum> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67E6EBBC-57B7-45D0-9161-A6AFE639E3A0@mac.com> Content-Transfer-Encoding: 7bit From: Graham Subject: Re: The atom:uri element Date: Wed, 25 May 2005 13:53:05 +0100 To: atom-syntax X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 to "atom:link" unless they are proper link elements. I'm fairly happy with the current situation. Graham From owner-atom-syntax@mail.imc.org Wed May 25 09:03:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08654 for ; Wed, 25 May 2005 09:03: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 j4PCvSOV099556; Wed, 25 May 2005 05:57: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 j4PCvSmp099555; Wed, 25 May 2005 05:57:28 -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 [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCvR3E099514 for ; Wed, 25 May 2005 05:57:28 -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 1DavRu-0004ie-00; Wed, 25 May 2005 13:57:26 +0100 Date: Wed, 25 May 2005 13:57:26 +0100 From: James Aylett To: "atom-syntax Syntax'" Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Message-ID: <20050525125726.GB26265@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax Syntax' References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 24, 2005 at 01:54:20PM -0400, Karl Dubost wrote: > >The implication (and I think it's pretty clear, but perhaps I'm used > > Implication :) You just name it and that's the source of loooong > (endless) discussions when specs are released. As I said, I'm probably more used to IETF-style specifications than not. Personally I find them more useful than many W3C documents, but of course, not everyone is used to the IETF style :-) > >>What is a conformant Atom Authoring Tool? > > > >The term "Atom Authoring Tool" isn't in the draft, and it doesn't > >need to be. > > why? I don't think we need to define every possible way in which software can act upon documents in one of the Atom formats. They're documents, so there are two /main/ roles: software that produces the documents, and software that consumes the documents. (Any software may do both, of course.) The specification tells us what is a legal Feed Document, and what is a legal Entry Document (but see following paragraph), and we're not making any additional restrictions on something that produces Atom documents. However we need to discuss how things that /consume/ Atom documents work, because we need to tell them (for instance) how to compare atom:id instances, and note that there are potential security considerations in handling URIs and IRIs. You have an issue with the clarity of how legal Feed/Entry Documents are defined by the spec, but that's actually orthogonal to defining all the possible software actions on these documents - which is why I'm certain we can have a completely clear specification without lots of role definitions. You want the specification to be more explicit. I'm happy without the extra verbiage, because my way of reading the existing document allows me to figure these things out without having to read too much. (It's a bit like that bit in patents which says "this patent also covers derived stuff that is obvious to people versed in the field" - with a document specifying the format, I can infer the existence of different types of software acting in different roles on Atom Feed Documents and Atom Entry Documents.) Having said that, I'm not averse to having a small amount of text defining an Atom Producer as something that creates Feed/Entry Documents in accordance with the spec. > >> It means that all XSLTs, Web hosting > >>services, etc can NOT claim conformance to Atom. :) > > > >Yes they can. > > no for the reason I gave and no because there's no way to claim > conformance to the spec. The reason you gave is that we don't define conformance, but we do. The start of 1.2 says quite clearly: "this specification describes conformance in terms of two artifacts ...", and then goes on to say what those artifacts consist of. I read this as saying, quite clearly, "here are our definitions of two artifacts: obey the rules in this document and you'll be working in the world of comforming Atom documents". I think the argument (discussion? :-) here is just between two different styles of trying to get the same information across. This one has been around a long time, and seems terse yet clear enough to me. I hope I'm not misrepresenting you when I say that your main concern is that this style isn't sufficient. > They are plenty marketing department which will claim conformance to > something even if they have a bad support of it :) Which has after > implications in the world of markets, business offering and > certifications which leads to quagmires. Do we have an example of a spec in the Atom/IETF style that has caused such problems, and of ones in the W3C (conformance level) style that haven't? Marketing departments, unfortunately, will make claims no matter what we write in the final RFC. > >They just can't claim to be Atom Processors unless they > >abide by the rules for Atom Processors (and abide by any definition of > >Atom Processors). > > There's none. We have a number of MUST restrictions on Atom Processors, for instance. > >Something that produces an XML document that abides > >by every normative part of the Atom spec (including honouring every > >MUST clause) that applies to Atom Feed Documents can be considered > >something that 'conforms' to the Atom spec for producing such a > >document. > > Conformity of a document is not conformity of a product. Two > different classes of products. I don't think that's a helpful line of reasoning, but I'm having difficulty expressing why. I understand what you're on about, but consider this: "A JamesGram is a textual representation of the letters 'J', 'a', 'm', 'e', 's', using a character encoding of your choice." From this, I can tell you that software that says "JamesGram arrived!" when it finds the text "Aylett" in some email is NOT compliant to the JamesGram specification. I don't need the specification to define a "JamesGram Reception Agent", or even point out that a JamesGram can be transmitted in the body of an email. This is, I think, a very important point: by saying less, we avoid making assumptions about usage, and can still be clear. The Atom spec defines two file formats. You either support those formats, or you don't. A product /supports/ Atom or it does not. This is why I said initially that I have a problem with the word 'conform' - it's a sticky conceptual path. > >Or, more clearly, it produces Atom Feed Documents. If it > >produced something it claimed were Atom Feed Documents that weren't > >conformant, they wouldn't be Atom Feed Documents. > > Documents and Softwares are not the same thing. No, of course not. Software that works with documents, however, can choose to work with Atom Documents by following the spec, or can choose not to be avoiding it. We don't define an Atom Archiver either, because it's not necessary, practical or even advisable. > >Actually, since this is in the context of a security consideration, > >it's not a restriction on the processors AT ALL. > > Where what you just said is explained. You said before that > everything which is in the spec is normative and now you are saying > that this part is not normative? It is normative, but it is not placing a restriction on an Atom Processor. What it's doing is conveying useful information to people who write Atom Processors - information that will enable them to write better, safer software for their users. We're saying "Atom works like this, by the way you probably want to be careful about these bits". A bit like saying "a car works like this, but you might like to take some lessons first" - the lessons aren't part of the definition of a car. (Actually, I'm reminded of a story someone told me about a C++ compiler engineer who, on leaving his company, was presented with a book on learning how to program in C++ - because he didn't know. He didn't need to be able to /use/ C++ to implement it.) > I'm lost or does it show that it's > important to know which part of the specifications are informative > and which ones are normative? > http://atompub.org/2005/04/18/draft-ietf-atompub- > format-08.html#rfc.section.8 Aren't all parts normative unless stated otherwise? I think they are. > >It's saying "since > >Atom Processors are going to have to work with URIs/IRIs - they'll > >have to handle them - implementors should consult RFC3986 and RFC3987 > >for security considerations in doing this". > > where ? That's what the security considerations sections mean, or at least what I take them to mean. The security considerations sections of RFCs work in a certain way, and this is how I've read them in all sorts of different RFCs. > >>In the prose before it is said: > >>"If the "src" attribute is present, Atom Processors MAY use the IRI > >>to retrieve the content. " > >> > >>What is the behavior of the Atom processor when the MAY is not > >>implemented because it's optional and because it's not mandatory for > >>"Atom Processors" to handle URIs or IRIs. > > > >If we assume, as is I think reasonable, that handling URIs/IRIs is > >something that Atom Processors do by definition, then the last half of > >that question isn't relevant. > > "Assume" MUST not be part of a technical specification. That's the > whole problem here ;) Okay, bad wording. "If we accept that my understanding of what the other bits mean, then ...". English is such a pesky language, and it's bad enough we're using it for the specification, without having to /talk/ about the specification in it :-) (Bring back Wilkins, all is forgiven.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Wed May 25 09:34:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11669 for ; Wed, 25 May 2005 09:34: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 j4PDKk5f008716; Wed, 25 May 2005 06:20: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 j4PDKkTA008715; Wed, 25 May 2005 06:20:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PDKjVI008703 for ; Wed, 25 May 2005 06:20:46 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH1003LJXLNTOA0@osl1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 25 May 2005 17:27:23 +0200 (CEST) Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH100791RWIVNN1@osl1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 25 May 2005 15:24:18 +0200 (CEST) Date: Wed, 25 May 2005 15:25:04 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: The atom:uri element In-reply-to: <67E6EBBC-57B7-45D0-9161-A6AFE639E3A0@mac.com> To: Graham Cc: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <20050525052004.GB10318@klangraum> <67E6EBBC-57B7-45D0-9161-A6AFE639E3A0@mac.com> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 25 May 2005 14:53:05 +0200, Graham wrote: > -1 to "atom:link" unless they are proper link elements. What about atom:author@href, then? > I'm fairly happy with the current situation. Okay, but do you agree that the atom:uri element is a bit inconsistent with the rest of the format specification? -- Asbjrn Ulsberg -=|=- http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away From owner-atom-syntax@mail.imc.org Wed May 25 10:27:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16337 for ; Wed, 25 May 2005 10:27: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 j4PEJDBf018444; Wed, 25 May 2005 07:19: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 j4PEJDQi018443; Wed, 25 May 2005 07:19:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PEJBY7018431 for ; Wed, 25 May 2005 07:19:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PEH87e006504; Wed, 25 May 2005 15:17:14 +0100 (BST) In-Reply-To: References: <20050525052004.GB10318@klangraum> <67E6EBBC-57B7-45D0-9161-A6AFE639E3A0@mac.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: atom-syntax From: Graham Subject: Re: The atom:uri element Date: Wed, 25 May 2005 15:17:07 +0100 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PEJCY7018438 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 25 May 2005, at 2:25 pm, Asbjrn Ulsberg wrote: > What about atom:author@href, then? No, I want multiple uris. I've just checked the spec and noticed it doesn't allow them. Why? Shouldn't I be able to have an http: uri and an aim: uri? And couldn't email be a mailto: uri? +1 to replacing atom:email and atom:uri with multiple real atom:link elements (to allow titles). (I don't care about the rel value) Graham From owner-atom-syntax@mail.imc.org Wed May 25 11:19:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20603 for ; Wed, 25 May 2005 11:19: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 j4PFBGRw032242; Wed, 25 May 2005 08:11: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 j4PFBG4I032241; Wed, 25 May 2005 08:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4PFBDFw032210 for ; Wed, 25 May 2005 08:11:15 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000431564 for ; Thu, 26 May 2005 01:11:12 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 26 May 2005 01:11:08 +1000 Subject: Re: The atom:uri element 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 25/5/05 2:45 PM, "Eric Scheid" wrote: >> I agree with this. I thought it was unusual to name a tag after a specific >> technology rather than its intent (atom:email is an exception). In this >> instance, I think atom:name, atom:resource, or atom:link works better. > > +1 atom:link doh! I was thinking "link" vs "web" vs "any-damn-name" ... totally forgot we already have an element named "link". so ... -1 atom:link which is not a Link Construct +1 atom:link which is a Link Construct +1 renaming atom:uri to something semantic instead of some data type +0.5 to making it an attribute, just as we have with atom:generator -1 to leaving it as it is (yes, yes, I know we don't have Link Construct in the spec any more) e. From owner-atom-syntax@mail.imc.org Wed May 25 13:21:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02194 for ; Wed, 25 May 2005 13:21: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 j4PHE0d5060614; Wed, 25 May 2005 10:14: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 j4PHE07H060613; Wed, 25 May 2005 10:14: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.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PHDxD9060603 for ; Wed, 25 May 2005 10:13:59 -0700 (PDT) (envelope-from pilgrim@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1581449wri for ; Wed, 25 May 2005 10:13:53 -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=o/DDJamVXxo1DZvOWxgS7j5w3IDRF1hpxsRtbwIaYnlPz93f11X0+66h+Jy2+Z7y38dD0H+laBHRG1WeeY1XRbLQC2ilGqMg+kbWWByN/2v63iayOHOclRqq2MtwuKejFEuDLbeZm8lCfU2F/+qSLf1dG6msX8lY/AoUuGo4zXc= Received: by 10.54.8.41 with SMTP id 41mr1369100wrh; Wed, 25 May 2005 10:13:53 -0700 (PDT) Received: by 10.54.25.10 with HTTP; Wed, 25 May 2005 10:13:52 -0700 (PDT) Message-ID: <14be96d3050525101328285f74@mail.gmail.com> Date: Wed, 25 May 2005 13:13:52 -0400 From: Mark Pilgrim Reply-To: Mark Pilgrim To: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Cc: "atom-syntax Syntax'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PHDxD9060608 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/24/05, Karl Dubost wrote: > Validation is something very precise. It can be validated against a > DTD, or against a Schema or another grammar language, etc. At least > the "Feed validator" could become a "Feed checker" which develops a > heuristic to check if the requirements of the specification are > verified. :))) "up to the validator authors" :) This from the organization that added a "fussy parsing" option *enabled by default* in their (X)HTML "Validator" for almost 8 months. -- Cheers, -Mark From owner-atom-syntax@mail.imc.org Wed May 25 14:08:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05524 for ; Wed, 25 May 2005 14:08: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 j4PI06jS073149; Wed, 25 May 2005 11:00: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 j4PI0620073146; Wed, 25 May 2005 11:00:06 -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 j4PI05nm073116 for ; Wed, 25 May 2005 11:00:05 -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 E500F4EEBC; Wed, 25 May 2005 14:00:03 -0400 (EDT) In-Reply-To: <14be96d3050525101328285f74@mail.gmail.com> References: <07263C37-98A2-42D0-8DEA-3087A3F648FC@w3.org> <68fba5c5050523150468d9f7ea@mail.gmail.com> <20050524161935.GZ21277@tartarus.org> <14be96d3050525101328285f74@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4118566C-4DEC-4FBF-BE5F-4A973370CA63@w3.org> Cc: "atom-syntax Syntax'" From: Karl Dubost Subject: Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines Date: Wed, 25 May 2005 14:00:01 -0400 To: Mark Pilgrim X-Mailer: Apple Mail (2.730) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PI05nm073132 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Le 05-05-25 13:13, Mark Pilgrim a crit : > On 5/24/05, Karl Dubost wrote: > >> Validation is something very precise. It can be validated against a >> DTD, or against a Schema or another grammar language, etc. At least >> the "Feed validator" could become a "Feed checker" which develops a >> heuristic to check if the requirements of the specification are >> verified. :))) "up to the validator authors" :) >> > > This from the organization that added a "fussy parsing" option > *enabled by default* in their (X)HTML "Validator" for almost 8 months. To avoid "fussy comment", the W3C Mark-Up Validator exactly. The W3C Mark-Up Validator is maintained by a wonderful community of _volunteers_ And I wish we had more perl developers to help us because the main developers Terje, Nick, Ville and Olivier can't do everything. I wish we could have a Mark-Up checker that would develop also heuristic to check certain requirements of some mark-up languages that are not testable by a Schema or DTD validation. Basically, Mark, you are off-base, it was not a reproach to the feed validator. Quite the opposite, which I always found being a remarkable tool. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Wed May 25 14:08:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05557 for ; Wed, 25 May 2005 14:08: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 j4PI3dH1075237; Wed, 25 May 2005 11:03: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 j4PI3dEu075235; Wed, 25 May 2005 11:03: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-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 j4PI3bVo075209 for ; Wed, 25 May 2005 11:03:38 -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 j4PI3b0R025910 for ; Wed, 25 May 2005 12:03:37 -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 <0IH200KOW4U1MX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 25 May 2005 12:03:37 -0600 (MDT) Received: from [10.192.24.143] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH200APN4U0TI@mail.sun.net> for atom-syntax@imc.org; Wed, 25 May 2005 12:03:37 -0600 (MDT) Date: Wed, 25 May 2005 11:03:46 -0700 From: Tim Bray Subject: Consensus snapshot, 2005/05/25 To: atom-syntax Syntax Message-id: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; 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 The level of traffic in recent days have been ferocious, and reading through it, we observe the WG has consensus on changing the format draft in a surprisingly small number of areas. Here they are: 1. The restriction that atom:author can appear only once is removed. 2. The draft should include an explanation that if entry/author is absent, then all entry/source/author entries apply if there are any, otherwise all feed/author entries apply. 3. Change to previous consensus call. The phrase that begins "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same empty..." loses the language about how software MUST treat them as such. 4. atom:id is a compulsory child of atom:feed (or did we already say that?) 5. rework the last paragraph of 4.1.3.2. First of all, the description involving "text/" and "+xml" needs fixing per Thomas Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/ msg15444.html), and second, the SHOULD is gone, see http:// www.imc.org/atom-syntax/mail-archive/msg15412.html Have I missed any? Yes, there has been high-volume debate on several other issues; but have there been any other outcomes where we can reasonably claim consensus exists? -Tim From owner-atom-syntax@mail.imc.org Wed May 25 14:44:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07709 for ; Wed, 25 May 2005 14:44: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 j4PIcaQi079240; Wed, 25 May 2005 11:38: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 j4PIca76079239; Wed, 25 May 2005 11:38:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIcZ3i079224 for ; Wed, 25 May 2005 11:38:35 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4PIcPWn023840 for ; Wed, 25 May 2005 14:38:34 -0400 (EDT) Received: from boblaptop ([212.129.242.67]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DGC41996 (AUTH bob@wyman.us); Wed, 25 May 2005 14:38:23 -0400 (EDT) Message-Id: <200505251838.DGC41996@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Atom Syntax'" Subject: ByLines, NewsML and interop with other syndication formats Date: Wed, 25 May 2005 14:38:20 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01C56137.66F47700" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVhKvG1sAKRF8FbS8mDOFw6DSR2Bw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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_0069_01C56137.66F47700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've spent an interesting day in Amsterdam at the IPTC News Summit and had a chance to talk about standards convergence issues with various folk in the IPTC (owners of NewsML, NITF, EventsML, SportsML, ANPA, etc.). These folk seem sincerely interested in getting some better worked out compatibility between things like NewsML and Atom. I'd like to suggest that we explicitly invite the IPTC folk to propose a set of Atom extensions (that would include ByLine) with the intention that these extensions would incorporate their detailed knowledge of the publishing world and facilitate the interchange or translation of documents between NewsML, NITF, etc. formats and Atom. bob wyman ------=_NextPart_000_0069_01C56137.66F47700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve spent an = interesting day in Amsterdam at the IPTC News Summit and had a chance to talk about standards = convergence issues with various folk in the IPTC (owners of NewsML, NITF, EventsML, SportsML, ANPA, etc.). These folk seem sincerely interested in getting = some better worked out compatibility between things like NewsML and = Atom…

         =    I’d like to suggest that we explicitly invite the IPTC folk to propose a set of Atom extensions (that would include = ByLine) with the intention that these extensions would incorporate their detailed = knowledge of the publishing world and facilitate the interchange or translation of documents between NewsML, NITF, etc. formats and = Atom.

 

         =             &= nbsp;  bob wyman

 

------=_NextPart_000_0069_01C56137.66F47700-- From owner-atom-syntax@mail.imc.org Wed May 25 14:44:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07732 for ; Wed, 25 May 2005 14:44: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 j4PIa5C0079058; Wed, 25 May 2005 11:36: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 j4PIa5K0079057; Wed, 25 May 2005 11:36:05 -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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIa4pH079049 for ; Wed, 25 May 2005 11:36:04 -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 <20050525183558016004tk20e>; Wed, 25 May 2005 18:35:58 +0000 Date: Wed, 25 May 2005 12:35:56 -0600 Subject: Re: Consensus snapshot, 2005/05/25 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: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> 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 Wednesday, May 25, 2005, at 12:03 PM, Tim Bray wrote: > The level of traffic in recent days have been ferocious, and reading > through it, we observe the WG has consensus on changing the format > draft in a surprisingly small number of areas. Here they are: All looks good (or at least entirely acceptable) to me. One question though: > 3. Change to previous consensus call. The phrase that begins "If > multiple atom:entry elements with the same atom:id value appear in an > Atom Feed document, they describe the same empty..." loses the > language about how software MUST treat them as such. A few of people appeared to support[1][2] this[0]: * State that multiple entries originating in the same feed with the same atom:id are instances of the same entry [yes, they're SUPPOSED to be, even "REQUIRED" to be universally unique, but let's live in the real world] ...but there was no Pace written (oops), and little or no comment directed specifically toward this detail, either for or against. This wording got no response when suggested[3] two days ago: "If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the feed document, they describe the same entry." I'm going to write a Pace right now, in case that will make any difference. Comments? Antone [0] http://www.imc.org/atom-syntax/mail-archive/msg15517.html [1] http://www.imc.org/atom-syntax/mail-archive/msg15518.html [2] http://www.imc.org/atom-syntax/mail-archive/msg15526.html [3] http://www.imc.org/atom-syntax/mail-archive/msg15644.html From owner-atom-syntax@mail.imc.org Wed May 25 15:15:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11176 for ; Wed, 25 May 2005 15:15: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 j4PJ6Wwk087619; Wed, 25 May 2005 12:06: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 j4PJ6WAs087618; Wed, 25 May 2005 12:06:32 -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 j4PJ6VfR087607 for ; Wed, 25 May 2005 12:06:32 -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 <2005052519062601400su863e>; Wed, 25 May 2005 19:06:26 +0000 Date: Wed, 25 May 2005 13:06:19 -0600 Subject: PaceDuplicateIdsEntryOrigin posted (was Re: Consensus snapshot, 2005/05/25) 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: <1383BB62-CD50-11D9-A0FA-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, May 25, 2005, at 12:35 PM, Antone Roundy wrote: > I'm going to write a Pace right now, in case that will make any > difference. Here it is--now comments on that particular detail can be directed at a proper Pace: http://www.intertwingly.net/wiki/pie/PaceDuplicateIdsEntryOrigin == Abstract == State the atom:entries from the same feed with the same ID are the same entry, whether simulateously in the feed document or not. == Status == New == Rationale == * The accepted language for allowing duplicate IDs in a feed document speaks only multiple atom:entry elements with the same atom:id describing the same entry if they exist in the same document--of course, we intend for them to describe the same entry whether they're simultaneously in the feed document or not * The accepted language does not speak of the origin feed of the entries. Ideally, an atom:id should be univerally unique to one entry resource, and we rightly require publishers to mint them with that goal. However, in reality, malicious or undereducted publishers might duplicate the IDs of others. Therefore, it is proposed to modify the specification to state that the atom:entry elements describe the same entry (resource) if they originate in the same feed. * Aggregators wishing to protect against DOS attacks are not unlikely to perform some sort of safety checks to detect malicious atom:id duplication, regardless of whether the specification "authorizes" them to or not. == Proposal == in format-08: 1. Remove this bullet point from 4.1.1: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values. 2. Add the following paragraph, either to atom:entry or atom:feed, at the editors' discretion (instead of the first sentence proposed by PaceAllowDuplicateIDs, if accepted): If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the feed document, they describe the same entry. == Impacts == * Aggregators wishing to both perform duplicate detection and protect against DOS attacks will be justified by the specification in applying their judgement regarding whether entries with the same atom:id come from the same source or not. == Notes == * Because we are unlikely to agree on a method for determining whether the atom:entry elements originate in the same feed or not, no particular method will be specified. * The proposed language does not preclude the possibility of aggregators applying their own judgement regarding whether two atom:entry elements with the same atom:id which originate in different feeds might describe the same entry resource, which they might if someone posts the same to entry to, for example, a category feed and a feed of all their categories, and doesn't present one as having been aggregated from the other by including an atom:source element. From owner-atom-syntax@mail.imc.org Wed May 25 15:28:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12471 for ; Wed, 25 May 2005 15:28: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 j4PJM3MG088542; Wed, 25 May 2005 12:22: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 j4PJM3tt088541; Wed, 25 May 2005 12:22:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJM2N2088512 for ; Wed, 25 May 2005 12:22:02 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PJKipX015933; Wed, 25 May 2005 20:20:55 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DBC1801-D7A8-4959-99C6-21D4BF061EAC@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: Consensus snapshot, 2005/05/25 Date: Wed, 25 May 2005 20:20:43 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 May 2005, at 7:35 pm, Antone Roundy wrote: > "If multiple atom:entry elements originating in the same Atom feed > have the same atom:id value, whether they exist simultaneously in > one document or in different instances of the feed document, they > describe the same entry." > > I'm going to write a Pace right now, in case that will make any > difference. Comments? What about when they don't? I don't see any value here. A line saying that when two matching entry ids found in different feeds is fine, but (apparently) saying it's completely meaningless goes way, way too far. (Also, do we have a definition for "Atom feed" that exists beyond a single instance of a "feed document"?) Graham From owner-atom-syntax@mail.imc.org Wed May 25 15:38:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13633 for ; Wed, 25 May 2005 15:38: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 j4PJWooa089146; Wed, 25 May 2005 12:32: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 j4PJWopK089145; Wed, 25 May 2005 12:32:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4PJWnnl089119 for ; Wed, 25 May 2005 12:32:50 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] ([203.30.247.18] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000432365 for ; Thu, 26 May 2005 05:32:48 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 26 May 2005 05:32:44 +1000 Subject: Re: Consensus snapshot, 2005/05/25 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <5DBC1801-D7A8-4959-99C6-21D4BF061EAC@mac.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/5/05 5:20 AM, "Graham" wrote: > (Also, do we have a definition for "Atom feed" that exists beyond a > single instance of a "feed document"?) we should have, but we don't. similarly for "Atom Entry". e. From owner-atom-syntax@mail.imc.org Wed May 25 15:41:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14011 for ; Wed, 25 May 2005 15:41: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 j4PJYCJD089213; Wed, 25 May 2005 12:34: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 j4PJYCrD089212; Wed, 25 May 2005 12:34:12 -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 j4PJYAvx089206; Wed, 25 May 2005 12:34:10 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505251838.DGC41996@ms8.netsolmail.com> References: <200505251838.DGC41996@ms8.netsolmail.com> Date: Wed, 25 May 2005 12:34:07 -0700 To: , "'Atom Syntax'" From: Paul Hoffman Subject: Re: ByLines, NewsML and interop with other syndication formats 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:38 PM -0400 5/25/05, Bob Wyman wrote: > I'd like to suggest that we explicitly invite the IPTC >folk to propose a set of Atom extensions (that would include ByLine) >with the intention that these extensions would incorporate their >detailed knowledge of the publishing world and facilitate the >interchange or translation of documents between NewsML, NITF, etc. >formats and Atom. The IETF can't formally do this, but wearing my co-chair hat I'll happily +1 that. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 25 16:10:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20571 for ; Wed, 25 May 2005 16:10: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 j4PK1mrm094652; Wed, 25 May 2005 13:01: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 j4PK1mWU094651; Wed, 25 May 2005 13:01: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 [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PK1ljU094635 for ; Wed, 25 May 2005 13:01: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 <20050525200139016004tmr7e>; Wed, 25 May 2005 20:01:39 +0000 Date: Wed, 25 May 2005 14:01:38 -0600 Subject: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) 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: <5DBC1801-D7A8-4959-99C6-21D4BF061EAC@mac.com> 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 Wednesday, May 25, 2005, at 01:20 PM, Graham wrote: > On 25 May 2005, at 7:35 pm, Antone Roundy wrote: >> "If multiple atom:entry elements originating in the same Atom feed >> have the same atom:id value, whether they exist simultaneously in one >> document or in different instances of the feed document, they >> describe the same entry." > > What about when they don't? I don't see any value here. A line saying > that when two matching entry ids found in different feeds is fine, but > (apparently) saying it's completely meaningless goes way, way too far. In my grand tradition (...I'm sure I've done this before), I've posted an alternative to my own proposal. The following would legitimize considering more than just atom:id in doing duplicate detection in order to protect against DOS, but without risking anyone thinking we've weakened the requirement for universal uniqueness of atom:id. I'd vote for this over PaceDuplicateIdsEntryOrigin, and PaceDuplicateIdsEntryOrigin over no change. http://www.intertwingly.net/wiki/pie/PaceAtomIdDos == Abstract == Point out the potential for denial of service by duplicating others' atom:id values. == Status == New == Rationale == * We want atom:id to be univerally unique to a particular entry resource. * However, depending on such uniqueness could lead to denial of service attacks where the attacker publishes an entry with an atom:id value used by someone else. * Restricting the uniqueness scope of atom:id entirely to a single feed would make it much less valuable, since entries are often copied form feed to feed, and sometimes simultaneously published in multiple feeds. * Only requiring entries with the same atom:id to be considered the same if coming from the same feed, but allowing the consuming application to exercize judgement with respect to entries originating in different feeds is a much better match with reality. * Still, pointing out the potential for DOS attacks in the Security Considerations section may be preferable to loosening the scope of atom:id uniqueness elsewhere in the spec in either of the ways describe by the preceding bullet points. == Proposal == Add the following to format-08: 8.5 Denial of Service Attacks Atom Processors should be aware of the potential for denial of service attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, and perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value or combination of atom:id and atom:updated values, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates. From owner-atom-syntax@mail.imc.org Wed May 25 16:34:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27289 for ; Wed, 25 May 2005 16:34: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 j4PKNkxB095601; Wed, 25 May 2005 13: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 j4PKNkQk095600; Wed, 25 May 2005 13:23:46 -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 j4PKNjv1095593 for ; Wed, 25 May 2005 13:23:45 -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 AFC71B6 for ; Wed, 25 May 2005 13:23:40 -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 j4PKNYng029418 for ; Wed, 25 May 2005 13:23:40 -0700 (PDT) Date: Wed, 25 May 2005 13:38:14 -0700 From: Walter Underwood To: atom-syntax Syntax Subject: Re: Consensus snapshot, 2005/05/25 Message-ID: <2B52E1B0C1A3314D9C2405C9@diva.verity.com> In-Reply-To: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> References: <649FD186-18E7-4127-B898-BE4F9332031F@sun.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 Wednesday, May 25, 2005 11:03:46 AM -0700 Tim Bray wrote: > > Have I missed any? Yes, there has been high-volume debate on several > other issues; but have there been any other outcomes where we can > reasonably claim consensus exists? Changing atom:author to atom:creator? No objections, so far. I paste together a PACE with the official Dublin Core definition. Should we mention DC for atom:contributor? wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed May 25 16:37:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27506 for ; Wed, 25 May 2005 16:37: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 j4PKQ5mw095731; Wed, 25 May 2005 13:26: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 j4PKQ5xA095730; Wed, 25 May 2005 13:26:05 -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 j4PKQ5EZ095723 for ; Wed, 25 May 2005 13:26:05 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 92823 invoked by uid 17064); 25 May 2005 20:26:04 -0000 Received: from unknown (HELO [192.168.0.2]) ([83.112.132.127]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 25 May 2005 20:26:04 -0000 Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88BD53F5-CB42-4749-9A0B-EDC9B15E9F89@bblfish.net> Cc: Antone Roundy Content-Transfer-Encoding: 7bit From: Henry Story Subject: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted Date: Wed, 25 May 2005 22:26:02 +0200 To: atom-syntax Syntax X-Mailer: Apple Mail (2.730) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 May 2005, at 21:06, Antone Roundy wrote: > > * The accepted language does not speak of the origin feed of the > entries. Ideally, an atom:id should be univerally unique to one > entry resource, and we rightly require publishers to mint them with > that goal. However, in reality, malicious or undereducted > publishers might duplicate the IDs of others. Therefore, it is > proposed to modify the specification to state that the atom:entry > elements describe the same entry (resource) if they originate in > the same feed. > * Aggregators wishing to protect against DOS attacks are not > unlikely to perform some sort of safety checks to detect malicious > atom:id duplication, regardless of whether the specification > "authorizes" them to or not. I understand your motivation, but I think it is misguided. I only recently understood why myself [1]. Let me explain a little how I come to this conclusion. An easy way to understand semantics is to think of it as about the objects out there. Take the sentences: (a) Superman can fly (b) Superman is Clark Kent we can immediately deduce truly that (c) Clark Kent can fly. Since the referents of "Superman" and "Clark Kent" are the same, what is true of the one, is true of the other. When speaking directly about the world, we can replace any occurrence of Superman with Clark Kent, and still say something true. When we are speaking about what others believe, this is no longer true. Lois Lane may believe (a) without believing (c). She may think Superman is a hero, but not think that Clark Kent is one. There is in logic therefore a fundamental distinction between sentences used in a direct semantic way, and sentences used in this indirect way, when the sentence is in a belief context. This distinction is so fundamental that there is a well known mental illness that goes with people who are not able to make this distinction: autism. Autistic children have great difficulty understanding the difference between what is and how people perceive things to be. In RDF this distinction shows up when moving from triples to 4- tuples. RDF/XML is a language that works best in the Semantic realm. With triples we can describe objects and their relationships. If we want speak about consistent ways of seeing the world we need to group statements with formulae as is done in N3[2] and TriX for example. This then allows us to name consistent sets of statements. It also allows one to simultaneously refer to sets that are inconsistent. I can for example consistently hold the following: Lois lane believes that Superman is different from Clark Kent Clark Kent believes that he is Superman. without contradiction. So how does this relate to Atom? Well we need to be clear that semantically a entryId and a feedId point to one thing and one thing only. But this does not mean that there can not be erroneous, false, corrupted,... feeds out there. Aggregators wishing to protect against DOS attacks should simply do what we humans do in such circumstances, namely quote what others are saying and not assert the things others are saying. This is why the proposal by Roy Fielding to allow feeds inside of feeds was probably the best way to do things (I just came to this conclusion yesterday, before this I had no idea what he was going on about). So to prevent a DOS attack, best is to have aggregator feeds such as: tag://true.org,2005/feed1 Enter your credit card number here ... tag://true.org,2005/feed1 Enter your credit card number here ... Here all the aggregator feed is claiming is that he has seen entries inside other feeds. He never need claim to agree with any of their content. And so the content of the first internal feed and the second internal feed can be contradictory. They can for example have the same id with the same updated timestamp and with different content. It will be up to the consumer of such aggregated feeds to decide which to trust. The good thing about this way of doing things is that one can define a first level feed in a simple semantic vocabulary, without needing to create all kinds of exceptional clauses all over the place. When dealing with feeds inside a feed one can then simply mention that this indirection is equivalent to the belief context indirection. Statements can be contradictory across such internal feeds. Taking this into account should help make the spec a lot cleaner, easier to write and easier to understand. The problems are fundamental, so they cannot be swept under the carpet. They will keep popping up. Henry Story [1] http://www.imc.org/atom-syntax/mail-archive/msg15608.html [2] http://www.w3.org/DesignIssues/Notation3.html From owner-atom-syntax@mail.imc.org Wed May 25 16:50:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28223 for ; Wed, 25 May 2005 16:50: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 j4PKegcs096531; Wed, 25 May 2005 13:40: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 j4PKegiT096530; Wed, 25 May 2005 13:40: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.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PKefPq096521 for ; Wed, 25 May 2005 13:40:41 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so70661wra for ; Wed, 25 May 2005 13:40:36 -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=XpG+oDeTW480KRYOewROjpzHLodmIDrtD0G2rxQJEW8yH9qJ99Jvg0FEI80ZmNQnBCdN0EcQ0abak5zD8XYU7BfVN36LJ7ZCV/oVsAlwjMo1S7cw1jrwSEV1EyAAifj2aJP08S2mpyAc8el97f0kcu9pqjXTcSiRF7XfPzWp+B4= Received: by 10.54.52.61 with SMTP id z61mr552714wrz; Wed, 25 May 2005 13:40:35 -0700 (PDT) Received: by 10.54.71.13 with HTTP; Wed, 25 May 2005 13:40:35 -0700 (PDT) Message-ID: <68fba5c505052513404ed6e350@mail.gmail.com> Date: Wed, 25 May 2005 16:40:35 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: Consensus snapshot, 2005/05/25 Cc: atom-syntax Syntax In-Reply-To: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PKefPq096524 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5/25/05, Tim Bray wrote: > Have I missed any? Yes, there has been high-volume debate on several > other issues; but have there been any other outcomes where we can > reasonably claim consensus exists? Not in my opinion. Looks good to me. Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 25 16:53:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28336 for ; Wed, 25 May 2005 16:53: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 j4PKfA7I096570; Wed, 25 May 2005 13: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 j4PKfASd096569; Wed, 25 May 2005 13:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PKf9Fe096560 for ; Wed, 25 May 2005 13:41:09 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050525204059.WNSH9046.mta09-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Wed, 25 May 2005 21:40:59 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050525204058.TZNQ18002.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 25 May 2005 21:40:58 +0100 Date: Wed, 25 May 2005 21:40:54 +0100 From: David Powell X-Mailer: The Bat! (v3.5.0.16) Professional X-Priority: 3 (Normal) Message-ID: <1225690969.20050525214054@djpowell.net> To: Tim Bray CC: atom-syntax Subject: Re: extension elements inside link elements? In-Reply-To: <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> References: <68fba5c505052408075404b24f@mail.gmail.com> <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@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 Tuesday, May 24, 2005, 9:28:09 PM, Tim Bray wrote: > On the one hand I agree with Graham; this does feel like a > substantial change. On the other, it's hard to see that having stuff > inside would do any damage; I best most software would never > notice it. Having said that, I don't agree that it's editorial > change and I'd like to see a couple more voices in favor and give > people a chance to shout "No!" before going ahead and doing it. -Tim I'm either +1 or -1. I haven't decided yet, but I'm lying in the road on this one :) I can't answer this until something is explained to me: What is section 6.3 "unknown foreign markup" for? * We have content constructs which are extensible by allowing any type of data to be embedded using the IANA registry of MIME types. * We have carefully designed an IANA registry for @rel values, and used the distributed nature of namespace URIs to allow for unregistered values. * We have carefully defined two classes of extension construct (Simple and Structured) to ensure that extensions are disambiguated by namespace URIs, and that xml:lang issues are considered. Simple extensions make generic support for this class of extension feasible for real-world implementations; Structured extensions are there for those that need the extra power. And, we have "unknown foreign markup". I believed that the purpose of "unknown foreign markup" was to define an error handling strategy for parsers, and to give the spec a bit of breathing room for things like Atom 1.1. This is great. But I'm getting a sneaking suspicion though, that "unknown foreign markup" is positioning itself as a third (poorly thought through) class of extension point. Please tell me that that isn't the intent? In the future someone said: > Hey, I've had an idea for an extension to atom:link. The text content > of atom:link could be a tooltip giving a long description for the link > It would work like this: > > > This is a picture of my holiday. I'm the one on the right. > > > What do you think? In the future someone said: > Hey, I've had an idea for an extension to atom:link. The text content > of atom:link could be a GUID of an ActiveX control that is capable of > displaying the linked object. It would work like this: > > > 0A28AB31-3143-4b70-B969-8650BDFDBAC9 > > > What do you think? -- Dave From owner-atom-syntax@mail.imc.org Wed May 25 16:55:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28468 for ; Wed, 25 May 2005 16:55: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 j4PKo4iw099684; Wed, 25 May 2005 13:50: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 j4PKo4CP099683; Wed, 25 May 2005 13:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PKo3HF099656 for ; Wed, 25 May 2005 13:50:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PKn59W008201; Wed, 25 May 2005 21:49:11 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <332C7B9D-F25A-48AD-AC04-626453501A55@mac.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) Date: Wed, 25 May 2005 21:49:04 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 May 2005, at 9:01 pm, Antone Roundy wrote: > 8.5 Denial of Service Attacks > > Atom Processors should be aware of the potential for denial of > service attacks where the attacker publishes an atom:entry with the > atom:id value of an entry from another feed, and perhaps with a > falsified atom:source element duplicating the atom:id of the other > feed. Atom Processors which, for example, suppress display of > duplicate entries by displaying only one entry with a particular > atom:id value or combination of atom:id and atom:updated values, > might also take steps to determine whether the entries originated > from the same publisher before considering them to be duplicates. How is this a "Denial of service" attack? Isn't it just ordinary spoofing/impersonation? Apart from that, +1. Graham From owner-atom-syntax@mail.imc.org Wed May 25 17:03:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29005 for ; Wed, 25 May 2005 17:03: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 j4PKvUkl000609; Wed, 25 May 2005 13:57: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 j4PKvUDm000608; Wed, 25 May 2005 13:57:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PKvUIE000597 for ; Wed, 25 May 2005 13:57: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 (rwcrmhc13) with SMTP id <2005052520572401500ftel2e>; Wed, 25 May 2005 20:57:24 +0000 Date: Wed, 25 May 2005 14:57:22 -0600 Subject: Re: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted 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: <88BD53F5-CB42-4749-9A0B-EDC9B15E9F89@bblfish.net> Message-Id: <972346C6-CD5F-11D9-A0FA-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, May 25, 2005, at 02:26 PM, Henry Story wrote: > Since the referents of "Superman" and "Clark Kent" are the same, what > is true of the one, > is true of the other. When speaking directly about the world, we can > replace any occurrence > of Superman with Clark Kent, and still say something true. "Clark Kent is the secret identity of Superman." -> "Superman is the secret identity of Superman." Whether they're perfectly interchangeable or not depends on whether the name is referring to the object or some a facet of the object. The second sentence actually works if the first "Superman" refers to the persona, and the second to the person. But getting back to Atom... > Autistic children have great difficulty understanding the difference > between what is and how people perceive things to be. They sure don't have a monopoly on this! Really getting back to Atom!... > So to prevent a DOS attack, best is to have aggregator feeds such as: > > > > > tag://true.org,2005/feed1 > > Enter your credit card number here > ... > > > > tag://true.org,2005/feed1 > > Enter your credit card number here > ... > > > > > Here all the aggregator feed is claiming is that he has seen entries > inside other > feeds. ... > It will be up to the consumer of such aggregated feeds to decide which > to trust. From the end user's point of view, it's not much different. Somebody still has to make the decision, and the end user doesn't want to be the one doing it--they want the super aggregator or their feed reader or somebody else to do it for them. The feed reader should be doing it anyway, since they won't be getting all of their data through a super aggregator. But the super aggregator is likely to want to do it too, both to reduce how much data they forward to their clients, and because many feed readers aren't going to do it very well, so handling part of the job for them will improve the end user's experience. I'm not a fan of feeds of feeds (though I have proposed and still like a one-level embedding of feeds in a different top-level element). Plus, I think it's inconceivable that the WG would make this drastic a change at this point. Let's focus on doing what's actually possible, given the WG schedule and temperment, to mitigate this problem. From owner-atom-syntax@mail.imc.org Wed May 25 17:12:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29440 for ; Wed, 25 May 2005 17:12: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 j4PL5dpl001153; Wed, 25 May 2005 14:05: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 j4PL5dIG001152; Wed, 25 May 2005 14:05:39 -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 j4PL5d7e001144 for ; Wed, 25 May 2005 14:05:39 -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 <2005052521053401400sqjeve>; Wed, 25 May 2005 21:05:34 +0000 Date: Wed, 25 May 2005 15:05:32 -0600 Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) 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: <332C7B9D-F25A-48AD-AC04-626453501A55@mac.com> 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 Wednesday, May 25, 2005, at 02:49 PM, Graham wrote: > On 25 May 2005, at 9:01 pm, Antone Roundy wrote: >> 8.5 Denial of Service Attacks >> >> Atom Processors should be aware of the potential for denial of >> service attacks where the attacker publishes an atom:entry with the >> atom:id value of an entry from another feed, and perhaps with a >> falsified atom:source element duplicating the atom:id of the other >> feed. Atom Processors which, for example, suppress display of >> duplicate entries by displaying only one entry with a particular >> atom:id value or combination of atom:id and atom:updated values, >> might also take steps to determine whether the entries originated >> from the same publisher before considering them to be duplicates. > > How is this a "Denial of service" attack? Isn't it just ordinary > spoofing/impersonation? > > Apart from that, +1. I don't particularly care whether we call it a DOS or something else, as long as we point it out and give implementers something to point to if asked why they're not simply accepting atom:id at face value. But is it not potentially a DOS? The Good Guy publishes an entry. The Bad Guy copies the atom:id of that entry into an entry with different content, gives it a later atom:updated, and publishes it. The aggregator stops publishing/displaying the Good Guy's entry and instead publishes/displays the Bad Guy's entry. Thus, the subscriber doesn't see the Good Guy's entry (unless they saw it before it was replaced). But you're also right--if they saw it before it was replaced and then, when they see the "updated" version, they think it was updated by The Good Guy, it becomes a spoof/impersonation. Perhaps we should say "Denial of Service and Spoofing Attacks" and "...potential for denial of service and spoofing attacks..."? How that's worded doesn't really matter to me. From owner-atom-syntax@mail.imc.org Wed May 25 17:13:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29637 for ; Wed, 25 May 2005 17:13: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 j4PL4lgL001086; Wed, 25 May 2005 14:04: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 j4PL4l8M001085; Wed, 25 May 2005 14:04: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-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 j4PL4kRb001079 for ; Wed, 25 May 2005 14:04:46 -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 j4PL4j0R005693 for ; Wed, 25 May 2005 15:04:46 -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 <0IH200JQ1D7XRL@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 25 May 2005 15:04:45 -0600 (MDT) Received: from [10.224.11.150] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH2002RAD7WUG@mail.sun.net> for atom-syntax@imc.org; Wed, 25 May 2005 15:04:45 -0600 (MDT) Date: Wed, 25 May 2005 14:04:52 -0700 From: Tim Bray Subject: Re: extension elements inside link elements? In-reply-to: <1225690969.20050525214054@djpowell.net> To: David Powell Cc: atom-syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <68fba5c505052408075404b24f@mail.gmail.com> <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 25, 2005, at 1:40 PM, David Powell wrote: > What is section 6.3 "unknown foreign markup" for? I think the notion of foreign markup exists so that we can write the extremely-important section 6.3, our MustIgnore assertion. The point is, either software knows what to do with an extension and does it, or if not it's not allowed to to break and should pass text through in contentful contexts. -Tim > > > * We have content constructs which are extensible by allowing any type > of data to be embedded using the IANA registry of MIME types. > > * We have carefully designed an IANA registry for @rel values, and > used > the distributed nature of namespace URIs to allow for unregistered > values. > > * We have carefully defined two classes of extension construct (Simple > and Structured) to ensure that extensions are disambiguated by > namespace URIs, and that xml:lang issues are considered. Simple > extensions make generic support for this class of extension feasible > for real-world implementations; Structured extensions are there for > those that need the extra power. > > And, we have "unknown foreign markup". > > > I believed that the purpose of "unknown foreign markup" was to define > an error handling strategy for parsers, and to give the spec a bit of > breathing room for things like Atom 1.1. This is great. > > But I'm getting a sneaking suspicion though, that "unknown foreign > markup" is positioning itself as a third (poorly thought through) > class of extension point. > > Please tell me that that isn't the intent? > > > > In the future someone said: > > >> Hey, I've had an idea for an extension to atom:link. The text >> content >> of atom:link could be a tooltip giving a long description for the >> link >> It would work like this: >> >> >> This is a picture of my holiday. I'm the one on the right. >> >> >> What do you think? >> > > > In the future someone said: > > >> Hey, I've had an idea for an extension to atom:link. The text >> content >> of atom:link could be a GUID of an ActiveX control that is capable of >> displaying the linked object. It would work like this: >> >> >> 0A28AB31-3143-4b70-B969-8650BDFDBAC9 >> >> >> What do you think? >> > > > -- > Dave > > From owner-atom-syntax@mail.imc.org Wed May 25 17:35:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00672 for ; Wed, 25 May 2005 17:35: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 j4PLTNJC002513; Wed, 25 May 2005 14: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 j4PLTN4R002512; Wed, 25 May 2005 14:29:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PLTLqv002503 for ; Wed, 25 May 2005 14:29:22 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050525212916.DAJG23015.mta05-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Wed, 25 May 2005 22:29:16 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050525212916.HGVT2392.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Wed, 25 May 2005 22:29:16 +0100 Date: Wed, 25 May 2005 22:29:12 +0100 From: David Powell X-Mailer: The Bat! (v3.5.0.16) Professional X-Priority: 3 (Normal) Message-ID: <1024293439.20050525222912@djpowell.net> To: Tim Bray CC: atom-syntax Subject: Re: extension elements inside link elements? In-Reply-To: References: <68fba5c505052408075404b24f@mail.gmail.com> <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@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 Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote: > On May 25, 2005, at 1:40 PM, David Powell wrote: >> What is section 6.3 "unknown foreign markup" for? > I think the notion of foreign markup exists so that we can write the > extremely-important section 6.3, our MustIgnore assertion. Sorry I wasn't clear: When I said "Section 6.3" markup, I was referring to the subset of "Section 6.3 markup" that isn't also a "Section 6.4 extension". (we could do with a term for this) Section 6.4 extensions are MustIgnore, so what is this other subset of 6.3 markup for? I know that it the intent is that Atom parsers shouldn't fail on it, but is it supposed to be an extension point for extension authors? The problem with section 6 is that we define 3 different classes of non-Atom markup, but don't say why we've done that, or help authors to know which type they should choose when they write a document. I'll have a go at writing an editorial proposal to explain things a bit better. It doesn't really make sense we have thought out how to extend atom:feed, atom:entry, atom:author etc, but atom:link is a sub-RSS free-for-all. -- Dave From owner-atom-syntax@mail.imc.org Wed May 25 18:03:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02418 for ; Wed, 25 May 2005 18: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 j4PLuaQH006020; Wed, 25 May 2005 14:56: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 j4PLua0G006019; Wed, 25 May 2005 14:56:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PLuZIw006000 for ; Wed, 25 May 2005 14:56:36 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4PLtMFx023489; Wed, 25 May 2005 22:55:27 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) Date: Wed, 25 May 2005 22:55:21 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.730) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 May 2005, at 10:05 pm, Antone Roundy wrote: > But is it not potentially a DOS? The Good Guy publishes an entry. > The Bad Guy copies the atom:id of that entry into an entry with > different content, gives it a later atom:updated, and publishes > it. The aggregator stops publishing/displaying the Good Guy's > entry and instead publishes/displays the Bad Guy's entry. Thus, > the subscriber doesn't see the Good Guy's entry (unless they saw it > before it was replaced). Technically, yes, it is denial of service. But the term "Denial of Service" refers specifically to attacks where the main objective is to prevent a service being accessible. Replacing content does deny service, yes, but it's also a lot more than that. Graham From owner-atom-syntax@mail.imc.org Wed May 25 18:44:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05725 for ; Wed, 25 May 2005 18:44: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 j4PMZv3C008497; Wed, 25 May 2005 15:35: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 j4PMZvqp008496; Wed, 25 May 2005 15:35:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4PMZugd008488 for ; Wed, 25 May 2005 15:35:56 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 41018 messnum 2890542 invoked from network[83.70.217.193/unknown]); 25 May 2005 22:35:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail06.svc.cra.dublin.eircom.net (qp 41018) with SMTP; 25 May 2005 22:35:49 -0000 Message-ID: <4294FDC5.6070307@dehora.net> Date: Wed, 25 May 2005 23:35:49 +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 Syntax Subject: Re: Consensus snapshot, 2005/05/25 References: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> In-Reply-To: <649FD186-18E7-4127-B898-BE4F9332031F@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: > Have I missed any? Yes, there has been high-volume debate on several > other issues; but have there been any other outcomes where we can > reasonably claim consensus exists? -Tim Good summary, thank you. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 25 19:32:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08089 for ; Wed, 25 May 2005 19:32: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 j4PNNmig024462; Wed, 25 May 2005 16:23: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 j4PNNm4B024461; Wed, 25 May 2005 16:23:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PNNlWo024364 for ; Wed, 25 May 2005 16:23:47 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050525232341.OEXF12530.mta13-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com> for ; Thu, 26 May 2005 00:23:41 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050525232341.XWWC242.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com> for ; Thu, 26 May 2005 00:23:41 +0100 Date: Thu, 26 May 2005 00:23:37 +0100 From: David Powell X-Mailer: The Bat! (v3.5.0.16) Professional X-Priority: 3 (Normal) Message-ID: <376130909.20050526002337@djpowell.net> To: Atom Syntax Subject: Re: Comments about Extensions (1) In-Reply-To: <907035544.20050524201957@djpowell.net> References: <907035544.20050524201957@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 > Section 6.4: > The RNGs in this section require Extension Elements to be in a > namespace that isn't the Atom namespace. This requirement is missing > from the text. Just a note: This proposal doesn't rehash the "extensions -- Atom NS and unprefixed attributes" thread [1], because it only applies to "6.4 Extension Elements"; not to "6.2 future extensions to atom" - so the arguments about change control of the specification are irrelevant. Is this just an editorial fix on the basis that it is already in the RNG, and 6.4.1 already implies the presence of a namespace URI; or do I need to campaign for consensus on this? [1] http://www.imc.org/atom-syntax/mail-archive/msg15035.html -- Dave From owner-atom-syntax@mail.imc.org Wed May 25 19:53:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09231 for ; Wed, 25 May 2005 19:53: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 j4PNlVUZ029207; Wed, 25 May 2005 16:47: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 j4PNlV4h029206; Wed, 25 May 2005 16:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PNlU92029128 for ; Wed, 25 May 2005 16:47:31 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050525234724.IOIT20297.mta10-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Thu, 26 May 2005 00:47:24 +0100 Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050525234724.NKOP29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>; Thu, 26 May 2005 00:47:24 +0100 Date: Thu, 26 May 2005 00:47:20 +0100 From: David Powell X-Mailer: The Bat! (v3.5.0.16) Professional X-Priority: 3 (Normal) Message-ID: <1665867878.20050526004720@djpowell.net> To: Tim Bray CC: atom-syntax Subject: Re: extension elements inside link elements? In-Reply-To: References: <68fba5c505052408075404b24f@mail.gmail.com> <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@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 Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote: > I think the notion of foreign markup exists so that we can write the > extremely-important section 6.3, our MustIgnore assertion. The point > is, either software knows what to do with an extension and does it, > or if not it's not allowed to to break and should pass text through > in contentful contexts. -Tim Basically, I want future versions of Atom to be able to add markup anywhere it likes (including on or inside atom:link), and Atom 1.0 should be designed to ignore such "unknown foreign markup". What I really don't want is "unknown foreign markup" to be used as a poor-man's "Extension Element". Does that match the consensus of the WG? I'm also a bit confused about the terminology in Section 6.3: > It might be the case that the software is able to process the > foreign markup correctly and does so. Otherwise, such markup is > termed "unknown foreign markup". So "unknown foreign markup" is "foreign markup" that software is unable to process? But then 6.3 goes on to explain how to process it. This sounds like a contradiction? Also, in what cases would software be able to process "foreign markup" other than by ignoring it as described in section 6.3 or treating it as a 6.4 extension? So I don't see how the term "foreign markup" and "unknown foreign markup" are any different? Also, if 6.4 extensions are a subset of "unknown[?] foreign markup", then the rule "[software] MUST NOT change its behavior as a result of the markup's presence" doesn't really make sense? Surely extensions can change the behaviour of software. -- Dave From owner-atom-syntax@mail.imc.org Wed May 25 20:26:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11533 for ; Wed, 25 May 2005 20:26: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 j4Q0EguQ038977; Wed, 25 May 2005 17:14: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 j4Q0Egsg038976; Wed, 25 May 2005 17:14: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.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q0EfKn038968 for ; Wed, 25 May 2005 17:14:41 -0700 (PDT) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1856626wri for ; Wed, 25 May 2005 17:14:35 -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=taYrEE+Lqj/p83xNovuBrq4Li0guoXU1r3pDwoKxt5stEyZg52oA+Vo8eftIvwzq+4KZWbIMzpv1tl6E91Xl1xaUSWgH/1MzKcLVQxynKGZu3evuUkpprvJChKhExbFdwOpnMsAVXYINARVhlHtlnQc/TzU9rNzdqAZ38T0C2ZY= Received: by 10.54.44.53 with SMTP id r53mr1595660wrr; Wed, 25 May 2005 17:14:35 -0700 (PDT) Received: from ?192.168.1.102? ([67.181.223.222]) by mx.gmail.com with ESMTP id g2sm1229272wra.2005.05.25.17.14.35; Wed, 25 May 2005 17:14:35 -0700 (PDT) Message-ID: <429514D5.5020509@gmail.com> Date: Wed, 25 May 2005 17:14:13 -0700 From: James M Snell 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: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) 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 Please forgive me for stepping in here, because of the recent list volume I've only been able to partially pay attention to this discussion, but I just wanted to make a quick observation.. Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? If I put out an entry with a given ID and digitally sign it, and someone comes along and attempts to publish an entry with a duplicate ID and updated timestamp and it is NOT signed with the same key my original was signed with, then hey, Houston we've got a problem. Without any kind of cryptographic guarantee of this sort, the best you could do is make an educated guess. Would it make sense to include some language along these lines? Antone Roundy wrote: > > On Wednesday, May 25, 2005, at 02:49 PM, Graham wrote: > >> On 25 May 2005, at 9:01 pm, Antone Roundy wrote: >> >>> 8.5 Denial of Service Attacks >>> >>> Atom Processors should be aware of the potential for denial of >>> service attacks where the attacker publishes an atom:entry with the >>> atom:id value of an entry from another feed, and perhaps with a >>> falsified atom:source element duplicating the atom:id of the other >>> feed. Atom Processors which, for example, suppress display of >>> duplicate entries by displaying only one entry with a particular >>> atom:id value or combination of atom:id and atom:updated values, >>> might also take steps to determine whether the entries originated >>> from the same publisher before considering them to be duplicates. >> >> >> How is this a "Denial of service" attack? Isn't it just ordinary >> spoofing/impersonation? >> >> Apart from that, +1. > > > I don't particularly care whether we call it a DOS or something else, > as long as we point it out and give implementers something to point to > if asked why they're not simply accepting atom:id at face value. > > But is it not potentially a DOS? The Good Guy publishes an entry. > The Bad Guy copies the atom:id of that entry into an entry with > different content, gives it a later atom:updated, and publishes it. > The aggregator stops publishing/displaying the Good Guy's entry and > instead publishes/displays the Bad Guy's entry. Thus, the subscriber > doesn't see the Good Guy's entry (unless they saw it before it was > replaced). > > But you're also right--if they saw it before it was replaced and then, > when they see the "updated" version, they think it was updated by The > Good Guy, it becomes a spoof/impersonation. Perhaps we should say > "Denial of Service and Spoofing Attacks" and "...potential for denial > of service and spoofing attacks..."? How that's worded doesn't really > matter to me. > > From owner-atom-syntax@mail.imc.org Wed May 25 20:43:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16734 for ; Wed, 25 May 2005 20:43: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 j4Q0WWNp039775; Wed, 25 May 2005 17:32: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 j4Q0WWJW039774; Wed, 25 May 2005 17:32: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 j4Q0WVRc039768 for ; Wed, 25 May 2005 17:32: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 j4Q0WVjO017465 for ; Wed, 25 May 2005 18:32:31 -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 <0IH200LAOMU68H@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 25 May 2005 18:32:31 -0600 (MDT) Received: from [192.168.1.100] ([216.113.204.6]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IH200AGCMU5O6@mail.sun.net> for atom-syntax@imc.org; Wed, 25 May 2005 18:32:30 -0600 (MDT) Date: Wed, 25 May 2005 17:32:40 -0700 From: Tim Bray Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25) In-reply-to: <332C7B9D-F25A-48AD-AC04-626453501A55@mac.com> To: Graham Cc: Antone Roundy , atom-syntax Message-id: <5550C4AC-A2CE-40B4-A886-2DA6576C3ADD@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.730) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <332C7B9D-F25A-48AD-AC04-626453501A55@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On May 25, 2005, at 1:49 PM, Graham wrote: >> >> Atom Processors should be aware of the potential for denial of >> service attacks where the attacker publishes an atom:entry with >> the atom:id value of an entry from another feed, and perhaps with >> a falsified atom:source element duplicating the atom:id of the >> other feed. Atom Processors which, for example, suppress display >> of duplicate entries by displaying only one entry with a >> particular atom:id value or combination of atom:id and >> atom:updated values, might also take steps to determine whether >> the entries originated from the same publisher before considering >> them to be duplicates. > > How is this a "Denial of service" attack? Isn't it just ordinary > spoofing/impersonation? > > Apart from that, +1. Yeah, it seems like it can't possibly be wrong to highlight this risk, which I at least didn't notice until someone pointed it out to me, so I bet others will miss it too. -Tim From owner-atom-syntax@mail.imc.org Wed May 25 23:31:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00472 for ; Wed, 25 May 2005 23: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 j4Q3NI9O082128; Wed, 25 May 2005 20:23: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 j4Q3NISt082127; Wed, 25 May 2005 20:23:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web42209.mail.yahoo.com (web42209.mail.yahoo.com [66.218.93.220]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4Q3NIlr082120 for ; Wed, 25 May 2005 20:23:18 -0700 (PDT) (envelope-from jfcst24_public@yahoo.com) Received: (qmail 77076 invoked by uid 60001); 26 May 2005 03:23:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=LbFmKz5h/Us5iRK3jHCEymP0Ej+agr7VyFOygT+PnPRljX0MeiMh+WoNlDLkR0D1gHJ4xQt68ZA6lCC44LKhKbS6Gjj/yQ7KY7m109Jd4h5mH7zRdJAU00RLQqWY2UOjzzdGaQe/9wir39CwzHHo5c92RwolzwVESSHhyerCz5k= ; Message-ID: <20050526032312.77073.qmail@web42209.mail.yahoo.com> Received: from [4.155.81.183] by web42209.mail.yahoo.com via HTTP; Wed, 25 May 2005 20:23:12 PDT Date: Wed, 25 May 2005 20:23:12 -0700 (PDT) From: James Cerra Subject: Re: atom:type, xsl:output To: Atom WG , Henri Sivonen In-Reply-To: 6667 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: Henri Sivonen, > > If the intended Atom content contains essential comments, > > There should be no such thing as essential comments. The XML spec does > not require XML processors to report comments to the app. Hence, > comments are inappropriate for transferring essential data. Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still inappropriately use comments for that purpose. Then there are example XML documents (i.e. for tutorials) that sometimes require comments be preserved. So although it is not required by XML processors, it is nice to not introduce incompatibility with that optional part of the spec. Finally if you are posting content associated with an entry with the Atom API, then it is important that any documents uploaded are not modified. (Besides at worst this is a non-issue if no comments are ever essential.) > > processing instructions, > > These could be supported in embedded content if the Atom spec said PIs > in atom:content belong in content and should not be acted upon by the > Atom processor. I don't like this condition. Any content will be read by XML processors before being handed to an Atom processor. So the generic XML processor will not be able to differentiate between PIs that are significant - and thus should be processed by their processors - from those which should be passed through. > > entities > > Entities can be flattened. Again, as with comments, I agree in principle, but in practice some processors depend on them. > > DOCTYPE declaration(s) > > If DOCTYPE is essential for the receiving app, you've got bigger > problems than Atom. Hardwiring IDness based on namespaces is more > practical than relying on DTD-based data typing. I'm not necessarily talking about external document type definitions. Preventing DOCTYPEs would cause incompatibilities with XML well-formedness processing. From the spec: "[Definition: While they are not required to check the document for validity, they are REQUIRED to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they MUST use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values.]" Some RDF/XML processors already put internal DOCTYPE declarations to make the content more readable. There is nothing intrinsically bad about DOCTYPE sections, they provide hints to validating XML processors about validity and can save time, space, and increase readability. Remember that anything compatible with XML MUST allow its optional features to be in the markup (even if they are just ignored). So if you disallow DOCTYPE sections, then you can't claim to support XML. Anything that could have any chance of dataloss - in this case, the loss of XML comments, PIs, and XML and DOCTYPE declarations is bad. Your comment is a good design pattern for XML based specifications, but in general they don't have to follow that rule of thumb. Besides, I don't want the implementors to get any bad ideas so explicitly stating these things disenfranchises that behavior from being acceptable from the beginning. -- Jimmy Cerra https://nemo.dev.java.net __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From owner-atom-syntax@mail.imc.org Thu May 26 02:48:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03634 for ; Thu, 26 May 2005 02:48: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 j4Q6eet4008594; Wed, 25 May 2005 23:40: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 j4Q6eeaa008593; Wed, 25 May 2005 23:40: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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6ec2L008587 for ; Wed, 25 May 2005 23:40:39 -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 9265C3185B9; Thu, 26 May 2005 08:40:32 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Thu, 26 May 2005 08:40:32 +0200 (CEST) Message-ID: <2413.82.127.77.43.1117089632.squirrel@ssl-webmail.sitadelle.com> Date: Thu, 26 May 2005 08:40:32 +0200 (CEST) Subject: Re: some small comments on 08 From: "Thomas Broyer" To: In-Reply-To: <0A950265-44D0-4928-B157-9034C06D7E94@mac.com> References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> <0A950265-44D0-4928-B157-9034C06D7E94@mac.com> 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 Graham wrote: > With the Pace, try transporting this: >
Text
> > Wrap it in a div: >
> > Decode it: > Text > > Oops, we've thrown data away. Whether the change is significant or not > isn't important. As a user, I expect to be able to type something in > at one end and have it reliably appear in the same form, > regardless of what I type, or whether Thomas Broyer thinks the change > didn't matter. With the current (08) draft, try transporting this textual summary: This deals with - feeding cats - feeding dogs - feeding fishes Put it in atom:summary: This deals with - feeding cats - feeding dogs - feeding fishes Decode: This deals with - feeding cats - feeding dogs - feeding fishes Oops, we've thrown data away. Whether the change is significant or not isn't important. As a user, I expect to be able to type something in at one end and have it reliably appear in the same form, regardless of what I type, or whether [someone] thinks the change didn't matter. It all depends what you expect from atom:content with "special" @type values and Text Constructs: - transport textual data, eventually enriched with some markup - transport data (which happen to be textual) without modifying it in any way I think Atom should be homogeneous as to how it deals with this: allow "insignificant" changes, as long as the text has the same meaning. In the same way we define whitespace collapsing for @type="text"; we could define "dummy div discarding" for type="xhtml". -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 26 02:50:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03759 for ; Thu, 26 May 2005 02:50: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 j4Q6jgT0009319; Wed, 25 May 2005 23:45: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 j4Q6jgdw009318; Wed, 25 May 2005 23:45:42 -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 (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6jffc009243 for ; Wed, 25 May 2005 23:45:41 -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 1999C3184A2; Thu, 26 May 2005 08:45:35 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Thu, 26 May 2005 08:45:36 +0200 (CEST) Message-ID: <2421.82.127.77.43.1117089936.squirrel@ssl-webmail.sitadelle.com> Date: Thu, 26 May 2005 08:45:36 +0200 (CEST) Subject: Re: Consensus snapshot, 2005/05/25 From: "Thomas Broyer" To: In-Reply-To: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> References: <649FD186-18E7-4127-B898-BE4F9332031F@sun.com> 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 Tim Bray wrote: > 5. rework the last paragraph of 4.1.3.2. First of all, the > description involving "text/" and "+xml" needs fixing per Thomas > Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/ > msg15444.html), [...] What about the list items in 4.1.3.3 (see [1])? Anw how about the "(case-insensitive)" which is used sometimes but not always? [1] http://www.imc.org/atom-syntax/mail-archive/msg15357.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 26 04:18:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10205 for ; Thu, 26 May 2005 04:18: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 j4Q89sO5029125; Thu, 26 May 2005 01: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 j4Q89smH029124; Thu, 26 May 2005 01:09:54 -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 j4Q89rP1029116 for ; Thu, 26 May 2005 01:09:54 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:52465 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228697AbVEZIJv convert rfc822-to-8bit (ORCPT ); Thu, 26 May 2005 11:09:51 +0300 In-Reply-To: <20050526032312.77073.qmail@web42209.mail.yahoo.com> References: <20050526032312.77073.qmail@web42209.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: 8BIT Cc: Atom WG From: Henri Sivonen Subject: Re: atom:type, xsl:output Date: Thu, 26 May 2005 11:09:26 +0300 To: James Cerra X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On May 26, 2005, at 06:23, James Cerra wrote: > Henri Sivonen, > >>> If the intended Atom content contains essential comments, >> >> There should be no such thing as essential comments. The XML spec does >> not require XML processors to report comments to the app. Hence, >> comments are inappropriate for transferring essential data. > > Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still > inappropriately > use comments for that purpose. I am not familiar with that. What purpose exactly? Why should Atom support it? > Then there are example XML documents (i.e. for tutorials) that > sometimes require comments be preserved. If you want people to read the source as is, it would make sense to make it text/plain or put the source snippets in or 
 in an 
(X)HTML tutorial.

> Finally if you are posting content associated with an entry with the 
> Atom API, then it is important that any documents uploaded are not 
> modified.

I think Atom processors should not be required to preserve 
serialization artifacts. That is, IMO, they should not be required to 
care about anything that is not exposed via SAX2 ContentHandler with 
qNames ignored.

>>> processing instructions,
>>
>> These could be supported in embedded content if the Atom spec said PIs
>> in atom:content belong in content and should not be acted upon by the
>> Atom processor.
>
> I don't like this condition.  Any content will be read by XML 
> processors before
> being handed to an Atom processor.  So the generic XML processor will 
> not be
> able to differentiate between PIs that are significant - and thus 
> should be
> processed by their processors - from those which should be passed 
> through.

Vanilla XML processors don't act on PIs. They report them to the 
application--in this case the Atom processor.

>>> entities
>>
>> Entities can be flattened.
>
> Again, as with comments, I agree in principle, but in practice some 
> processors
> depend on them.

Depending on an entity reference and not being able to accept the 
straight replacement text is just wrong.

>>> DOCTYPE declaration(s)
>>
>> If DOCTYPE is essential for the receiving app, you've got bigger
>> problems than Atom. Hardwiring IDness based on namespaces is more
>> practical than relying on DTD-based data typing.
>
> I'm not necessarily talking about external document type definitions.
> Preventing DOCTYPEs would cause incompatibilities with XML 
> well-formedness
> processing.  From the spec:
>
> "[Definition: While they are not required to check the document for 
> validity,
> they are REQUIRED to process all the declarations they read in the 
> internal DTD
> subset and in any parameter entity that they read, up to the first 
> reference to
> a parameter entity that they do not read; that is to say, they MUST 
> use the
> information in those declarations to normalize attribute values, 
> include the
> replacement text of internal entities, and supply default attribute 
> values.]"

That's a non-issue. You don't just throw away the DOCTYPE but parse the 
original document with it and reserialize as a DOCTYPEless fragment. 
You don't lose well-formedness or content. You only lose the shallow 
attribute data typing provided by the DTD.

> Some RDF/XML processors already put internal DOCTYPE declarations to 
> make the
> content more readable.

Atom's main purpose is to facilitate software to software 
communication. When interop or implementation ease and readability 
conflict, readability should yield.

> There is nothing intrinsically bad about DOCTYPE sections

Yes, there is. On the Web you cannot trust that the recipient is using 
an XML processor that processes the DOCTYPE beyond checking the 
internal subset for well-formedness. An optional feature that does not 
degrade gracefully when not supported is bad. DOCTYPE is such a 
feature. In the cases where the DOCTYPE can be gracefully ignored, the 
DOCTYPE is pointless.

> Remember that anything compatible with XML MUST allow its optional 
> features to
> be in the markup (even if they are just ignored).  So if you disallow 
> DOCTYPE
> sections, then you can't claim to support XML.

Atom is not claiming that you could embed the literal source of any XML 
doc. You can embed the stuff that canonicalization would preserve.

> Anything that could have any chance of dataloss - in this case, the 
> loss of XML
> comments, PIs, and XML and DOCTYPE declarations  is bad.

Would you consider changes in the order of attributes and the white 
space between attributes data loss as well?

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



From owner-atom-syntax@mail.imc.org  Thu May 26 05:41:09 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14562
	for ; Thu, 26 May 2005 05:41: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 j4Q9XvMs043630;
	Thu, 26 May 2005 02:33: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 j4Q9XvOw043629;
	Thu, 26 May 2005 02:33:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4Q9XtWr043613
	for ; Thu, 26 May 2005 02:33:56 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 23186 messnum 5389863 invoked from network[83.70.217.193/unknown]); 26 May 2005 09:33:50 -0000
Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193)
  by mail08.svc.cra.dublin.eircom.net (qp 23186) with SMTP; 26 May 2005 09:33:50 -0000
Message-ID: <429597FD.1030007@dehora.net>
Date: Thu, 26 May 2005 10:33:49 +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: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
References:  <429514D5.5020509@gmail.com>
In-Reply-To: <429514D5.5020509@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


James M Snell wrote:

> Ignoring the overhead that it adds for now, isn't this the kind of 
> situation digital signatures are designed to handle?  

Yes. Norm and I have mentioned this as well. I do not think we can solve 
this problem by patching the Atom level, ensuring that the Atom level 
can be ex-canonicalised and signed is sufficient.


> If I put out an 
> entry with a given ID and digitally sign it, and someone comes along and 
> attempts to publish an entry with a duplicate ID and updated timestamp 
> and it is NOT signed with the same key my original was signed with, then 
> hey, Houston we've got a problem.  Without any kind of cryptographic 
> guarantee of this sort, the best you could do is make an educated 
> guess.  Would it make sense to include some language along these lines?

Belongs in the security sections. I would trust the editors to add the 
text if they were willing.

cheers
Bill







From owner-atom-syntax@mail.imc.org  Thu May 26 05:55:48 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15521
	for ; Thu, 26 May 2005 05:55: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 j4Q9lb9J044581;
	Thu, 26 May 2005 02:47: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 j4Q9lbr7044580;
	Thu, 26 May 2005 02:47:37 -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 j4Q9lbpX044574
	for ; Thu, 26 May 2005 02:47:37 -0700 (PDT)
	(envelope-from henry.story@bblfish.net)
Received: (qmail 47438 invoked by uid 17064); 26 May 2005 09:47:36 -0000
Received: from unknown (HELO [192.168.0.2]) ([83.112.143.160])
          (envelope-sender )
          by 192.220.66.168 (qmail-ldap-1.03) with SMTP
          for ; 26 May 2005 09:47:36 -0000
In-Reply-To: <972346C6-CD5F-11D9-A0FA-003065EA6144@geckotribe.com>
References: <972346C6-CD5F-11D9-A0FA-003065EA6144@geckotribe.com>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <23DB150E-0F12-497D-9008-234877F64633@bblfish.net>
Cc: atom-syntax@imc.org
Content-Transfer-Encoding: 7bit
From: Henry Story 
Subject: Re: Semantics and Belief contexts - was: PaceDuplicateIdsEntryOrigin posted
Date: Thu, 26 May 2005 11:47:34 +0200
To: Antone Roundy 
X-Mailer: Apple Mail (2.730)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7bit


Part of the reason I went into the detailed explanation I did, is  
because not everyone
here may be familiar with mathematical logic. What I was explaining  
is a heavy condensation
of what I learned in my BA in philosophy. I am not plucking these  
thoughts out of a hat.

So let me apply these a little more directly to your proposal.

I very much agree with the spirit of what you are saying. But I think  
that the danger is that by looking at the problem the way you are, we  
may end up confusing things a lot more than we are clarifying them.

On 25 May 2005, at 21:06, Antone Roundy wrote:
> == Rationale ==
>
>  * The accepted language for allowing duplicate IDs in a feed  
> document speaks only multiple atom:entry elements with the same  
> atom:id describing the same entry if they exist in the same  
> document--of course, we intend for them to describe the same entry  
> whether they're simultaneously in the feed document or not

If we put this in terms of ontology, what we want is to state simply  
that an ID refers to one and
only one entry. There is not much to add by the way, other than that  
the ID is a URI, since the
whole role of URIs is to identify one and only one thing.

>  * The accepted language does not speak of the origin feed of the  
> entries. Ideally, an atom:id should be univerally unique to one  
> entry resource, and we rightly require publishers to mint them with  
> that goal. However, in reality, malicious or undereducted  
> publishers might duplicate the IDs of others. Therefore, it is  
> proposed to modify the specification to state that the atom:entry  
> elements describe the same entry (resource) if they originate in  
> the same feed.

When you say 'ideally', I say ontologically. Let us imagine that  
instead of creating an ontology
for a atom entry, we were creating one for a gun. We could say that  
guns have a number of
properties, one of them being that they are physical objects.  
Physical objects can only be at
one place at a time. So a gun can only be at one place at a time.
     Now you can see how it won't help the definition of a gun if  
someone were to introduce the
following reasoning.  When a policeman asks someone where they put  
the gun, some people are honest
and tell them where, but many people (the most interesting ones) will  
lie to them. The policeman has
to report the facts as he sees and hears them. He may hear two  
conflicting reports on where the
gun is. Are guns therefore weird objects that have a position  
relative to the person who speaks
about them?
     This is confusing semantics and the way people speak about the  
world. It is confusing our
concepts about the world, and the context in which sentences  
containing those concepts about the world appear.

>  * Aggregators wishing to protect against DOS attacks are not  
> unlikely to perform some sort of safety checks to detect malicious  
> atom:id duplication, regardless of whether the specification  
> "authorizes" them to or not.

The policeman is not unlikely to do a lot of safety checks to find  
out where the gun is. He may for
example scan the person who told him he has not gun anyway, just to  
make sure.


On 25 May 2005, at 22:57, Antone Roundy wrote:
> On Wednesday, May 25, 2005, at 02:26  PM, Henry Story wrote:
>> Since the referents of "Superman" and "Clark Kent" are the same,  
>> what is true of the one,
>> is true of the other. When speaking directly about the world, we  
>> can replace any occurrence
>> of Superman with Clark Kent, and still say something true.
>>
> "Clark Kent is the secret identity of Superman." -> "Superman is  
> the secret identity of Superman."  Whether they're perfectly  
> interchangeable or not depends on whether the name is referring to  
> the object or some a facet of the object.  The second sentence  
> actually works if the first "Superman" refers to the persona, and  
> the second to the person.  But getting back to Atom...

There are a lot of corner cases. I was trying to give an overview of  
a complicated field.
I was restricting myself to sentences where words clearly identify  
objects.  If you use Superman
to refer to a persona then we are speaking about something else.  
Other cases are "Superman is so called because he is strong". Well  
known, but it does not undermine the distinction I was making.

> [snip]
>> So to prevent a DOS attack, best is to have aggregator feeds such as:
>>
>> 
>>     
>>     
>>        tag://true.org,2005/feed1
>>        
>>           Enter your credit card number here
>>           ...
>>        
>>      
>>     
>>        tag://true.org,2005/feed1
>>        
>>           Enter your credit card number here
>>           ...
>>        
>>     
>> 
>>
>> Here all the aggregator feed is claiming is that he has seen  
>> entries inside other
>> feeds.
>>
> ...
>
>> It will be up to the consumer of such aggregated feeds to decide  
>> which to trust.
>>
>
> From the end user's point of view, it's not much different.   
> Somebody still has to make the decision, and the end user doesn't  
> want to be the one doing it--they want the super aggregator or  
> their feed reader or somebody else to do it for them.  The feed  
> reader should be doing it anyway, since they won't be getting all  
> of their data through a super aggregator.

Yes, this problem is especially strong if entry ids have no way of  
being clearly verified. If an
entry id were a URL pointing to the location where the entry can be  
fetched then it would be easy
to resolve some of the ambiguity. Either that or entries need to be  
signed, or the author trusted.
In all cases the intent is that an atom id identify an entry  
universally, across the same user's feeds and across other publishers  
feeds. After all we want people to be able to refer to an entry from  
another feed too.

So what we need are mechanisms to enable trust, not make universality  
relative to a feed. Though
of course what you are describing is what is going to happen if we  
don't take seriously the issue
of trust and verifiability.

> But the super aggregator is likely to want to do it too, both to  
> reduce how much data they forward to their clients, and because  
> many feed readers aren't going to do it very well, so handling part  
> of the job for them will improve the end user's experience.

The super aggregator can in any case reduce how much data he is  
sending to his clients, by filtering
what he knows to fit the question he is asked. We currently allow the  
indirection I am speaking about with the source element. The problem  
I think is that the hidden indirection of the source
element is creating a lot of confusion and complication everywhere,  
since every-time some statement
is made on the role of an element, it has to be qualified in some way  
with respect to the source element.
     So we have to say that a feed can only contain one entry with  
the same id and timestamp, except
if there is a source feed in which case the source feed needs to be  
consistent... Imagine having to define a gun the same way. Instead of  
saying a gun can only be at one place, one would have to say that a  
gun, being a physical object, can only be at one place, except if  
people speak about guns, in which case they need to be consistent  
about what they say about a gun, and can only believe it to be at one  
place,...

Confusion makes for complication.

> I'm not a fan of feeds of feeds (though I have proposed and still  
> like a one-level embedding of feeds in a different top-level  
> element).  Plus, I think it's inconceivable that the WG would make  
> this drastic a change at this point.  Let's focus on doing what's  
> actually possible, given the WG schedule and temperment, to  
> mitigate this problem.

Frankly until a week ago I did not understand the point of a feed  
containing a feed at all.
The working group can do what it likes, but the essential difference  
between sentences using in a
propositional context (S believes that P, S knows that P, S fears  
that P) and using them directly
(P is true, P) is fundamental. Acknowledging it will make things move  
forward a lot quicker.

Henry Story
http://bblfish.net/



From owner-atom-syntax@mail.imc.org  Thu May 26 07:18:47 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20172
	for ; Thu, 26 May 2005 07:18: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 j4QB8vxP058902;
	Thu, 26 May 2005 04:08: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 j4QB8uAU058901;
	Thu, 26 May 2005 04:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QB8tho058893
	for ; Thu, 26 May 2005 04:08:56 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [161.73.58.69] (data-csmail2 [192.168.2.2])
	by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4QB7oF0020497;
	Thu, 26 May 2005 12:07:56 +0100 (BST)
In-Reply-To: <2413.82.127.77.43.1117089632.squirrel@ssl-webmail.sitadelle.com>
References: <42904F50.3020404@annevankesteren.nl> <20050523004203.GA30042@klangraum> <1217.82.127.77.43.1116837905.squirrel@ssl-webmail.sitadelle.com> <4291A2F2.6030306@gmx.de> <5ca681b3f9e026dfd17cbee5aa66af08@iki.fi> <2572D4B3-BCD2-4AAA-9A95-528CDAF1E556@mac.com> <1771.82.127.77.43.1116940448.squirrel@ssl-webmail.sitadelle.com> <1820.82.127.77.43.1116942074.squirrel@ssl-webmail.sitadelle.com> <0A950265-44D0-4928-B157-9034C06D7E94@mac.com> <2413.82.127.77.43.1117089632.squirrel@ssl-webmail.sitadelle.com>
Mime-Version: 1.0 (Apple Message framework v730)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0FB6B56D-0B6C-4451-A19C-1006C31CAB6D@mac.com>
Cc: atom-syntax 
Content-Transfer-Encoding: 7bit
From: Graham 
Subject: Re: some small comments on 08
Date: Thu, 26 May 2005 12:07:51 +0100
To: Thomas Broyer 
X-Mailer: Apple Mail (2.730)
X-MailScanner-Information: Oxford Brookes University MailScanner
X-MailScanner: Clean
X-MailScanner-From: dtcd@mac.com
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7bit


On 26 May 2005, at 7:40 am, Thomas Broyer wrote:

> With the current (08) draft, try transporting this textual summary:
> This deals with
>  - feeding cats
>  - feeding dogs
>  - feeding fishes
>
> Put it in atom:summary:
> 
> This deals with
>  - feeding cats
>  - feeding dogs
>  - feeding fishes
> 
>
> Decode:
> This deals with - feeding cats - feeding dogs - feeding fishes

That's not decoding, that's display. There's nothing in the Atom spec  
that says the line breaks need to be (or even can be) removed from  
the actual data, it just says you don't need to display them to the  
end user. The body of the message is preserved end-to-end.

Graham



From owner-atom-syntax@mail.imc.org  Thu May 26 09:45:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29110
	for ; Thu, 26 May 2005 09:45: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 j4QDaph9001798;
	Thu, 26 May 2005 06:36: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 j4QDapvh001797;
	Thu, 26 May 2005 06:36: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 j4QDanRA001781
	for ; Thu, 26 May 2005 06:36:50 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 26 May 2005 13:36:43 -0000
Received: from xdsl-213-196-252-189.netcologne.de (EHLO klangraum) [213.196.252.189]
  by mail.gmx.net (mp014) with SMTP; 26 May 2005 15:36:43 +0200
X-Authenticated: #163624
Date: Thu, 26 May 2005 15:40:24 +0200
From: "A. Pagaltzis" 
To: Atom WG 
Subject: Re: atom:type, xsl:output
Message-ID: <20050526134024.GA9395@klangraum>
Mail-Followup-To: Atom WG 
References: <20050526032312.77073.qmail@web42209.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050526032312.77073.qmail@web42209.mail.yahoo.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: 8bit


* James Cerra  [2005-05-26 05:35]:
> Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still
> inappropriately use comments for that purpose.  Then there are
> example XML documents (i.e. for tutorials) that sometimes
> require comments be preserved.
> 
> > Entities can be flattened.
> 
> Again, as with comments, I agree in principle, but in practice
> some processors depend on them.

I do not consider it at all wise to legislate anything in the
Atom spec to address these cases.

Nothing prevents anyone from writing a generator or pre- or
postprocessor for Atom documents to cater to the needs of their
particular brand of broken software. Wrangling that particular
piece of broken software however is their job; not ours nor the
Atom spec’s.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Thu May 26 09:46:17 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29131
	for ; Thu, 26 May 2005 09:46: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 j4QDe17R002135;
	Thu, 26 May 2005 06:40: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 j4QDe1BF002134;
	Thu, 26 May 2005 06:40:01 -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 j4QDe04O002113
	for ; Thu, 26 May 2005 06:40:00 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 26 May 2005 13:39:54 -0000
Received: from xdsl-213-196-252-189.netcologne.de (EHLO klangraum) [213.196.252.189]
  by mail.gmx.net (mp024) with SMTP; 26 May 2005 15:39:54 +0200
X-Authenticated: #163624
Date: Thu, 26 May 2005 15:43:35 +0200
From: "A. Pagaltzis" 
To: Atom WG 
Subject: Re: atom:type, xsl:output
Message-ID: <20050526134335.GB9395@klangraum>
Mail-Followup-To: Atom WG 
References: <20050526032312.77073.qmail@web42209.mail.yahoo.com> 
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: 


* Henri Sivonen  [2005-05-26 10:20]:
> On May 26, 2005, at 06:23, James Cerra wrote:
> >Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still
> >inappropriately use comments for that purpose.
> 
> I am not familiar with that. What purpose exactly? Why should
> Atom support it?

http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp

They are parsed in HTML documents; I have no idea if IE actually
respects these in XML documents.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Thu May 26 10:10:25 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00951
	for ; Thu, 26 May 2005 10:10: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 j4QE0fW7004054;
	Thu, 26 May 2005 07:00: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 j4QE0fOo004053;
	Thu, 26 May 2005 07:00:41 -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 j4QE0dc2004040
	for ; Thu, 26 May 2005 07:00:40 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 26 May 2005 14:00:33 -0000
Received: from xdsl-213-196-252-189.netcologne.de (EHLO klangraum) [213.196.252.189]
  by mail.gmx.net (mp002) with SMTP; 26 May 2005 16:00:33 +0200
X-Authenticated: #163624
Date: Thu, 26 May 2005 16:04:15 +0200
From: "A. Pagaltzis" 
To: atom-syntax 
Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
Message-ID: <20050526140415.GC9395@klangraum>
Mail-Followup-To: atom-syntax 
References:  <332C7B9D-F25A-48AD-AC04-626453501A55@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <332C7B9D-F25A-48AD-AC04-626453501A55@mac.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: 8bit


* Graham  [2005-05-25 23:00]:
> How is this a "Denial of service" attack? Isn't it just
> ordinary spoofing/impersonation?

Indeed; I’d like to see this reworded to refer to “spoofing,” as
that’s what it is.

> Apart from that, +1.

+1 as well; always a good idea to alert people about issues.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Thu May 26 10:51:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04377
	for ; Thu, 26 May 2005 10:51: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 j4QEigvE017374;
	Thu, 26 May 2005 07:44: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 j4QEigrs017373;
	Thu, 26 May 2005 07:44: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 j4QEif8k017363
	for ; Thu, 26 May 2005 07:44: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 <2005052614443501100oqu1de>; Thu, 26 May 2005 14:44:36 +0000
Date: Thu, 26 May 2005 08:44:34 -0600
Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
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: <429514D5.5020509@gmail.com>
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 Wednesday, May 25, 2005, at 06:14  PM, James M Snell wrote:
> Ignoring the overhead that it adds for now, isn't this the kind of 
> situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures 
in the near term (and more importantly, how many aren't?), and who 
knows how many consuming applications will support them.  Until digital 
signatures start providing more help with this kind of thing, let's 
provide a warning to developers so that they can at least consider what 
they might do to safeguard the quality of their users' experience.

And I just thought of another thing (I don't know how digital 
signatures work in this case, so I may be missing something, but I'm 
pretty sure the following is at least partially valid): if I get an 
entry with a valid digital signature and one with no signature (both 
with the same atom:id, of course), then what?  Do I always accept the 
one with the signature?  If so, then DOSing/spoofing unsigned entries 
will be even easier, because all you'd have to do is sign your fake 
entry.  So even in that case, some extra checking might have to be done 
before concluding that the entries are duplicates, and that the 
unsigned one is the one that's disposable.

> Without any kind of cryptographic guarantee of this sort, the best you 
> could do is make an educated guess.
Wouldn't that be better than nothing until digital signatures become 
more ubiquitous?

> Would it make sense to include some language along these lines?
Sure.



From owner-atom-syntax@mail.imc.org  Thu May 26 10:53:48 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04521
	for ; Thu, 26 May 2005 10:53: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 j4QEkmQm017514;
	Thu, 26 May 2005 07:46: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 j4QEkmJm017513;
	Thu, 26 May 2005 07:46:48 -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 j4QEkmHh017495
	for ; Thu, 26 May 2005 07:46: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 (sccrmhc14) with SMTP
          id <2005052614463801400i6s68e>; Thu, 26 May 2005 14:46:38 +0000
Date: Thu, 26 May 2005 08:46:37 -0600
Subject: Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
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: <20050526140415.GC9395@klangraum>
Message-Id: 
X-Mailer: Apple Mail (2.553)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QEkmHh017508
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


On Thursday, May 26, 2005, at 08:04  AM, A. Pagaltzis wrote:
> * Graham  [2005-05-25 23:00]:
>> How is this a "Denial of service" attack? Isn't it just
>> ordinary spoofing/impersonation?
>
> Indeed; Id like to see this reworded to refer to spoofing, as
> thats what it is.

I presume the specific wording can be left to the discretion of the 
editors.



From owner-atom-syntax@mail.imc.org  Thu May 26 10:55:39 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04661
	for ; Thu, 26 May 2005 10:55: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 j4QEnJZ0017716;
	Thu, 26 May 2005 07: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 j4QEnJSp017715;
	Thu, 26 May 2005 07:49:19 -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 j4QEnJd2017705
	for ; Thu, 26 May 2005 07:49:19 -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 <2005052614491301400iaq20e>; Thu, 26 May 2005 14:49:13 +0000
Date: Thu, 26 May 2005 08:49:12 -0600
Subject: Re: PaceDuplicateIdsEntryOrigin posted (was Re: Consensus snapshot, 2005/05/25)
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: <1383BB62-CD50-11D9-A0FA-003065EA6144@geckotribe.com>
Message-Id: <52DD8150-CDF5-11D9-8CF8-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, May 25, 2005, at 01:06  PM, Antone Roundy wrote:
> == Abstract ==
>
> State the atom:entries from the same feed with the same ID are the 
> same entry, whether simulateously in the feed document or not.

I'm retracting this proposal in preference for PaceAtomIdDos, which I 
like better and is getting more support.



From owner-atom-syntax@mail.imc.org  Thu May 26 11:16:19 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05652
	for ; Thu, 26 May 2005 11:16: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 j4QF8gB4019270;
	Thu, 26 May 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 j4QF8go6019269;
	Thu, 26 May 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 zproxy.gmail.com (zproxy.gmail.com [64.233.162.196])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QF8f37019259
	for ; Thu, 26 May 2005 08:08:41 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so927130nzp
        for ; Thu, 26 May 2005 08:08:36 -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=G+vcx6t+W86a3eDvk3vXxYq06f1HHn0DVztSX7fQNZChF0B4L91vA9Li1O7V6ZSwlIt8EcxhXVjIYKrzCWUZYntawkPfHcFad6+0d/6YPH9+G0h6bpbfQfx/yoTZ9g4O0tTiILYfl4ipElUYDZYh+1U4ykxiYqMFm+oNEf70LWg=
Received: by 10.36.19.12 with SMTP id 12mr664443nzs;
        Thu, 26 May 2005 08:08:35 -0700 (PDT)
Received: from ?192.168.1.102? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 15sm307855nzn.2005.05.26.08.08.35;
        Thu, 26 May 2005 08:08:35 -0700 (PDT)
Message-ID: <4295E65B.1030608@gmail.com>
Date: Thu, 26 May 2005 08:08:11 -0700
From: James M Snell 
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: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
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


Antone Roundy wrote:

>
> On Wednesday, May 25, 2005, at 06:14  PM, James M Snell wrote:
>
>> Ignoring the overhead that it adds for now, isn't this the kind of 
>> situation digital signatures are designed to handle?
>
> Sure, but how many publishers are going to be using digital signatures 
> in the near term (and more importantly, how many aren't?), and who 
> knows how many consuming applications will support them.  Until 
> digital signatures start providing more help with this kind of thing, 
> let's provide a warning to developers so that they can at least 
> consider what they might do to safeguard the quality of their users' 
> experience.
>
Oh, absolutely, I was simply making an observation and thinking a bit 
about whether or not it would make sense to have some language as part 
of the warning that mentioned the potential application of digital 
signatures to solving this problem.  I dunno, just thinking out loud 
here a bit.

> And I just thought of another thing (I don't know how digital 
> signatures work in this case, so I may be missing something, but I'm 
> pretty sure the following is at least partially valid): if I get an 
> entry with a valid digital signature and one with no signature (both 
> with the same atom:id, of course), then what?  Do I always accept the 
> one with the signature?  If so, then DOSing/spoofing unsigned entries 
> will be even easier, because all you'd have to do is sign your fake 
> entry.  So even in that case, some extra checking might have to be 
> done before concluding that the entries are duplicates, and that the 
> unsigned one is the one that's disposable.
>
Well, it comes down to whether the signature is trusted by the reader or 
not.  If the signature in the entry is not from the trusted, expected 
source, the user should be able to reject it in favor of the unsigned 
entry. 

>> Without any kind of cryptographic guarantee of this sort, the best 
>> you could do is make an educated guess.
>
> Wouldn't that be better than nothing until digital signatures become 
> more ubiquitous?
>
Absolutely... see my first response above ;-)

>> Would it make sense to include some language along these lines?
>
> Sure.
>
>



From owner-atom-syntax@mail.imc.org  Thu May 26 11:18:19 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05854
	for ; Thu, 26 May 2005 11:18: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 j4QFDRNl019788;
	Thu, 26 May 2005 08:13: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 j4QFDRsc019787;
	Thu, 26 May 2005 08:13:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4QFDQIb019777
	for ; Thu, 26 May 2005 08:13:26 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000435736 for ; Fri, 27 May 2005 01:13:23 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 27 May 2005 01:13:22 +1000
Subject: Re: The atom:uri element
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


>> I've mentioned this several times before and haven't had time to follow  the
>> evolvement of the draft up until now, but as far as I can tell,  atom:uri is
>> still in place in the specification... Do we really need a  pace to have that
>> element renamed before the spec goes final?
> 
> -1 to renaming the element.
> See http://www.imc.org/atom-syntax/mail-archive/msg13864.html

There are two arguments in parallel here:
    (1) which is the proper term for a url/uri/iri ?
    (2) is naming an element after the data type sensible ?

I say the first argument is a red herring, a bike shed, and entirely
redundant as we've already extensively used "IRI" in the spec.

Consider also:
    http://www.imc.org/atom-syntax/mail-archive/msg13860.html

We have /author/name and not /author/string for a reason. Why then do we
have /author/uri?

Perhaps /author/about fits the intent?

> -1 to atom:link. No need for change for the sake of change.

plus I realised immediately after I posted that /author/link would get
confused with Link Constructs, which wasn't what I was suggesting.

That's not to say I'm averse to using Link Constructs in atom:author (or
atom:contributor) ...

e.



From owner-atom-syntax@mail.imc.org  Thu May 26 13:36:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15741
	for ; Thu, 26 May 2005 13:36: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 j4QHQk6e045526;
	Thu, 26 May 2005 10:26: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 j4QHQk4r045523;
	Thu, 26 May 2005 10:26:46 -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 j4QHQjeM045510
	for ; Thu, 26 May 2005 10:26:45 -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 j4QHQjjO010812
	for ; Thu, 26 May 2005 11:26: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 <0IH300CK8XSKY6@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Thu, 26 May 2005 11:26:45 -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 <0IH300AYBXSJO6@mail.sun.net> for atom-syntax@imc.org; Thu,
 26 May 2005 11:26:44 -0600 (MDT)
Date: Thu, 26 May 2005 10:26:54 -0700
From: Tim Bray 
Subject: Last and final consensus pronouncement
To: atom-syntax Syntax 
Message-id: <78257677-BFE1-4CE1-8725-2A4935C85190@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; 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 behalf of Paul and myself:  This is it.  The initial phase of the  
WG's work in designing the Atompub data format specification is  
finished over, pining for the fjords, etc.  Please everyone reach  
around and pat yourselves on the back, I think the community will  
generally view this as a fine piece of work.

Stand by for announcements on buckling down on Atom-Protocol.

Note that this is a pronouncement, not a "call for further debate".   
Here are the next steps:

1. Editors take the assembled changes and produce a format-09 I-D.   
Sooner is better.
2. They post the I-D.
3. Paul sends Scott a message, cc'ing the WG, that we're done.
4. At this point there may be objections from the WG.  We decide  
whether to accept the objections and pull the draft back, or tell the  
objectors they'll have to pursue the appeal process.
5. The IESG process takes over at this point and we'll eventually  
hear back from them.

Last two draft changes:

1. PaceAtomIdDOS

We think that the WG has consensus that it is of benefit to add a  
warning to section 8 "Security Considerations".  The language from  
PaceAtomIdDos is mostly OK, except that the late suggestion of  
talking about spoofing instead of DOS seemed to get general support.   
I reworded slightly.  We'll leave it up to the editors to decide  
whether a new subsection of section 8 is required.

"Atom Processors should be aware of the potential for spoofing  
attacks where the attacker publishes an atom:entry with the atom:id  
value of an entry from another feed, perhaps with a falsified  
atom:source element duplicating the atom:id of the other feed. Atom  
Processors which, for example, suppress display of duplicate entries  
by displaying only one entry with a particular atom:id value, perhaps  
by selecting the one with the latest atom:updated value, might also  
take steps to determine whether the entries originated from the same  
publisher before considering them to be duplicates."

2. PaceAtom10

http://www.intertwingly.net/wiki/pie/PaceAtom10

We just missed this one in the previous consensus call; seeing lots  
of +1's and no pushback, it's accepted.





From owner-atom-syntax@mail.imc.org  Thu May 26 13:57:34 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16960
	for ; Thu, 26 May 2005 13:57: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 j4QHmQvA058354;
	Thu, 26 May 2005 10:48: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 j4QHmQI1058353;
	Thu, 26 May 2005 10:48:26 -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 j4QHmPpt058343
	for ; Thu, 26 May 2005 10:48:25 -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 B892DDE
	for ; Thu, 26 May 2005 10:48:20 -0700 (PDT)
Received: from localhost (spike.verity.com [10.69.100.102])
	by soda.verity.com (8.12.6/8.12.6) with ESMTP id j4QHmJng013964
	for ; Thu, 26 May 2005 10:48:20 -0700 (PDT)
Date: Thu, 26 May 2005 10:48:20 -0700
From: Walter Underwood 
To: atom-syntax Syntax 
Subject: Re: Last and final consensus pronouncement
Message-ID: 
In-Reply-To: <78257677-BFE1-4CE1-8725-2A4935C85190@sun.com>
References:  <78257677-BFE1-4CE1-8725-2A4935C85190@sun.com>
X-Mailer: Mulberry/4.0.0b3 (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


The atom:author element name is embarrassing. Make it atom:creator.
There were no objections to that.

wunder

--On May 26, 2005 10:26:54 AM -0700 Tim Bray  wrote:

> 
> 
> On behalf of Paul and myself:  This is it.  The initial phase of the  WG's work in designing the Atompub data format specification is  finished over, pining for the fjords, etc.  Please everyone reach  around and pat yourselves on the back, I think the community will  generally view this as a fine piece of work.
> 
> Stand by for announcements on buckling down on Atom-Protocol.
> 
> Note that this is a pronouncement, not a "call for further debate".   Here are the next steps:
> 
> 1. Editors take the assembled changes and produce a format-09 I-D.   Sooner is better.
> 2. They post the I-D.
> 3. Paul sends Scott a message, cc'ing the WG, that we're done.
> 4. At this point there may be objections from the WG.  We decide  whether to accept the objections and pull the draft back, or tell the  objectors they'll have to pursue the appeal process.
> 5. The IESG process takes over at this point and we'll eventually  hear back from them.
> 
> Last two draft changes:
> 
> 1. PaceAtomIdDOS
> 
> We think that the WG has consensus that it is of benefit to add a  warning to section 8 "Security Considerations".  The language from  PaceAtomIdDos is mostly OK, except that the late suggestion of  talking about spoofing instead of DOS seemed to get general support.   I reworded slightly.  We'll leave it up to the editors to decide  whether a new subsection of section 8 is required.
> 
> "Atom Processors should be aware of the potential for spoofing  attacks where the attacker publishes an atom:entry with the atom:id  value of an entry from another feed, perhaps with a falsified  atom:source element duplicating the atom:id of the other feed. Atom  Processors which, for example, suppress display of duplicate entries  by displaying only one entry with a particular atom:id value, perhaps  by selecting the one with the latest atom:updated value, might also  take steps to determine
whether the entries originated from the same  publisher before considering them to be duplicates."
> 
> 2. PaceAtom10
> 
> http://www.intertwingly.net/wiki/pie/PaceAtom10
> 
> We just missed this one in the previous consensus call; seeing lots  of +1's and no pushback, it's accepted.
> 
> 
> 
> 



--
Walter Underwood
Principal Architect, Verity



From owner-atom-syntax@mail.imc.org  Thu May 26 14:23:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18880
	for ; Thu, 26 May 2005 14:23: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 j4QIEHif060219;
	Thu, 26 May 2005 11:14: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 j4QIEHRM060217;
	Thu, 26 May 2005 11:14: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 j4QIEGCs060203;
	Thu, 26 May 2005 11:14: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 j4QIEG0R025796;
	Thu, 26 May 2005 12:14:16 -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 <0IH300BS4ZZR1Q@edgemail1.Central.Sun.COM>; Thu,
 26 May 2005 12:14:16 -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 <0IH300AWHZZROI@mail.sun.net>; Thu,
 26 May 2005 12:14:15 -0600 (MDT)
Date: Thu, 26 May 2005 11:14:25 -0700
From: Tim Bray 
Subject: Editorship announcement
To: Atom Protocol ,
        atom-syntax Syntax 
Message-id: 
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QIEGCt060204
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit



As we get ready to buckle down on the Atom Publishing Protocol draft,  
we're doing some editor-shuffling.  With thanks to Rob Sayre for his  
excellent work up through protocol-04, we're shifting from Rob-and- 
Joe to Joe Gregorio and Bill de hra as co-editors of the Atom  
protocol draft.

  -Tim (on behalf of myself and Paul)




From owner-atom-syntax@mail.imc.org  Thu May 26 14:35:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19835
	for ; Thu, 26 May 2005 14:35: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 j4QIKaTl060836;
	Thu, 26 May 2005 11:20: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 j4QIKacx060835;
	Thu, 26 May 2005 11:20:36 -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 (mf01.sitadelle.com [212.94.174.80])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIKZC9060814
	for ; Thu, 26 May 2005 11:20:35 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.55.2])
	by smtp.cegetel.net (Postfix) with ESMTP id 1B059318502;
	Thu, 26 May 2005 20:20:29 +0200 (CEST)
Message-ID: <42961367.7040701@cegetel.net>
Date: Thu, 26 May 2005 20:20:23 +0200
From: Thomas Broyer 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: David Powell 
Cc: Tim Bray , atom-syntax 
Subject: Re: extension elements inside link elements?
References:   <68fba5c505052408075404b24f@mail.gmail.com>  <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@djpowell.net>  <1665867878.20050526004720@djpowell.net>
In-Reply-To: <1665867878.20050526004720@djpowell.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


David Powell wrote:

>I'm also a bit confused about the terminology in Section 6.3:
>
>  
>
>>It might be the case that the software is able to process the
>>foreign markup correctly and does so. Otherwise, such markup is
>>termed "unknown foreign markup".
>>    
>>
>
>So "unknown foreign markup" is "foreign markup" that software is
>unable to process?
>
Yes, something in a namespace that is not understood by the Atom Processor.

>But then 6.3 goes on to explain how to process it.
>This sounds like a contradiction?
>  
>
No, why?

Say I am an Atom Processor and I find these extensions elements:

26.58
-97.83

Is this something I know how to process?

    * yes: this is "known foreign markup", I process it
    * no: this is "unknown foreign markup", I ignore it without failing
      or signaling an error

>Also, in what cases would software be able to process "foreign markup"
>other than by ignoring it as described in section 6.3 or treating it
>as a 6.4 extension?
>  
>
Treating it as a 6.4 extension *is* processing it as described in 
section 6.3.
There is no other case (this is technically implied by section 6.4, see 
below)

>So I don't see how the term "foreign markup" and "unknown foreign
>markup" are any different?
>  
>
"unknown foreign markup" is the subset of "foreign markup" that an Atom 
Processor ignores because it doesn't know what do do with it (i.e. how 
to process it).

>Also, if 6.4 extensions are a subset of "unknown[?] foreign markup",
>  
>
6.4 extensions are not a subset of "foreign markup" or "unknown foreign 
markup". 6.4 extensions are the whole "foreign markup" set (except it 
doesn't deal with "foreign attributes", but the whole section 6 and the 
whole spec doesn't deal with them).

If you read carefully the section 6.4, you'll notice that what is not a 
Simple Extension Element is a Structured Extension Element.
A Simple Extension Element is an element with no attribute and is either 
empty or has text-only content.
A Structured Extension Element is an element with at least an attribute 
or a child.

These are Simple Extension Elements:


foo

These are Structured Extension Elements:


foo

bazbaz

bazbaz

Is there any other construct I missed?

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Thu May 26 14:58:46 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21311
	for ; Thu, 26 May 2005 14:58: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 j4QIqxWk065566;
	Thu, 26 May 2005 11:52: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 j4QIqxaD065565;
	Thu, 26 May 2005 11:52:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIqw0q065517
	for ; Thu, 26 May 2005 11:52:58 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8])
          by mta10-winn.mailhost.ntl.com with ESMTP
          id <20050526185252.BMHI20297.mta10-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>;
          Thu, 26 May 2005 19:52:52 +0100
Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41])
          by aamta04-winn.mailhost.ntl.com with ESMTP
          id <20050526185252.UVEX29369.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>;
          Thu, 26 May 2005 19:52:52 +0100
Date: Thu, 26 May 2005 19:52:49 +0100
From: David Powell 
X-Mailer: The Bat! (v3.5.0.16) Professional
X-Priority: 3 (Normal)
Message-ID: <2668300.20050526195249@djpowell.net>
To: Thomas Broyer 
CC: atom-syntax 
Subject: Re: extension elements inside link elements?
In-Reply-To: <42961367.7040701@cegetel.net>
References: 
 
 <68fba5c505052408075404b24f@mail.gmail.com>
 
 <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com>
 <1225690969.20050525214054@djpowell.net>
 
 <1665867878.20050526004720@djpowell.net> <42961367.7040701@cegetel.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



Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:

>>But then 6.3 goes on to explain how to process it.
>>This sounds like a contradiction?
>>  
>>
> No, why?

Ok, I'd interpreted "ignoring" it to be processing it, as opposed to
failing.  I'll concede that I misinterpreted that.


> Say I am an Atom Processor and I find these extensions elements:
> 
> 26.58
> -97.83

> Is this something I know how to process?

>     * yes: this is "known foreign markup", I process it
>     * no: this is "unknown foreign markup", I ignore it without failing
>       or signaling an error

So known 6.4 extensions are "known foreign markup", and unknown
extensions are "unknown foreign markup"?  Ok.


>>Also, if 6.4 extensions are a subset of "unknown[?] foreign markup",

> 6.4 extensions are not a subset of "foreign markup" or "unknown foreign
> markup". 6.4 extensions are the whole "foreign markup" set

6.2 says that new elements and attributes can be added. Earlier
discussion in this thread suggested that these may be inside
 elements. Isn't this a type of markup that isn't a 6.4
extension?

6.4 extensions can only appear in atom:feed, atom:entry, and Person
constructs. [BUG ALERT!!!! - they should blatantly be allowed inside
atom:source too, and the inheritance needs explaining]

For the people who were proposing that atom:link shouldn't ban
content, can they tell me which type of Section 6 markup they regard
it to be?  Or were they proposing that Section 6.4 should be extended
to allow Link Extensions.


> (except it doesn't deal with "foreign attributes", but the whole
> section 6 and the whole spec doesn't deal with them).

Yes it does, section 6.2 says that future versions of Atom can add new
attributes.


> If you read carefully the section 6.4, you'll notice that what is not a
> Simple Extension Element is a Structured Extension Element.
> A Simple Extension Element is an element with no attribute and is either
> empty or has text-only content.
> A Structured Extension Element is an element with at least an attribute
> or a child.

Yep, I understand Section 6.4, but these rules only apply directly
inside atom:entry, atom:feed, and Person constructs [and atom:source].
Foreign markup in other places isn't 6.4 markup, so what is it?


> Is there any other construct I missed?

* Elements in places that they aren't banned such as atom:category, and
depending on the outcome of this thread, atom:link - presumably
intended for future versions of Atom.  Allowed by Section 6.2.

[BUG ALERT!!! The RNG says that the content is empty, the text
doesn't]

* Attributes on any existing elements.  Allowed by Section 6.2.


-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu May 26 16:02:48 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02222
	for ; Thu, 26 May 2005 16:02: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 j4QJoPRI073357;
	Thu, 26 May 2005 12:50: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 j4QJoNG9073311;
	Thu, 26 May 2005 12:50:23 -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.79])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJoLRv073158
	for ; Thu, 26 May 2005 12:50:21 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.55.2])
	by smtp.cegetel.net (Postfix) with ESMTP id 9D8BC1A408F;
	Thu, 26 May 2005 21:49:26 +0200 (CEST)
Message-ID: <4296286C.6040409@cegetel.net>
Date: Thu, 26 May 2005 21:50:04 +0200
From: Thomas Broyer 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: David Powell 
Cc: atom-syntax 
Subject: Re: extension elements inside link elements?
References:   <68fba5c505052408075404b24f@mail.gmail.com>  <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@djpowell.net>  <1665867878.20050526004720@djpowell.net> <42961367.7040701@cegetel.net> <2668300.20050526195249@djpowell.net>
In-Reply-To: <2668300.20050526195249@djpowell.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


David Powell wrote:

>Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
>
>>Say I am an Atom Processor and I find these extensions elements:
>>
>>26.58
>>-97.83
>>    
>>
>>Is this something I know how to process?
>>    
>>
>>    * yes: this is "known foreign markup", I process it
>>    * no: this is "unknown foreign markup", I ignore it without failing
>>      or signaling an error
>>    
>>
>
>So known 6.4 extensions are "known foreign markup", and unknown
>extensions are "unknown foreign markup"?  Ok.
>  
>
Yes, though "known foreign markup" is not used in the spec (or I missed it).
And actually, you're right (see below) saying 6.4 extensions do not 
describe the whole "foreign markup" set (see below).

>>6.4 extensions are not a subset of "foreign markup" or "unknown foreign
>>markup". 6.4 extensions are the whole "foreign markup" set
>>    
>>
>
>6.2 says that new elements and attributes can be added.
>
6.2 deals with the "Atom vocabulary", which is the markup in the Atom 
namespace or un prefixed attributes on Atom-namespaced elements (this is 
my interpretation, it's not clearly stated in the spec, and I'm quite 
sure I already raised this in the past two weeks).
6.1 deals with "foreign markup", that is (still not clearly stated by 
the spec text) markup in a namespace different from the Atom namespace.

>Earlier
>discussion in this thread suggested that these may be inside
> elements. Isn't this a type of markup that isn't a 6.4
>extension?
>
>6.4 extensions can only appear in atom:feed, atom:entry, and Person
>constructs. [BUG ALERT!!!! - they should blatantly be allowed inside
>atom:source too, and the inheritance needs explaining]
>  
>
You're right, 6.4 extensions are the subset of "foreign markup" known as 
"Metadata Elements", they' do not represent the whole "foreign markup" set.

>For the people who were proposing that atom:link shouldn't ban
>content, can they tell me which type of Section 6 markup they regard
>it to be?  Or were they proposing that Section 6.4 should be extended
>to allow Link Extensions.
>  
>
If future versions of Atom adds (unprefixed) attributes or 
(Atom-namespaced) elements inside atom:link, they will be "Extensions to 
the Atom Vocabulary" per section 6.2.

If someone defines extensions (attributes or elements in a namespace 
other than the Atom namespace) inside atom:link, they will be 
"Extensions From Non-Atom Vocabularies", per section 6.1. As they won't 
match section 6.4 criteria (not inside atom:feed, atom:entry or a Person 
Construct), they won't be "Metadata Elements" and thus their role is 
undefined (per section 6.4, last sentence of the single 6.4 paragraph).

>>(except it doesn't deal with "foreign attributes", but the whole
>>section 6 and the whole spec doesn't deal with them).
>>    
>>
>
>Yes it does, section 6.2 says that future versions of Atom can add new
>attributes.
>  
>
You're right. Although you should have refered to section 6.1. Their 
role is just undefined by the spec.

>>If you read carefully the section 6.4, you'll notice that what is not a
>>Simple Extension Element is a Structured Extension Element.
>>A Simple Extension Element is an element with no attribute and is either
>>empty or has text-only content.
>>A Structured Extension Element is an element with at least an attribute
>>or a child.
>>    
>>
>
>Yep, I understand Section 6.4, but these rules only apply directly
>inside atom:entry, atom:feed, and Person constructs [and atom:source].
>Foreign markup in other places isn't 6.4 markup, so what is it?
>  
>
It is just "foreign markup", per section 6.1. Its role is undefined by 
the spec. What the spec says is only how to process it (the MustIgnore 
in section 6.3).

Markup which the section 6.2 deals with is markup inside the Atom 
namespace. It is not "foreign markup", though it must be considered as 
such by Atom 1.0 Processors for the "purposes of this discussion". If it 
matches 6.4 criteria, it is "Metadata Elements" markup, otherwise, it is 
just "Atom markup which is considered foreign markup for the purposes of 
this discussion".

I must however agree that the spec is not as clear as it could be... it 
doesn't for example clearly define "Atom Vocabulary" on which definition 
of "foreign markup" is relying.

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Thu May 26 16:42:45 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10545
	for ; Thu, 26 May 2005 16:42: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 j4QKXesZ079832;
	Thu, 26 May 2005 13:33: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 j4QKXeau079831;
	Thu, 26 May 2005 13:33:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKXdt9079818
	for ; Thu, 26 May 2005 13:33:40 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8])
          by mta10-winn.mailhost.ntl.com with ESMTP
          id <20050526203333.XFYR20297.mta10-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>;
          Thu, 26 May 2005 21:33:33 +0100
Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41])
          by aamta05-winn.mailhost.ntl.com with ESMTP
          id <20050526203333.MJEY8884.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>;
          Thu, 26 May 2005 21:33:33 +0100
Date: Thu, 26 May 2005 21:33:30 +0100
From: David Powell 
X-Mailer: The Bat! (v3.5.0.16) Professional
X-Priority: 3 (Normal)
Message-ID: <1695124645.20050526213330@djpowell.net>
To: Thomas Broyer 
CC: atom-syntax 
Subject: Re: extension elements inside link elements?
In-Reply-To: <4296286C.6040409@cegetel.net>
References: 
 
 <68fba5c505052408075404b24f@mail.gmail.com>
 
 <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com>
 <1225690969.20050525214054@djpowell.net>
 
 <1665867878.20050526004720@djpowell.net> <42961367.7040701@cegetel.net>
 <2668300.20050526195249@djpowell.net> <4296286C.6040409@cegetel.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



Thursday, May 26, 2005, 8:50:04 PM, you wrote:

>>6.2 says that new elements and attributes can be added.
>>
> 6.2 deals with the "Atom vocabulary", which is the markup in the Atom
> namespace or un prefixed attributes on Atom-namespaced elements (this is
> my interpretation, it's not clearly stated in the spec, and I'm quite
> sure I already raised this in the past two weeks).

Yes, I proposed that we fix this here too:


It is extremely important that clients can discriminate Section 6.2
elements from Section 6.4 elements.

If we don't make this change, then implementations could interpret
atom-namespaced "section 6.2 elements" inside entry/feed/person/source
as "section 6.4 metadata elements". Implementations may then forward
these elements believing that they are harmless metadata, when in fact
they are more likely to be control elements, which they definitely
should not be forwarded by implementations that don't understand them.

This is pretty much exactly the same problem as the one that caused
HTTP 1.0 Persistent Connections to fail. [see RFC2068 section 19.7.1]

-- 
Dave



From owner-atom-syntax@mail.imc.org  Thu May 26 16:55:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11700
	for ; Thu, 26 May 2005 16:55: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 j4QKlRaO080765;
	Thu, 26 May 2005 13:47: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 j4QKlRvq080764;
	Thu, 26 May 2005 13:47:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKlQDd080756
	for ; Thu, 26 May 2005 13:47:27 -0700 (PDT)
	(envelope-from asbjorn@tigerstaden.no)
Received: from osl1sminn1.broadpark.no ([80.202.4.59])
 by osl1smout1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IH4008FJCYC1950@osl1smout1.broadpark.no> for
 atom-syntax@imc.org; Fri, 27 May 2005 00:54:12 +0200 (CEST)
Received: from quark ([84.48.117.46]) by osl1sminn1.broadpark.no
 (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004))
 with ESMTP id <0IH400C58794KFJ0@osl1sminn1.broadpark.no> for
 atom-syntax@imc.org; Thu, 26 May 2005 22:51:05 +0200 (CEST)
Date: Thu, 26 May 2005 22:51:40 +0200
From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= 
Subject: Re: The atom:uri element
In-reply-to: 
To: Graham 
Cc: atom-syntax 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Content-transfer-encoding: 8BIT
References:  <20050525052004.GB10318@klangraum>
 <67E6EBBC-57B7-45D0-9161-A6AFE639E3A0@mac.com> 
 
User-Agent: Opera M2/8.0 (Win32, build 7561)
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8BIT


On Wed, 25 May 2005 16:17:07 +0200, Graham  wrote:

>> What about atom:author@href, then?
>
> No, I want multiple uris.

Okay, that's a good point.

> And couldn't email be a mailto: uri?

Another good point I think the atom:link element could solve pretty nicely.

> +1 to replacing atom:email and atom:uri with multiple real atom:link  
> elements (to allow titles).

Yay. +1.

> (I don't care about the rel value)

Me neither, although I feel alternate is an a bit awkward value (even  
though it's not alternate to the actual author (no, he's not in the feed  
somewhere ;-), but to the metadata about the author).

-- 
Asbjrn Ulsberg     -=|=-    http://virtuelvis.com/quark/
He's a loathsome offensive brute, yet I can't look away



From owner-atom-syntax@mail.imc.org  Thu May 26 18:24:44 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19190
	for ; Thu, 26 May 2005 18:24: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 j4QMGCJC023040;
	Thu, 26 May 2005 15:16: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 j4QMGCR7023039;
	Thu, 26 May 2005 15:16:12 -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 (mf01.sitadelle.com [212.94.174.80])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QMGA9u022917
	for ; Thu, 26 May 2005 15:16:11 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.55.2])
	by smtp.cegetel.net (Postfix) with ESMTP id D36FF3180AF;
	Fri, 27 May 2005 00:16:04 +0200 (CEST)
Message-ID: <42964AA5.6010109@cegetel.net>
Date: Fri, 27 May 2005 00:16:05 +0200
From: Thomas Broyer 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: David Powell 
Cc: atom-syntax 
Subject: Re: extension elements inside link elements?
References:   <68fba5c505052408075404b24f@mail.gmail.com>  <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com> <1225690969.20050525214054@djpowell.net>  <1665867878.20050526004720@djpowell.net> <42961367.7040701@cegetel.net> <2668300.20050526195249@djpowell.net> <4296286C.6040409@cegetel.net> <1695124645.20050526213330@djpowell.net>
In-Reply-To: <1695124645.20050526213330@djpowell.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


David Powell wrote:

>Thursday, May 26, 2005, 8:50:04 PM, you wrote:
>  
>
>>6.2 deals with the "Atom vocabulary", which is the markup in the Atom
>>namespace or un prefixed attributes on Atom-namespaced elements (this is
>>my interpretation, it's not clearly stated in the spec, and I'm quite
>>sure I already raised this in the past two weeks).
>>    
>>
>Yes, I proposed that we fix this here too:
>
>  
>
It'd be still be necessary to define the term "vocabulary" somewhere, in 
section 6 or in the introduction (section 1).

As "vocabulary" is only used only in sections 6.1 and 6.2, I suggest 
using "namespace" instead:

[
6.1  Extensions From Non-Atom Namespaces

   This specification describes Atom's XML markup namespace.  Markup
   from other namespaces ("foreign markup") can be used in an Atom
   document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2  Extensions To The Atom Namespace

   Future versions of this specification could add new elements and
   attributes to the Atom markup namespace.  Software written to
   conform to this version of the specification will not be able to
   process such markup correctly and, in fact, will not be able to
   distinguish it from markup error.  For the purposes of this
   discussion, unrecognized markup from the Atom namespace will be
   considered "foreign markup".
]

This however doesn't prevent us adding your sentence to 6.4 to make it 
clearer.

-- 
Thomas Broyer





From owner-atom-syntax@mail.imc.org  Thu May 26 19:09:53 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22587
	for ; Thu, 26 May 2005 19:09: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 j4QN156g053312;
	Thu, 26 May 2005 16:01: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 j4QN15Gr053311;
	Thu, 26 May 2005 16:01:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4QN132J053300
	for ; Thu, 26 May 2005 16:01:04 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000436861 for ; Fri, 27 May 2005 09:01:01 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 27 May 2005 09:00:59 +1000
Subject: Re: The atom:uri element
From: Eric Scheid 
To: Atom Syntax 
Message-ID: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QN152J053306
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


On 27/5/05 6:51 AM, "Asbjrn Ulsberg"  wrote:

>> +1 to replacing atom:email and atom:uri with multiple real atom:link
>> elements (to allow titles).
> 
> Yay. +1.

+1

that's elegant and clean, and seeing as we're unlikely to be seeing many
feeds with email addresses at all it's no great loss to see a specialised
element fade away.

>> (I don't care about the rel value)
> 
> Me neither, although I feel alternate is an a bit awkward value (even
> though it's not alternate to the actual author (no, he's not in the feed
> somewhere ;-), but to the metadata about the author).

+1 :-)

e.




From owner-atom-syntax@mail.imc.org  Thu May 26 19:24:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23321
	for ; Thu, 26 May 2005 19:24: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 j4QNH3WJ054986;
	Thu, 26 May 2005 16:17: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 j4QNH3nc054985;
	Thu, 26 May 2005 16:17:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QNH3YJ054979
	for ; Thu, 26 May 2005 16:17:03 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4QNGxeB004009;
	Thu, 26 May 2005 19:16:59 -0400 (EDT)
Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DGL82724 (AUTH bob@wyman.us);
	Thu, 26 May 2005 19:16:58 -0400 (EDT)
Message-Id: <200505262316.DGL82724@ms8.netsolmail.com>
Reply-To: 
From: "Bob Wyman" 
To: "'James M Snell'" , 
Subject: Signatures - I blog, therefore I am... ( was: RE: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25))
Date: Thu, 26 May 2005 19:16:54 -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
In-Reply-To: <4295E65B.1030608@gmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcViBttjC2T45vLeQl29Sg5kDVtY8AAPPNhQ
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7bit


James M Snell wrote:
> Well, it comes down to whether the signature is trusted by the
> reader or not.  If the signature in the entry is not from the trusted,
> expected source, the user should be able to reject it in favor of the
> unsigned entry.
	Clearly, we're going to have to put a good bit of thought into how
signatures work in Atom in the future. I think it is great that Atom V1.0
has the signature support that it does, however, my guess is that we'll
probably need to develop some extensions and some "best practices" to really
make this stuff work well.

	One interesting question that I think we should consider is "Who's
signature is it anyway?" In most existing signature based applications, we
seem to assume that a person is the entity that creates a signature.
However, I think it may be appropriate to do something different with feeds.
Specifically, I think that it may make a great deal of sense for the *feed*
to sign things. 
	Today, we trust that an entry came from a specific feed if we
inspect the feed and discover that it contains the entry. For a great many
applications, it doesn't really matter who owns the feed. Thus, it might
make sense in the future to associate signing keys with the feed rather than
with the owner of the feed. Signatures would then be used to make statements
that entries -- even if found in other feeds -- actually came from the
source feed that they are claimed to have come from. This would solve a
great many problems that arise when search engines, intermediaries like
PubSub, LinkBlogs, etc. copy entries around.
	The only mechanism that we would need in order to allow feeds to
sign their content would be a means to associate a signing key with a feed
or set of feeds. This could be done in one of two ways: 
	* The traditional indirect manner of having a certificate authority
create a certificate for someone once they prove administrative control over
a feed.
	* The much simpler method of the feed including an extension element
that identifies its signing keys -- it could either point to a file or to a
key server.
	The second method above has the downside that one would either have
to be familiar with the feed and thus have memory of its statements
concerning keys or one would have to fetch the feed as part of the signature
verification process. However, the fact that the second method dispenses
with the need for a certificate authority may make it appear quite
appealing... Also, the second method allows one to do things like replace,
expire, and cancel keys simply by changing the associations in the feed.
	One of the really interesting side-effects of having feeds, not
people, be the owners of keys is that we might then find that it makes sense
to allow feeds to issue certificates to their owners. (Yes, I know that this
probably sounds odd...) Basically, the idea is that instead of giving keys
to a person and then doing things to associate the feed with the person, we
might turn things around and give keys to the feed and then associate the
person with the feed. An intriguing aspect of doing this is that any
measures of the "authority" of the feed could be passed on to the owner of
the feed. Your personal authority, popularity, identity, etc. might be
derived from your feed... So, instead of having to go through the sometimes
great nuisance of presenting birth certificates, SSNs, and other evidence of
personhood to a certificate authority, we could simply assert our personal
existence by linking to the blogs we own... I blog, therefore I am.

	Another interesting question would be what is that role of
intermediaries like PubSub or search engines in signing things? Some such
services might be "trusted" when they make statements like "I found this
entry in the feed identified in the source element." If this is the case,
there could be value in having such trusted services sign the entries that
that pass on. Then, if you found a copy of an entry that carried such a
signature, you could have just as much faith in its correctness as if you
had retrieved the entry directly from the intermediary rather than from
someone who had copied it from the intermediary.
	There are a number of interesting possibilities here....

		bob wyman




From owner-atom-syntax@mail.imc.org  Thu May 26 19:29:00 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23547
	for ; Thu, 26 May 2005 19:28: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 j4QNLMPv055342;
	Thu, 26 May 2005 16:21: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 j4QNLMqe055341;
	Thu, 26 May 2005 16:21:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QNLLcG055331
	for ; Thu, 26 May 2005 16:21:22 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8])
          by mta10-winn.mailhost.ntl.com with ESMTP
          id <20050526232115.EFEZ20297.mta10-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>;
          Fri, 27 May 2005 00:21:15 +0100
Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41])
          by aamta03-winn.mailhost.ntl.com with ESMTP
          id <20050526232115.EYQG2626.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>;
          Fri, 27 May 2005 00:21:15 +0100
Date: Fri, 27 May 2005 00:21:12 +0100
From: David Powell 
X-Mailer: The Bat! (v3.5.0.16) Professional
X-Priority: 3 (Normal)
Message-ID: <877985317.20050527002112@djpowell.net>
To: Thomas Broyer 
CC: atom-syntax 
Subject: Re: extension elements inside link elements?
In-Reply-To: <42964AA5.6010109@cegetel.net>
References: 
 
 <68fba5c505052408075404b24f@mail.gmail.com>
 
 <8728696A-6F9C-46CB-9AD6-DF7B1DEEC7EE@sun.com>
 <1225690969.20050525214054@djpowell.net>
 
 <1665867878.20050526004720@djpowell.net> <42961367.7040701@cegetel.net>
 <2668300.20050526195249@djpowell.net> <4296286C.6040409@cegetel.net>
 <1695124645.20050526213330@djpowell.net> <42964AA5.6010109@cegetel.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



Thursday, May 26, 2005, 11:16:05 PM, Thomas Broyer wrote:

> David Powell wrote:

>>Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote:
>>
>>>6.2 deals with the "Atom vocabulary", which is the markup in the Atom
>>>namespace or un prefixed attributes on Atom-namespaced elements (this is
>>>my interpretation, it's not clearly stated in the spec, and I'm quite
>>>sure I already raised this in the past two weeks).
>>>
>>Yes, I proposed that we fix this here too:
>>
>>
> It'd be still be necessary to define the term "vocabulary" somewhere, in
> section 6 or in the introduction (section 1).

> As "vocabulary" is only used only in sections 6.1 and 6.2, I suggest
> using "namespace" instead:

> [
> 6.1  Extensions From Non-Atom Namespaces

>    This specification describes Atom's XML markup namespace.  Markup
>    from other namespaces ("foreign markup") can be used in an Atom
>    document.  Note that the atom:content element is designed to support
>    the inclusion of arbitrary foreign markup.

> 6.2  Extensions To The Atom Namespace

>    Future versions of this specification could add new elements and
>    attributes to the Atom markup namespace.  Software written to
>    conform to this version of the specification will not be able to
>    process such markup correctly and, in fact, will not be able to
>    distinguish it from markup error.  For the purposes of this
>    discussion, unrecognized markup from the Atom namespace will be
>    considered "foreign markup".
> ]

This sounds good, but 6.2 ought to also include unprefixed attributes
on atom elements as well as atom: prefixed ones.

> This however doesn't prevent us adding your sentence to 6.4 to make it
> clearer.

I think 6.3 would be much easier to understand if its position was
swapped with 6.4. When you read 6.3 you assume that everything not
mentioned so far must be "unknown foreign markup", then when you read
6.4, it redefines some of that as "metadata elements". They are
intended to be disjoint, but the ordering suggested to me that 6.4 was
a subset.

Paragraph 2 of 6.3 reinforced my misconception that 6.4 markup is
subset of "unknown foreign markup", especially as it didn't mention
markup on other elements or attributes as 6.2 proposed. If 6.3 and 6.4
were swapped, then I think paragraph 2 of 6.3 could be trimmed down to
avoid this. Replace paragraph 2 & 3 of 6.3, with:

  When unknown foreign markup is encountered in a Text Contruct or
  atom:content element, software SHOULD ignore the markup and process
  any text content of foreign elements as though the surrounding
  markup were not present.

  When unknown foreign markup is encountered elsewhere, software MAY
  bypass the markup and any textual content and MUST NOT change its
  behavior as a result of the markup's presence.

--
Dave







From owner-atom-syntax@mail.imc.org  Thu May 26 20:15:02 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25707
	for ; Thu, 26 May 2005 20:15: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 j4R06iMX059223;
	Thu, 26 May 2005 17:06: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 j4R06ikb059222;
	Thu, 26 May 2005 17:06:44 -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 j4R06gjl059216
	for ; Thu, 26 May 2005 17:06:43 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <200505262316.DGL82724@ms8.netsolmail.com>
References: <200505262316.DGL82724@ms8.netsolmail.com>
Date: Thu, 26 May 2005 17:06:40 -0700
To: Atom WG 
From: Paul Hoffman 
Subject: Re: Signatures - I blog, therefore I am...
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:16 PM -0400 5/26/05, Bob Wyman wrote:
>	The only mechanism that we would need in order to allow feeds to
>sign their content would be a means to associate a signing key with a feed
>or set of feeds. This could be done in one of two ways:
>	* The traditional indirect manner of having a certificate authority
>create a certificate for someone once they prove administrative control over
>a feed.
>	* The much simpler method of the feed including an extension element
>that identifies its signing keys -- it could either point to a file or to a
>key server.

Much simpler, but completely insecure. :-) It's a self-signed 
attestation that has to be verified by out-of-band means that, from a 
security standpoint, are equivalent to the first if done right and 
horribly dangerous if done wrong.

Having said that, I support the latter more than the former, and 
believe that >90% of signed feeds that people actually use will 
follow that model.

>	The second method above has the downside that one would either have
>to be familiar with the feed and thus have memory of its statements
>concerning keys or one would have to fetch the feed as part of the signature
>verification process. However, the fact that the second method dispenses
>with the need for a certificate authority may make it appear quite
>appealing... Also, the second method allows one to do things like replace,
>expire, and cancel keys simply by changing the associations in the feed.

And, to do any of those securely, you need to do the same things you 
did to get the keys in the first place, using the same security 
mechanism.

>	One of the really interesting side-effects of having feeds, not
>people, be the owners of keys...

Wait, stop. There is no such thing as an "owner" of a key. There are 
things that control the private key of a key pair. That is *always* a 
computer of some sort, and that computer is *always* controllable by 
at least one person. If you're careful/lucky, everyone who has access 
to the private key is someone who should have access.

It is much better to say "..having feeds, not people, be associated 
with keys...". That is, the identifier that is associated with the 
key is a URI of the feed, not a person or company name.

>  is that we might then find that it makes sense
>to allow feeds to issue certificates to their owners. (Yes, I know that this
>probably sounds odd...) Basically, the idea is that instead of giving keys
>to a person and then doing things to associate the feed with the person, we
>might turn things around and give keys to the feed and then associate the
>person with the feed. An intriguing aspect of doing this is that any
>measures of the "authority" of the feed could be passed on to the owner of
>the feed. Your personal authority, popularity, identity, etc. might be
>derived from your feed... So, instead of having to go through the sometimes
>great nuisance of presenting birth certificates, SSNs, and other evidence of
>personhood to a certificate authority, we could simply assert our personal
>existence by linking to the blogs we own... I blog, therefore I am.

Stated another way, the anchor of the key hierarchy is identified by 
the URI of a feed, and the leaves might be identified by human names.

A different method would be to have multiple identities associated 
with keys. My key might be identified with "Paul Hoffman" and 
"http://lookit.proper.com" and "http://saladwithsteve.com/osx/" and 
so on.

>	Another interesting question would be what is that role of
>intermediaries like PubSub or search engines in signing things? Some such
>services might be "trusted" when they make statements like "I found this
>entry in the feed identified in the source element." If this is the case,
>there could be value in having such trusted services sign the entries that
>that pass on. Then, if you found a copy of an entry that carried such a
>signature, you could have just as much faith in its correctness as if you
>had retrieved the entry directly from the intermediary rather than from
>someone who had copied it from the intermediary.

Exactly right. Intermediary validation is what drives security folks 
crazy (witness the more-than-five-year history of SCVP in the PKIX 
WG), but it is exactly what most people use every day.

>	There are a number of interesting possibilities here....

+1

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri May 27 01:43:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18497
	for ; Fri, 27 May 2005 01:43: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 j4R5YXwK035694;
	Thu, 26 May 2005 22:34: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 j4R5YXmD035693;
	Thu, 26 May 2005 22:34:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4R5YUYq035658
	for ; Thu, 26 May 2005 22:34:32 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000437971 for ; Fri, 27 May 2005 15:34:24 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 27 May 2005 15:34:21 +1000
Subject: Re: Editorship announcement
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 27/5/05 4:14 AM, "Tim Bray"  wrote:

> protocol-04

btw, where can we find it?

e.



From owner-atom-syntax@mail.imc.org  Fri May 27 01:56:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19332
	for ; Fri, 27 May 2005 01:56: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 j4R5mjMD043295;
	Thu, 26 May 2005 22:48: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 j4R5mjAv043292;
	Thu, 26 May 2005 22:48:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R5mj7g043276;
	Thu, 26 May 2005 22:48:45 -0700 (PDT)
	(envelope-from bob@wyman.us)
Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180])
	by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j4R5miWl018589;
	Fri, 27 May 2005 01:48:44 -0400 (EDT)
Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137])
	by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id DGM84080;
	Fri, 27 May 2005 01:48:43 -0400 (EDT)
Message-Id: <200505270548.DGM84080@ms8.netsolmail.com>
Reply-To: 
From: "Bob Wyman" 
To: "'Paul Hoffman'" , "'Atom WG'" 
Subject: RE: Signatures - I blog, therefore I am...
Date: Fri, 27 May 2005 01:48: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
Thread-Index: AcViUb6gcfsXHqLKRUC/J42Pz3kEJwAKdd6Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: 
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7bit


Paul Hoffman wrote:
> It is much better to say "..having feeds, not people, be
> associated with keys...". That is, the identifier that is 
> associated with the key is a URI of the feed, not a person
> or company name.
	You are, of course, correct. My apologies for being sloppy and
letting the "ownership" concept slip in. The correct concept is an
association between things, not ownership.

> A different method would be to have multiple identities
> associated with keys. My key might be identified with "Paul 
> Hoffman" and "http://lookit.proper.com" and
> http://saladwithsteve.com/osx/" and so on.
	This is certainly possible. However, I quite like the idea of
rooting the hierarchy in an association between keys and a verifiable
network resource. Presumably, it will be much easier for us to gather
"reputation" information concerning feeds and having such verifiable
resources at the root of the hierarchy will make it somewhat harder for
people to generate spurious keys. 

> Much simpler, but completely insecure. :-)... Having said that, 
>I support the latter more than the former, and believe that >90% of
> signed feeds that people actually use will follow that model.
	I agree. In many ways, the process of getting keys from a small
number of centralized certificate authorities may be viewed as "more
correct." However, we have decades of experience with "correct" solutions
that are simply not used. They are often elegant, but useless... If we're
ever going to get signatures in wide use, we're going to have to compromise
a bit and focus on what is practical -- not just what is technically
superior. An unimplemented solution is *not* superior, in any useful sense,
to a less elegant but implemented solution that delivers the same result.

		bob wyman




From owner-atom-syntax@mail.imc.org  Fri May 27 03:05:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15395
	for ; Fri, 27 May 2005 03:05: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 j4R6nINs070757;
	Thu, 26 May 2005 23:49: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 j4R6nIXY070756;
	Thu, 26 May 2005 23:49:18 -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 (mf01.sitadelle.com [212.94.174.80])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R6nAFH070636
	for ; Thu, 26 May 2005 23:49:13 -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 57A863184ED;
	Fri, 27 May 2005 08:49:01 +0200 (CEST)
Received: from 82.127.77.43
        (SquirrelMail authenticated user t.broyer@cegetel.net)
        by ssl-webmail.sitadelle.com with HTTP;
        Fri, 27 May 2005 08:49:02 +0200 (CEST)
Message-ID: <2750.82.127.77.43.1117176542.squirrel@ssl-webmail.sitadelle.com>
Date: Fri, 27 May 2005 08:49:02 +0200 (CEST)
Subject: Re: Editorship announcement
From: "Thomas Broyer" 
To: 
In-Reply-To: 
References: 
        
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



Eric Scheid wrote:
>
> On 27/5/05 4:14 AM, "Tim Bray"  wrote:
>
>> protocol-04
>
> btw, where can we find it?

Replace "format-08" with "protocol-04" and you get it ;o)

http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt

There's also a link to the last version from
http://intertwingly.net/wiki/pie/FrontPage

Discussions go on atom-protocol@imc.org

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Fri May 27 11:02:53 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19047
	for ; Fri, 27 May 2005 11: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 j4REsR98075127;
	Fri, 27 May 2005 07: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 j4REsR16075126;
	Fri, 27 May 2005 07:54: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 j4REsQPI075112
	for ; Fri, 27 May 2005 07:54:26 -0700 (PDT)
	(envelope-from hlddn.atom@gmail.com)
Received: by wproxy.gmail.com with SMTP id 55so1306089wri
        for ; Fri, 27 May 2005 07:54: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:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=hcl/I/3uL+Putt8qMO76Ohcdck/GJcsY8cqiVsJIHvrPdH+IBIG6xry9BTQpWmj53VnbQi0UYe//eEizXPIR8ubNn4E+In/PFMv5c9G2ObfWbEe2TlAc2mGV26UzrQ9ucWgeom38SkPDHOkue58Klgewzh0zUY6/k1Eq78czx9A=
Received: by 10.54.138.5 with SMTP id l5mr2584720wrd;
        Fri, 27 May 2005 07:54:21 -0700 (PDT)
Received: by 10.54.45.71 with HTTP; Fri, 27 May 2005 07:54:21 -0700 (PDT)
Message-ID: <5817a40605052707546e251ea4@mail.gmail.com>
Date: Fri, 27 May 2005 22:54:21 +0800
From: starry 
Reply-To: starry 
To: atom-protocol@imc.org, atom-syntax@imc.org
Subject: i want it to support nokis's lifeblog,please help me.
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 j4REsQPI075115
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


I have a server(freebsd+apache+php), i want it to support nokis's
lifeblog. what do i need to do to receive the atom send by lifeblog
and reply to it's document. also, can php solve "X-WSSE" header?



From owner-atom-syntax@mail.imc.org  Fri May 27 11:04:33 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19218
	for ; Fri, 27 May 2005 11:04: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 j4REwGO1075873;
	Fri, 27 May 2005 07:58: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 j4REwGFX075872;
	Fri, 27 May 2005 07:58:16 -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 j4REwFLC075748
	for ; Fri, 27 May 2005 07:58:16 -0700 (PDT)
	(envelope-from hlddn.atom@gmail.com)
Received: by wproxy.gmail.com with SMTP id 55so1308620wri
        for ; Fri, 27 May 2005 07:58:08 -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=i+iUFu+Nj9s8xcIvx0bn69ExyMakqE8laxg2wg8qf/9xjnRqBZqOj/+BQNcmWoBvM8lrAtI/OsjBpXHneLMqHgHGeHNVqQ6mGJ/C4OxcjM7Y5LjsRBOU+uAwMS7guuE6OcQ8+16FLFOz+dLEKh8Bp3kin7ZxJ1LQI6go3FY297s=
Received: by 10.54.27.62 with SMTP id a62mr2610393wra;
        Fri, 27 May 2005 07:58:08 -0700 (PDT)
Received: by 10.54.45.71 with HTTP; Fri, 27 May 2005 07:58:08 -0700 (PDT)
Message-ID: <5817a40605052707581f5e7ba1@mail.gmail.com>
Date: Fri, 27 May 2005 22:58:08 +0800
From: starry 
Reply-To: starry 
To: Atom Protocol ,
        atom-syntax Syntax 
Subject: i want it to support nokis's lifeblog,please help me.
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 j4REwGLC075867
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


I have a server(freebsd+apache+php), i want it to support nokis's
lifeblog. what do i need to do to receive the atom send by lifeblog
and reply to it's document. also, can php solve "X-WSSE" header?
Thanks!!



From owner-atom-syntax@mail.imc.org  Fri May 27 11:08:31 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19463
	for ; Fri, 27 May 2005 11:08: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 j4RF37jD077356;
	Fri, 27 May 2005 08: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 j4RF37oN077354;
	Fri, 27 May 2005 08:03: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.195])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RF35oI077340
	for ; Fri, 27 May 2005 08:03:06 -0700 (PDT)
	(envelope-from djacobs@gmail.com)
Received: by zproxy.gmail.com with SMTP id 13so1513463nzp
        for ; Fri, 27 May 2005 08:03:00 -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=djUqluU7VkF12gdGVCdQTCZukqvPFK0Pp4fa5uEuDsUnQCEWxSjR5PnC9yuSIW1VMh3QwjZXrZLKastvWCaHHjLWHHFenni+5WLPBMv5ktq5Sn9xA2vLvWwjkVqTsae0vMhzIRVt3DWrfZ+XbkG/cKwQjMz+q+uFxGGRjnZhfM4=
Received: by 10.36.19.12 with SMTP id 12mr1087844nzs;
        Fri, 27 May 2005 08:02:59 -0700 (PDT)
Received: by 10.36.13.14 with HTTP; Fri, 27 May 2005 08:02:59 -0700 (PDT)
Message-ID: <466cecc905052708026b10113d@mail.gmail.com>
Date: Fri, 27 May 2005 11:02:59 -0400
From: David Jacobs 
Reply-To: David Jacobs 
To: starry 
Subject: Re: i want it to support nokis's lifeblog,please help me.
Cc: atom-protocol@imc.org, atom-syntax@imc.org
In-Reply-To: <5817a40605052707546e251ea4@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <5817a40605052707546e251ea4@mail.gmail.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RF36oI077344
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


Hi Starry, I can help you with this. Drop me a line at djacobs@gmail.com

Thanks. 


On 5/27/05, starry  wrote:
> 
> I have a server(freebsd+apache+php), i want it to support nokis's
> lifeblog. what do i need to do to receive the atom send by lifeblog
> and reply to it's document. also, can php solve "X-WSSE" header?
> 
>



From owner-atom-syntax@mail.imc.org  Fri May 27 14:33:27 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10772
	for ; Fri, 27 May 2005 14: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 j4RINpCf002762;
	Fri, 27 May 2005 11:23: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 j4RINpkx002761;
	Fri, 27 May 2005 11:23:51 -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 j4RINoCV002741
	for ; Fri, 27 May 2005 11:23:51 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so1814941wra
        for ; Fri, 27 May 2005 11:23: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:subject:content-type:content-transfer-encoding;
        b=HZ3Wd4dVVFR/pl0KOhuAD4DQOZ/+WUruxojlDkL5fPLstqQv4smvDGM5TgmkjWxUQ7Z/RHK5u6te8fpnJaj9P5QZdCsBR0ymFFqtVozmXmwG8JzJqdum4vfe6tCRHbVBkywsWVkOJVJnHSZ6naCafTysY1KMcSVdJ/dbDy5LCek=
Received: by 10.54.35.72 with SMTP id i72mr1751722wri;
        Fri, 27 May 2005 11:23:45 -0700 (PDT)
Received: from ?192.168.1.102? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 26sm1243531wrl.2005.05.27.11.23.45;
        Fri, 27 May 2005 11:23:45 -0700 (PDT)
Message-ID: <4297659D.70400@gmail.com>
Date: Fri, 27 May 2005 11:23:25 -0700
From: James M Snell 
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: [Fwd: Re: Signatures - I blog, therefore I am...]
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


In general, the idea of associating the signing keys with the network 
resource (feed or entry document URI) makes a lot of sense but I think 
there may be some issues there with aggregate feeds and intermediaries 
(e.g. Feedburner) that would need to be worked out. In any case, this is 
definitely something that should be worked up. If there is interest in 
coming up with a ID on the topic, I volunteer to help write it up. The 
question is whether or not this list is the right place to discuss 
extensions like this or whether we should take this offline?

Bob Wyman wrote:

>Paul Hoffman wrote:
>  
>
>>It is much better to say "..having feeds, not people, be
>>associated with keys...". That is, the identifier that is 
>>associated with the key is a URI of the feed, not a person
>>or company name.
>>    
>>
>	You are, of course, correct. My apologies for being sloppy and
>letting the "ownership" concept slip in. The correct concept is an
>association between things, not ownership.
>
>  
>
>>A different method would be to have multiple identities
>>associated with keys. My key might be identified with "Paul 
>>Hoffman" and "http://lookit.proper.com" and
>>http://saladwithsteve.com/osx/" and so on.
>>    
>>
>	This is certainly possible. However, I quite like the idea of
>rooting the hierarchy in an association between keys and a verifiable
>network resource. Presumably, it will be much easier for us to gather
>"reputation" information concerning feeds and having such verifiable
>resources at the root of the hierarchy will make it somewhat harder for
>people to generate spurious keys. 
>
>  
>
>>Much simpler, but completely insecure. :-)... Having said that, 
>>I support the latter more than the former, and believe that >90% of
>>signed feeds that people actually use will follow that model.
>>    
>>
>	I agree. In many ways, the process of getting keys from a small
>number of centralized certificate authorities may be viewed as "more
>correct." However, we have decades of experience with "correct" solutions
>that are simply not used. They are often elegant, but useless... If we're
>ever going to get signatures in wide use, we're going to have to compromise
>a bit and focus on what is practical -- not just what is technically
>superior. An unimplemented solution is *not* superior, in any useful sense,
>to a less elegant but implemented solution that delivers the same result.
>
>		bob wyman
>
>
>
>  
>




From owner-atom-syntax@mail.imc.org  Fri May 27 14:54:46 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14482
	for ; Fri, 27 May 2005 14:54: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 j4RImNNk004762;
	Fri, 27 May 2005 11:48: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 j4RImNY9004761;
	Fri, 27 May 2005 11:48:23 -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 j4RImNRK004755
	for ; Fri, 27 May 2005 11:48: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 j4RImNjO027118
	for ; Fri, 27 May 2005 12:48:23 -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 <0IH500H1PW8MKW@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Fri, 27 May 2005 12:48:23 -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 <0IH500A7JW8LO6@mail.sun.net> for atom-syntax@imc.org; Fri,
 27 May 2005 12:48:22 -0600 (MDT)
Date: Fri, 27 May 2005 11:48:33 -0700
From: Tim Bray 
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
In-reply-to: <4297659D.70400@gmail.com>
To: James M Snell 
Cc: atom-syntax@imc.org
Message-id: <9E8AB1EB-8E64-445C-866D-48852C2C4162@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <4297659D.70400@gmail.com>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7BIT


On May 27, 2005, at 11:23 AM, James M Snell wrote:

> In general, the idea of associating the signing keys with the  
> network resource (feed or entry document URI) makes a lot of sense  
> but I think there may be some issues there with aggregate feeds and  
> intermediaries (e.g. Feedburner) that would need to be worked out.  
> In any case, this is definitely something that should be worked up.  
> If there is interest in coming up with a ID on the topic, I  
> volunteer to help write it up. The question is whether or not this  
> list is the right place to discuss extensions like this or whether  
> we should take this offline?

I think that this list is the perfect place to discuss this stuff,  
the people who care are here.

Also, until we get AtomPubIssuesList cleaned up and the format I-D  
filed, the WG is kind of between tasks, so now is a good time.   -Tim



From owner-atom-syntax@mail.imc.org  Fri May 27 15:01:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15483
	for ; Fri, 27 May 2005 15:01: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 j4RItN5l005739;
	Fri, 27 May 2005 11:55: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 j4RItNLl005738;
	Fri, 27 May 2005 11:55:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4RItLPp005731
	for ; Fri, 27 May 2005 11:55:22 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000440266 for ; Sat, 28 May 2005 04:55:22 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 28 May 2005 04:18:40 +1000
Subject: protocol-04 first reading
From: Eric Scheid 
To: Atom Syntax 
Message-ID: 
In-Reply-To: <2750.82.127.77.43.1117176542.squirrel@ssl-webmail.sitadelle.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/5/05 4:49 PM, "Thomas Broyer"  wrote:

> Replace "format-08" with "protocol-04" and you get it ;o)
> http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt

except I've been getting format-nn from http://atompub.org/... ;-)

ok, for those in the know, could you please point out the parts of the
protocol spec which have been mostly thrashed out and thought to be close to
stable. I'd like to try reading those parts from the point of view of
someone reading a spec without the benefit of reading all the discussions
leading up to it. You know, just like we hope to have developers read the
spec. Might be interesting to see which parts make sense and which don't.

e.



From owner-atom-syntax@mail.imc.org  Fri May 27 15:02:28 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15532
	for ; Fri, 27 May 2005 15:02: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 j4RIvTgg005844;
	Fri, 27 May 2005 11:57: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 j4RIvTpY005843;
	Fri, 27 May 2005 11:57:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.rfburst.com ([66.119.143.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RIvS7X005837
	for ; Fri, 27 May 2005 11:57:29 -0700 (PDT)
	(envelope-from ho@alum.mit.edu)
Received: from tobermory.localdomain ([66.119.143.202])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j4RIvMTq012394
	for ; Fri, 27 May 2005 12:57:22 -0600
Received: from tobermory.localdomain (localhost [127.0.0.1])
	by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id j4RIvKwq000315
	for ; Fri, 27 May 2005 12:57:20 -0600
Received: (from ho@localhost)
	by tobermory.localdomain (8.12.10/8.12.10/Submit) id j4RIvIFC000311;
	Fri, 27 May 2005 12:57:18 -0600
Date: Fri, 27 May 2005 12:57:18 -0600
Message-Id: <200505271857.j4RIvIFC000311@tobermory.localdomain>
From: "The Purple Streak, Hilarie Orman" 
To: atom-syntax@imc.org
In-reply-to: Yourmessage <4297659D.70400@gmail.com>
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-MailScanner-From: ho@alum.mit.edu
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


It's silly to require that signatures be validated without some
security model relating that signature to some kind of meaningful
authentication.

Feeds should be able to provide certificates (self-signed or
otherwise) or be required to provide a method to get the cert; the
signature on the data should be checked against that certificate; the
user should be given some visible information about the identity
associated with the certificate used to validate a signature and a
chance to accept or reject the signed data.

Do you intend to require Keyinfo in the Signature element?  Any
requirements on that?

Hilarie Orman




From owner-atom-syntax@mail.imc.org  Fri May 27 15:15:44 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17778
	for ; Fri, 27 May 2005 15:15: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 j4RJ4fi4011757;
	Fri, 27 May 2005 12:04: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 j4RJ4edh011756;
	Fri, 27 May 2005 12:04:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RJ4d3g011666
	for ; Fri, 27 May 2005 12:04:39 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta03-winn.mailhost.ntl.com ([212.250.162.8])
          by mta10-winn.mailhost.ntl.com with ESMTP
          id <20050527190433.ECJR20297.mta10-winn.mailhost.ntl.com@aamta03-winn.mailhost.ntl.com>;
          Fri, 27 May 2005 20:04:33 +0100
Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41])
          by aamta03-winn.mailhost.ntl.com with ESMTP
          id <20050527190433.STMF2626.aamta03-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>;
          Fri, 27 May 2005 20:04:33 +0100
Date: Fri, 27 May 2005 20:04:31 +0100
From: David Powell 
X-Mailer: The Bat! (v3.5.0.16) Professional
X-Priority: 3 (Normal)
Message-ID: <1822789518.20050527200431@djpowell.net>
To: Eric Scheid 
CC: Atom Syntax 
Subject: Re: protocol-04 first reading
In-Reply-To: 
References: <2750.82.127.77.43.1117176542.squirrel@ssl-webmail.sitadelle.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



Friday, May 27, 2005, 7:18:40 PM, Eric Scheid wrote:

> On 27/5/05 4:49 PM, "Thomas Broyer"  wrote:

>> Replace "format-08" with "protocol-04" and you get it ;o)
>> http://ietf.org/internet-drafts/draft-ietf-atompub-protocol-04.txt

> except I've been getting format-nn from http://atompub.org/... ;-)

The HTML version and the diffs seem to be here:



-- 
Dave



From owner-atom-syntax@mail.imc.org  Fri May 27 16:09:53 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28541
	for ; Fri, 27 May 2005 16:09: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 j4RK2SSf037594;
	Fri, 27 May 2005 13:02: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 j4RK2Slx037592;
	Fri, 27 May 2005 13:02:28 -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] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RK2JWC037435;
	Fri, 27 May 2005 13:02:20 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <200505271857.j4RIvIFC000311@tobermory.localdomain>
References: <200505271857.j4RIvIFC000311@tobermory.localdomain>
Date: Fri, 27 May 2005 13:02:17 -0700
To: "The Purple Streak, Hilarie Orman" , atom-syntax@imc.org
From: Paul Hoffman 
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
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:57 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
>Do you intend to require Keyinfo in the Signature element?  Any
>requirements on that?

In the base format spec, we are simply relying on XMLDigSig. If that 
turns out to be insufficient, we'll certainly add advice about what 
signed feeds and entries should do.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Fri May 27 16:37:16 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01871
	for ; Fri, 27 May 2005 16:37: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 j4RKUZcK043408;
	Fri, 27 May 2005 13:30: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 j4RKUZlJ043407;
	Fri, 27 May 2005 13:30:35 -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 j4RKUYhV043376
	for ; Fri, 27 May 2005 13:30:34 -0700 (PDT)
	(envelope-from jasnell@gmail.com)
Received: by wproxy.gmail.com with SMTP id 70so1884117wra
        for ; Fri, 27 May 2005 13:30:29 -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=TZhphcKsLOzDilmMCopvPIShuqa9v94idFCunjSAdA+6ZMC8ZD61gqZL6YYBvdnSm/biVL1+hVrDX727qV+H2Sl7bXLNrDJgm19vW3kke9qAJ30iUtQuMqmWUZg6wgcEyFMEkcvH4st2utikz3NY+hM9mNoNx6qLqvVMpp/FvZ0=
Received: by 10.54.145.14 with SMTP id s14mr1805467wrd;
        Fri, 27 May 2005 13:30:28 -0700 (PDT)
Received: from ?192.168.1.102? ([67.181.223.222])
        by mx.gmail.com with ESMTP id 28sm621276wrl.2005.05.27.13.30.28;
        Fri, 27 May 2005 13:30:28 -0700 (PDT)
Message-ID: <42978350.6010008@gmail.com>
Date: Fri, 27 May 2005 13:30:08 -0700
From: James M Snell 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray , atom-syntax@imc.org
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
References: <4297659D.70400@gmail.com> <9E8AB1EB-8E64-445C-866D-48852C2C4162@sun.com>
In-Reply-To: <9E8AB1EB-8E64-445C-866D-48852C2C4162@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:

> On May 27, 2005, at 11:23 AM, James M Snell wrote:
>
>> In general, the idea of associating the signing keys with the  
>> network resource (feed or entry document URI) makes a lot of sense  
>> but I think there may be some issues there with aggregate feeds and  
>> intermediaries (e.g. Feedburner) that would need to be worked out.  
>> In any case, this is definitely something that should be worked up.  
>> If there is interest in coming up with a ID on the topic, I  
>> volunteer to help write it up. The question is whether or not this  
>> list is the right place to discuss extensions like this or whether  
>> we should take this offline?
>
>
> I think that this list is the perfect place to discuss this stuff,  
> the people who care are here.
>
> Also, until we get AtomPubIssuesList cleaned up and the format I-D  
> filed, the WG is kind of between tasks, so now is a good time.   -Tim
>
>
Excellent.

Ok, so given that, continuing on what Paul and Bob have already put forward:

Associating the keys with the feed rather than with the individual is 
goodness.  The issue of how we establish trust of those keys is going to 
be the sticking point (as always). 

 >>    * The much simpler method of the feed including an extension element
 >>that identifies its signing keys -- it could either point to a file 
or to a
 >>key server.
 >Much simpler, but completely insecure. :-) It's a self-signed 
attestation that
 >has to be verified by out-of-band means that, from a security 
standpoint, are
 >equivalent to the first if done right and horribly dangerous if done 
wrong.
 >Having said that, I support the latter more than the former, and believe
 >that >90% of signed feeds that people actually use will follow that 
model.

Agreed that the second approach is better, but both approaches should be 
supported (that is, it should still be possible to use certificates 
issued by a centralized CA).  Can we articulate the right and wrong ways 
of doing the second option?

Other important questions that need hashing out (just throwing these out 
as I think of 'em for discussion)

1. What is being signed?  In a feed document, is it the entire feed, the 
collection of entries as a whole, individual entries, entry metadata, 
etc. and where does the signature go?  
? ?
2. What is the purpose of the signature?  That is, is it saying "This 
feed/entry really was generated by x" or is it saying "This entry really 
did come from source x".  If the latter, how do we authenticate the 
origin of "source x"?
3. What about aggregate feeds (e.g. feeds produced by intermediaries 
that contains entries from multiple sources, some set of which may have 
already been signed by the source generator).
4. How should intermediaries handle signatures?  For example, what 
should happen if someone asks Feedburner to augment a digitally signed 
feed?  Is FeedBurner a client that is generating a new feed from the 
source original (and therefore may or may not be required to produce a 
new signature) or is FeedBurner modifying the existing feed and required 
to pass along the existing signatures in tact?
5. What are the validation requirements?  How should clients handle 
feeds/entries that don't validate?

- James



From owner-atom-syntax@mail.imc.org  Fri May 27 17:14:24 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04804
	for ; Fri, 27 May 2005 17:14: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 j4RL7Qaa053552;
	Fri, 27 May 2005 14:07: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 j4RL7Q4u053542;
	Fri, 27 May 2005 14:07:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.rfburst.com ([66.119.143.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RL7Ppj053530;
	Fri, 27 May 2005 14:07:25 -0700 (PDT)
	(envelope-from ho@alum.mit.edu)
Received: from tobermory.localdomain ([66.119.143.202])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j4RL7JTq029755;
	Fri, 27 May 2005 15:07:19 -0600
Received: from tobermory.localdomain (localhost [127.0.0.1])
	by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id j4RL7Hwq005472;
	Fri, 27 May 2005 15:07:17 -0600
Received: (from ho@localhost)
	by tobermory.localdomain (8.12.10/8.12.10/Submit) id j4RL7H8P005468;
	Fri, 27 May 2005 15:07:17 -0600
Date: Fri, 27 May 2005 15:07:17 -0600
Message-Id: <200505272107.j4RL7H8P005468@tobermory.localdomain>
From: "The Purple Streak, Hilarie Orman" 
To: phoffman@imc.org
Cc: atom-syntax@imc.org
In-reply-to: Yourmessage 
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-MailScanner-From: ho@alum.mit.edu
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Fri, 27 May 2005 at 13:02:17 -0700 Paul Hoffman spoke thusly:

>  At 12:57 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
>  >Do you intend to require Keyinfo in the Signature element?  Any
>  >requirements on that?

>  In the base format spec, we are simply relying on XMLDigSig. If that 
>  turns out to be insufficient, we'll certainly add advice about what 
>  signed feeds and entries should do.

>  --Paul Hoffman, Director
>  --Internet Mail Consortium

The Key Info is part of the XMLDigSig, but it is not required.  Because
it tells you where and how to obtain the pertinent certificate, it
could be a boon for this particular application.  There is no need
to keep the signer secret, so I'd think it should be required.

It doesn't solve the chain-of-trust problem, though.

Hilarie



From owner-atom-syntax@mail.imc.org  Fri May 27 22:11:09 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23148
	for ; Fri, 27 May 2005 22:11: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 j4S1sLtL056650;
	Fri, 27 May 2005 18:54: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 j4S1sLH2056649;
	Fri, 27 May 2005 18:54:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42208.mail.yahoo.com (web42208.mail.yahoo.com [66.218.93.209])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4S1sKK8056627
	for ; Fri, 27 May 2005 18:54:20 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 4360 invoked by uid 60001); 28 May 2005 01:54:15 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=RUsse3/vOI6NEMDgOVLyT6QHdC2Ei8BiXmccYfCFBjlvlSXMUSUjvtynBY8vT47DjZJOP65CilPNTxC7EgiTAJQJX/horvJg4JMa651G+EorIuZlqWLcbHyFqoZ4TrTV5E6XG4Gdu84RdG6AQn1gM9vekRFHgOvWY5V/HglUNHw=  ;
Message-ID: <20050528015415.4358.qmail@web42208.mail.yahoo.com>
Received: from [4.155.69.226] by web42208.mail.yahoo.com via HTTP; Fri, 27 May 2005 18:54:15 PDT
Date: Fri, 27 May 2005 18:54:15 -0700 (PDT)
From: James Cerra 
Subject: atom, xslt processors (Re: atom:type, xsl:output)
To: "A. Pagaltzis" , Atom WG ,
        Henri Sivonen 
In-Reply-To: 6667
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: 


Aristotle, Henri Sivonen,

> > > Entities can be flattened.
> > 
> > Again, as with comments, I agree in principle, but in practice
> > some processors depend on them.
> 
> I do not consider it at all wise to legislate anything in the
> Atom spec to address these cases.

That's probably a good idea.

> Nothing prevents anyone from writing a generator or pre- or
> postprocessor for Atom documents to cater to the needs of their
> particular brand of broken software. Wrangling that particular
> piece of broken software however is their job; not ours nor the
> Atom specs.

Yes, but any Atom document MUST be processable from just an XML processor, an
 processor, among other specs it uses, and possiblely produce
something that can be transformed Atom's processing model allows.  This is
because:

(1) The first stage of an Atom processor will probably be an XML processor.

(2) RSS and Atom documents are now processed with  PIs, and
there is no way to formally specify when those instructions should be executed
(except for specific instances that don't matter here).  So any
 nodes, and PI nodes in general, must be assumed to be
linked to the document as a whole; I know of no standard granularity mechanism.
 

That's one reason the following is not true:

> Vanilla XML processors don't act on PIs. They report them to the 
> application--in this case the Atom processor.

Instead, they could be reported to the PI processor before the atom processor. 
In my mind, any Atom processor (or any language-specific processor) has to sit
on top of several other ones:

IO Processor
XML Processor
PI Processors
Atom Processor

An example of an IO processor is an HTTP processor: it reads Atom documents. 
An example of a PI processor is an XSLT processor or CSS renderer.  Forcing the
Atom Processor to be first is practically impossible and counter to the reason
for writing generic processors for IO, XML or PIs at all.



--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/



From owner-atom-syntax@mail.imc.org  Fri May 27 22:46:36 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25101
	for ; Fri, 27 May 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 j4S2SAEC064712;
	Fri, 27 May 2005 19:28: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 j4S2SAqr064711;
	Fri, 27 May 2005 19:28:10 -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 j4S2SAxY064704
	for ; Fri, 27 May 2005 19:28:10 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 42968 invoked by uid 60001); 28 May 2005 02:28:05 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=PrYL/KOLUprztrvc+jbffv5JBRQueokqI6oYQUm9p73bF8YtOGPbJbKkHpWWA45zjmN+nUSxx/MzMhjk3OsQ5GWnQCG7VEkdKBOywvFnQ79wsoY7e7a9TgAAUrXoA8+3piVS0+QnYpM5o7duyq36J2VOHlLDAe84K9JYjNYbfsA=  ;
Message-ID: <20050528022805.42966.qmail@web42204.mail.yahoo.com>
Received: from [4.155.69.226] by web42204.mail.yahoo.com via HTTP; Fri, 27 May 2005 19:28:05 PDT
Date: Fri, 27 May 2005 19:28:05 -0700 (PDT)
From: James Cerra 
Subject: Re: atom:type, xsl:output
To: Henri Sivonen 
Cc: Atom WG 
In-Reply-To: 
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: 


Henri Sivonen,

> > Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still 
> > inappropriately
> > use comments for that purpose.
> 
> I am not familiar with that. What purpose exactly? Why should Atom 
> support it?

MSIE conditional comments.  See other person's reply.

> > Then there are example XML documents (i.e. for tutorials) that 
> > sometimes require comments be preserved.
> 
> If you want people to read the source as is, it would make sense to 
> make it text/plain or put the source snippets in  or 
 in an 
> (X)HTML tutorial.

Except when it is a live example.  Or when posting XHTML or XML content that is
intended to be embedded (via object element) as a seperate, child document.  It
seems silly to allow anything NOT xml to be embedded unmodified (i.e. PNGs,
sounds), while no XML content can have that guarantee.

And yes: I know that Atom is not FTP or HTTP.  I'm looking at the Atom entry
uploader's POV rather than the downloader's perspective.  The Atom API is a way
to simplify managing web sites: it would be silly to make it unusable for
associating XML in general while allowing any other type to be unmodified.

> > Finally if you are posting content associated with an entry with the 
> > Atom API, then it is important that any documents uploaded are not 
> > modified.
> 
> I think Atom processors should not be required to preserve 
> serialization artifacts. That is, IMO, they should not be required to 
> care about anything that is not exposed via SAX2 ContentHandler with 
> qNames ignored.

So do I.  That's why the spec should state that any XML fragments embedded into
atom:content as an XML tree become part of that tree.  So PIs become associated
with the Atom document rather than the content, for example.  If the entry MUST
be preserved unmodified (Author's intention), the spec should either specify
that it must be associated externally via @src or encoded via entities or
base64 like any other non-xml-compatible formats in the current draft.


> Vanilla XML processors don't act on PIs. They report them to the 
> application--in this case the Atom processor.

So Atom Processors MUST be between any XML and PI processor stages?  That
sucks!  It means just to display Atom, I can't use a generic XSLT processor
like Saxon or MSIE.

> Depending on an entity reference and not being able to accept the 
> straight replacement text is just wrong.

I agree.  I'm just bringing up possible incompatibilities for debate!

> >>> DOCTYPE declaration(s)
> >>
> >> If DOCTYPE is essential for the receiving app, you've got bigger
> >> problems than Atom. Hardwiring IDness based on namespaces is more
> >> practical than relying on DTD-based data typing.
> >
> > I'm not necessarily talking about external document type definitions.
> > Preventing DOCTYPEs would cause incompatibilities with XML 
> > well-formedness
> > processing.  From the spec:
> >
> > "[Definition: While they are not required to check the document for 
> > validity,
> > they are REQUIRED to process all the declarations they read in the 
> > internal DTD
> > subset and in any parameter entity that they read, up to the first 
> > reference to
> > a parameter entity that they do not read; that is to say, they MUST 
> > use the
> > information in those declarations to normalize attribute values, 
> > include the
> > replacement text of internal entities, and supply default attribute 
> > values.]"
> 
> That's a non-issue. You don't just throw away the DOCTYPE but parse the 
> original document with it and reserialize as a DOCTYPEless fragment. 
> You don't lose well-formedness or content. You only lose the shallow 
> attribute data typing provided by the DTD.

Well, that data could be valuable.  Some situations require them, and it would
be really nice to have optional DOCTYPE info kept with the fragment.  With
DOCTYPE information associated with embedded content, it becomes possible to
transform entries into valid XML or HTML documents.  Some apps change their
behavior with well-formed and valid modes.  DOCTYPE switching may be evil, but
it is currently a necessary evil.  I see this as low risk (it doesn't break
anything and could even be an OPTIONAL feature) while easing the pain when
dealing with the existing web.

> Atom's main purpose is to facilitate software to software 
> communication. When interop or implementation ease and readability 
> conflict, readability should yield.

That's why I proposed they should be externally referenced (or base64ed), so
the Atom processor doesn't touch them!  This is a hint to authors on how to
avoid a common error.

> > There is nothing intrinsically bad about DOCTYPE sections
> 
> Yes, there is. On the Web you cannot trust that the recipient is using 
> an XML processor that processes the DOCTYPE beyond checking the 
> internal subset for well-formedness. An optional feature that does not 
> degrade gracefully when not supported is bad. DOCTYPE is such a 
> feature. In the cases where the DOCTYPE can be gracefully ignored, the 
> DOCTYPE is pointless.

No, any well formed XML processor MUST expand internal entities and add
replaced attributes as well.  This is NOT OPTIONAL.

> > Remember that anything compatible with XML MUST allow its optional 
> > features to
> > be in the markup (even if they are just ignored).  So if you disallow 
> > DOCTYPE
> > sections, then you can't claim to support XML.
> 
> Atom is not claiming that you could embed the literal source of any XML 
> doc. You can embed the stuff that canonicalization would preserve.

Yet you can do that with PNG, PDF, or other content via base 64 encodings.  It
is silly to allow that for them and not XML.

> > Anything that could have any chance of dataloss - in this case, the 
> > loss of XML
> > comments, PIs, and XML and DOCTYPE declarations  is bad.
> 
> Would you consider changes in the order of attributes and the white 
> space between attributes data loss as well?

I wouldn't in general, but XML never claimed to encode that data in the first
place.



--
Jimmy Cerra
https://nemo.dev.java.net

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From owner-atom-syntax@mail.imc.org  Sat May 28 04:55:16 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06613
	for ; Sat, 28 May 2005 04:55: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 j4S8adm7037733;
	Sat, 28 May 2005 01:36: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 j4S8adXC037732;
	Sat, 28 May 2005 01:36:39 -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 j4S8ac7c037710
	for ; Sat, 28 May 2005 01:36:39 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:53107
        "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net
        with ESMTP id S1228709AbVE1Igg (ORCPT );
        Sat, 28 May 2005 11:36:36 +0300
In-Reply-To: <20050528022805.42966.qmail@web42204.mail.yahoo.com>
References: <20050528022805.42966.qmail@web42204.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <13f3d68c6feb5435857698203ffc36a9@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: Atom WG 
From: Henri Sivonen 
Subject: Re: atom:type, xsl:output
Date:   Sat, 28 May 2005 11:36:16 +0300
To: James Cerra 
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 May 28, 2005, at 05:28, James Cerra wrote:

> Henri Sivonen,
>
>>> Yes, but MSIE^H^H^H^Hsome xml processors (cough  cough) still
>>> inappropriately
>>> use comments for that purpose.
>>
>> I am not familiar with that. What purpose exactly? Why should Atom
>> support it?
>
> MSIE conditional comments.  See other person's reply.

I thought they were for text/html tag soup only. Anyway, I think Atom 
should not try to enable such bogosity in XML.

> And yes: I know that Atom is not FTP or HTTP.  I'm looking at the Atom 
> entry
> uploader's POV rather than the downloader's perspective.  The Atom API 
> is a way
> to simplify managing web sites:

Is it really? Straight bytes over HTTP PUT seems a lot simpler to me 
than Base64 in an XML envelope over HTTP PUT.

>> Vanilla XML processors don't act on PIs. They report them to the
>> application--in this case the Atom processor.
>
> So Atom Processors MUST be between any XML and PI processor stages?  
> That
> sucks!  It means just to display Atom, I can't use a generic XSLT 
> processor
> like Saxon or MSIE.

What PIs do they act on besides the style sheet PI, which must appear 
in the prolog (so conforming tools should not act on it if it appears 
within atom:content)?

>> Depending on an entity reference and not being able to accept the
>> straight replacement text is just wrong.
>
> I agree.  I'm just bringing up possible incompatibilities for debate!

I don't think that's an incompatibility that deserves catering for.

>> That's a non-issue. You don't just throw away the DOCTYPE but parse 
>> the
>> original document with it and reserialize as a DOCTYPEless fragment.
>> You don't lose well-formedness or content. You only lose the shallow
>> attribute data typing provided by the DTD.
>
> Well, that data could be valuable.

IDness is. For practical purposes, the other stuff is not. There are 
other solutions for IDness.

> With DOCTYPE information associated with embedded content, it becomes 
> possible to
> transform entries into valid XML or HTML documents.

What do you need valid documents for if the validity is just an 
property internal to the document? That is, the document is valid 
according to its own rules as opposed to conforming to the rules 
required by some downstream software.

> Some apps change their behavior with well-formed and valid modes.

That seems like a bad idea. Can you give examples?

> DOCTYPE switching may be evil, but it is currently a necessary evil.

It is not a necessary evil for XML. I am strongly against any Atom 
feature motivated by or designed for enabling and/or encouraging 
doctype sniffing in XML.

Please see http://hsivonen.iki.fi/doctype/#xml

> I see this as low risk (it doesn't break anything and could even be an 
> OPTIONAL feature)

Optional features always have a cost. Also, they tend to become de 
facto mandatory for everyone or de facto useless for everyone.

>> Atom's main purpose is to facilitate software to software
>> communication. When interop or implementation ease and readability
>> conflict, readability should yield.
>
> That's why I proposed they should be externally referenced (or 
> base64ed), so
> the Atom processor doesn't touch them!  This is a hint to authors on 
> how to
> avoid a common error.

Base64 XML in XML was rejected earlier in the working group process.

>>> There is nothing intrinsically bad about DOCTYPE sections
>>
>> Yes, there is. On the Web you cannot trust that the recipient is using
>> an XML processor that processes the DOCTYPE beyond checking the
>> internal subset for well-formedness. An optional feature that does not
>> degrade gracefully when not supported is bad. DOCTYPE is such a
>> feature. In the cases where the DOCTYPE can be gracefully ignored, the
>> DOCTYPE is pointless.
>
> No, any well formed XML processor MUST expand internal entities and add
> replaced attributes as well.  This is NOT OPTIONAL.

So is expat non-conforming?

>> Atom is not claiming that you could embed the literal source of any 
>> XML
>> doc. You can embed the stuff that canonicalization would preserve.
>
> Yet you can do that with PNG, PDF, or other content via base 64 
> encodings.  It
> is silly to allow that for them and not XML.

Looks like straight HTTP without an Atom envelope in between suits your 
needs better.

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



From owner-atom-syntax@mail.imc.org  Sat May 28 05:02:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06917
	for ; Sat, 28 May 2005 05:02: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 j4S8jBo0040391;
	Sat, 28 May 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 j4S8jB2T040390;
	Sat, 28 May 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 smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S8jAbl040379
	for ; Sat, 28 May 2005 01:45:10 -0700 (PDT)
	(envelope-from hsivonen@iki.fi)
Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:53118
        "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net
        with ESMTP id S1228710AbVE1IpJ (ORCPT );
        Sat, 28 May 2005 11:45:09 +0300
In-Reply-To: <20050528015415.4358.qmail@web42208.mail.yahoo.com>
References: <20050528015415.4358.qmail@web42208.mail.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <92e6d7de9ef502e8444f0aed4db4aa16@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: Atom WG 
From: Henri Sivonen 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
Date:   Sat, 28 May 2005 11:45:06 +0300
To: James Cerra 
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 May 28, 2005, at 04:54, James Cerra wrote:

> Aristotle, Henri Sivonen,

> Yes, but any Atom document MUST be processable from just an XML 
> processor, an
>  processor,

A conforming xml-stylesheet processor will only act on the PI if it 
appears in the prolog. For this reason, it would be possible to allow 
xml-stylesheet PIs in atom:content and spec that they are part of the 
content document, so that an XML document with the PI in its prolog 
could be constructed from the content.

> (2) RSS and Atom documents are now processed with  
> PIs, and
> there is no way to formally specify when those instructions should be 
> executed
> (except for specific instances that don't matter here).

Perhaps it follows that you should not use xml-stylesheet if you don't 
want it to be acted upon.

> So any  nodes, and PI nodes in general, must be 
> assumed to be
> linked to the document as a whole;

Only if the PI appears in the prolog.

> That's one reason the following is not true:
>
>> Vanilla XML processors don't act on PIs. They report them to the
>> application--in this case the Atom processor.
>
> Instead, they could be reported to the PI processor before the atom 
> processor.

Why do you think it is appropriate to have a random PI processor in 
between the XML processor and the Atom processor?

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



From owner-atom-syntax@mail.imc.org  Sat May 28 05:08:05 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07141
	for ; Sat, 28 May 2005 05:08: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 j4S8qjL9042678;
	Sat, 28 May 2005 01: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 j4S8qj8s042676;
	Sat, 28 May 2005 01:52:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S8qiRd042632
	for ; Sat, 28 May 2005 01:52:44 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8])
          by mta10-winn.mailhost.ntl.com with ESMTP
          id <20050528085238.RPGM20297.mta10-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>;
          Sat, 28 May 2005 09:52:38 +0100
Received: from cpc3-stok1-5-0-cust41.bagu.cable.ntl.com ([82.11.128.41])
          by aamta02-winn.mailhost.ntl.com with ESMTP
          id <20050528085238.BOKY10462.aamta02-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust41.bagu.cable.ntl.com>;
          Sat, 28 May 2005 09:52:38 +0100
Date: Sat, 28 May 2005 09:52:30 +0100
From: David Powell 
X-Mailer: The Bat! (v3.5.21) Professional
X-Priority: 3 (Normal)
Message-ID: <554778667.20050528095230@djpowell.net>
To: Graham 
CC: atom-syntax 
Subject: Re: extension elements inside link elements?
In-Reply-To: 
References: 
 
 <68fba5c505052408075404b24f@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, May 24, 2005, 5:26:39 PM, you wrote:


> On 24 May 2005, at 4:07 pm, Robert Sayre wrote:

>> 4.2.9 (editorial):  The atom:link element is explicitly described as
>> empty, which violates the rules in 6 for foreign element extension.
>> Remove "is an empty element that".

> That's not an editorial change, that's newly allowing extension  
> elements in a place most people (such as Paul and myself) assumed  
> they weren't.

IF, the interpretation of Section 6, that Thomas Broyer has helped me
to hammered out is correct, then:

Extension Elements [6.4], in Atom 1.0, are allowed only as direct
children of atom:entry, atom:feed, Person Constructs, and atom:source.
They must be qualified with a namespace, and it mustn't be the atom
namespace. Extension Elements, atom:content, and atom:link/@rel are
the only User Extensions to Atom.

Future versions of Atom [6.2] may add additional elements to the Atom
namespace, may add attributes (namespaced or otherwise) to existing
Atom elements, and presumably may allow text inside Atom elements
(basically any markup that isn't in the spec or an Extension Element).
(Text as a 6.2 element isn't mentioned, but it probably ought to be
treated as 6.2 by clients.)

This is to allow Atom 1.0 implementations to be forward compatible
with future versions of Atom. Atom 1.0 implementations won't know how
to handle these elements and MUST ignore them, and MUST NOT forward
them. (they could be some sort of link-level control element; or they
might be an element that allows a relative URIRef, which would break
if it was dependant on the source document's base URI)

So, assuming that that description is roughly correct, and that we can
rework section 6 to make it easier to understand and unambiguous about
the difference between 6.2 and 6.4 markup, then I am +1 to removing
"is an empty element that", because it contradicts section 6.2 which
is supposed to apply everywhere.

-- 
Dave



From owner-atom-syntax@mail.imc.org  Sat May 28 05:11:03 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07235
	for ; Sat, 28 May 2005 05: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 j4S8qcqv042630;
	Sat, 28 May 2005 01:52: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 j4S8qcC9042629;
	Sat, 28 May 2005 01:52:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4S8qWmG042583
	for ; Sat, 28 May 2005 01:52:35 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000442124 for ; Sat, 28 May 2005 18:52:26 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sat, 28 May 2005 18:52:23 +1000
Subject: some xmlns:atom tomfoolery
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



An Atom Entry can have XML content, right...

Consider this example:


    ...
    
        the minimal Atom Entry
        A minimal entry has only ...
        
            
                ...
            
        
    


Entirely legal, but who wants to bet the feed validator throws a fit ;-)

e.



From owner-atom-syntax@mail.imc.org  Sat May 28 06:17:18 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10351
	for ; Sat, 28 May 2005 06:17: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 j4S9uLr1080365;
	Sat, 28 May 2005 02:56: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 j4S9uLJ4080364;
	Sat, 28 May 2005 02:56: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 (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4S9uJqX080320
	for ; Sat, 28 May 2005 02:56:20 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 28 May 2005 09:56:12 -0000
Received: from xdsl-213-196-245-163.netcologne.de (EHLO klangraum) [213.196.245.163]
  by mail.gmx.net (mp022) with SMTP; 28 May 2005 11:56:12 +0200
X-Authenticated: #163624
Date: Sat, 28 May 2005 11:59:55 +0200
From: "A. Pagaltzis" 
To: James Cerra 
Cc: Atom WG , Henri Sivonen 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
Message-ID: <20050528095955.GA20439@klangraum>
Mail-Followup-To: James Cerra ,
	Atom WG , Henri Sivonen 
References: <20050528015415.4358.qmail@web42208.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050528015415.4358.qmail@web42208.mail.yahoo.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: 8bit


* James Cerra  [2005-05-28 04:00]:
> > Nothing prevents anyone from writing a generator or pre- or
> > postprocessor for Atom documents to cater to the needs of
> > their particular brand of broken software. Wrangling that
> > particular piece of broken software however is their job; not
> > ours nor the Atom specs.
> 
> Yes, but any Atom document MUST be processable from just an XML
> processor, an  processor, among other specs
> it uses, and possiblely produce something that can be
> transformed Atom's processing model allows.  This is because:

Note that I wrote the above in reference to broken software that
depends on particular entities vs the literal character or on
specific comments, not in reference to PIs. That’s why I quoted
that part of the previous conversation which I quoted.

> (2) RSS and Atom documents are now processed with
>  PIs, and there is no way to formally specify
> when those instructions should be executed (except for specific
> instances that don't matter here).  So any 
> nodes, and PI nodes in general, must be assumed to be linked to
> the document as a whole; I know of no standard granularity
> mechanism.

I agree, but I see this as a problem with the xml-stylesheet PI
rather than as something that Atom must solve. You are right, of
course, that it would be prudent for the spec to legislate that
PIs which occur in atom:content with an XML payload should be
passed thru to the processor for that XML payload.

Btw, it might well be that the practice of attaching a stylesheet
goes out of fashion again in a year or two, if other browsers
follow Safari’s lead and acquire feed rendering capabilities.

> That's one reason the following is not true:
> 
> > Vanilla XML processors don't act on PIs. They report them to
> > the application--in this case the Atom processor.
> 
> Instead, they could be reported to the PI processor before the
> atom processor. In my mind, any Atom processor (or any
> language-specific processor) has to sit on top of several other
> ones:
> 
> IO Processor
> XML Processor
> PI Processors
> Atom Processor

I disagree. The typical setup, IMO, would be

1. IO Processor
2. XML Processor
3. Atom Processor
4a. Possibly a processor for that specific XML NS
4b. Possibly a PI Processor

where 4a might or might not itself act on specific PIs.

F.ex, I would expect that an Atom processor will disregard an
xml-stylesheet PI attached to a feed as a whole. But it might
apply an XSL transformation if it is told to process a document
which is not an Atom feed – under the assumption that this
transform might generate a valid feed document.

That’s still murky (and I have to go read up on xml-stylesheet
in detail to see how much room for interpretation it allows), but
all of this seems to indicate to me it’s that the semantics of
that particular PI which are ill thoughtout, rather than a
general problem with PI granularity.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Sat May 28 06:28:06 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10729
	for ; Sat, 28 May 2005 06:28: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 j4SAH9OY090440;
	Sat, 28 May 2005 03:17: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 j4SAH9Wo090439;
	Sat, 28 May 2005 03:17:09 -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 j4SAH7a3090300
	for ; Sat, 28 May 2005 03:17:08 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 56650 messnum 7066321 invoked from network[83.70.217.193/unknown]); 28 May 2005 10:17:00 -0000
Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193)
  by mail01.svc.cra.dublin.eircom.net (qp 56650) with SMTP; 28 May 2005 10:17:00 -0000
Message-ID: <4298451B.9060301@dehora.net>
Date: Sat, 28 May 2005 11:16:59 +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 Cerra 
CC: Henri Sivonen , Atom WG 
Subject: Re: atom:type, xsl:output
References: <20050528022805.42966.qmail@web42204.mail.yahoo.com>
In-Reply-To: <20050528022805.42966.qmail@web42204.mail.yahoo.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


James Cerra wrote:

> So do I.  That's why the spec should state that any XML fragments embedded into
> atom:content as an XML tree become part of that tree.  So PIs become associated
> with the Atom document rather than the content, for example.  If the entry MUST
> be preserved unmodified (Author's intention), the spec should either specify
> that it must be associated externally via @src or encoded via entities or
> base64 like any other non-xml-compatible formats in the current draft.


This is why MIME is still a good idea.

cheers
Bill




From owner-atom-syntax@mail.imc.org  Sat May 28 07:15:52 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14079
	for ; Sat, 28 May 2005 07:15: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 j4SAwSgN017989;
	Sat, 28 May 2005 03:58: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 j4SAwRUh017988;
	Sat, 28 May 2005 03:58: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 j4SAwPGg017948
	for ; Sat, 28 May 2005 03:58:26 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 28 May 2005 10:58:19 -0000
Received: from xdsl-213-196-245-163.netcologne.de (EHLO klangraum) [213.196.245.163]
  by mail.gmx.net (mp016) with SMTP; 28 May 2005 12:58:19 +0200
X-Authenticated: #163624
Date: Sat, 28 May 2005 13:02:02 +0200
From: "A. Pagaltzis" 
To: Atom Syntax 
Subject: Re: some xmlns:atom tomfoolery
Message-ID: <20050528110202.GA20970@klangraum>
Mail-Followup-To: Atom Syntax 
References: 
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-05-28 11:00]:
> An Atom Entry can have XML content, right...
> 
> Consider this example:
> 
> Entirely legal, but who wants to bet the feed validator throws
> a fit ;-)

Most aggregators will probably ignore the content, and likely not
even do anything useful with the entry.

Hmm. Escher Atom?

    
        The inifinite Atom Entry:
        Reflecting on myself.
        
    

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Sat May 28 07:19:11 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14249
	for ; Sat, 28 May 2005 07:19: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 j4SB4Rv3019827;
	Sat, 28 May 2005 04: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 j4SB4RCf019826;
	Sat, 28 May 2005 04:04:27 -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.79])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SB4QpC019787
	for ; Sat, 28 May 2005 04:04:27 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.32.249])
	by smtp.cegetel.net (Postfix) with ESMTP id 5C3751A423C;
	Sat, 28 May 2005 13:03:29 +0200 (CEST)
Message-ID: <42985037.70806@cegetel.net>
Date: Sat, 28 May 2005 13:04:23 +0200
From: Thomas Broyer 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: David Powell 
Cc: Graham , atom-syntax 
Subject: Re: extension elements inside link elements?
References:   <68fba5c505052408075404b24f@mail.gmail.com>  <554778667.20050528095230@djpowell.net>
In-Reply-To: <554778667.20050528095230@djpowell.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


David Powell wrote:

>IF, the interpretation of Section 6, that Thomas Broyer has helped me
>to hammered out is correct, then:
>
>Extension Elements [6.4], in Atom 1.0, are allowed only as direct
>children of atom:entry, atom:feed, Person Constructs, and atom:source.
>They must be qualified with a namespace, and it mustn't be the atom
>namespace.
>
Note that this kind of extension elements ("foreign markup" appearing in 
atom:feed, atom:entry, Person Constructs, and atom:source) is called 
Metadata Elements, because Atom states such extensions provide 
additional metadata to their container element (or more accurately 
additional metadata to the to the resource represented by the container 
element).

>Extension Elements, atom:content, and atom:link/@rel are the only User Extensions to Atom.
>  
>
No (for the definition of Extension Elements you gave above).

Atom allows foreign markup anywhere in an Atom document. Foreign markup 
is made of "extension elements" and "extension attributes" (i.e. 
anything not in the Atom namespace, except unprefixed attributes on 
Atom-namespaced elements). Atom doesn't define the role/interpretation 
of foreign markup except for those elements appearing in atom:feed, 
atom:entry, Person Constructs and atom:source, which it defines as 
Metadata Elements carrying additional metadata about their container 
element.

>Future versions of Atom [6.2] may add additional elements to the Atom
>namespace, may add attributes (namespaced or otherwise) to existing
>Atom elements,
>
If attributes are namespaced and the namespace is not the Atom 
namespace, they obviously are "foreign attributes" (at least for me).

>and presumably may allow text inside Atom elements (basically any markup that isn't in the spec or an Extension Element). (Text as a 6.2 element isn't mentioned, but it probably ought to be treated as 6.2 by clients.)
>  
>
I think that later allowing "just text" inside an Atom element would 
prove a design flaw...

At least, it should be made clear that an Atom 1.0 Processor MUST ignore 
text as a child of an element which Atom doesn't define as allowing 
text. (er, am I clear?)

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Sat May 28 12:26:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15204
	for ; Sat, 28 May 2005 12:26: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 j4SGFt9E003547;
	Sat, 28 May 2005 09:15: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 j4SGFtiE003546;
	Sat, 28 May 2005 09:15: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 j4SGFpMv003484
	for ; Sat, 28 May 2005 09:15:52 -0700 (PDT)
	(envelope-from rubys@intertwingly.net)
Received: from [192.168.1.102] (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 j4SGGC7t032403;
	Sat, 28 May 2005 12:16:12 -0400
Message-ID: <42989937.3040405@intertwingly.net>
Date: Sat, 28 May 2005 12:15:51 -0400
From: Sam Ruby 
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid 
CC: Atom Syntax 
Subject: Re: some xmlns:atom tomfoolery
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:
> 
> An Atom Entry can have XML content, right...
> 
> Consider this example:
> 
> 
>     ...
>     
>         the minimal Atom Entry
>         A minimal entry has only ...
>         
>             
>                 ...
>             
>         
>     
> 
> 
> Entirely legal, but who wants to bet the feed validator throws a fit ;-)

I'll take that bet.

- Sam Ruby



From owner-atom-syntax@mail.imc.org  Sat May 28 17:23:01 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04617
	for ; Sat, 28 May 2005 17:22: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 j4SL9iZW083798;
	Sat, 28 May 2005 14: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 j4SL9ibU083797;
	Sat, 28 May 2005 14:09:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mcom.com (c3po.aoltw.net [64.236.137.25])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SL9fQo083789
	for ; Sat, 28 May 2005 14:09:41 -0700 (PDT)
	(envelope-from jpanzer@aol.net)
Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47])
	by mcom.com (8.10.0/8.10.0) with ESMTP id j4SL9Kq02916
	for ; Sat, 28 May 2005 14:09:30 -0700 (PDT)
Received: from [10.146.2.5] ([10.146.2.5]) by judge.mcom.com
          (Netscape Messaging Server 4.15) with ESMTP id IH7XFJ03.42T;
          Sat, 28 May 2005 14:09:19 -0700 
Message-ID: <4298DDF8.60805@aol.net>
Date: Sat, 28 May 2005 14:09:12 -0700
From: jpanzer@aol.net (John Panzer)
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Scheid 
CC: Atom Syntax 
Subject: Re: some xmlns:atom tomfoolery
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:

>An Atom Entry can have XML content, right...
>
>Consider this example:
>
>
>    ...
>    
>        the minimal Atom Entry
>        A minimal entry has only ...
>        
>            
>                ...
>            
>  
>
Or perhaps:
                            
                                   ...
                            

:^)

>        
>    
>
>
>Entirely legal, but who wants to bet the feed validator throws a fit ;-)
>
>e.
>
>  
>



From owner-atom-syntax@mail.imc.org  Sat May 28 17:48:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06014
	for ; Sat, 28 May 2005 17:48: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 j4SLdbhR091995;
	Sat, 28 May 2005 14:39: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 j4SLdbVG091994;
	Sat, 28 May 2005 14:39:37 -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 j4SLdZQx091988
	for ; Sat, 28 May 2005 14:39: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 j4SLdZjO002897
	for ; Sat, 28 May 2005 15:39:35 -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 <0IH700H3NYTYJN@edgemail1.Central.Sun.COM> for
 atom-syntax@imc.org; Sat, 28 May 2005 15:39:35 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.204.6])
 by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
 with ESMTPSA id <0IH7000S8YTX8A@mail.sun.net> for atom-syntax@imc.org; Sat,
 28 May 2005 15:39:34 -0600 (MDT)
Date: Sat, 28 May 2005 14:39:46 -0700
From: Tim Bray 
Subject: Re: some xmlns:atom tomfoolery
In-reply-to: <4298DDF8.60805@aol.net>
To: John Panzer 
Cc: Eric Scheid ,
        Atom Syntax 
Message-id: <61873EF1-13DE-4184-8031-85B1C5FECDE6@sun.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: 
 <4298DDF8.60805@aol.net>
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7BIT


On May 28, 2005, at 2:09 PM, John Panzer wrote:

>>    
>>        the minimal Atom Entry
>>        A minimal entry has only ...
>>        
>>            
>>                ...
>>            
>>
>>
> Or perhaps:
>                            
>                                   ...
>                            

You guys are sick, evil, and twisted.  Snicker.   -Tim



From owner-atom-syntax@mail.imc.org  Sat May 28 18:18:47 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09149
	for ; Sat, 28 May 2005 18:18: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 j4SMArP0002354;
	Sat, 28 May 2005 15:10: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 j4SMArFU002353;
	Sat, 28 May 2005 15:10:53 -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] (user-2ivfj2p.dialup.mindspring.com [165.247.204.89])
	(authenticated bits=0)
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SMAgCJ002339;
	Sat, 28 May 2005 15:10:43 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <200505272107.j4RL7H8P005468@tobermory.localdomain>
References: <200505272107.j4RL7H8P005468@tobermory.localdomain>
Date: Sat, 28 May 2005 14:01:56 -0700
To: "The Purple Streak, Hilarie Orman" 
From: Paul Hoffman 
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
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 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
>The Key Info is part of the XMLDigSig, but it is not required.  Because
>it tells you where and how to obtain the pertinent certificate, it
>could be a boon for this particular application.  There is no need
>to keep the signer secret, so I'd think it should be required.

This is the kind of thing we can do in the implementer's guidelines.

>It doesn't solve the chain-of-trust problem, though.

Nothing does :-) . Or is that :-( ?

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Sat May 28 20:00:22 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13211
	for ; Sat, 28 May 2005 20:00: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 j4SNp6In025652;
	Sat, 28 May 2005 16:51: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 j4SNp6PF025650;
	Sat, 28 May 2005 16:51:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail.rfburst.com ([66.119.143.56])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SNp6Jb025638;
	Sat, 28 May 2005 16:51:06 -0700 (PDT)
	(envelope-from ho@alum.mit.edu)
Received: from tobermory.localdomain ([66.119.143.202])
	by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j4SNowTq021219;
	Sat, 28 May 2005 17:50:59 -0600
Received: from tobermory.localdomain (localhost [127.0.0.1])
	by tobermory.localdomain (8.12.10/8.11.6) with ESMTP id j4SNmXwq002050;
	Sat, 28 May 2005 17:48:33 -0600
Received: (from ho@localhost)
	by tobermory.localdomain (8.12.10/8.12.10/Submit) id j4SNmXf4002046;
	Sat, 28 May 2005 17:48:33 -0600
Date: Sat, 28 May 2005 17:48:33 -0600
Message-Id: <200505282348.j4SNmXf4002046@tobermory.localdomain>
From: "The Purple Streak, Hilarie Orman" 
To: phoffman@imc.org
Cc: atom-syntax@imc.org
In-reply-to: Yourmessage 
Subject: Re: [Fwd: Re: Signatures - I blog, therefore I am...]
X-esmartscan-MailScanner-Information: Please contact the ISP for more information
X-esmartscan-MailScanner: Found to be clean
X-MailScanner-From: ho@alum.mit.edu
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Sat, 28 May 2005 at 14:01:56 -0700 Paul Hoffman opined:

>  At 3:07 PM -0600 5/27/05, The Purple Streak, Hilarie Orman wrote:
>  >The Key Info is part of the XMLDigSig, but it is not required.  Because
>  >it tells you where and how to obtain the pertinent certificate, it
>  >could be a boon for this particular application.  There is no need
>  >to keep the signer secret, so I'd think it should be required.

>  This is the kind of thing we can do in the implementer's guidelines.

It's more like an actual law than a guideline :-) You couldn't
possibly write a compliant implementation for checking signatures
without knowing how to get the certificate that goes with a signed
entry, so it seems to be a fundamental part of the design, not an
implementation guideline.

>  >It doesn't solve the chain-of-trust problem, though.

>  Nothing does :-) . Or is that :-( ?

Yes to both.  Sweet and sour.

But what is the intent of the signature?  It should be to validate that
some entity, having some relationship to the signed entry, declared
that at some time, it was authentic.  How can a checker decide that
the entity has an appropriate relationship?  If the signer doesn't
know this, then the signature might hamper interoperability.

Hilarie



From owner-atom-syntax@mail.imc.org  Sun May 29 05:45:05 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05757
	for ; Sun, 29 May 2005 05:45: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 j4T9acSN035661;
	Sun, 29 May 2005 02:36: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 j4T9acup035660;
	Sun, 29 May 2005 02:36:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from ironclad.net.au ([203.30.247.11])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4T9aXxG035613
	for ; Sun, 29 May 2005 02:36:36 -0700 (PDT)
	(envelope-from eric.scheid@ironclad.net.au)
Received: from [203.30.247.2] (HELO [10.0.1.2]) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0000446563 for ; Sun, 29 May 2005 19:34:55 +1000
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Sun, 29 May 2005 19:36:29 +1000
Subject: Re: some xmlns:atom tomfoolery
From: Eric Scheid 
To: Atom Syntax 
Message-ID: 
In-Reply-To: <4298DDF8.60805@aol.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 29/5/05 7:09 AM, "John Panzer"  wrote:

>>        
>>            
>>                ...
>>            
>>  
>> 
> Or perhaps:
>                           
>                                  ...
>                           
> 
> :^)
> 
>>        


hmmm... seriously though, that's one way to provide a package of multipart
content. An example might be a play list. A bit of difficulty subscribing to
that feed though ;-)

e.



From owner-atom-syntax@mail.imc.org  Sun May 29 19:56:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07283
	for ; Sun, 29 May 2005 19:56: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 j4TNm1c4094117;
	Sun, 29 May 2005 16:48: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 j4TNm1Dw094115;
	Sun, 29 May 2005 16:48:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42205.mail.yahoo.com (web42205.mail.yahoo.com [66.218.93.206])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4TNm0p3093921
	for ; Sun, 29 May 2005 16:48:00 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 28025 invoked by uid 60001); 29 May 2005 23:47:54 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=gXkMz073KMeHl0UgFMlFMbr9bEubdQyIaXc+NPwd9K9MCUQGyCs4NDb7MuKrTaz/oecx44cdXW0h5LQir+MhRP3PDjrdm8GfR76gPrWARo4TkU6nTRzjsjDJkEHLjgn0kttYHhOXao8MVVSTPIyYK7RvDWZ+RF4C+QrJMTu9sC4=  ;
Message-ID: <20050529234754.28023.qmail@web42205.mail.yahoo.com>
Received: from [136.142.20.97] by web42205.mail.yahoo.com via HTTP; Sun, 29 May 2005 16:47:54 PDT
Date: Sun, 29 May 2005 16:47:54 -0700 (PDT)
From: James Cerra 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
To: Henri Sivonen 
Cc: Atom WG 
In-Reply-To: 6667
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: 


Henri Sivonen,

> A conforming xml-stylesheet processor will only act on the PI if it 
> appears in the prolog. For this reason, it would be possible to allow 
> xml-stylesheet PIs in atom:content and spec that they are part of the 
> content document, so that an XML document with the PI in its prolog 
> could be constructed from the content.

You are correct.  I forgot that part of the spec and should have re-read it.

One possible area of incompatibility is where the xml-stylesheet spec says that
they are only allowed in the prolog (as you stated as well).  So if any are in
the application/xml atom:content, then they could be flagged as errors.  The
spec doesn't say whether they must or should be considered errors or warnings. 
:-(

> >> Vanilla XML processors don't act on PIs. They report them to the
> >> application--in this case the Atom processor.
> >
> > Instead, they could be reported to the PI processor before the atom 
> > processor.
> 
> Why do you think it is appropriate to have a random PI processor in 
> between the XML processor and the Atom processor?

Because the XML is just the grammar serializing the ontology, or data
structure, of interest.  I see Atom processors as normally the Bridge between
the XML document and the particular CMS, IA, or web browser application's
internal structure.  So an Atom processor would be the last stage before the
data is internalized.  The intent of _Processing_ Instructions seems to change
how the document is processed.  That implies to me that they would probably be
interpreted between the XML processor and the particular grammar's processor.


--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/



From owner-atom-syntax@mail.imc.org  Sun May 29 20:30:21 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09439
	for ; Sun, 29 May 2005 20:30: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 j4U0OkDX003329;
	Sun, 29 May 2005 17:24: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 j4U0Ojr1003328;
	Sun, 29 May 2005 17:24:45 -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 j4U0Ojvo003320
	for ; Sun, 29 May 2005 17:24:45 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 66980 invoked by uid 60001); 30 May 2005 00:24:40 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=AYP/CwobgJ6LT8nfpMm3Ll5ucetzwBKpkEJleRmbDYf/RBQSIh12hyVFK4eOf2bMIZ9RWaeatpkpdi3QLsksEu7bCz7soSa0MbwK++PHrwXt+7PauCdZIDGAxgI0+iXiZrWCcRDR+qRJ3gCAyZAdeE5wMUt+5YH2vvvs0kpqqq0=  ;
Message-ID: <20050530002440.66978.qmail@web42204.mail.yahoo.com>
Received: from [136.142.20.97] by web42204.mail.yahoo.com via HTTP; Sun, 29 May 2005 17:24:40 PDT
Date: Sun, 29 May 2005 17:24:40 -0700 (PDT)
From: James Cerra 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
To: "A. Pagaltzis" 
Cc: Atom WG , Henri Sivonen 
In-Reply-To: 6667
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: 


Aristotle,

> > (2) RSS and Atom documents are now processed with
> >  PIs, and there is no way to formally specify
> > when those instructions should be executed (except for specific
> > instances that don't matter here).  So any 
> > nodes, and PI nodes in general, must be assumed to be linked to
> > the document as a whole; I know of no standard granularity
> > mechanism.
> 
> I agree, but I see this as a problem with the xml-stylesheet PI
> rather than as something that Atom must solve. You are right, of
> course, that it would be prudent for the spec to legislate that
> PIs which occur in atom:content with an XML payload should be
> passed thru to the processor for that XML payload.

Note that I was wrong about  though I still believe the
property holds for PIs in general.

I think that *all* PIs in the XML document should be considered readable - and
therefor dangerous - before the Atom processor does its magic of informing the
application about the feed's ontology.  Letting ONLY escaped (either into
strings or with base64 encoding) content of atom:content, or documents linked
via @href, is one way to allow literal, complete XML documents as content (and
not just XML fragments).  This gives them the same treatment as any non-XML
content like images or sounds.  OTOH for XML fragments, I think it would be
nice to allow the content to be a child of atom:content, as currently possible.

> > Instead, they could be reported to the PI processor before the
> > atom processor. In my mind, any Atom processor (or any
> > language-specific processor) has to sit on top of several other
> > ones:
> > 
> > IO Processor
> > XML Processor
> > PI Processors
> > Atom Processor
> 
> I disagree. The typical setup, IMO, would be
> 
> 1. IO Processor
> 2. XML Processor
> 3. Atom Processor
> 4a. Possibly a processor for that specific XML NS
> 4b. Possibly a PI Processor
> 
> where 4a might or might not itself act on specific PIs.
> 
> F.ex, I would expect that an Atom processor will disregard an
> xml-stylesheet PI attached to a feed as a whole. But it might
> apply an XSL transformation if it is told to process a document
> which is not an Atom feed – under the assumption that this
> transform might generate a valid feed document.

I disagree.  I see any XML application conceptually as a transformer from the
XML processor's trees or events to the internal data structure of the
application.  To use an analogy, I see an XML processor as a lexer and the
grammar's processor as the parser - substituting tokens for XML objects (i.e.
elements with names, attributes, children, base uri, etc.).  XSLT is a case
when the grammar's processor's output are XML objects that can be parsed by
another grammar's processor without having to use an XML processor.  So I see
an Atom processor as taking XML objects and producing an ontology to be
converted into the program's internal data structure.  This is the abstraction
I use; practically the details are usually different (though compatible with
that abstraction).

For a counter example: For internal use I might create an Atom feed from atom
entries with  attached to either the feed or the entries. 
Furthermore, I could add instructions for my stylesheet by defining PIs used in
the entries.  In this case, the PI processor is an xslt processor that works
before the atom processor.  The original contains global options and defines
the template, while the entries are parsed and aggregated into the original
file.  This way it is easier to change the feed's options without editing the
XSLT source files.  The atom processor becomes the last stage in the pipe.



--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs



From owner-atom-syntax@mail.imc.org  Sun May 29 21:15:49 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12129
	for ; Sun, 29 May 2005 21:15: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 j4U18mVm006560;
	Sun, 29 May 2005 18:08: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 j4U18m1g006559;
	Sun, 29 May 2005 18:08:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42202.mail.yahoo.com (web42202.mail.yahoo.com [66.218.93.203])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4U18lA4006551
	for ; Sun, 29 May 2005 18:08:47 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 30817 invoked by uid 60001); 30 May 2005 01:08:36 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=SvjWBuj8t77ygD12AVpkmAGGa0b7YOQ6hKvQAq90XXueJ9DncrwoMqm+6JIZM2tSCETV6tqrnulGNzuPhL4lMCxQNUru7BrBVZE6sH7IGxfmbtiagCWGbxn7Oyhhph1pC+25P45EpZpx5ka1i5yu1o2DE3yqc4uGWhkh9FJQLF4=  ;
Message-ID: <20050530010836.30815.qmail@web42202.mail.yahoo.com>
Received: from [136.142.22.218] by web42202.mail.yahoo.com via HTTP; Sun, 29 May 2005 18:08:36 PDT
Date: Sun, 29 May 2005 18:08:36 -0700 (PDT)
From: James Cerra 
Subject: Re: atom:type, xsl:output
To: Henri Sivonen 
Cc: Atom WG 
In-Reply-To: <13f3d68c6feb5435857698203ffc36a9@iki.fi>
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: 


Henri Sivonen,

> > MSIE conditional comments.  See other person's reply.
> 
> I thought they were for text/html tag soup only. Anyway, I think Atom 
> should not try to enable such bogosity in XML.

I don't think Atom should take a position if it doesn't have to.

> > And yes: I know that Atom is not FTP or HTTP.  I'm looking at the Atom 
> > entry
> > uploader's POV rather than the downloader's perspective.  The Atom API 
> > is a way
> > to simplify managing web sites:
> 
> Is it really? Straight bytes over HTTP PUT seems a lot simpler to me 
> than Base64 in an XML envelope over HTTP PUT.

In this case, the simplier grammar option is a more complex job.  First, Atom
already supports this with every other MIME type including HTML, but not
anything that is XML.  Why?  Second, if your content is a literal document of
*any* type then:

** steps with envelope **
1. PUT doc-with-envelope.atom to http://uri1.com.
2. PUT doc-with-envelope.atom to http://uri2.com with user, pass.

** steps without envelope **
1. PUT doc-referencing-uri1.atom to http://uri1.com.
2. PUT image.png to http://uri1.com/images/image.png.
3. Modify doc-referencing-uri1.atom to reference uri2.
4. PUT doc-referencing-uri2.atom to http://uri2.com with user, pass.
5. PUT image.png to http://uri2.com/_title_of_entry_/image.png with user, pass.

That is, including it in an atom:content element and sending that off to the
server allows you to send that off to another server with ***only changing the
Atom document's PUT uri*** rather than sending the external document according
to each server's implementation (i.e. uri or other means).  Having a standard
way of sending files for a blog - like a picture blog for instance - is really
nice.  Otherwise it is much harder to change servers or atom processors.

> >> Vanilla XML processors don't act on PIs. They report them to the
> >> application--in this case the Atom processor.
> >
> > So Atom Processors MUST be between any XML and PI processor stages?  
> > That
> > sucks!  It means just to display Atom, I can't use a generic XSLT 
> > processor
> > like Saxon or MSIE.
> 
> What PIs do they act on besides the style sheet PI, which must appear 
> in the prolog (so conforming tools should not act on it if it appears 
> within atom:content)?

You are correct about  but in general there could be others. 
XSLT stylesheets can use them for flexibility, for example.  Better not to make
assumptions about their behavior.

> >> Depending on an entity reference and not being able to accept the
> >> straight replacement text is just wrong.
> >
> > I agree.  I'm just bringing up possible incompatibilities for debate!
> 
> I don't think that's an incompatibility that deserves catering for.

Why not?  Why be incompatible for the sake of incompatibility?  That's just
asking for trouble when Atom is used in ways not originally envisioned (and
there always are).

> >> That's a non-issue. You don't just throw away the DOCTYPE but parse 
> >> the
> >> original document with it and reserialize as a DOCTYPEless fragment.
> >> You don't lose well-formedness or content. You only lose the shallow
> >> attribute data typing provided by the DTD.
> >
> > Well, that data could be valuable.
> 
> IDness is. For practical purposes, the other stuff is not. There are 
> other solutions for IDness.

I don't understand why?

> > With DOCTYPE information associated with embedded content, it becomes 
> > possible to
> > transform entries into valid XML or HTML documents.
> 
> What do you need valid documents for if the validity is just an 
> property internal to the document? That is, the document is valid 
> according to its own rules as opposed to conforming to the rules 
> required by some downstream software.

Valid as in, this is valid HTML 3.2 or that is valid HTML 5 or this is valid
HTML 4.01 transitional.  Right now it is impossible to specify that for
atom:content[@type="html"] content, but that doctype information is esssencial
for properly interpreting the semantics of the HTML content, and possibly how
to write it out as a web page.  :-(  If you make me guessing I'll go mad!  :-)

> > Some apps change their behavior with well-formed and valid modes.
> 
> That seems like a bad idea. Can you give examples?
> 
> > DOCTYPE switching may be evil, but it is currently a necessary evil.
> 
> It is not a necessary evil for XML. I am strongly against any Atom 
> feature motivated by or designed for enabling and/or encouraging 
> doctype sniffing in XML.
> 
> Please see http://hsivonen.iki.fi/doctype/#xml

See reply immediately above.  HTML currently uses doctypes for switching
between versions of the langauage.  There is no other way to properly interpret
content without guessing in the current drafts.  That is a worse sin inflicted
upon programmers, than allowing the subset that do rendering to do naughty
DOCTYPE sniffing.

> > I see this as low risk (it doesn't break anything and could even be an 
> > OPTIONAL feature)
> 
> Optional features always have a cost. Also, they tend to become de 
> facto mandatory for everyone or de facto useless for everyone.

Yes, but this is a low cost as long as the semantics of having the doctype
specified and not having it specified are clearly stated.  The cost of not
including it is having implementions differing on how they interpret the xml. 
The result is that people will become locked into particular atom processors
and the practical spec will diverge from the standard.  That would be a failure
of Atom.

> Base64 XML in XML was rejected earlier in the working group process.

It is in the latest public draft that I read.  What is replacing it?

> > No, any well formed XML processor MUST expand internal entities and add
> > replaced attributes as well.  This is NOT OPTIONAL.
> 
> So is expat non-conforming?

If it doesn't, then it is non-conforming.  That's how non-validating XML
processors are defined by the spec.  I quote from section 5.1 paragraph 4:

[Definition: While they are not required to check the document for validity,
they are REQUIRED to process all the declarations they read in the internal DTD
subset and in any parameter entity that they read, up to the first reference to
a parameter entity that they do not read; that is to say, they MUST use the
information in those declarations to normalize attribute values, include the
replacement text of internal entities, and supply default attribute values.]

There is no room for any other interpretation, I think.

> >> Atom is not claiming that you could embed the literal source of any 
> >> XML
> >> doc. You can embed the stuff that canonicalization would preserve.
> >
> > Yet you can do that with PNG, PDF, or other content via base 64 
> > encodings.  It
> > is silly to allow that for them and not XML.
> 
> Looks like straight HTTP without an Atom envelope in between suits your 
> needs better.

It is inflexible working at such low protocols; you should not need WS-* or a
standard REST format (and I know of no way to specify REST URIs/requests in a
standard format anyway) to switch between blogging servers/clients.  See second
reply.



--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/



From owner-atom-syntax@mail.imc.org  Mon May 30 03:23:39 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23797
	for ; Mon, 30 May 2005 03:23: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 j4U7E2LJ041793;
	Mon, 30 May 2005 00:14: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 j4U7E2oY041792;
	Mon, 30 May 2005 00:14:02 -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.79])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U7E0IW041748
	for ; Mon, 30 May 2005 00:14:01 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from cegetel.net (217-19-192-104.dti.cegetel.net [217.19.192.104])
	by smtp.cegetel.net (Postfix) with SMTP id 767351A4245
	for ; Mon, 30 May 2005 09:12:59 +0200 (CEST)
Received: from 82.127.77.43
        (SquirrelMail authenticated user t.broyer@cegetel.net)
        by ssl-webmail.sitadelle.com with HTTP;
        Mon, 30 May 2005 09:13:54 +0200 (CEST)
Message-ID: <1072.82.127.77.43.1117437234.squirrel@ssl-webmail.sitadelle.com>
Date: Mon, 30 May 2005 09:13:54 +0200 (CEST)
Subject: Problem with Metadata Elements (section 6.4)
From: "Thomas Broyer" 
To: 
X-Priority: 3
Importance: Normal
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



I was discussing extensions offlist with Dave Powell and came to explain
what I previously said on the list about Simple/Structured Extension
Elements [1] when I thought I found a real problem with that.

There have been much discussion last weeks about authors, contributors and
bylines and bylines were rejected to extensions (and I'm +1 on that,
that's not the point). So imagine I want to create such a byline
extension.

Ideally, I'd like it to be text that can be enriched with some markup. The
obvious choice here is to reuse the Text Construct mechanism: it is
already implemented in every Atom Processor so adding support for my
byline extension would be made much easier than redefining a different
mechanism, and of course it is homogeneous with Atom so better for users.

So my ext:byline element MAY have a "type" attribute with value "text",
"html" or "xhtml". When not present, it defaults to "text". Depending on
the  "type" attribute's value, the content is "plain flowed text", escaped
HTML or an XHTML div.

My byline extension then looks like the following, and is obviously a
Structured Extension Element (as it comes in atom:feed, atom:entry or
atom:source):
By Thomas Broyer and al.
By <a href="http://www.ltgt.net/">Thomas
Broyer</a> and al.

  


The problem come when I use a "plain flowed text" and can then omit the
"type" attribute:
By Thomas Broyer and al.
My extension becomes a Simple Extension Element when processed by an Atom
Processor, and an Atom Processor having some "generic support" for Simple
Extension Elements (which is really the intent of SEE) would change its
behavior when processing it, which is not really wanted.
However, I don't think I badly designed the byline extension, or this
would imply that Atom itself is badly designed (and I don't think so).

Are other people here seeing a problem with Simple vs. Structured
Extension ELements or am I the only one?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15751.html

-- 
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Mon May 30 05:53:10 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01349
	for ; Mon, 30 May 2005 05: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 j4U9hM73031641;
	Mon, 30 May 2005 02:43: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 j4U9hMpk031637;
	Mon, 30 May 2005 02:43:22 -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 j4U9hJov031540
	for ; Mon, 30 May 2005 02:43:20 -0700 (PDT)
	(envelope-from djpowell@djpowell.net)
Received: (qmail 92720 invoked from network); 30 May 2005 09:38:37 -0000
Received: from localhost.34sp.com (HELO localhost) (127.0.0.1)
  by localhost.34sp.com with SMTP; 30 May 2005 09:38:37 -0000
Received: from cmbg-cache-4.server.ntli.net (cmbg-cache-4.server.ntli.net [62.253.128.14]) 
	by webmail.djpowell.net (IMP) with HTTP 
	for ; Mon, 30 May 2005 10:38:36 +0100
Message-ID: <1117445916.429adf1cf2483@webmail.djpowell.net>
Date: Mon, 30 May 2005 10:38:36 +0100
From: David Powell 
To: Thomas Broyer 
Cc: atom-syntax@imc.org
Subject: Re: Problem with Metadata Elements (section 6.4)
References: <1072.82.127.77.43.1117437234.squirrel@ssl-webmail.sitadelle.com>
In-Reply-To: <1072.82.127.77.43.1117437234.squirrel@ssl-webmail.sitadelle.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: 62.253.128.14
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


Quoting Thomas Broyer :

> The problem come when I use a "plain flowed text" and can then omit the
> "type" attribute:
> By Thomas Broyer and al.
> My extension becomes a Simple Extension Element when processed by an Atom
> Processor, and an Atom Processor having some "generic support" for Simple
> Extension Elements (which is really the intent of SEE) would change its
> behavior when processing it, which is not really wanted.
> However, I don't think I badly designed the byline extension, or this
> would imply that Atom itself is badly designed (and I don't think so).

I don't think that this is a big problem.  The allowed syntax of Structured
Extension Elements is defined by the designer of the Structured Extension.  It
is the designer's responsibility to ensure that Structured Extensions don't
flip into being Simple Extensions, so they need to be designed in a way such
that they have at least one child element or attribute.

In this case the easiest way to do this would be to make @type mandatory even
when @type="text" is required.

--
Dave




From owner-atom-syntax@mail.imc.org  Mon May 30 08:37:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11258
	for ; Mon, 30 May 2005 08:37: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 j4UCSrDY001927;
	Mon, 30 May 2005 05: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 j4UCSr7n001926;
	Mon, 30 May 2005 05:28:53 -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 (mf01.sitadelle.com [212.94.174.80])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UCSpIO001811
	for ; Mon, 30 May 2005 05:28:51 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from cegetel.net (217-19-192-102.dti.cegetel.net [217.19.192.102])
	by smtp.cegetel.net (Postfix) with SMTP id 70A52318393;
	Mon, 30 May 2005 14:28:45 +0200 (CEST)
Received: from 82.127.77.43
        (SquirrelMail authenticated user t.broyer@cegetel.net)
        by ssl-webmail.sitadelle.com with HTTP;
        Mon, 30 May 2005 14:28:45 +0200 (CEST)
Message-ID: <2125.82.127.77.43.1117456125.squirrel@ssl-webmail.sitadelle.com>
Date: Mon, 30 May 2005 14:28:45 +0200 (CEST)
Subject: Re: Problem with Metadata Elements (section 6.4)
From: "Thomas Broyer" 
To: 
In-Reply-To: <1117445916.429adf1cf2483@webmail.djpowell.net>
References: <1072.82.127.77.43.1117437234.squirrel@ssl-webmail.sitadelle.com>
        <1117445916.429adf1cf2483@webmail.djpowell.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



David Powell wrote:
>
> Quoting Thomas Broyer:
>
>> The problem come when I use a "plain flowed text" and can then omit
>> the "type" attribute:
>> By Thomas Broyer and al.
>> My extension becomes a Simple Extension Element when processed by an
>> Atom Processor, and an Atom Processor having some "generic support"
>> for Simple Extension Elements (which is really the intent of SEE)
>> would change its behavior when processing it, which is not really
>> wanted.
>> However, I don't think I badly designed the byline extension, or this
>> would imply that Atom itself is badly designed (and I don't think so).
>
> I don't think that this is a big problem.  The allowed syntax of
> Structured Extension Elements is defined by the designer of the
> Structured Extension.  It is the designer's responsibility to ensure
> that Structured Extensions don't flip into being Simple Extensions, so
> they need to be designed in a way such that they have at least one child
> element or attribute.
>
> In this case the easiest way to do this would be to make @type mandatory
> even when @type="text" is required.

Of course yes, but the extension then doesn't follow the same rules as
Text Constructs, which are part of Atom, and it's bothering me. If I can't
design my extensions in the same way Atom designed its markup, I think
there is a problem... That's why I think the Metadata Elements (Simple and
Structured Extension Elements) wording is too strong in the spec.

The intent is (should be) to give a hint to Atom implementors providing
generic support for "name/value pair" properties and to extension
designers, not to enforce a particular behavior.

Changing that would also throw away your problem (discussed offlist) with
later allowing (e.g. in Atom 1.1) Metadata Elements in Atom elements where
foreign markup is today just "foreign markup", without any defined role.
To summarize for other people on the list, David's problem was that if we
don't define a role today for foreign markup inside Atom elements other
than atom:feed, atom:entry, Person Constructs and atom:source, e.g. inside
atom:link, then we wouldn't be able to define it later, because foreign
markup that would have been used with Atom 1.0 don't necessarily follow
the rules of section 6.4 and therefor won't be ok if Atom 1.1 says that
atom:link's foreign markup children are now considered Metadata Elements.

--
Thomas Broyer




From owner-atom-syntax@mail.imc.org  Mon May 30 10:52:07 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19861
	for ; Mon, 30 May 2005 10:52: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 j4UEhtcQ038185;
	Mon, 30 May 2005 07:43: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 j4UEht8C038184;
	Mon, 30 May 2005 07:43:55 -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 j4UEhrj7038175
	for ; Mon, 30 May 2005 07:43:54 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 30 May 2005 14:43:47 -0000
Received: from xdsl-213-196-242-77.netcologne.de (EHLO klangraum) [213.196.242.77]
  by mail.gmx.net (mp004) with SMTP; 30 May 2005 16:43:47 +0200
X-Authenticated: #163624
Date: Mon, 30 May 2005 16:47:31 +0200
From: "A. Pagaltzis" 
To: Atom WG 
Subject: Re: atom:type, xsl:output
Message-ID: <20050530144731.GA1153@klangraum>
Mail-Followup-To: Atom WG 
References: <13f3d68c6feb5435857698203ffc36a9@iki.fi> <20050530010836.30815.qmail@web42202.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050530010836.30815.qmail@web42202.mail.yahoo.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: 8bit


* James Cerra  [2005-05-30 03:20]:
> > >> Depending on an entity reference and not being able to
> > >> accept the straight replacement text is just wrong.
> > >
> > > I agree.  I'm just bringing up possible incompatibilities
> > > for debate!
> > 
> > I don't think that's an incompatibility that deserves
> > catering for.
> 
> Why not?  Why be incompatible for the sake of incompatibility?
> That's just asking for trouble when Atom is used in ways not
> originally envisioned (and there always are).

That’s bogus. Some software generates or processes non-wellformed
XML. Should Atom cater to that too? If not, where do you draw the
line between somewhat-broken software that Atom should support
and really-broken software that it should not?

> HTML currently uses doctypes for switching between versions of
> the langauage.

No, it doesn’t. Browsers do so, but only as a hack; the idea is
that an author who puts a DOCTYPE declaration in their document
*probably* cares about validity and so his document should
*probably* be treated as strict standards compliance requires.
But there is nothing in any spec that justifies this behaviour.

> There is no other way to properly interpret content without
> guessing in the current drafts.  That is a worse sin inflicted
> upon programmers, than allowing the subset that do rendering to
> do naughty DOCTYPE sniffing.

You don’t seem to understand XML. XML has something called
namespaces. Use them.

> > > No, any well formed XML processor MUST expand internal
> > > entities and add replaced attributes as well.  This is NOT
> > > OPTIONAL.
> > 
> > So is expat non-conforming?
> 
> If it doesn't, then it is non-conforming.

Wrong.

> That's how non-validating XML processors are defined by the
> spec.  I quote from section 5.1 paragraph 4:
> 
> [Definition: While they are not required to check the document
> for validity, they are REQUIRED to process all the declarations
> they read in the internal DTD subset and in any parameter
                   ^^^^^^^^     ^^^^^^
> entity that they read, up to the first reference to a parameter
         ^^^^^^^^^^^^^^
> entity that they do not read; that is to say, they MUST use the
         ^^^^^^^^^^^^^^^^^^^^^
> information in those declarations to normalize attribute
> values, include the replacement text of internal entities, and
> supply default attribute values.]
> 
> There is no room for any other interpretation, I think.

Nowhere is a non-validating processor REQUIRED to read an
external DTD in the spec. Only *internal* declarations MUST be
processed and references resolved.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Mon May 30 10:57:38 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20106
	for ; Mon, 30 May 2005 10:57: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 j4UEomVi038591;
	Mon, 30 May 2005 07:50: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 j4UEompZ038590;
	Mon, 30 May 2005 07:50: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 (mail.gmx.net [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4UEohI9038580
	for ; Mon, 30 May 2005 07:50:44 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 30 May 2005 14:50:38 -0000
Received: from xdsl-213-196-242-77.netcologne.de (EHLO klangraum) [213.196.242.77]
  by mail.gmx.net (mp031) with SMTP; 30 May 2005 16:50:38 +0200
X-Authenticated: #163624
Date: Mon, 30 May 2005 16:54:23 +0200
From: "A. Pagaltzis" 
To: Atom WG 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
Message-ID: <20050530145423.GB1153@klangraum>
Mail-Followup-To: Atom WG 
References: <92e6d7de9ef502e8444f0aed4db4aa16@iki.fi> <20050529234754.28023.qmail@web42205.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050529234754.28023.qmail@web42205.mail.yahoo.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: 8bit


* James Cerra  [2005-05-30 02:00]:
> > Why do you think it is appropriate to have a random PI
> > processor in between the XML processor and the Atom
> > processor?
> 
> Because the XML is just the grammar serializing the ontology,
> or data structure, of interest. I see Atom processors as
> normally the Bridge between the XML document and the particular
> CMS, IA, or web browser application's internal structure. So
> an Atom processor would be the last stage before the data is
> internalized. The intent of _Processing_ Instructions seems to
> change how the document is processed. That implies to me that
> they would probably be interpreted between the XML processor
> and the particular grammar's processor.

Atom is a transport envelope for potentially a multitude of
documents. Saying that the enveloped documents should be
preprocessed before they are unfolded from the envelope is like
saying that a part of a multipart/mime document which has a
“Content-Encoding: gzip” header should be uncompressed in situ
*before* it is extracted from the multipart envelope.

That doesn’t make any sense.

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Mon May 30 11:08:17 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20735
	for ; Mon, 30 May 2005 11:08: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 j4UExGkD039321;
	Mon, 30 May 2005 07:59: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 j4UExGXi039320;
	Mon, 30 May 2005 07:59: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 (pop.gmx.de [213.165.64.20])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4UExEui039261
	for ; Mon, 30 May 2005 07:59:15 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 30 May 2005 14:59:08 -0000
Received: from xdsl-213-196-242-77.netcologne.de (EHLO klangraum) [213.196.242.77]
  by mail.gmx.net (mp022) with SMTP; 30 May 2005 16:59:08 +0200
X-Authenticated: #163624
Date: Mon, 30 May 2005 17:02:53 +0200
From: "A. Pagaltzis" 
To: Atom WG 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
Message-ID: <20050530150253.GC1153@klangraum>
Mail-Followup-To: Atom WG 
References: <20050528095955.GA20439@klangraum> <20050530002440.66978.qmail@web42204.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050530002440.66978.qmail@web42204.mail.yahoo.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 Cerra  [2005-05-30 02:35]:
> For a counter example: For internal use I might create an Atom
> feed from atom entries with  attached to
> either the feed or the entries. Furthermore, I could add
> instructions for my stylesheet by defining PIs used in the
> entries. In this case, the PI processor is an xslt processor
> that works before the atom processor. The original contains
> global options and defines the template, while the entries are
> parsed and aggregated into the original file. This way it is
> easier to change the feed's options without editing the XSLT
> source files. The atom processor becomes the last stage in the
> pipe.

So you expect every XML processor to have an XSLT processor
attached so that it will be able to resolve your custom Atom+PIs
superformat to regular Atom?

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Mon May 30 12:19:11 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25201
	for ; Mon, 30 May 2005 12:19: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 j4UGApEf043546;
	Mon, 30 May 2005 09:10: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 j4UGApcN043545;
	Mon, 30 May 2005 09:10:51 -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 j4UGAoV7043538
	for ; Mon, 30 May 2005 09:10:51 -0700 (PDT)
	(envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20050530145423.GB1153@klangraum>
References: <92e6d7de9ef502e8444f0aed4db4aa16@iki.fi>
 <20050529234754.28023.qmail@web42205.mail.yahoo.com>
 <20050530145423.GB1153@klangraum>
Date: Mon, 30 May 2005 09:10:47 -0700
To: Atom WG 
From: Paul Hoffman 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
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 4:54 PM +0200 5/30/05, A. Pagaltzis wrote:
>Atom is a transport envelope for potentially a multitude of
>documents. Saying that the enveloped documents should be
>preprocessed before they are unfolded from the envelope is like
>saying that a part of a multipart/mime document which has a
>"Content-Encoding: gzip" header should be uncompressed in situ
>*before* it is extracted from the multipart envelope.
>
>That doesn't make any sense.

+1

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-atom-syntax@mail.imc.org  Mon May 30 13:56:40 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00674
	for ; Mon, 30 May 2005 13:56: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 j4UHiVhj048880;
	Mon, 30 May 2005 10:44: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 j4UHiVDT048879;
	Mon, 30 May 2005 10:44:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42202.mail.yahoo.com (web42202.mail.yahoo.com [66.218.93.203])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4UHiVgh048869
	for ; Mon, 30 May 2005 10:44:31 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 2851 invoked by uid 60001); 30 May 2005 17:44:26 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=ouoXufD9ItBDnwEEU8hjdHdKErvo8FOruUJNTsCN1xfx4VoSlEl71y36QQAJQq+wLD8gZC0MY6ebFGEr7VThdF+JX8ZRdrudLEsCCgQ7rtsZQxPBY7flVUYxRgJg/fm19mRag5UixaRVtYm83fmDhQxLMwdvyTg9SqE0zQXSHs0=  ;
Message-ID: <20050530174426.2849.qmail@web42202.mail.yahoo.com>
Received: from [136.142.21.159] by web42202.mail.yahoo.com via HTTP; Mon, 30 May 2005 10:44:26 PDT
Date: Mon, 30 May 2005 10:44:26 -0700 (PDT)
From: James Cerra 
Subject: Re: atom:type, xsl:output
To: "A. Pagaltzis" , Atom WG 
In-Reply-To: 6667
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: 


Aristotle,

> > > >> Depending on an entity reference and not being able to
> > > >> accept the straight replacement text is just wrong.
> > > >
> > > > I agree.  I'm just bringing up possible incompatibilities
> > > > for debate!
> > > 
> > > I don't think that's an incompatibility that deserves
> > > catering for.
> > 
> > Why not?  Why be incompatible for the sake of incompatibility?
> > That's just asking for trouble when Atom is used in ways not
> > originally envisioned (and there always are).
> 
> That’s bogus. Some software generates or processes non-wellformed
> XML. Should Atom cater to that too? If not, where do you draw the
> line between somewhat-broken software that Atom should support
> and really-broken software that it should not?

Depends on the situation.  :-)

I think that Atom should support specifying doctypes since there're in the XML
spec and are well-formed constructs (even if external subsets are not read). 
I'd like Atom to support having _all_ well-formed XML documents be possible
atom:content (referenced by @src at least).

> > HTML currently uses doctypes for switching between versions of
> > the langauage.
> 
> No, it doesn’t. Browsers do so, but only as a hack; the idea is
> that an author who puts a DOCTYPE declaration in their document
> *probably* cares about validity and so his document should
> *probably* be treated as strict standards compliance requires.
> But there is nothing in any spec that justifies this behaviour.

How do you differentiate between XHTML 1.0 Strict and XHTML 1.0 Transitional
without doctypes?

> > There is no other way to properly interpret content without
> > guessing in the current drafts.  That is a worse sin inflicted
> > upon programmers, than allowing the subset that do rendering to
> > do naughty DOCTYPE sniffing.
> 
> You don’t seem to understand XML. XML has something called
> namespaces. Use them.

I understand XML and namespaces.  Lets keep the personal attacks out of this
thread, and not start a flame war, OK?

The problem is that there are specs which use one namespace for several
versions!

> > > > No, any well formed XML processor MUST expand internal
> > > > entities and add replaced attributes as well.  This is NOT
> > > > OPTIONAL.
> > > 
> > > So is expat non-conforming?
> > 
> > If it doesn't, then it is non-conforming.
> 
> Wrong.
> 
> > That's how non-validating XML processors are defined by the
> > spec.  I quote from section 5.1 paragraph 4:
> > 
> > [Definition: While they are not required to check the document
> > for validity, they are REQUIRED to process all the declarations
> > they read in the internal DTD subset and in any parameter
>                    ^^^^^^^^     ^^^^^^
> > entity that they read, up to the first reference to a parameter
>          ^^^^^^^^^^^^^^
> > entity that they do not read; that is to say, they MUST use the
>          ^^^^^^^^^^^^^^^^^^^^^
> > information in those declarations to normalize attribute
> > values, include the replacement text of internal entities, and
> > supply default attribute values.]
> > 
> > There is no room for any other interpretation, I think.
> 
> Nowhere is a non-validating processor REQUIRED to read an
> external DTD in the spec. Only *internal* declarations MUST be
> processed and references resolved.

Um, I was talking about internal declarations!  Non-validating processors are
required to read the external subset declaration (but they don't have to
resolve and parse it) and the internal subset up to any paramater references
they don't read.  So in the following declaration everything must be read
except for anything in the external file:


]>

A non-validating processor will report the public and system ids as well as
processing the entity declaration.  Since the declaration of the external
subset is used, in this case, to change semantics of the XHTML elements
(namely, which version of the standard they conform to).



--
Jimmy Cerra
https://nemo.dev.java.net


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/



From owner-atom-syntax@mail.imc.org  Mon May 30 14:03:15 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01232
	for ; Mon, 30 May 2005 14:03: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 j4UHuBLK049652;
	Mon, 30 May 2005 10:56: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 j4UHuBjB049651;
	Mon, 30 May 2005 10:56:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web42206.mail.yahoo.com (web42206.mail.yahoo.com [66.218.93.207])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4UHuAjH049642
	for ; Mon, 30 May 2005 10:56:10 -0700 (PDT)
	(envelope-from jfcst24_public@yahoo.com)
Received: (qmail 55188 invoked by uid 60001); 30 May 2005 17:56:05 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  b=GVoXBadZwHgGtA7166j2i+8QVllYTRes2DGo1QbiZJy5XwZ03PMmNFFc4FnP8/TkAyFGpyRah2M0i7HbJje8ngJYhOBGzbkbgdQ7sKUgEYCuPwRz6qo/CNw5AbjuzLkt4uLP1jfGoqF6v5bM0XB8Zlck9zZqG6tNDLzxvo+hg/k=  ;
Message-ID: <20050530175605.55186.qmail@web42206.mail.yahoo.com>
Received: from [136.142.21.159] by web42206.mail.yahoo.com via HTTP; Mon, 30 May 2005 10:56:05 PDT
Date: Mon, 30 May 2005 10:56:05 -0700 (PDT)
From: James Cerra 
Subject: Re: atom, xslt processors (Re: atom:type, xsl:output)
To: "A. Pagaltzis" , Atom WG 
In-Reply-To: 6667
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: 


Aristotle,

> > > Why do you think it is appropriate to have a random PI
> > > processor in between the XML processor and the Atom
> > > processor?
> > 
> > Because the XML is just the grammar serializing the ontology,
> > or data structure, of interest. I see Atom processors as
> > normally the Bridge between the XML document and the particular
> > CMS, IA, or web browser application's internal structure. So
> > an Atom processor would be the last stage before the data is
> > internalized. The intent of _Processing_ Instructions seems to
> > change how the document is processed. That implies to me that
> > they would probably be interpreted between the XML processor
> > and the particular grammar's processor.
> 
> Atom is a transport envelope for potentially a multitude of
> documents. Saying that the enveloped documents should be
> preprocessed before they are unfolded from the envelope is like
> saying that a part of a multipart/mime document which has a
> “Content-Encoding: gzip” header should be uncompressed in situ
> *before* it is extracted from the multipart envelope.

Note that by "change how the document is processed" I mean the Atom document -
i.e. the envelope - not the content of atom:content - the enveloped document. 
Sorry for my imprecise language.  So PIs change how the Atom document is
processed.  Could you give an example of how they would be clearly associated
with the enveloped document (which counters this argument)?



--
Jimmy Cerra
https://nemo.dev.java.net

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From owner-atom-syntax@mail.imc.org  Mon May 30 14:45:20 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04403
	for ; Mon, 30 May 2005 14:45: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 j4UIbMjL052808;
	Mon, 30 May 2005 11:37: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 j4UIbM5x052807;
	Mon, 30 May 2005 11:37:22 -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 j4UIbL6g052797;
	Mon, 30 May 2005 11:37:21 -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 j4UIbL0R005683;
	Mon, 30 May 2005 12:37:21 -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 <0IHB00G4SFQ8MW@edgemail1.Central.Sun.COM>; Mon,
 30 May 2005 12:37:21 -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 <0IHB00AHIFQ8TI@mail.sun.net>; Mon,
 30 May 2005 12:37:20 -0600 (MDT)
Date: Mon, 30 May 2005 11:37:35 -0700
From: Tim Bray 
Subject: OpenSearch RSS
To: Atom Syntax , Atom Protocol 
Message-id: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.730)
Content-type: text/plain; charset=US-ASCII; delsp=yes; 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


Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
to hear substantial buzz around this thing.

I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
cause any heartburn?  I'm inclined to think not, but would appreciate  
others having a look.

I get the feeling that OpenSearch + Atom could be real useful. -Tim



From owner-atom-syntax@mail.imc.org  Mon May 30 18:23:38 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19111
	for ; Mon, 30 May 2005 18:23: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 j4UMDhHH064164;
	Mon, 30 May 2005 15:13: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 j4UMDhVL064162;
	Mon, 30 May 2005 15:13:43 -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 (mf01.sitadelle.com [212.94.174.80])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UMDeFO064147;
	Mon, 30 May 2005 15:13:41 -0700 (PDT)
	(envelope-from t.broyer@cegetel.net)
Received: from [127.0.0.1] (unknown [84.5.69.172])
	by smtp.cegetel.net (Postfix) with ESMTP id 060413184F7;
	Tue, 31 May 2005 00:13:34 +0200 (CEST)
Message-ID: <429B9016.4010700@cegetel.net>
Date: Tue, 31 May 2005 00:13:42 +0200
From: Thomas Broyer 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Atom Syntax , Atom Protocol 
Subject: Re: OpenSearch RSS
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM>
In-Reply-To: <125068F7-E88E-42FF-9063-86ADF502F355@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:

>
> Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
> to hear substantial buzz around this thing.
>
> I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
> cause any heartburn?  I'm inclined to think not, but would appreciate  
> others having a look.
>
> I get the feeling that OpenSearch + Atom could be real useful. -Tim
>
Just to see how it would look like, this is what the search result 
example [1] would be in Atom:

A9.com Search: New York City history
tag:A9.com,2005:New%20York%20City%20history

Search results for "New York City history" at 
A9.com
© 2003-2005, A9.com, Inc. or its affiliates.

   A9.com, Inc.
   http://a9.com/

2005-05-30T23:50:00+02:00
4230000
1
10


   New York City History
   
   
http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html
   2005-05-30T00:00:00+02:00
   ... Harlem.NYC - A virtual tour and information on 
businesses ... with historic photos of Columbia's own New York 
neighborhood ... Internet Resources for the City's History. 
...


   Gotham Center for New York City History
   
   http://www.gothamcenter.org/
   2005-05-30T00:00:00+02:00
   ... Submit Events Edit Your Submission. Main 
Neighborhood Stories NYC History in the ... The Gotham Center for New 
York City History is supported by The CUNY Graduate ...



   Welcome to the Museum of the City of New York
   
   http://www.mcny.org/
   2005-05-30T00:00:00+02:00
   ... a list with the event staff. Additional information 
will be included in the confirming email. © Museum of the City of 
New York.



Some comments:

    * I set type="text/html" on the feed's alternate link, because the
      OpenSearch RSS 1.0 Specification [1] says the RSS  is "a URL
      that can recreate the search in HTML format", @type is not used in
      entries as it might not be text/html
    * I changed the escaped-HTML &copy; to ©, it saves us an
      internal DTD subset while allowing us to use type="text"
    * Atom mandates an atom:author, I added a dummy one
    * Atom mandates an atom:updated in the feed, I added a dummy one; it
      should be set to the latest atom:updated date found in the feed's
      entries, or at least to the date the request was made.
    * Atom mandates an atom:updated in each entry, I added a dummy one;
      it should be set to the last access of the search engine to the
      "result document", or eventually the date the request was made.
      For example, Google is able to give you this date if it has cached
      the document (when you look at a cached page, Google puts a "this
      is Google's cache of  as retrieved on " on top of the page.
    * I used the address of the "result document" (permalink?) as the
      atom:id of each entry, because this is the easiest way to do it...

I've put this document online [2], with the "Atom 0.3" namespace URI 
(http://purl.org/Atom/ns#)

Note that the OpenSearch RSS 1.0 Specification [1] forbids the use of 
escaped HTML in many elements. If there were an "OpenSearch Atom", it 
could also be limited to type="text" (and/or type="xhtml", because it's 
quite easy to transform XHTML to plain text), though A9.com website 
(which acts as an reader/aggregator for OpenSearch RSS documents) would 
then not be a valid Atom Processor.

The OpenSearch Description Document [3] would /a priori/ be the same 
(except of course that it would use a different value in the "Format" 
element to indicate "OpenSearch Atom" instead of "OpenSearch RSS".

The Atom result document could also link to the next and previous 
"pages" with additional atom:link elements in the atom:feed, with 
"extended" @rel values.

[1] http://opensearch.a9.com/spec/opensearchrss/1.0/
[2] http://www.ltgt.net/atom/opensearch.atom
[3] http://opensearch.a9.com/spec/opensearchdescription/1.0/

-- 
Thomas Broyer





From owner-atom-syntax@mail.imc.org  Mon May 30 19:15:29 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22600
	for ; Mon, 30 May 2005 19:15: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 j4UN91AE067906;
	Mon, 30 May 2005 16:09: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 j4UN91pw067903;
	Mon, 30 May 2005 16:09:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24])
	by above.proper.com (8.12.11/8.12.9) with SMTP id j4UN8xMw067887
	for ; Mon, 30 May 2005 16:09:00 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 68955 messnum 5381312 invoked from network[83.70.217.193/unknown]); 30 May 2005 23:08:54 -0000
Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193)
  by mail08.svc.cra.dublin.eircom.net (qp 68955) with SMTP; 30 May 2005 23:08:54 -0000
Message-ID: <429B9D04.3070906@dehora.net>
Date: Tue, 31 May 2005 00:08: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 , Atom Protocol 
Subject: Re: OpenSearch RSS
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net>
In-Reply-To: <429B9016.4010700@cegetel.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


Thomas Broyer wrote:
> 
> Tim Bray wrote:
> 
>>
>> Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
>> to hear substantial buzz around this thing.
>>
>> I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
>> cause any heartburn?  I'm inclined to think not, but would appreciate  
>> others having a look.
>>
>> I get the feeling that OpenSearch + Atom could be real useful. -Tim

> 
>    * I set type="text/html" on the feed's alternate link, because the
>      OpenSearch RSS 1.0 Specification [1] says the RSS  is "a URL
>      that can recreate the search in HTML format", @type is not used in
>      entries as it might not be text/html
>    * I changed the escaped-HTML &copy; to ©, it saves us an
>      internal DTD subset while allowing us to use type="text"
>    * Atom mandates an atom:author, I added a dummy one
>    * Atom mandates an atom:updated in the feed, I added a dummy one; it
>      should be set to the latest atom:updated date found in the feed's
>      entries, or at least to the date the request was made.
>    * Atom mandates an atom:updated in each entry, I added a dummy one;
>      it should be set to the last access of the search engine to the
>      "result document", or eventually the date the request was made.
>      For example, Google is able to give you this date if it has cached
>      the document (when you look at a cached page, Google puts a "this
>      is Google's cache of  as retrieved on " on top of the page.
>    * I used the address of the "result document" (permalink?) as the
>      atom:id of each entry, because this is the easiest way to do it...

I did the same experiment; bottom line Amazon will need to add

  -atom:updated
  -atom:id
  -atom:modified
  -a few attributes

to use Atom. They also need to fix their example*, it's invalid XML 
(© in the last entry). By the looks of things, with the feed level 
extensions, they're going the route Nature have taken with RSS1.0.

cheers
Bill

* http://opensearch.a9.com/spec/opensearchrss/1.0/





From owner-atom-syntax@mail.imc.org  Mon May 30 19:40:05 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24054
	for ; Mon, 30 May 2005 19:40: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 j4UNXPxF069284;
	Mon, 30 May 2005 16:33: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 j4UNXOKV069282;
	Mon, 30 May 2005 16:33:24 -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 j4UNXNB3069264
	for ; Mon, 30 May 2005 16:33:24 -0700 (PDT)
	(envelope-from bill@dehora.net)
Received: (qmail 40350 messnum 6688478 invoked from network[83.70.217.193/unknown]); 30 May 2005 23:33:18 -0000
Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193)
  by mail10.svc.cra.dublin.eircom.net (qp 40350) with SMTP; 30 May 2005 23:33:18 -0000
Message-ID: <429BA2BD.70104@dehora.net>
Date: Tue, 31 May 2005 00:33:17 +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 , Atom Protocol 
Subject: Re: OpenSearch RSS
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net> <429B9D04.3070906@dehora.net>
In-Reply-To: <429B9D04.3070906@dehora.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


Bill de hra wrote:

> I did the same experiment; bottom line Amazon will need to add
>  [...]

Oops, please ignore:

>  -atom:modified

[My eyes! The specifications! They do nothing!]

cheers
Bill



From owner-atom-syntax@mail.imc.org  Mon May 30 19:41:02 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24119
	for ; Mon, 30 May 2005 19:41: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 j4UNZhhc069404;
	Mon, 30 May 2005 16:35: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 j4UNZh1v069402;
	Mon, 30 May 2005 16:35:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged))
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UNZgj1069391;
	Mon, 30 May 2005 16:35:42 -0700 (PDT)
	(envelope-from mint@franklinmint.fm)
Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.12])
	by web02.designerslab.net with esmtpa (Exim 4.43)
	id 1DctnG-0002JI-2q; Mon, 30 May 2005 23:35:38 +0000
Message-ID: <429BA33A.4010807@franklinmint.fm>
Date: Mon, 30 May 2005 19:35:22 -0400
From: Robert Sayre 
Reply-To: mint@franklinmint.fm
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tim Bray 
CC: Atom Protocol , Atom Syntax 
Subject: Re: OpenSearch RSS
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM>
In-Reply-To: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - web02.designerslab.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - franklinmint.fm
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 7bit


Tim Bray wrote:
> I wonder, is embedding the OpenSearch RSS stuff in Atom going to  cause 
> any heartburn?  I'm inclined to think not, but would appreciate  others 
> having a look.

I've reviewed this stuff before, and I don't see any barriers to using
this stuff in Atom, other than the extra required elements Atom asks 
for. OTOH, the query spec



says:

   Results

   Search results are expected to be returned in the OpenSearch RSS
   format. For search content providers that do not offer search results
   in OpenSearch RSS format, a wrapper must be authored that can perform
   the transformation.


> I get the feeling that OpenSearch + Atom could be real useful.

There is substantial overlap with Atom Protocol paging, especially
existing gregorio-07 implementations. I quite like their approach to URI
construction and their description document, which allows servers to 
place the query parameters anywhere in their URI space.

http://opensearch.a9.com/spec/opensearchdescription/1.0/

They have a read-only protocol, so they don't have to worry about the
relation of state changes to result sets, but it did give me some
simplicity envy when I first read it.

Robert Sayre



From owner-atom-syntax@mail.imc.org  Tue May 31 04:54:22 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18473
	for ; Tue, 31 May 2005 04: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 j4V8ki4N087700;
	Tue, 31 May 2005 01:46: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 j4V8kiGr087698;
	Tue, 31 May 2005 01:46:44 -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 j4V8khK2087660;
	Tue, 31 May 2005 01:46:43 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	id 1Dd2OV-00047N-00; Tue, 31 May 2005 09:46:39 +0100
Date: Tue, 31 May 2005 09:46:39 +0100
From: James Aylett 
To: Atom Protocol , Atom Syntax 
Subject: Re: OpenSearch RSS
Message-ID: <20050531084639.GE12923@tartarus.org>
Mail-Followup-To: James Aylett ,
	Atom Protocol ,
	Atom Syntax 
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429BA33A.4010807@franklinmint.fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <429BA33A.4010807@franklinmint.fm>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Mon, May 30, 2005 at 07:35:22PM -0400, Robert Sayre wrote:

> >I get the feeling that OpenSearch + Atom could be real useful.
> 
> There is substantial overlap with Atom Protocol paging, especially
> existing gregorio-07 implementations. I quite like their approach to URI
> construction and their description document, which allows servers to 
> place the query parameters anywhere in their URI space.
> 
> http://opensearch.a9.com/spec/opensearchdescription/1.0/

I seem to remember when I looked at it that it rang bells with me by
looking like part of WSDL. At which point I wondered why they didn't
use WSDL. That's more of an aside, though.

A couple of us from Xapian [1] looked at OpenSearch, and implemented
it for our example search engine. It took about half an hour (mostly
because we use a templating language for query results), but ten to
fifteen minutes of that was spent figuring out what OpenSearch
actually meant, and we had to make a number of assumptions in doing
so.

Were someone to produce a document describing Atom+OpenSearch, I'd
expect it to have the rigour of Atom. OpenSearch is written in the
RSS2 style, which isn't really appropriate for a highly interoperable
format, which is clearly what's desired.

We were also a little concerned that the OpenSearch model was very
simplistic - there were many possible use cases we could think of that
weren't catered for, and indeed we could only think of one that was
really supported, being the one that A9 puts it to (which is a slim
superset of feeding OpenSearch into a desktop aggregator). We did
start to put together a proposal for an Atom+Search extension, and
completed the conceptual work but then got distracted by other
things. This is kind of orthogonal to the OpenSearch issue, but if
people are interested in discussing a richer search extension we can
try to clear some time to pull it into shape.

[1] 

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Tue May 31 05:07:32 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19839
	for ; Tue, 31 May 2005 05:07: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 j4V902EY092537;
	Tue, 31 May 2005 02:00: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 j4V9024a092535;
	Tue, 31 May 2005 02:00:02 -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 j4V9010X092518;
	Tue, 31 May 2005 02:00:01 -0700 (PDT)
	(envelope-from james@ixion.tartarus.org)
Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	id 1Dd2bQ-0004Gc-00; Tue, 31 May 2005 10:00:00 +0100
Date: Tue, 31 May 2005 10:00:00 +0100
From: James Aylett 
To: Atom Syntax , Atom Protocol 
Subject: Re: OpenSearch RSS
Message-ID: <20050531090000.GF12923@tartarus.org>
Mail-Followup-To: James Aylett ,
	Atom Syntax ,
	Atom Protocol 
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <429B9016.4010700@cegetel.net>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Tue, May 31, 2005 at 12:13:42AM +0200, Thomas Broyer wrote:

> 
>   New York City History
>         href="http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html" />
>   
> http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html
>   2005-05-30T00:00:00+02:00
>   ... Harlem.NYC - A virtual tour and information on 
> businesses ... with historic photos of Columbia's own New York 
> neighborhood ... Internet Resources for the City's History. 
> ...
> 
> 
>   Gotham Center for New York City History
>   
>   http://www.gothamcenter.org/
>   2005-05-30T00:00:00+02:00
>   ... Submit Events Edit Your Submission. Main 
> Neighborhood Stories NYC History in the ... The Gotham Center for New 
> York City History is supported by The CUNY Graduate ...

I'm going backwards and forwards on whether
atom:entry/atom:link[@rel="alternate"]/@href is the right thing to put
into atom:entry/atom:id. On the plus side it's simple and works in the
basic case of syndication (eg: my search results appear in an A9
search column). On the negative side I'm wondering what will happen if
I take two search feeds into a desktop aggregator - presumably the
result will only appear once. However that may well be what is
desired, which would kind of be a neutral side.

It does limit things (at least by draft-ietf-atompub-format-08) in
that if I aggregate two search feeds into one and they have search
results for the same site, either I have to drop one of them or I have
to rewrite all the atom:id values myself - and the latter is
explicitly forbidden by 4.2.7 of atompub.

I know there's been some related discussion on this that hasn't made
its way into the I-D yet - I /think/ consensus was reached around
PaceAtomIdDos, but I can't find a statement one way of another on the
list archives. With something like that text in atompub, at least
people are aware of the problem, although something explicit in an
Atom+OpenSearch document is probably required to make sure everyone's
aware of what would happen.

I'm also not convinced that the semantics are quite right (surely the
feed is a feed of search results, where a search result seems
different to me conceptually than the website a search result refers
to as the source of the match). This isn't nearly so important,
though, and I'm quite willing to accept the shmershing together of the
ideas. (Or even that I'm wrong.)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Tue May 31 05:40:12 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21784
	for ; Tue, 31 May 2005 05:40: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 j4V9XEk5004191;
	Tue, 31 May 2005 02:33: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 j4V9XEoK004190;
	Tue, 31 May 2005 02:33: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 j4V9XCjY004148
	for ; Tue, 31 May 2005 02:33:13 -0700 (PDT)
	(envelope-from pagaltzis@gmx.de)
Received: (qmail invoked by alias); 31 May 2005 09:33:06 -0000
Received: from xdsl-213-196-244-125.netcologne.de (EHLO klangraum) [213.196.244.125]
  by mail.gmx.net (mp015) with SMTP; 31 May 2005 11:33:06 +0200
X-Authenticated: #163624
Date: Tue, 31 May 2005 11:36:52 +0200
From: "A. Pagaltzis" 
To: Atom Syntax 
Subject: Re: OpenSearch RSS
Message-ID: <20050531093652.GA4463@klangraum>
Mail-Followup-To: Atom Syntax 
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net> <20050531090000.GF12923@tartarus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050531090000.GF12923@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: 8bit


* James Aylett  [2005-05-31 11:10]:
> It does limit things (at least by draft-ietf-atompub-format-08)
> in that if I aggregate two search feeds into one and they have
> search results for the same site, either I have to drop one of
> them or I have to rewrite all the atom:id values myself - and
> the latter is explicitly forbidden by 4.2.7 of atompub.

Wasn’t that going to be allowed if you create the proper
atom:source elements? Or did I misread the discussion?

Regards,
-- 
Aristotle



From owner-atom-syntax@mail.imc.org  Tue May 31 06:05:41 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23428
	for ; Tue, 31 May 2005 06:05: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 j4V9uIWJ011762;
	Tue, 31 May 2005 02:56: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 j4V9uItA011761;
	Tue, 31 May 2005 02:56:18 -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 j4V9uHo4011749
	for ; Tue, 31 May 2005 02:56:17 -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 1Dd3Ts-0005Um-00; Tue, 31 May 2005 10:56:16 +0100
Date: Tue, 31 May 2005 10:56:16 +0100
From: James Aylett 
To: Atom Syntax 
Subject: Re: OpenSearch RSS
Message-ID: <20050531095616.GG12923@tartarus.org>
Mail-Followup-To: James Aylett ,
	Atom Syntax 
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net> <20050531090000.GF12923@tartarus.org> <20050531093652.GA4463@klangraum>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050531093652.GA4463@klangraum>
User-Agent: Mutt/1.3.28i
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 


On Tue, May 31, 2005 at 11:36:52AM +0200, A. Pagaltzis wrote:

> > It does limit things (at least by draft-ietf-atompub-format-08)
> > in that if I aggregate two search feeds into one and they have
> > search results for the same site, either I have to drop one of
> > them or I have to rewrite all the atom:id values myself - and
> > the latter is explicitly forbidden by 4.2.7 of atompub.
> 
> Wasn't that going to be allowed if you create the proper
> atom:source elements? Or did I misread the discussion?

That's what I remember, yes. However I wonder, in this case, if that's
actually what we want - since you might end up with ten entries at the
top all for the same page, just from different search engines.

This is why I'm uncertain quite what the right approach is - it all
depends on what you're trying to do.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james@tartarus.org                               uncertaintydivision.org



From owner-atom-syntax@mail.imc.org  Tue May 31 08:47:23 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06182
	for ; Tue, 31 May 2005 08:47: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 j4VCcBgj069434;
	Tue, 31 May 2005 05:38: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 j4VCcBmF069433;
	Tue, 31 May 2005 05:38:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f
Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VCc9LY069385
	for ; Tue, 31 May 2005 05:38:10 -0700 (PDT)
	(envelope-from dtcd@mac.com)
Received: from [161.73.58.69] (data-csmail2 [192.168.2.2])
	by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j4VCat2W001550;
	Tue, 31 May 2005 13:36:55 +0100 (BST)
In-Reply-To: <20050531093652.GA4463@klangraum>
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429B9016.4010700@cegetel.net> <20050531090000.GF12923@tartarus.org> <20050531093652.GA4463@klangraum>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: 
Cc: atom-syntax 
From: Graham 
Subject: Re: OpenSearch RSS
Date: Tue, 31 May 2005 13:36:55 +0100
To: "A. Pagaltzis" 
X-Mailer: Apple Mail (2.730)
X-MailScanner-Information: Oxford Brookes University MailScanner
X-MailScanner: Clean
X-MailScanner-From: dtcd@mac.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VCcALY069425
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: 
List-Unsubscribe: 
List-ID: 
Content-Transfer-Encoding: 8bit


On 31 May 2005, at 10:36 am, A. Pagaltzis wrote:

>
> * James Aylett  [2005-05-31 11:10]:
>
>> It does limit things (at least by draft-ietf-atompub-format-08)
>> in that if I aggregate two search feeds into one and they have
>> search results for the same site, either I have to drop one of
>> them or I have to rewrite all the atom:id values myself - and
>> the latter is explicitly forbidden by 4.2.7 of atompub.
>>
>
> Wasnt that going to be allowed if you create the proper
> atom:source elements? Or did I misread the discussion?

That proposal was rejected, or at least no one stood up to support  
it, sadly.

Graham



From owner-atom-syntax@mail.imc.org  Tue May 31 20:08:16 2005
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11868
	for ; Tue, 31 May 2005 20:08: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 j5101OmZ026779;
	Tue, 31 May 2005 17:01: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 j5101OhT026778;
	Tue, 31 May 2005 17:01:24 -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 j5101Mud026762;
	Tue, 31 May 2005 17:01: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 A86BDB4;
	Tue, 31 May 2005 17:01:17 -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 j5101Cng002656;
	Tue, 31 May 2005 17:01:12 -0700 (PDT)
Date: Tue, 31 May 2005 17:17:15 -0700
From: Walter Underwood 
To: James Aylett , Atom Protocol ,
        Atom Syntax 
Subject: Re: OpenSearch RSS
Message-ID: <6A95C1AE0873748A5645AC8D@diva.verity.com>
In-Reply-To: <20050531084639.GE12923@tartarus.org>
References: <125068F7-E88E-42FF-9063-86ADF502F355@Sun.COM> <429BA33A.4010807@franklinmint.fm> <20050531084639.GE12923@tartarus.org>
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 Tuesday, May 31, 2005 09:46:39 AM +0100 James Aylett  wrote:
>
> We were also a little concerned that the OpenSearch model was very
> simplistic ...
>
> ...  This is kind of orthogonal to the OpenSearch issue, but if
> people are interested in discussing a richer search extension we can
> try to clear some time to pull it into shape.

That was my feeling, too. OpenSearch is so limited that it is not
very interesting.

That's too bad, because most of the hard design work was done nearly
ten years ago at the STARTS project at Stanford. A couple of years ago,
we put together a fairly general search web service. It is time to
update that, so maybe I'll look at doing it on Atom.

STARTS is here: 

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek