From owner-atom-syntax@mail.imc.org Mon May 01 00:43:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaQG3-0007HZ-Ry for atompub-archive@lists.ietf.org; Mon, 01 May 2006 00:43:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaQG2-0005r1-F4 for atompub-archive@lists.ietf.org; Mon, 01 May 2006 00:43:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k414Q91W075535; Sun, 30 Apr 2006 21:26:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k414Q9d1075534; Sun, 30 Apr 2006 21:26:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k414Q8w2075527 for ; Sun, 30 Apr 2006 21:26:08 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2061868wra for ; Sun, 30 Apr 2006 21:26: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:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HxKQCq7QW7expV7AQ7C6cnnGODMBSlfNXbXk2h7wEs/BwAcyzZtxkpBf1qOX5pNPpdvW3BRmKi6TDvJ/zZ14x5lbmqH9dNMrkKlEjW9727TWLtix9MCjVPP+l/MC1R5rLo7Eys63yMug+kusiS6y8Hvea6cDLkFVSHDAz10/8DQ= Received: by 10.54.94.17 with SMTP id r17mr3324309wrb; Sun, 30 Apr 2006 21:26:07 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 39sm3573600wrl.2006.04.30.21.26.00; Sun, 30 Apr 2006 21:26:01 -0700 (PDT) Message-ID: <44558DD6.4070809@gmail.com> Date: Sun, 30 Apr 2006 21:25:58 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax Subject: Re: Tools that make use of previous/next/first/last links? References: <4450200D.1000809@aol.net> <95133C9F-3CC3-4403-8B95-8C2B02232311@mnot.net> In-Reply-To: <95133C9F-3CC3-4403-8B95-8C2B02232311@mnot.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Mark, While I'm sure the other James may have his own particular set of issues, the one pain point for me with the history spec is the use of the "previous" link to point back in time. This runs counter to the use of the previous link in both OpenSearch, APP and Gdata. It would be excellent if rather than using previous, feed history would look at the set of feeds as a list of pages ordered in reverse chronological order, where "next" pointed to the next oldest set of entries. e.g. current=/feed.xml first=/2006/04/feed.xml next=/2006/03/feed.xml next=/2006/02/feed.xml next=/2006/01/feed.xml ... - James Mark Nottingham wrote: > > Did you find that algorithm wrong, too hard to understand/implement, or > did you just do a different take on it? Does the approach that you took > end up having the same result? > > Any suggestions on how to better document it appreciated. > > Cheers, > > > On 2006/04/26, at 8:35 PM, James Holderness wrote: > >> >> We added support for next/prev/previous links in version 0.3.0 of >> Snarfer [1]. We don't use the reconstruction algorithm suggested in >> the Feed History draft, but your example feed seems to work ok for an >> initial retrieval. There may be problems with subsequent updates, >> though, depending on how you handle items falling out the bottom of >> the main feed. >> >> Regards >> James >> >> [1] http://www.snarfware.com/ >> >> John Panzer wrote: >>> We just deployed support for link@rel="previous" et al. for >>> AOL Journals. If anyone has a client that makes use of these >>> links, please let me know, I'd love to see if there are any >>> interoperability problems. >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Mon May 01 03:18:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaSg7-0000fu-Nd for atompub-archive@lists.ietf.org; Mon, 01 May 2006 03:18:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaSg6-0002wU-Ck for atompub-archive@lists.ietf.org; Mon, 01 May 2006 03:18:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4175JQL080375; Mon, 1 May 2006 00:05:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4175JNG080374; Mon, 1 May 2006 00:05:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4175G51080352 for ; Mon, 1 May 2006 00:05:17 -0700 (MST) (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.0002340180 for ; Mon, 01 May 2006 17:04:40 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 01 May 2006 17:04:36 +1000 Subject: Re: Tools that make use of previous/next/first/last links? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <44558DD6.4070809@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 1/5/06 2:25 PM, "James M Snell" wrote: > While I'm sure the other James may have his own particular set of > issues, the one pain point for me with the history spec is the use of > the "previous" link to point back in time. This runs counter to the use > of the previous link in both OpenSearch, APP and Gdata. I thought OpenSearch results are not sorted by chronological age at all, but instead by relevance? Using "next" with OpenSearch makes sense in that context. Using "previous" for stepping back thru time in a data store arranged chronologically makes sense. I'm not familiar with how Gdata arranges it's data, but briefly scanning the API docs it's modelled on OpenSearch, and furthermore it says "Result ordering is up to the implementation" ... thus I would think it would be right for it to use 'next' to get the next page, but wrong to assume that this would imply stepping backwards chronologically. e. From owner-atom-syntax@mail.imc.org Mon May 01 04:06:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaTQd-00062L-Q7 for atompub-archive@lists.ietf.org; Mon, 01 May 2006 04:06:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaTQd-0004m4-Dh for atompub-archive@lists.ietf.org; Mon, 01 May 2006 04:06:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k417trQw081708; Mon, 1 May 2006 00:55:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k417trWC081707; Mon, 1 May 2006 00:55:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k417tqad081701 for ; Mon, 1 May 2006 00:55:53 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so2550584wri for ; Mon, 01 May 2006 00:55:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JF9zBPjdrsiXzsKzvR1WS/12CQvucnwfYY50snLpq2k7v/cjTH8Zlxa1nNIJHAYmlsalzU3vb/o4wclVFXY1skRvVXe8OlAvsfhb+MyOOoY1oyfhmt/z2BEjrGjL1VX8W+OYZrFEvtob+Z87xuS6odUnRHSf5dtZuU6/ck3C7Zs= Received: by 10.54.95.12 with SMTP id s12mr3696702wrb; Mon, 01 May 2006 00:55:52 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm1706596wra.2006.05.01.00.55.46; Mon, 01 May 2006 00:55:47 -0700 (PDT) Message-ID: <4455BF00.4090605@gmail.com> Date: Mon, 01 May 2006 00:55:44 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Eric Scheid wrote: > On 1/5/06 2:25 PM, "James M Snell" wrote: > >> While I'm sure the other James may have his own particular set of >> issues, the one pain point for me with the history spec is the use of >> the "previous" link to point back in time. This runs counter to the use >> of the previous link in both OpenSearch, APP and Gdata. > > I thought OpenSearch results are not sorted by chronological age at all, but > instead by relevance? Using "next" with OpenSearch makes sense in that > context. Using "previous" for stepping back thru time in a data store > arranged chronologically makes sense. > My apologies, I did not mean to imply that OS used chronological ordering. Quite the opposite, in fact; that is, opensearch defines no meaning to the ordering of pages at all. Previous just means the previous page in a set. > I'm not familiar with how Gdata arranges it's data, but briefly scanning the > API docs it's modelled on OpenSearch, and furthermore it says "Result > ordering is up to the implementation" ... thus I would think it would be > right for it to use 'next' to get the next page, but wrong to assume that > this would imply stepping backwards chronologically. > I'm generally against making any assumptions about whether or not next/previous points to anything but some other page of entries; if you want to know whether they're newer or older, just look at the updated timestamp and sort accordingly. That said, however, we end up with a problem when we have one spec that says next points backwards in time (APP), one spec that says next points forwards in time (feed history) and one spec that says next is just another page of entries that match some criteria (opensearch). No matter what the various link types point to, there needs to be consistency. As it stands now, a single feed cannot implement APP, OpenSearch AND Feed History. - James From owner-atom-syntax@mail.imc.org Mon May 01 05:40:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaUtD-0001hL-56 for atompub-archive@lists.ietf.org; Mon, 01 May 2006 05:40:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaUt7-0002oj-Ox for atompub-archive@lists.ietf.org; Mon, 01 May 2006 05:40:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k419TExn084855; Mon, 1 May 2006 02:29:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k419TEA3084854; Mon, 1 May 2006 02:29:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ironclad.net.au ([203.30.247.11]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k419TAS5084847 for ; Mon, 1 May 2006 02:29:12 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] ([203.30.247.118] verified) by ironclad.net.au (Stalker SMTP Server 1.7) with ESMTP id S.0002345411 for ; Mon, 01 May 2006 19:29:07 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 01 May 2006 19:18:35 +1000 Subject: Re: Tools that make use of previous/next/first/last links? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4455BF00.4090605@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On 1/5/06 5:55 PM, "James M Snell" wrote: > That said, however, we end up with a > problem when we have one spec that says next points backwards in time > (APP), one spec that says next points forwards in time (feed history) > and one spec that says next is just another page of entries that match > some criteria (opensearch). No matter what the various link types point > to, there needs to be consistency. As it stands now, a single feed > cannot implement APP, OpenSearch AND Feed History. I just reviewed the relevant example in the APP spec and it's worrisome. Reading between the lines it suggests that the subscription uri is "http://example.org/entries/go", with the rest of the collection available via rel="next" through to "http://example.org/entries/10". The worrisome thing is that once that collection gains another 10 entries, then the resource "http://example.org/entries/11" will now contain the entries which were previously contained by resource "http://example.org/entries/10". Every page of the collection needs to be updated and have the entries shuffled along. A simplified example: /entries/go contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D which then gets another 4 entries added (ie. U,V,W,X) and the collection now looks like this: /entries/go contains entries U,V,W,X /entries/1 contains entries Q,R,S,T /entries/2 contains entries M,N,O,P /entries/3 contains entries I,J,K,L /entries/4 contains entries E,F,G,H /entries/5 contains entries A,B,C,D This is just smells bad in so many ways. Pity the blog package that publishes static files and will have to rebuild every collection page. Pity the poor server that gets asked if /entries/3 has been modified and if so hand it over. Pity the google bot that does all that asking. Of course, this sentence doesn't parse into English real well either: "next" and "prev" link elements reference the preceding and subsequent feed documents in the set. ie. "next" references the *preceding* feed document, and "prev" references the *subsequent* feed document. It doesn't even make sense when read Down Under ;-) e. From owner-atom-syntax@mail.imc.org Mon May 01 06:26:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaVbl-000166-SI for atompub-archive@lists.ietf.org; Mon, 01 May 2006 06:26:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaVbk-0004Jq-DY for atompub-archive@lists.ietf.org; Mon, 01 May 2006 06:26:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41AGn0f086842; Mon, 1 May 2006 03:16:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41AGn77086841; Mon, 1 May 2006 03:16:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41AGmZO086818 for ; Mon, 1 May 2006 03:16:48 -0700 (MST) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay04.plus.net with esmtp (Exim) id 1FaVSM-0003HR-GU for atom-syntax@imc.org; Mon, 01 May 2006 11:16:42 +0100 To: atom-syntax@imc.org (atom-syntax) In-Reply-To: <8FEBADFF-E70E-45C0-B301-EB161479B4BC@mnot.net> Subject: Re: Tools that make use of previous/next/first/last links? From: pmrobinson@gmx.net (Peter Robinson) Date: Mon, 1 May 2006 11:16:41 +0100 Message-ID: <1henngd.rdufq2q68uugM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.4.6) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Mark Nottingham wrote: > One thing I did notice -- you're using URLs like this for your archives: > http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? > page=2&count=10 > > Are they really permanent? If they're relative to the current state > of the feed (i.e., the above URI means "give me the ten latest > entries"), you can get into some inconsistent states; e.g., if > somebody adds/deletes an entry between when the client fetches the > different archives. Also, if a client doesn't visit for a long time, > it will see > http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? > page=2&count=10 > and assume it already has all of the entries in it, because it's > fetched that URI before. This is the biggest issue I have with the history spec as written. I have urls like that, which aren't 'archive documents' as defined. That means I can't implement the history spec even though I have conventional chronologically ordered feeds with link rel="prev/next" elements where old entries are available. I believe that by being more precise about exactly what is needed by the client to implement feed history usefully you can significantly relax the requirements. I believe the algorithm can be written so that clients can use history with a feed like mine. Regards, Peter From owner-atom-syntax@mail.imc.org Mon May 01 06:29:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaVf1-0003Kj-Ti for atompub-archive@lists.ietf.org; Mon, 01 May 2006 06:29:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaVf0-0004S7-Gd for atompub-archive@lists.ietf.org; Mon, 01 May 2006 06:29:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41AGnOW086834; Mon, 1 May 2006 03:16:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41AGnj7086833; Mon, 1 May 2006 03:16:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41AGlYm086817 for ; Mon, 1 May 2006 03:16:48 -0700 (MST) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay04.plus.net with esmtp (Exim) id 1FaVSL-0003HR-Kl for atom-syntax@imc.org; Mon, 01 May 2006 11:16:41 +0100 To: atom-syntax@imc.org (atom-syntax) In-Reply-To: <44558DD6.4070809@gmail.com> Subject: Re: Tools that make use of previous/next/first/last links? From: pmrobinson@gmx.net (Peter Robinson) Date: Mon, 1 May 2006 11:16:41 +0100 Message-ID: <1henmz4.1otx8xv1m2qk8bM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.4.6) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d James M Snell wrote: > While I'm sure the other James may have his own particular set of > issues, the one pain point for me with the history spec is the use of > the "previous" link to point back in time. This runs counter to the use > of the previous link in both OpenSearch, APP and Gdata. Yes it does. (Though as was later clarified it's not that OpenSearch specifies any chronological ordering as such, but it is true that anyone who wants to implement OpenSearch in a conventional time-ordered feed will have to have "next" pointing back in time.) I thought it was agreed when we were discussing registering the link relations for prev/next etc. that the registration would not specify whether next meant backwards or forwards in time, but that specs making use of them would be written to be 'sign independent'. E.g. the history spec (or something else) would define an element or whatever, that publishers could set and consumers would be required to check. Regards, Peter -- Peter Robinson Concerts, sport and theatre tickets From owner-atom-syntax@mail.imc.org Mon May 01 12:08:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faawv-0000Uf-BA for atompub-archive@lists.ietf.org; Mon, 01 May 2006 12:08:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faawt-000147-Tr for atompub-archive@lists.ietf.org; Mon, 01 May 2006 12:08:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41FopS1001670; Mon, 1 May 2006 08:50:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41FopOZ001669; Mon, 1 May 2006 08:50:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41Fooq7001663 for ; Mon, 1 May 2006 08:50:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2135312wra for ; Mon, 01 May 2006 08:50:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=f9YlIgAnW1cn0rmTOYv2RxdHCtyTydhqP1InuHqvxHVTOwqJpr9fclGGvdZV35QYytcDEIDl/XKBqbu9iY0fHTvkLWlrAB7zYGpdgeLTC/WLma6nIyv4fRN0kFDoByAXvJJRP+Ns6zUyjAxstxMfnj6pIRI16CnklNTEaY9e7Rk= Received: by 10.54.110.13 with SMTP id i13mr865108wrc; Mon, 01 May 2006 08:50:50 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 65sm1243483wra.2006.05.01.08.50.48; Mon, 01 May 2006 08:50:49 -0700 (PDT) Message-ID: <44562E55.4070002@gmail.com> Date: Mon, 01 May 2006 08:50:45 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Yes, the paging in APP is a problem (one I've been largely ignoring up to this point in our own implementation). There is no way of reliably and efficiently reconstructing the entire feed history. - James Eric Scheid wrote: > On 1/5/06 5:55 PM, "James M Snell" wrote: > >> That said, however, we end up with a >> problem when we have one spec that says next points backwards in time >> (APP), one spec that says next points forwards in time (feed history) >> and one spec that says next is just another page of entries that match >> some criteria (opensearch). No matter what the various link types point >> to, there needs to be consistency. As it stands now, a single feed >> cannot implement APP, OpenSearch AND Feed History. > > I just reviewed the relevant example in the APP spec and it's worrisome. > Reading between the lines it suggests that the subscription uri is > "http://example.org/entries/go", with the rest of the collection available > via rel="next" through to "http://example.org/entries/10". > > The worrisome thing is that once that collection gains another 10 entries, > then the resource "http://example.org/entries/11" will now contain the > entries which were previously contained by resource > "http://example.org/entries/10". Every page of the collection needs to be > updated and have the entries shuffled along. > > A simplified example: > > /entries/go contains entries Q,R,S,T > /entries/2 contains entries M,N,O,P > /entries/3 contains entries I,J,K,L > /entries/4 contains entries E,F,G,H > /entries/5 contains entries A,B,C,D > > which then gets another 4 entries added (ie. U,V,W,X) and the collection now > looks like this: > > /entries/go contains entries U,V,W,X > /entries/1 contains entries Q,R,S,T > /entries/2 contains entries M,N,O,P > /entries/3 contains entries I,J,K,L > /entries/4 contains entries E,F,G,H > /entries/5 contains entries A,B,C,D > > This is just smells bad in so many ways. Pity the blog package that > publishes static files and will have to rebuild every collection page. Pity > the poor server that gets asked if /entries/3 has been modified and if so > hand it over. Pity the google bot that does all that asking. > > > Of course, this sentence doesn't parse into English real well either: > > "next" and "prev" link elements reference the > preceding and subsequent feed documents in the set. > > ie. "next" references the *preceding* feed document, and "prev" references > the *subsequent* feed document. It doesn't even make sense when read Down > Under ;-) > > e. > > From owner-atom-syntax@mail.imc.org Mon May 01 13:49:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FacWi-00021H-P3 for atompub-archive@lists.ietf.org; Mon, 01 May 2006 13:49:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FacWh-0004qK-Bo for atompub-archive@lists.ietf.org; Mon, 01 May 2006 13:49:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41HaLB9005945; Mon, 1 May 2006 10:36:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41HaLG8005944; Mon, 1 May 2006 10:36:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41HaJJF005937 for ; Mon, 1 May 2006 10:36:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2154302wra for ; Mon, 01 May 2006 10:36:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VyrkrXQ8ueatZbf4bcaSKBCcEuw2M42zhAQRHcCzw+oZVRzhdvO2OBwvngICoUsM85p4ujM6mnU/Yl8D+RjFIpuFOh/mFuIVjKimigOAR5FcRsgWSxcTNuvwXLDXMLaSLtxQD+8XQpZPa88YIXZYjapuQ05N5Yp1sqoGniI4kJg= Received: by 10.54.82.6 with SMTP id f6mr218960wrb; Mon, 01 May 2006 10:36:19 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 66sm1269270wra.2006.05.01.10.36.17; Mon, 01 May 2006 10:36:18 -0700 (PDT) Message-ID: <4456470E.6090003@gmail.com> Date: Mon, 01 May 2006 10:36:14 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Mark Nottingham CC: atom-syntax Subject: Re: Tools that make use of previous/next/first/last links? References: <4450200D.1000809@aol.net> <95133C9F-3CC3-4403-8B95-8C2B02232311@mnot.net> In-Reply-To: <95133C9F-3CC3-4403-8B95-8C2B02232311@mnot.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Mark, Right now, the subscription feed uses "previous" to point to the archive feeds. Perhaps a better approach would be to to have an "archive" link relation that points to the first of a distinct set of archive feeds. Also, remove the temporal semantics from the the previous link and require that each archive page contain the entries from a fixed period of time (that is, each archive feed document is "complete" within a given time period) ... ... ... This completely removes the current subscription feed from the history reconstruction and eliminates the sliding window effect. Reconstructing the feed history becomes a simple matter of locating the archive link and iterating over a set of fixed pages. - James Mark Nottingham wrote: > > Did you find that algorithm wrong, too hard to understand/implement, or > did you just do a different take on it? Does the approach that you took > end up having the same result? > > Any suggestions on how to better document it appreciated. > > Cheers, > > > On 2006/04/26, at 8:35 PM, James Holderness wrote: > >> >> We added support for next/prev/previous links in version 0.3.0 of >> Snarfer [1]. We don't use the reconstruction algorithm suggested in >> the Feed History draft, but your example feed seems to work ok for an >> initial retrieval. There may be problems with subsequent updates, >> though, depending on how you handle items falling out the bottom of >> the main feed. >> >> Regards >> James >> >> [1] http://www.snarfware.com/ >> >> John Panzer wrote: >>> We just deployed support for link@rel="previous" et al. for >>> AOL Journals. If anyone has a client that makes use of these >>> links, please let me know, I'd love to see if there are any >>> interoperability problems. >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Mon May 01 16:32:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faf45-000482-TH for atompub-archive@lists.ietf.org; Mon, 01 May 2006 16:32:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaeeR-0002vE-7G for atompub-archive@lists.ietf.org; Mon, 01 May 2006 16:05:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FaeRl-0001T9-3I for atompub-archive@lists.ietf.org; Mon, 01 May 2006 15:52:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41Jf4e8011210; Mon, 1 May 2006 12:41:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41Jf4r6011209; Mon, 1 May 2006 12:41:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41Jf3EP011194 for ; Mon, 1 May 2006 12:41:03 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2176122wra for ; Mon, 01 May 2006 12:41:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=RbEeF89CvArXd2rx3itwtxU6fHcBMd/8ge2IvHOFiQgLgBEOfcNr7QpyoGby0v2J21mKO2p1wSjg9EkP7LvxmkuzsKnWSG7fzgyDJ1glpJOOkuvfpiWhusguCUzWV0mI+AnFqntgQcXDOSoPW0nUEA17lRCVkoVeecX+ssM6E6U= Received: by 10.54.150.16 with SMTP id x16mr12848wrd; Mon, 01 May 2006 12:41:03 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 65sm1407259wra.2006.05.01.12.41.01; Mon, 01 May 2006 12:41:02 -0700 (PDT) Message-ID: <44566449.6080009@gmail.com> Date: Mon, 01 May 2006 12:40:57 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax CC: Kyle Marvin Subject: Entry types 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Looking at Google's gdata and IBM's open activities APP implementation as examples, there appears to be a solid use case for defining a common categorization scheme for associating a type label to an entry. For instance, Gdata defines the following: Our stuff uses: I'm wondering if it would make sense to have a single common "type" scheme that could be used consistently across implementations. The category could be used on Feeds and Entries. Thoughts? - James From owner-atom-syntax@mail.imc.org Mon May 01 16:41:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FafDE-00047G-8s for atompub-archive@lists.ietf.org; Mon, 01 May 2006 16:41:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FafD9-0004oa-LU for atompub-archive@lists.ietf.org; Mon, 01 May 2006 16:41:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41KV0VW013215; Mon, 1 May 2006 13:31:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41KV0Bf013214; Mon, 1 May 2006 13:31:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav11.bay109.hotmail.com [64.4.19.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41KUxPt013208 for ; Mon, 1 May 2006 13:30:59 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 May 2006 13:30:59 -0700 Message-ID: Received: from 81.179.109.21 by BAY109-DAV11.phx.gbl with DAV; Mon, 01 May 2006 20:30:57 +0000 X-Originating-IP: [81.179.109.21] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <4450200D.1000809@aol.net> <95133C9F-3CC3-4403-8B95-8C2B02232311@mnot.net> <4456470E.6090003@gmail.com> Subject: Re: Tools that make use of previous/next/first/last links? Date: Mon, 1 May 2006 21:30:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 01 May 2006 20:30:59.0388 (UTC) FILETIME=[281B77C0:01C66D5E] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 James M Snell wrote: > Right now, the subscription feed uses "previous" to point to the archive > feeds. Perhaps a better approach would be to to have an "archive" link > relation that points to the first of a distinct set of archive feeds. If I have to add yet another algorithm for paging support in addition to the ones that are already there, I'd be inclined to just dump the whole thing. > Yes, the paging in APP is a problem (one I've been largely ignoring up > to this point in our own implementation). There is no way of reliably > and efficiently reconstructing the entire feed history. I would have thought a combination of RFC3229/feed with paging would be adequate. Something like that should work perfectly well with any client that already supports those features. It doesn't require the invention of a whole new system. Regards James From owner-atom-syntax@mail.imc.org Mon May 01 19:34:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fahuh-0007Gd-2l for atompub-archive@lists.ietf.org; Mon, 01 May 2006 19:34:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fahuf-0004KJ-GR for atompub-archive@lists.ietf.org; Mon, 01 May 2006 19:34:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41NM77j020368; Mon, 1 May 2006 16:22:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k41NM7KQ020367; Mon, 1 May 2006 16:22:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k41NM6WT020361 for ; Mon, 1 May 2006 16:22:07 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2212557wra for ; Mon, 01 May 2006 16:22:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=DAhTvL33E1XgOI29qd6bF6VqFK4GL4hrd4Q0RTwKo9KOvdIkQg0kq7LiXEAOWktr1p62t1fxLc3NwhF9IPHSHpTc82eio41nTj1pqWrAczhy+zrPoTmTCSTP7e3ZsD/Va20kRLoWz2cYQBQGW/sovsjmVIOTiyTJ1hQLlgLrylo= Received: by 10.54.149.10 with SMTP id w10mr83175wrd; Mon, 01 May 2006 16:22:06 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 5sm886824wrh.2006.05.01.16.22.05; Mon, 01 May 2006 16:22:06 -0700 (PDT) Message-ID: <44569816.6090708@gmail.com> Date: Mon, 01 May 2006 16:21:58 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Atom Rank Extensions 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: X-Spam-Score: 1.9 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc All, A new draft of the Feed Rank extension has been published. Andreas Sewe has joined on as an author and has contributed significantly to this rev of the draft. There are many updates to the extension that are worth highlighting. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-09.txt First, the purpose of this extension is to provide a flexible means of ranking entries within a feed. For instance, a feed might represent an ordered listing of items from a movie rental queue; or each entry in a feed might contain a five star review ranking; or each entry in the feed might represent a listing of a students graded homework assignment, where each rank represents the grade assigned to the work, etc. For example, when combined with Mark Nottingham's Feed History extension for marking a feed as "complete", Feed Rank provides a good solution for representing a movie rental queue: tag:example.org,2006:my_movie_queue My Movie Queue 2006-05-01T12:00:00Z James tag:example.org,2006:movies/chaplin/citylights City Lights 2006-05-01T12:00:00Z Charlie Chaplin's cassic film 1 4.5 tag:example.org,2006:movies/chaplin/moderntimes Modern Times 2006-05-01T12:00:00Z Another Chaplin classic 3 3.5 tag:example.org,2006:movies/chaplin/thegoldrush The Gold Rush 2006-05-01T12:00:00Z Chaplin in a frozen wilderness 2 5.0 While there are a variety of changes throughout the entire spec, the key differences in this draft lie in the definition of the Ranking Schemes. A Ranking Scheme is now defined as a set of discreet values and/or ranges. For instance, a typical U.S. grading scheme can be represented using a series of ranges representing percentage values: 1.00 In contrast, the typical German grading scheme can be represented as a set of discreet values: 1.0 1.3 1.7 2.0 2.3 2.7 3.0 3.3 3.7 4.0 4.3 4.7 5.0 5.3 5.7 6.0 Anyway, as always, feedback is welcomed and requested. - James From owner-atom-syntax@mail.imc.org Mon May 01 21:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fak2E-0004kZ-Jr for atompub-archive@lists.ietf.org; Mon, 01 May 2006 21:50:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fak2D-0000RR-6i for atompub-archive@lists.ietf.org; Mon, 01 May 2006 21:50:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k421dG1E025039; Mon, 1 May 2006 18:39:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k421dGmm025038; Mon, 1 May 2006 18:39:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k421dFcX025032 for ; Mon, 1 May 2006 18:39:16 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so2937129pyc for ; Mon, 01 May 2006 18:39:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q1cN1VEru6faS3wt2zpD+QxyUGzQJpnWS7/s0oBp/1WiS15ABZghWf0wqw1KP9s/gJYGKThmF+RzVM2XtdOjkk01p/+u9wvO2MJeYfrLwZDpNIQk1h8X1fiVy+W+lIPDXdOYjiI3GOMpbapNBj2p+nUGH7C4LBVoqUCCL8MrwN0= Received: by 10.35.40.10 with SMTP id s10mr20228pyj; Mon, 01 May 2006 18:39:15 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Mon, 1 May 2006 18:39:15 -0700 (PDT) Message-ID: <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> Date: Mon, 1 May 2006 21:39:15 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Atom Rank Extensions Cc: atom-syntax , "Lisa Dusseault" In-Reply-To: <44569816.6090708@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k421dGcX025033 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On 5/1/06, James M Snell wrote: > > All, > > A new draft of the Feed Rank extension has been published. I am uncomfortable with the numerous "standards track" documents emanating from one person/company, especially when changes requested by the community are met with hostility and channel flooding. An excellent way to handle this gripe is to hold a BoF and let an Area Director guage interest in a charter with defined goals. When I read terms like "more standard" wrt the feed thread extension, it makes me cringe. By my count, James has 11 drafts in the system, all Atom-related. Many of them are copies of existing RSS extensions. It doesn't seem appropriate to issue competing versions of various extensions from Microsoft, Yahoo et al. and claim they are products of community consensus, for that excludes the IETF from defining the problem. It also turns the WG into a factor in silly vendor sports, which damages WG and IETF credibility. -- Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 01 22:57:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fal4W-0000o4-Qr for atompub-archive@lists.ietf.org; Mon, 01 May 2006 22:57:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fal4V-0002wN-Ae for atompub-archive@lists.ietf.org; Mon, 01 May 2006 22:57:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k422ioAx028214; Mon, 1 May 2006 19:44:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k422ioMh028213; Mon, 1 May 2006 19:44:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k422inlo028203 for ; Mon, 1 May 2006 19:44:49 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 02:44:42 -0000 Received: from xdsl-213-196-242-250.netcologne.de (EHLO klangraum) [213.196.242.250] by mail.gmx.net (mp017) with SMTP; 02 May 2006 04:44:42 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 04:44:48 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502024448.GK2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k422ioAx028214 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 * Robert Sayre [2006-05-02 03:50]: > especially when changes requested by the community are met with > hostility and channel flooding. Did this happen in more cases than the one I=E2=80=99m aware of? You know, the one where James eventually caved on both distinct points anyway? > When I read terms like "more standard" wrt the feed thread > extension, it makes me cringe. There are obvious reasons why that one is better than the rag-tag group of RSS extensions required to duplicate even a limited set of its use cases. We=E2=80=99ve had that discussion in other venues. (If you do require a blow-by-blow posted here, I can put together a summary for the WG.) > By my count, James has 11 drafts in the system, all > Atom-related. Many of them are copies of existing RSS > extensions. It doesn't seem appropriate to issue competing > versions of various extensions from Microsoft, Yahoo et al. and > claim they are products of community consensus, Granted, but don=E2=80=99t lump them all together. Some of them *are* products of community consensus; the Thread extension in particular got a lot of churn (more than the others by a wide margin; ~250 posts on this list by my last count, aside from a dozen weblog threads or so). At least one or two others received some attention as well (the Licence extension I think? I didn=E2=80=99t pay much attention to those). It appears that it would be most productive if you simply express any specific concerns you have about particular drafts and their overlap with particular RSS extensions, instead of going for an ad hominem against James. It worked for David Powell; his concerns about technical flaws in the Thread extension convinced James to revise the draft, where your vociferous unsubstantiated objections had previously failed. In any case I=E2=80=99m puzzled why you=E2=80=99d start ringing alarm bel= ls just now. None of these I-Ds are new; they=E2=80=99re all at least several months old and some have been through a half-dozen revisions and corresponding announcements. How did they escape your notice for so long? If they did not, why have they only become a problem now? > for that excludes the IETF from defining the problem. How do you mean? (Question to be taken at face value. I honestly am not sure what you mean here.) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon May 01 23:26:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FalX8-0005CA-MC for atompub-archive@lists.ietf.org; Mon, 01 May 2006 23:26:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FalX8-0003kw-A1 for atompub-archive@lists.ietf.org; Mon, 01 May 2006 23:26:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k423G6kD029464; Mon, 1 May 2006 20:16:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k423G6bj029463; Mon, 1 May 2006 20:16:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k423G4lP029457 for ; Mon, 1 May 2006 20:16:05 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so2954350pyc for ; Mon, 01 May 2006 20:16:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GwMNDE7cNhGUYe03yywN9PZtvWetCFiRyk++L35fuek6zOH8U+Nx9nZd5dlJLEjOuAhxYciPeiA0Y92Ut0F1DS3B91tIDx7DypfSSTv+baL0YRSINt+Ufs6K8mZZC4IWkcm4TWHFCqnuvSow7wdVV6aPUyuX+ZsAZltRVpiPc4Y= Received: by 10.35.8.1 with SMTP id l1mr320205pyi; Mon, 01 May 2006 20:16:04 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Mon, 1 May 2006 20:16:04 -0700 (PDT) Message-ID: <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> Date: Mon, 1 May 2006 23:16:04 -0400 From: "Robert Sayre" To: atom-syntax Subject: Re: Atom Rank Extensions In-Reply-To: <20060502024448.GK2690@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k423G5lP029458 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a On 5/1/06, A. Pagaltzis wrote: > > * Robert Sayre [2006-05-02 03:50]: > > especially when changes requested by the community are met with > > hostility and channel flooding. > > Did this happen in more cases than the one I'm aware of? Yes. > > > When I read terms like "more standard" wrt the feed thread > > extension, it makes me cringe. > > There are obvious reasons why that one is better than the rag-tag > group of RSS extensions... Disagree. There is no proof of that. > It appears that it would be most productive if you simply express > any specific concerns you have about particular drafts and their > overlap with particular RSS extensions, instead of going for an > ad hominem against James. I didn't go for an ad hominem. That would be something like "the feed draft is bad because James wrote it". I disagree with many decisions in the draft, but that is because I think they are misguided, not because I dislike the person who wrote them. For instance, every other threading extension uses a simple element with a number to represent the number of responses. This is limited in theory, but in practice, such elements are so easy to deploy, they prove valuable. In fact, a few WG members used my unauthorized version of the feed thread extension to track my comments. > It worked for David Powell; his > concerns about technical flaws in the Thread extension convinced > James to revise the draft, where your vociferous unsubstantiated > objections had previously failed. Nonsense. Sylvain pointed out that he was being pushy and ignorant, and only then did he changed it. I think you're confusing James' rhetoric with reality. A silly mistake. His rhetoric is pretty clumsy. > In any case I'm puzzled why you'd start ringing alarm bells just > now. I-Ds by themselves are not an issue.Of course, actual change control is, and documents pushed through the process without problem-definition in the IETF are much more prone to abuse. It really does bother me that these documents are being pushed through at the same level as the Atom draft itself, and I don't think I need to apologize for my timing. Anyway, I don't see how the timing of my email is not relevant to the topic at hand. Besides, I was b-b-b-banned during lots of it, but I've getting better at being courteous to the ethically-challenged. > > for that excludes the IETF from defining the problem. > > How do you mean? (Question to be taken at face value. I honestly > am not sure what you mean here.) > Defining the charter, etc, etc. It's a good thing to do. Are there any WG members left who were around at that phase? I joined right around then... -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 02 01:16:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FanF0-0004zs-NR for atompub-archive@lists.ietf.org; Tue, 02 May 2006 01:16:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FanEz-00070f-At for atompub-archive@lists.ietf.org; Tue, 02 May 2006 01:16:06 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4254nBW033258; Mon, 1 May 2006 22:04:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4254nkv033257; Mon, 1 May 2006 22:04:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4254mvj033251 for ; Mon, 1 May 2006 22:04:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2257641wra for ; Mon, 01 May 2006 22:04: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:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DA+SDrxBBazAs+fIwFQdvd6LvJYmnVLN+thfTZih4GjpVSvllED0jE4eig1sy+Tibw8EXkU6yyLeuPFq0pQdCS3lyQeTAoxTNHGRaDSNl1Q+s1FjxjVT7s/Bjm/nn5ybzepWZlqwbwCXmo3EMt5nDE1HDgrFvnaWUiMt+b0RS4c= Received: by 10.54.147.19 with SMTP id u19mr312460wrd; Mon, 01 May 2006 22:04:47 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 8sm1513644wrl.2006.05.01.22.04.46; Mon, 01 May 2006 22:04:47 -0700 (PDT) Message-ID: <4456E86A.5020702@gmail.com> Date: Mon, 01 May 2006 22:04:42 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Feed thread update References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> In-Reply-To: <20060502024448.GK2690@klangraum> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 A. Pagaltzis wrote: >It worked for David Powell; his > concerns about technical flaws in the Thread extension convinced > James to revise the draft, where your vociferous unsubstantiated > objections had previously failed. > Speaking of which, I'm not very happy about it, but I just sent off an updated version of the Feed thread draft for publication that does away with the thr;count and thr:when attributes on the link and introduces a thr:replies element. The example below appears within the updated draft, tag:example.org,2006 Entries and Comments ... tag:example.org,2006:1 My Post 2006-05-01T08:08:08Z ... tag:example.org,2006:2 My Second Post 2006-05-01T09:09:09Z ... As you can see from the example, the thr:replies/@ref attribute points to an atom:id value, and not the URI used by the link. When going through and trying to implement the original concept with href, the xml:base issues proved to be more hassle than it was worth. Look for the updated draft to publish in the next day or so. - James From owner-atom-syntax@mail.imc.org Tue May 02 02:55:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faoml-0003US-FP for atompub-archive@lists.ietf.org; Tue, 02 May 2006 02:55:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faomk-00039S-4f for atompub-archive@lists.ietf.org; Tue, 02 May 2006 02:55:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k426cG20037281; Mon, 1 May 2006 23:38:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k426cGaG037280; Mon, 1 May 2006 23:38:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k426cEli037273 for ; Mon, 1 May 2006 23:38:15 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.29] (sera-10-169-186-29.nscp.aoltw.net [10.169.186.29]) by mcom.com (8.10.0/8.10.0) with ESMTP id k426bZJ08282; Mon, 1 May 2006 23:37:37 -0700 (PDT) Message-ID: <4456FE2C.40101@aol.net> Date: Mon, 01 May 2006 23:37:32 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> In-Reply-To: <68fba5c50605012016if7d500bnb82d52dd05186a6c@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Robert Sayre wrote: > .. Are there any > WG members left who were around at that phase? I joined right around > then... *Holds up hand. Shrugs. Goes back to work.* From owner-atom-syntax@mail.imc.org Tue May 02 08:44:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauEv-00068F-Lh for atompub-archive@lists.ietf.org; Tue, 02 May 2006 08:44:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauEv-0001fc-KG for atompub-archive@lists.ietf.org; Tue, 02 May 2006 08:44:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FauAe-0001AC-Fa for atompub-archive@lists.ietf.org; Tue, 02 May 2006 08:40:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42COU1d053102; Tue, 2 May 2006 05:24:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42COUqv053101; Tue, 2 May 2006 05:24:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42COTBT053082 for ; Tue, 2 May 2006 05:24:29 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060502122422.BWHT29343.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 2 May 2006 13:24:22 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060502122422.ZYKF24467.aamtaout02-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Tue, 2 May 2006 13:24:22 +0100 Date: Tue, 2 May 2006 13:24:21 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1453489110.20060502132421@djpowell.net> To: James M Snell CC: atom-syntax Subject: Re: Entry types In-Reply-To: <44566449.6080009@gmail.com> References: <44566449.6080009@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: X-Spam-Score: -0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Monday, May 1, 2006, 8:40:57 PM, James Snell wrote: > I'm wondering if it would make sense to have a single common "type" > scheme that could be used consistently across implementations. "Type" seems a bit vague, this seems to be mainly about describing how an entry should be processed. A few possible ways to do that: a) Using categories and a known categorisation scheme b) Using an ex:processAs extension c) Using domain specific extensions, eg d) "duck-typing", eg assuming that contact:firstName implies the type. I think that using category might be an overloading of the semantics of category?, I'm not sure, it probably depends on the circumstances. Category is really a summary of the set of real-world concepts the entry is about, it ought to be under control of the publisher. Typical Atom consumers will probably provide a UI to filter entries by category. Do consumers want the set of categories for an entry polluted with physical properties of the entry? This might be ok sometimes, but not in general. Can entries have multiple types? Like an entry that includes both the event details and contact details for the organiser? Will typical Atom infrastructures be able to dispatch entries to multiple processors, or will it be like MIME-types, where this is difficult (as in the dispatching of generic XML types based on namespace, or of RDF)? Microsoft has a screen saver sample [1] that uses Windows Feed Platform to display picture feeds. It does this without any typing, just by examining each entry in the feeds associated with the screen saver, and selecting the appropriate ones. [1] http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx I remember seeing a demo of a calendar feed that synced with Outlook, I suspect that that also relied on having the plugin decide which entries it was interested in, rather than the engine dispatch entries to specific plugins. Engine driven dispatching might be slightly more performant, but plugin driven dispatching is more flexible and doesn't need a well-known type extension to key off. Is it enough to go for the "duck-typing" approach, and not require explicit typing? But, what if all of the extensions for contacts are optional? What if some are shared with the extensions for appointments? If the rules for deciding on the type of an entry aren't specified, it might be more prone to interop problems, where one implementation detects an entry as a contact, and another doesn't. I suppose a quick vcard:* check is pretty easy with XPath. -- Dave From owner-atom-syntax@mail.imc.org Tue May 02 09:00:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauUf-0007Iy-R2 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 09:00:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauUe-0002U3-Fh for atompub-archive@lists.ietf.org; Tue, 02 May 2006 09:00:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42CmX6b054291; Tue, 2 May 2006 05:48:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42CmXH0054290; Tue, 2 May 2006 05:48:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18m8+oMEr+C02GvFo4+6rwn9u3j1hVHGec@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42CmWL6054284 for ; Tue, 2 May 2006 05:48:32 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+dlG+MmiQmzihs43RZPF+xnD3SayiDEPc@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k42CmVnJ015451 for ; Tue, 2 May 2006 07:48:31 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k42CmV7I015449; Tue, 2 May 2006 13:48:31 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain); by mail1.python-hosting.com with HTTP; Tue, 2 May 2006 13:48:31 +0100 (BST) Message-ID: <6598.194.221.74.7.1146574111.squirrel@mail1.python-hosting.com> In-Reply-To: <1453489110.20060502132421@djpowell.net> References: <44566449.6080009@gmail.com> <1453489110.20060502132421@djpowell.net> Date: Tue, 2 May 2006 13:48:31 +0100 (BST) Subject: Re: Entry types From: "Sylvain Hellegouarch" To: "atom-syntax" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.3a-11.EL3 X-Mailer: SquirrelMail/1.4.3a-11.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 > "Type" seems a bit vague, this seems to be mainly about describing how > an entry should be processed. A few possible ways to do that: > > a) Using categories and a known categorisation scheme > b) Using an ex:processAs extension > c) Using domain specific extensions, eg > d) "duck-typing", eg assuming that contact:firstName implies the type. In order of preferences: c, a, b, d > > I think that using category might be an overloading of the semantics > of category?, Well RFC 4287 says for atom:category """This specification assigns no meaning to the content (if any) of this element""" Therefore I guess it would be fine from the spec point of view. However I do agree with you that it would be overloading the general meaning we give to a category. I'm not sure, it probably depends on the circumstances. > Category is really a summary of the set of real-world concepts the > entry is about, it ought to be under control of the publisher. Agreed. > I suppose a quick vcard:* check is pretty easy with XPath. Second that point too. - Sylvain From owner-atom-syntax@mail.imc.org Tue May 02 10:03:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavTS-0005zJ-04 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 10:03:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavTQ-0005DI-En for atompub-archive@lists.ietf.org; Tue, 02 May 2006 10:03:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Dm0ND057320; Tue, 2 May 2006 06:48:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Dm0i8057319; Tue, 2 May 2006 06:48:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42DlwD6057311 for ; Tue, 2 May 2006 06:47:59 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 13:47:53 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp037) with SMTP; 02 May 2006 15:47:53 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 15:47:59 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread update Message-ID: <20060502134759.GL2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4456E86A.5020702@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad * James M Snell [2006-05-02 07:15]: > As you can see from the example, the thr:replies/@ref attribute > points to an atom:id value, and not the URI used by the link. So fetching and parsing all relevant links is the only way to know which `thr:replies` element applies to which link, and no way to indicate a global reply count is available? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 11:03:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FawOz-0005Vp-9c for atompub-archive@lists.ietf.org; Tue, 02 May 2006 11:03:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FawOx-0007P9-UE for atompub-archive@lists.ietf.org; Tue, 02 May 2006 11:03:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42EoHXk060347; Tue, 2 May 2006 07:50:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42EoH4s060346; Tue, 2 May 2006 07:50:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.229]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42EoGUU060340 for ; Tue, 2 May 2006 07:50:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2348663wra for ; Tue, 02 May 2006 07:50:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VtXjQkRkCBBxsjQOE20ehv/0LoAbkHUxWzMqbRs3viNPwtIarjM2kMKTzFS7lRSjbmjHeGUKdiGpQ/h6RuXSCVsviLqpu6CRdyvzmdmwO27WPdt4LRg72DKFJHgCXXXPX+CZmC47E+kS+FjHN76l2ThwiIUXo3KKagZ/YWFNao8= Received: by 10.54.124.3 with SMTP id w3mr763068wrc; Tue, 02 May 2006 07:50:15 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 44sm731392wri.2006.05.02.07.50.14; Tue, 02 May 2006 07:50:15 -0700 (PDT) Message-ID: <445771A5.1020101@gmail.com> Date: Tue, 02 May 2006 07:50:13 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed thread update References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> In-Reply-To: <20060502134759.GL2690@klangraum> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Aristotle, I'm not 100% happy with it yet so it may change at least one more time. But I did want to get this out and in front of y'all to get initial reactions. I'll go ahead and make the ref attribute optional. Regarding the ref vs. href, issue, I really want to discourage client implementors from using the thr:replies as a link to the comment feed. Having and href attribute in there is inviting headaches. Suggestions on possible ways of wording the spec / attribute naming / etc would be greatly appreciated. - James A. Pagaltzis wrote: > * James M Snell [2006-05-02 07:15]: >> As you can see from the example, the thr:replies/@ref attribute >> points to an atom:id value, and not the URI used by the link. > > So fetching and parsing all relevant links is the only way to > know which `thr:replies` element applies to which link, and no > way to indicate a global reply count is available? > > Regards, From owner-atom-syntax@mail.imc.org Tue May 02 12:05:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxN7-0002rc-7Q for atompub-archive@lists.ietf.org; Tue, 02 May 2006 12:05:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaxN5-0001zM-KQ for atompub-archive@lists.ietf.org; Tue, 02 May 2006 12:05:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42FlffS062897; Tue, 2 May 2006 08:47:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42FlfUA062896; Tue, 2 May 2006 08:47:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42FleYl062890 for ; Tue, 2 May 2006 08:47:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0102.google.com with SMTP id 4so2673014nzn for ; Tue, 02 May 2006 08:47:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KygIehUs0eWxz4CBheFNKUCH8vHJ8n8evbfICaM3VKMxejyaDPHvl/Hu6233UaIZEMoyHRT+W1VClcNu9SzXBujS4DqPUw7+Vz40C8TqhIXXvcByypFDyII4eudYhjTc/aZHYgAOaSwU9MZrPehT7h+l0uZos/beEbd4HXbXNc0= Received: by 10.36.77.15 with SMTP id z15mr1344163nza; Tue, 02 May 2006 08:47:40 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id h41sm805980pyh.2006.05.02.08.47.38; Tue, 02 May 2006 08:47:39 -0700 (PDT) Message-ID: <44577F18.6080009@gmail.com> Date: Tue, 02 May 2006 08:47:36 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Entry types References: <44566449.6080009@gmail.com> <1453489110.20060502132421@djpowell.net> In-Reply-To: <1453489110.20060502132421@djpowell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hey David, Just some responses to your random thoughts. My goal is not to argue that the category approach is best, but only to state the rationale behind what we've done to this point. David Powell wrote: > Monday, May 1, 2006, 8:40:57 PM, James Snell wrote: > >> I'm wondering if it would make sense to have a single common "type" >> scheme that could be used consistently across implementations. > > > > "Type" seems a bit vague, this seems to be mainly about describing how > an entry should be processed. A few possible ways to do that: > > a) Using categories and a known categorisation scheme > b) Using an ex:processAs extension > c) Using domain specific extensions, eg > d) "duck-typing", eg assuming that contact:firstName implies the type. > There are two reasons our implementation uses category to represent the kind of entry. 1. To specify how the entry should be processed (e.g. our UI shows comment entries differently than file entries) 2. To allow existing feed readers that understand the category element to present that information to users. For instance, when I load one of our feeds in Liferea, I can see right away that an entry is a Task or a Comment, or a File, etc, even tho Liferea knows absolutely nothing about our particular application. Looking at Sylvain's order of preference, I would switch c and a: In order of preferences: a, c, b, d > I think that using category might be an overloading of the semantics > of category?, I'm not sure, it probably depends on the circumstances. > Category is really a summary of the set of real-world concepts the > entry is about, it ought to be under control of the publisher. Typical > Atom consumers will probably provide a UI to filter entries by > category. Do consumers want the set of categories for an entry > polluted with physical properties of the entry? This might be ok > sometimes, but not in general. > With the category approach, I can group entries by Task, by File, by Event, etc. Note also that we're making judicious use of the category scheme to differentiate the various types of categories. For instance, we have a type scheme, we have a visibility scheme (e.g. private, public), we have a status scheme (e.g. completed, not-completed), we have a tag scheme, etc. None of the feed readers we've tested actually make good use of the scheme attribute. In fact, at least one attempts to use it as a dereferenceable URI. Hopefully, that situation improves. > Can entries have multiple types? Like an entry that includes both the > event details and contact details for the organiser? Will typical Atom In our implementation no, but it generally, it's possible. > infrastructures be able to dispatch entries to multiple processors, or > will it be like MIME-types, where this is difficult (as in the > dispatching of generic XML types based on namespace, or of RDF)? > I certainly hope not. In our case, the entry typing is used to allow us to present intelligent UI options to the user based on what kind of thing the entry is. > Microsoft has a screen saver sample [1] that uses Windows Feed > Platform to display picture feeds. It does this without any typing, > just by examining each entry in the feeds associated with the screen > saver, and selecting the appropriate ones. > > [1] http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx > > I remember seeing a demo of a calendar feed that synced with Outlook, > I suspect that that also relied on having the plugin decide which > entries it was interested in, rather than the engine dispatch entries > to specific plugins. Engine driven dispatching might be slightly more > performant, but plugin driven dispatching is more flexible and doesn't > need a well-known type extension to key off. > > Is it enough to go for the "duck-typing" approach, and not require > explicit typing? But, what if all of the extensions for contacts are > optional? What if some are shared with the extensions for > appointments? If the rules for deciding on the type of an entry aren't > specified, it might be more prone to interop problems, where one > implementation detects an entry as a contact, and another doesn't. I > suppose a quick vcard:* check is pretty easy with XPath. > > I believe there is room for both. For example, I certainly do not need a type=podcast category to determine whether or not an entry contains a podcast. However, the category-based typing does prove useful when differentiating different kinds of entries that otherwise have similar or even identical structures. For example, tag:example.org,2006:1 A Comment 2006-05-02T12:12:12Z James This is a comment tag:example.org,2006:2 A link to some other page 2006-05-02T12:12:12Z James This is a link to some other page - James From owner-atom-syntax@mail.imc.org Tue May 02 12:18:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxZv-0003ts-AQ for atompub-archive@lists.ietf.org; Tue, 02 May 2006 12:18:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaxZs-0002D5-Q1 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 12:18:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42G29E8063508; Tue, 2 May 2006 09:02:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42G29LG063507; Tue, 2 May 2006 09:02:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42G28uL063500 for ; Tue, 2 May 2006 09:02:08 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1FaxK9-0001an-UN; Tue, 02 May 2006 18:02:05 +0200 Received: from ultra17.rbg.informatik.tu-darmstadt.de ([130.83.160.107]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1FaxK9-0007Dt-Kg; Tue, 02 May 2006 18:02:05 +0200 Message-ID: <44578275.9020105@rbg.informatik.tu-darmstadt.de> Date: Tue, 02 May 2006 18:01:57 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Eric Scheid wrote: > I just reviewed the relevant example in the APP spec and it's > worrisome. Reading between the lines it suggests that the > subscription uri is "http://example.org/entries/go", with the rest of > the collection available via rel="next" through to > "http://example.org/entries/10". > > The worrisome thing is that once that collection gains another 10 > entries, then the resource "http://example.org/entries/11" will now > contain the entries which were previously contained by resource > "http://example.org/entries/10". Every page of the collection needs > to be updated and have the entries shuffled along. Yes, I have noticed this problem some time ago as well. See "Directionality of "next"/"previous": Incompatibility with Feed-History I-D (long)" [1] for some more discussion on this very subject, which led in turn to PaceReverseLinks [2], which hasn't received much support, however. :-( Andreas Sewe [1] [2] From owner-atom-syntax@mail.imc.org Tue May 02 13:05:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FayJ6-0004Gx-6F for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:05:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FayJ4-0004PW-PM for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:05:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Gn3kQ065408; Tue, 2 May 2006 09:49:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Gn3d6065407; Tue, 2 May 2006 09:49:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42Gn1iR065389 for ; Tue, 2 May 2006 09:49:02 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 16:48:55 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp042) with SMTP; 02 May 2006 18:48:55 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 18:49:02 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502164902.GN2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42Gn3kQ065408 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 * Robert Sayre [2006-05-02 05:25]: > On 5/1/06, A. Pagaltzis wrote: > >* Robert Sayre [2006-05-02 03:50]: > >> especially when changes requested by the community are met > >> with hostility and channel flooding. > > > >Did this happen in more cases than the one I'm aware of? >=20 > Yes. Such as? > >> When I read terms like "more standard" wrt the feed thread > >> extension, it makes me cringe. > > > >There are obvious reasons why that one is better than the rag-tag > >group of RSS extensions... >=20 > Disagree. There is no proof of that. There is proof that the existing patchwork of RSS extensions is insufficient. That is enough to convince me that an extension which addresses their holes is useful. If addressing holes in existing standards was unnecessary, then RSS is good enough and the Atom was a giant waste of time. > I disagree with many decisions in the draft, but that is > because I think they are misguided, not because I dislike the > person who wrote them. For instance, every other threading > extension uses a simple element with a number to represent the > number of responses. That is just one case. I agree that the current setup in the FTE is less than pretty, and I=E2=80=99d like it to change; but I see what motivated the form of the provided features and so I consider them incomplete rather than completely misguided. > This is limited in theory, but in practice, such elements are > so easy to deploy, they prove valuable. I agree with that. (See my proposition elsewhere, which would have provided this as a special case; it does bother me that the revision that was just published does not provide for this.) > >> for that excludes the IETF from defining the problem. > > > >How do you mean? (Question to be taken at face value. I > >honestly am not sure what you mean here.) > > >=20 > Defining the charter, etc, etc. It's a good thing to do. Are > there any WG members left who were around at that phase? I > joined right around then... You mean there should be a formal agreed-on statement of what an I-D is supposed to achieve before the process starts? If that is what you mean: yes, that is definitely a fine idea. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 13:10:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FayO2-0007KR-0D for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:10:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FayO0-0004aj-KT for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:10:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42GtBFd065674; Tue, 2 May 2006 09:55:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42GtBDM065673; Tue, 2 May 2006 09:55:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42GsreH065645 for ; Tue, 2 May 2006 09:55:10 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 16:54:47 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp035) with SMTP; 02 May 2006 18:54:47 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 18:54:54 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread update Message-ID: <20060502165454.GO2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <445771A5.1020101@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42GtBFd065674 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a * James M Snell [2006-05-02 17:00]: > I'll go ahead and make the ref attribute optional. I think that still needs to be accompanied with verbiage about global vs local reply count though. There should be guidance on what it means when elements both with and without `ref` attributes are present on the same entry. > Regarding the ref vs. href, issue, I really want to discourage > client implementors from using the thr:replies as a link to the > comment feed. Having and href attribute in there is inviting > headaches. Suggestions on possible ways of wording the spec / > attribute naming / etc would be greatly appreciated. Okay, I can see that. Harumpf. Not happy; there has to be a way to associate links directly with `thr:replies` elements and the only other way than by comparing `href`s that I can think of is to put a namespaced attribute on the link, which sucks for reasons we=E2=80=99ve already been over. Will have to read this revision and think about it. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 13:23:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fayb2-0001oP-3b for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:23:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fayaz-0005Oq-Nm for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:23:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42H6WND066399; Tue, 2 May 2006 10:06:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42H6Wgl066398; Tue, 2 May 2006 10:06:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42H6Voe066392 for ; Tue, 2 May 2006 10:06:32 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so3135729pyc for ; Tue, 02 May 2006 10:06:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NeU4LFAwiRHnOVUaSndsn+C0QltPtijnKF8Z+m+JKOTse2dSAkJKnc6rBwy+JXTkzTzO34e53roGQB/zdgd27NTmdteVtOFEhqzVq6GI/s2YlLP3GOVFEc46anxnObEv4SKVQ7CBHJbauaZz2q3oP9s4ndh2ZJftVLcMRauGow8= Received: by 10.35.49.4 with SMTP id b4mr1298009pyk; Tue, 02 May 2006 10:06:31 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 10:06:31 -0700 (PDT) Message-ID: <68fba5c50605021006j243ac47bpe74a0530b80ee2b5@mail.gmail.com> Date: Tue, 2 May 2006 13:06:31 -0400 From: "Robert Sayre" To: atom-syntax Subject: Re: Atom Rank Extensions In-Reply-To: <20060502164902.GN2690@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k42H6Woe066393 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On 5/2/06, A. Pagaltzis wrote: > > Such as? Not appropriate for on-list discussion, sorry. > > >> When I read terms like "more standard" wrt the feed thread > > >> extension, it makes me cringe. > > > > > >There are obvious reasons why that one is better than the rag-tag > > >group of RSS extensions... > > > > Disagree. There is no proof of that. > > There is proof that the existing patchwork of RSS extensions is > insufficient. That is enough to convince me that an extension > which addresses their holes is useful. > > If addressing holes in existing standards was unnecessary, then > RSS is good enough and the Atom was a giant waste of time. > I don't I follow your reasoning. We have namespaces so vendors can create whatever they might like, without involving the standards organization. I fail to see the point in rubber-stamping such things. > > You mean there should be a formal agreed-on statement of what an > I-D is supposed to achieve before the process starts? If that is > what you mean: yes, that is definitely a fine idea. And WG chairs, etc, etc. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 02 13:56:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faz7A-0005Nz-TW for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:56:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faz7A-0007Y2-Ha for atompub-archive@lists.ietf.org; Tue, 02 May 2006 13:56:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42HhKTp068580; Tue, 2 May 2006 10:43:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42HhK9g068579; Tue, 2 May 2006 10:43:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42HhJRu068572 for ; Tue, 2 May 2006 10:43:20 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id i24so2390045wra for ; Tue, 02 May 2006 10:43:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hfxBoKz9w1BQpL3Q2GCQ0oUk927MEEvKB4FsOuFykDo60scZczKY1Q+AEvOjnp2GW3bGfPXghaJ6DFNniTZbpsdMxB4OW7haZupEFhPe/4ij4kiTTdu3VEfuS+tv8+kE+iQzTKheSIhKj8p3/S8cNkhu397cr7P/8e3WHLZZahA= Received: by 10.54.108.11 with SMTP id g11mr875219wrc; Tue, 02 May 2006 10:43:19 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 66sm2159693wra.2006.05.02.10.43.18; Tue, 02 May 2006 10:43:18 -0700 (PDT) Message-ID: <44579A33.3030404@gmail.com> Date: Tue, 02 May 2006 10:43:15 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: pagaltzis@gmx.de, atom-syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> In-Reply-To: <20060502164902.GN2690@klangraum> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 A. Pagaltzis wrote: > * Robert Sayre [2006-05-02 05:25]: >> On 5/1/06, A. Pagaltzis wrote: >>> * Robert Sayre [2006-05-02 03:50]: >>>> especially when changes requested by the community are met >>>> with hostility and channel flooding. >>> Did this happen in more cases than the one I'm aware of? >> Yes. > > Such as? > Aristotle, I appreciate the intention, but please don't bother. It is painfully clear that Robert has no intention of adding anything of any real value to the discussion. As far as FTE is concerned, please understand that I am trying to find the best way of accommodating a mix between "The simplest thing that could possibly work" with "The way things likely ought to work". I consider MSFT's decision to not preserve unknown foreign content to be extremely shortsighted. To contrast, in my implementation, supporting thr:when and thr:count as attributes on link requires no additional code, I can simply link.getAttribute(whenQname) and get the info I need. With the thr:replies element, to do it properly, I have to create a new extension element, create a factory, register the extension with the parser, etc. Adding in the difficulties inherent in matching equivalent href values between the atom:link and thr:replies element means that I'm having to do a whole lot more work than what is required with the attribute approach. So much, in fact, that I'm fairly certain that folks will be less likely to implement a FTE that incorporates the thr:replies element. So if I seem grumpy and reluctant to change, please try to be patient and understand. - James From owner-atom-syntax@mail.imc.org Tue May 02 14:02:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazCJ-0007IA-SJ for atompub-archive@lists.ietf.org; Tue, 02 May 2006 14:02:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazCF-0007cv-Fv for atompub-archive@lists.ietf.org; Tue, 02 May 2006 14:02:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42HphDM068919; Tue, 2 May 2006 10:51:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42HphjY068918; Tue, 2 May 2006 10:51:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Hpgte068903 for ; Tue, 2 May 2006 10:51:42 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id 4so2710173nzn for ; Tue, 02 May 2006 10:51:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=aMokwo5fgpOpoF4VRaWDs/iWi+2Qlo7FNFeuHd6XfP7hphMKA1xEqcA4lKWcRsjNNrQo9W62QEMjPSZtECRdi4RbUzZshvuMO5iC0IQjvJDu+gIhChxJrmPXnS040kECBXWcrol/tv0jebScQS1qcqMTt8YnGYmQBJ9HIzgz5Sw= Received: by 10.64.193.18 with SMTP id q18mr612531qbf; Tue, 02 May 2006 10:51:41 -0700 (PDT) Received: by 10.65.210.9 with HTTP; Tue, 2 May 2006 10:51:41 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 11:51:41 -0600 From: "M. David Peterson" To: "Atom Syntax" Subject: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k42Hphte068905 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 I can only assume that someone from Opera is on this list, and I'm not even sure this is that big of a deal, but then again.... From: http://my.opera.com/community/customize/widgets/info/?id=4021 This feed allows subscribing to an unlimited number of news feeds. Supported formats: RSS 2 and > Atom 2 <. Thus providing an advantage over per-site news feed aggregators. --- I realized Web2 is the hot "new" thing, but and RSS 2 is obviously not an issue (well, not from the standpoint of improper promotion of the so called version #) but if not mistaken, the Atom community will never have the need for an Atom 2.0 spec, so it might be worth pinging whomever developed the above widget to let them know they need to fix this. NOTE: Would have done so myself, but can't seem to find a place to post a note other than through the ratings panel, and I can only assume that, like the Fx community, the Opera community would prefer that bug reports don't come through the ratings channel. Thanks in advance! -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Tue May 02 14:30:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazeB-0008Ev-9x for atompub-archive@lists.ietf.org; Tue, 02 May 2006 14:30:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faze9-0000Er-Vi for atompub-archive@lists.ietf.org; Tue, 02 May 2006 14:30:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42IJW2B070408; Tue, 2 May 2006 11:19:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42IJWW6070407; Tue, 2 May 2006 11:19:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42IJVUv070401 for ; Tue, 2 May 2006 11:19:31 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so3154825pyc for ; Tue, 02 May 2006 11:19:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S/qkn2zon2g1vwHPutpU2E23XSD7lven4HQrXyn7bDw+WkkLzUbSdOTHcT7lO2mYRZJzGN4omVQH0I1cZUEH8IMyjvg4PrbE3cTHXMNlnF0w8XXKBqvs+w3InZ+cwiZdGNCgYyv2I2Z+n82hXvbS5WZgYGCDNQ+mkbXHVTi7Q6o= Received: by 10.35.84.12 with SMTP id m12mr1418009pyl; Tue, 02 May 2006 11:19:30 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 11:19:30 -0700 (PDT) Message-ID: <68fba5c50605021119k29a79c31q7a6d83d1b7db4e7e@mail.gmail.com> Date: Tue, 2 May 2006 14:19:30 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Atom Rank Extensions Cc: pagaltzis@gmx.de, atom-syntax In-Reply-To: <44579A33.3030404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k42IJVUv070402 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 5/2/06, James M Snell wrote: > > Aristotle, I appreciate the intention, but please don't bother. It is > painfully clear that Robert has no intention of adding anything of any > real value to the discussion. > ??? -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 02 15:14:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0KE-0001oA-13 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 15:14:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0KC-00025K-JG for atompub-archive@lists.ietf.org; Tue, 02 May 2006 15:14:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Iuucp072425; Tue, 2 May 2006 11:56:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42IuuRJ072424; Tue, 2 May 2006 11:56:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42Iusnv072416 for ; Tue, 2 May 2006 11:56:54 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 18:56:48 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp037) with SMTP; 02 May 2006 20:56:48 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 20:56:55 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502185655.GW2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <44579A33.3030404@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42Iuucp072425 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d * James M Snell [2006-05-02 19:45]: > A. Pagaltzis wrote: > > Such as? >=20 > Aristotle, I appreciate the intention, but please don't bother. > It is painfully clear that Robert has no intention of adding > anything of any real value to the discussion. I know. However, I despise politics and old boys clubs and prefer the merit of my decisions to be self-evident, so I=E2=80=99m avoiding any assumption of any axe to grind behind his behaviour, to see what should be addressed and how. If there is any meritorious concern in his objections, I=E2=80=99d like it addressed, regardless (despite?) of who brought them up and how. > As far as FTE is concerned, please understand that I am trying > to find the best way of accommodating a mix between "The > simplest thing that could possibly work" with "The way things > likely ought to work". Absolutely; I pushed for some of the compromises in the current design myself. > With the thr:replies element, to do it properly, I have to > create a new extension element, create a factory, register the > extension with the parser, etc. Adding in the difficulties > inherent in matching equivalent href values between the > atom:link and thr:replies element means that I'm having to do a > whole lot more work than what is required with the attribute > approach. I have to say that your architecture sounds rather heavyweight, though it could be close to the norm for people who don=E2=80=99t work at the DOM level. I don=E2=80=99t have experience with that. To give my experience from the other end, all my work has been at the DOM level, where the approaches differ only minimally. libxml2 provides a `getBase` method which makes xml:base support effortless; when I use XSLT to transform Atom feed documents, I wrap it and register it as an extension function, so matching `href`s is trivial: > So much, in fact, that I'm fairly certain that folks will be > less likely to implement a FTE that incorporates the > thr:replies element. I can see that. Hrmf. There=E2=80=99s gotta be a better way=E2=80=A6 I hope though that this also gives you an appreciation for Robert=E2=80=99s complaint about the lack of a global reply count provision. He=E2=80=99s right: for simple use cases that sidesteps a lot of headaches on the consumer=E2=80=99s end. > So if I seem grumpy and reluctant to change, please try to be > patient and understand. Yes, I see now how it comes about. However, referring to above, plus what we know about the Windows RSS Platform, please don=E2=80=99t forget the cases other than your own. Let=E2=80=99s see if we can come up with something that is as simple to implement as possible for everyone=E2=80=A6 Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 15:57:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0zp-0000YU-6y for atompub-archive@lists.ietf.org; Tue, 02 May 2006 15:57:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0zm-0004wt-RD for atompub-archive@lists.ietf.org; Tue, 02 May 2006 15:57:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Jh50w074937; Tue, 2 May 2006 12:43:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Jh5e0074936; Tue, 2 May 2006 12:43:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Jh45u074929 for ; Tue, 2 May 2006 12:43:04 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so3175778pyc for ; Tue, 02 May 2006 12:43:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rtsVpkIAEQIkaeV/O1QvjR/kb34o3z126lIalmBnpTwe8z+rh+j9YbcVjmwgoN85TM2A+4MYnRsklhisFepntV2LyknUqq2DBvSJhWSGe/lA80vmnKp3DlsUfoyBSI5ZlN0g1unjTyxmpktcnFqW2KRJ+2FCSdrqkGbyuv51RmY= Received: by 10.35.105.18 with SMTP id h18mr1531539pym; Tue, 02 May 2006 12:43:04 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 12:43:04 -0700 (PDT) Message-ID: <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> Date: Tue, 2 May 2006 15:43:04 -0400 From: "Robert Sayre" To: atom-syntax Subject: Re: Atom Rank Extensions In-Reply-To: <20060502185655.GW2690@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k42Jh55u074930 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On 5/2/06, A. Pagaltzis wrote: > > * James M Snell [2006-05-02 19:45]: > > A. Pagaltzis wrote: > > > Such as? > > > > Aristotle, I appreciate the intention, but please don't bother. > > It is painfully clear that Robert has no intention of adding > > anything of any real value to the discussion. > > I know. However, I despise politics and old boys clubs and prefer > the merit of my decisions to be self-evident, so I'm avoiding any > assumption of any axe to grind behind his behaviour, to see what > should be addressed and how. If there is any meritorious concern > in his objections, I'd like it addressed, regardless (despite?) > of who brought them up and how. > I've been saying the same thing for weeks. I suppose it's par for the course to handwave about them being "strictly advisory", supply circular definitions for the feature in the first place, claim no one will be implementing the feature, then claim that someone is, etc, etc. You know, stuffing an idea because of who proposed it. You can go read the atom-protocol archives if you want more evidence of that. The general pattern seems to be to sanctimoniously scold me for making the suggestion, and then to adopt it with cosmetic changes. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 02 16:23:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1P3-0006zh-Qz for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:23:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1P2-00060Q-CV for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:23:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KD06I076354; Tue, 2 May 2006 13:13:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42KD0ic076353; Tue, 2 May 2006 13:13:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KD0V0076347 for ; Tue, 2 May 2006 13:13:00 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so4396wri for ; Tue, 02 May 2006 13:12:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ompJiHLuQZmllZQi8auGkDBEM32pe81gb70mjU7yGGUlhDM4hcaA2AW2EeN2a9XVaAqkyhhumfqzyb7/lUbFXPrV5gXhWcHzCrMwey+GIj0Ja2etN1h8Snw1ALAxMm+BioK1ghfytv4aDEs5XWkaMJ5OgwqJKluR4EgZN6RGJdg= Received: by 10.54.61.11 with SMTP id j11mr3265wra; Tue, 02 May 2006 13:12:12 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 7sm390935wrl.2006.05.02.13.12.58; Tue, 02 May 2006 13:12:59 -0700 (PDT) Message-ID: <4457BD48.9070602@gmail.com> Date: Tue, 02 May 2006 13:12:56 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> In-Reply-To: <20060502185655.GW2690@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42KD06I076354 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e A. Pagaltzis wrote: >[snip] >> With the thr:replies element, to do it properly, I have to >> create a new extension element, create a factory, register the >> extension with the parser, etc. Adding in the difficulties >> inherent in matching equivalent href values between the >> atom:link and thr:replies element means that I'm having to do a >> whole lot more work than what is required with the attribute >> approach. >=20 > I have to say that your architecture sounds rather heavyweight, > though it could be close to the norm for people who don=E2=80=99t work = at > the DOM level. I don=E2=80=99t have experience with that. >=20 Heavyweight? It's Java. need I say more? By "do it properly", I mean being able to provide developers with an interface that understands the thread extension, it's a difference betwee= n: Option 1, which does not require adding any additional classes ExtensionElement el =3D entry.getExtension(thrReplies); int count =3D el.getAttribute("count"); Date updated =3D AtomDate.valueOf(el.getAttribute("updated")); and Option 2, which does require adding additional classes Replies replies =3D entry.getExtension(thrReplies); int count =3D replies.getCount(); Date updated =3D replies.getUpdated(); My implementation supports either. Getting the resolved href's for the link and replies is simple. Matching up all of the various equivalents is a pain. URI uri1 =3D link.getResolvedHref(); URI uri2 =3D replies.getResolvedHref(); // normalize and compare the uri's > To give my experience from the other end, all my work has been at > the DOM level, where the approaches differ only minimally. > libxml2 provides a `getBase` method which makes xml:base support > effortless; when I use XSLT to transform Atom feed documents, I > wrap it and register it as an extension function, so matching > `href`s is trivial: >=20 > name=3D"link-to-uri" > match=3D"atom:link" > use=3D"uri:resolve( uri:base( . ), @href )" > /> >=20 Does your implementation properly handle the following (contrived) exampl= e: ... ... I know for a fact that Java's built-in comparison functions for the URI and URL classes do not. I have to normalize the URI's after I resolve them before I can compare them. What's more, for each replies link, I need to iterate through all available thr:replies elements, resolve, normalize and compare each href. Pain. It is possible that the spec could dictate that the thr:replies resolved href attribute MUST match the link's href attribute character-for-character, making the above example invalid. >> So much, in fact, that I'm fairly certain that folks will be >> less likely to implement a FTE that incorporates the >> thr:replies element. >=20 > I can see that. Hrmf. There=E2=80=99s gotta be a better way=E2=80=A6 >=20 ;-) Yes, there is a better way, but y'all complained about it ;-) (sorry, couldn't resist) >[snip] > Let=E2=80=99s see if we can come up with something that is as simple to > implement as possible for everyone=E2=80=A6 >=20 As always, suggestions for spec text are always welcomed. oh, and btw, draft -09 is now available. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-09.tx= t - James From owner-atom-syntax@mail.imc.org Tue May 02 16:29:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1UT-0005Ba-Fx for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:29:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1UR-0006Pn-SV for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:29:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KI1Uj076487; Tue, 2 May 2006 13:18:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42KI19g076486; Tue, 2 May 2006 13:18:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KI1sH076477 for ; Tue, 2 May 2006 13:18:01 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so6738wra for ; Tue, 02 May 2006 13:18:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=m+TViYuth9ciiUVrApZ7xOL+qMy862+UoieIsl0zP/dS+nMFEVtD6DtE/AOsUXJmc8oKdovZF0+473jjDcmjvKVTO2WDbOK+cv9VwYpG3BTrNpGmGAxUI7BMKEUAt1cxvPNhsWixvlKPidjBTosrJ0WZ9VpcE/95SusSY6s6ycw= Received: by 10.54.101.18 with SMTP id y18mr1037869wrb; Tue, 02 May 2006 13:18:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm943573wra.2006.05.02.13.17.59; Tue, 02 May 2006 13:17:59 -0700 (PDT) Message-ID: <4457BE72.5050100@gmail.com> Date: Tue, 02 May 2006 13:17:54 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> In-Reply-To: <44569816.6090708@gmail.com> 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: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Just a quick heads up. To illustrate a simple example of feed rank bein used, I put together an xslt that renders my Netflix Queue as an Atom feed using the feed rank, feed history and MSFT simple list extensions. http://tinyurl.com/nxzgh Please excuse the tinyurl, the real URL for the feed is big and ugly because it goes through the W3C online xslt servlet to produce the result. You can find the original URL on my blog: http://www.snellspace.com/wp/?p=312 - James James M Snell wrote: > All, > > A new draft of the Feed Rank extension has been published. Andreas Sewe > has joined on as an author and has contributed significantly to this rev > of the draft. There are many updates to the extension that are worth > highlighting. > > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-09.txt > > First, the purpose of this extension is to provide a flexible means of > ranking entries within a feed. For instance, a feed might represent an > ordered listing of items from a movie rental queue; or each entry in a > feed might contain a five star review ranking; or each entry in the feed > might represent a listing of a students graded homework assignment, > where each rank represents the grade assigned to the work, etc. > > For example, when combined with Mark Nottingham's Feed History extension > for marking a feed as "complete", Feed Rank provides a good solution for > representing a movie rental queue: > > xmlns:r="http://purl.org/syndication/rank/1.0"> > tag:example.org,2006:my_movie_queue > > My Movie Queue > 2006-05-01T12:00:00Z > James > > > label="Queue Position" > significance="descending"> > > > label="Customer Reviews" > signifiance="ascending"> > step="0.5" scale="1" /> > > > tag:example.org,2006:movies/chaplin/citylights > City Lights > 2006-05-01T12:00:00Z > > Charlie Chaplin's cassic film > scheme="tag:example.org,2006:my_movie_queue">1 > domain="tag:example.org,2006:movie_reviews" > scheme="tag:example.org,2006:movie_reviews">4.5 > > > tag:example.org,2006:movies/chaplin/moderntimes > Modern Times > 2006-05-01T12:00:00Z > > Another Chaplin classic > scheme="tag:example.org,2006:my_movie_queue">3 > domain="tag:example.org,2006:movie_reviews" > scheme="tag:example.org,2006:movie_reviews">3.5 > > > tag:example.org,2006:movies/chaplin/thegoldrush > The Gold Rush > 2006-05-01T12:00:00Z > > Chaplin in a frozen wilderness > scheme="tag:example.org,2006:my_movie_queue">2 > domain="tag:example.org,2006:movie_reviews" > scheme="tag:example.org,2006:movie_reviews">5.0 > > > > While there are a variety of changes throughout the entire spec, the key > differences in this draft lie in the definition of the Ranking Schemes. > A Ranking Scheme is now defined as a set of discreet values and/or > ranges. > > For instance, a typical U.S. grading scheme can be represented using a > series of ranges representing percentage values: > > label="Percentage Grading System" > significance="ascending"> > minimum="0.00" > maximum="0.59" > scale="2" > step="0.01" /> > minimum="0.60" > maximum="0.69" > scale="2" > step="0.01" /> > minimum="0.70" > maximum="0.79" > scale="2" > step="0.01" /> > minimum="0.80" > maximum="0.89" > scale="2" > step="0.01" /> > minimum="0.90" > maximum="0.99" > scale="2" > step="0.01" /> > scale="2">1.00 > > > In contrast, the typical German grading scheme can be represented as a > set of discreet values: > > label="Grading System" > significance="descending"> > 1.0 > 1.3 > 1.7 > 2.0 > 2.3 > 2.7 > 3.0 > 3.3 > 3.7 > 4.0 > 4.3 > 4.7 > 5.0 > 5.3 > 5.7 > 6.0 > > > Anyway, as always, feedback is welcomed and requested. > > - James > From owner-atom-syntax@mail.imc.org Tue May 02 16:45:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1kE-0005Zb-BU for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:45:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1kA-0007TL-O3 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:45:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KYjYs077274; Tue, 2 May 2006 13:34:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42KYjNQ077273; Tue, 2 May 2006 13:34:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KYifm077267 for ; Tue, 2 May 2006 13:34:44 -0700 (MST) (envelope-from mihai.sucan@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so2083nfc for ; Tue, 02 May 2006 13:34:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:references:organization:content-type:mime-version:content-transfer-encoding:message-id:in-reply-to:user-agent; b=ozWdf+PdCdX5yrSCWvIhnm35lToJf7yubNIJ9bgRZ2HpPBeixtZ5EFHZeOwrVf6HFpMJS8KtdWVSZ6RgV6RVuqXQiMIcCAl0yfNcjEQLM2lWhjv0ur0k/g+GpHT279si3yY3Y3s+Z/A5ZKPy3ijtSXikLuXyaadmRsxlQmlJSts= Received: by 10.49.5.5 with SMTP id h5mr858753nfi; Tue, 02 May 2006 13:34:43 -0700 (PDT) Received: from localhost.localdomain ( [86.34.246.154]) by mx.gmail.com with ESMTP id x1sm39645nfb.2006.05.02.13.34.42; Tue, 02 May 2006 13:34:43 -0700 (PDT) Date: Tue, 02 May 2006 23:34:39 +0300 From: "Mihai Sucan" To: "M. David Peterson" , "Atom Syntax" Subject: Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community References: Organization: http://www.robodesign.ro Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.51 (Linux, build 1462) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42KYjYs077274 X-Spam-Score: 1.9 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Le Tue, 02 May 2006 20:51:41 +0300, M. David Peterson =20 a =C3=A9crit: > > I can only assume that someone from Opera is on this list, and I'm not > even sure this is that big of a deal, but then again.... > > > From: http://my.opera.com/community/customize/widgets/info/?id=3D4021 > > This feed allows subscribing to an unlimited number of news feeds. > Supported formats: RSS 2 and > Atom 2 <. Thus providing an advantage > over per-site news feed aggregators. > --- > > I realized Web2 is the hot "new" thing, but and RSS 2 is obviously not > an issue (well, not from the standpoint of improper promotion of the > so called version #) but if not mistaken, the Atom community will > never have the need for an Atom 2.0 spec, so it might be worth pinging > whomever developed the above widget to let them know they need to fix > this. > > NOTE: Would have done so myself, but can't seem to find a place to > post a note other than through the ratings panel, and I can only > assume that, like the Fx community, the Opera community would prefer > that bug reports don't come through the ratings channel. > > Thanks in advance! > > -- > > > M. David Peterson > http://www.xsltblog.com/ > Hello! I happend to be subscribed to this mailing list. Just joined this week. I am the author of the widget. Yes, my mistake. Appologies. I'll update the widget and I'll ask the editors of My Opera community sit= e =20 to fix that. I must make myself very clear, it was *not* my intention to use improper = =20 version number and to falsely promote Atom 2 support. Thank you very much for posting this, yet I would have been glad if you =20 would've contacted me first via my site. --=20 http://www.robodesign.ro ROBO Design - We bring you the future From owner-atom-syntax@mail.imc.org Tue May 02 16:52:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1rY-00071R-LQ for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:52:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1rY-0007n7-1Z for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:52:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KfCWI077814; Tue, 2 May 2006 13:41:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42KfCmL077813; Tue, 2 May 2006 13:41:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wproxy.gmail.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KfBCH077804 for ; Tue, 2 May 2006 13:41:11 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so3462wri for ; Tue, 02 May 2006 13:41:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VyHSww6VdV7Uiyn5dffeNzmt6I5YFPqpausewqgGlJ5KjHL0VEbnrt03BuTTXmJDyCesX4Qhw1qF8ljOtJfU1XvT/OLPxyXggncaEFph6a5hO6pOdn7bwLOde186/1zpGU7sBDaj3jgMyTyhv8zlOzZEz6Lc22CeVy3oH9dYaJ0= Received: by 10.65.15.19 with SMTP id s19mr724804qbi; Tue, 02 May 2006 13:41:10 -0700 (PDT) Received: by 10.65.210.9 with HTTP; Tue, 2 May 2006 13:41:10 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 14:41:10 -0600 From: "M. David Peterson" To: "Mihai Sucan" Subject: Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69005_24193021.1146602470312" References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.6 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 ------=_Part_69005_24193021.1146602470312 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VmVyeSBjb29sISAgVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlcGx5IDopCgpyZTogSSBtdXN0IG1h a2UgbXlzZWxmIHZlcnkgY2xlYXIsIGl0IHdhcyAqbm90KiBteSBpbnRlbnRpb24gdG8gdXNlIGlt cHJvcGVyCnZlcnNpb24gbnVtYmVyIGFuZCB0byBmYWxzZWx5IHByb21vdGUgQXRvbSAyIHN1cHBv cnQuCgpNeSBhcG9sb2dpZXMgaWYgSSBjYW1lIGFjcm9zcyB0aGUgd3Jvbmcgd2F5Li4uIEkgd2Fz bid0IG1lYW5pbmcgdG8gY2FsbCB5b3UKb3V0IGFuZCBzdWdnZXN0IHNvbWV0aGluZyBldmlsIGhh ZCB0YWtlbiBwbGFjZS4uLiBJIGhhdmUganVzdCBzZWVuIHRoaW5ncwpsaWtlIHRoaXMgYmUgdGFr ZW4gdG8gbWVhbiAiVGhlcmUncyBhIHZlcnNpb24gdHdvIG9uIGl0cyB3YXk/IiBvciBldmVuCnNv bWV0aGluZyBhcyBzaW1wbGUgYXMgYXNzdW1pbmcgdGhhdCBpbiBmYWN0LCBBdG9tIDIgaXMgdGhl IGN1cnJlbnQgdmVyc2lvbgphbmQgc2ltcGx5IGFjY2VwdCwgdG8gdGhlbiBwcm9wb2dyYXRlIHRo aXMgaW5mb3JtYXRpb24uICBJIHNpbXBseSB3YW50ZWQgdG8KbWFrZSBzdXJlIHRoYXQgdGhpcyBk aWRuJ3QgdGFrZSBwbGFjZS4KClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJlc3BvbnNlIGFuZCBmb3Ig dGFraW5nIHRoZSBzdGVwcyB0byBnZXQgaXQgZml4ZWQhIDopCgoKCk9uIDUvMi8wNiwgTWloYWkg U3VjYW4gPG1paGFpLnN1Y2FuQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPiBMZSBUdWUsIDAyIE1heSAy MDA2IDIwOjUxOjQxICswMzAwLCBNLiBEYXZpZCBQZXRlcnNvbgo+IDx4bWxoYWNrZXJAZ21haWwu Y29tPiBhIMOpY3JpdDoKPgo+ID4KPiA+IEkgY2FuIG9ubHkgYXNzdW1lIHRoYXQgc29tZW9uZSBm cm9tIE9wZXJhIGlzIG9uIHRoaXMgbGlzdCwgYW5kIEknbSBub3QKPiA+IGV2ZW4gc3VyZSB0aGlz IGlzIHRoYXQgYmlnIG9mIGEgZGVhbCwgYnV0IHRoZW4gYWdhaW4uLi4uCj4gPgo+ID4KPiA+IEZy b206IGh0dHA6Ly9teS5vcGVyYS5jb20vY29tbXVuaXR5L2N1c3RvbWl6ZS93aWRnZXRzL2luZm8v P2lkPTQwMjEKPiA+Cj4gPiBUaGlzIGZlZWQgYWxsb3dzIHN1YnNjcmliaW5nIHRvIGFuIHVubGlt aXRlZCBudW1iZXIgb2YgbmV3cyBmZWVkcy4KPiA+IFN1cHBvcnRlZCBmb3JtYXRzOiBSU1MgMiBh bmQgPiBBdG9tIDIgPC4gVGh1cyBwcm92aWRpbmcgYW4gYWR2YW50YWdlCj4gPiBvdmVyIHBlci1z aXRlIG5ld3MgZmVlZCBhZ2dyZWdhdG9ycy4KPiA+IC0tLQo+ID4KPiA+IEkgcmVhbGl6ZWQgV2Vi MiBpcyB0aGUgaG90ICJuZXciIHRoaW5nLCBidXQgYW5kIFJTUyAyIGlzIG9idmlvdXNseSBub3QK PiA+IGFuIGlzc3VlICh3ZWxsLCBub3QgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiBpbXByb3BlciBw cm9tb3Rpb24gb2YgdGhlCj4gPiBzbyBjYWxsZWQgdmVyc2lvbiAjKSBidXQgaWYgbm90IG1pc3Rh a2VuLCB0aGUgQXRvbSBjb21tdW5pdHkgd2lsbAo+ID4gbmV2ZXIgaGF2ZSB0aGUgbmVlZCBmb3Ig YW4gQXRvbSAyLjAgc3BlYywgc28gaXQgbWlnaHQgYmUgd29ydGggcGluZ2luZwo+ID4gd2hvbWV2 ZXIgZGV2ZWxvcGVkIHRoZSBhYm92ZSB3aWRnZXQgdG8gbGV0IHRoZW0ga25vdyB0aGV5IG5lZWQg dG8gZml4Cj4gPiB0aGlzLgo+ID4KPiA+IE5PVEU6IFdvdWxkIGhhdmUgZG9uZSBzbyBteXNlbGYs IGJ1dCBjYW4ndCBzZWVtIHRvIGZpbmQgYSBwbGFjZSB0bwo+ID4gcG9zdCBhIG5vdGUgb3RoZXIg dGhhbiB0aHJvdWdoIHRoZSByYXRpbmdzIHBhbmVsLCBhbmQgSSBjYW4gb25seQo+ID4gYXNzdW1l IHRoYXQsIGxpa2UgdGhlIEZ4IGNvbW11bml0eSwgdGhlIE9wZXJhIGNvbW11bml0eSB3b3VsZCBw cmVmZXIKPiA+IHRoYXQgYnVnIHJlcG9ydHMgZG9uJ3QgY29tZSB0aHJvdWdoIHRoZSByYXRpbmdz IGNoYW5uZWwuCj4gPgo+ID4gVGhhbmtzIGluIGFkdmFuY2UhCj4gPgo+ID4gLS0KPiA+IDxNOkQv Pgo+ID4KPiA+IE0uIERhdmlkIFBldGVyc29uCj4gPiBodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8K PiA+Cj4KPiBIZWxsbyEKPgo+IEkgaGFwcGVuZCB0byBiZSBzdWJzY3JpYmVkIHRvIHRoaXMgbWFp bGluZyBsaXN0LiBKdXN0IGpvaW5lZCB0aGlzIHdlZWsuCj4KPiBJIGFtIHRoZSBhdXRob3Igb2Yg dGhlIHdpZGdldC4gWWVzLCBteSBtaXN0YWtlLiBBcHBvbG9naWVzLgo+Cj4gSSdsbCB1cGRhdGUg dGhlIHdpZGdldCBhbmQgSSdsbCBhc2sgdGhlIGVkaXRvcnMgb2YgTXkgT3BlcmEgY29tbXVuaXR5 IHNpdGUKPiB0byBmaXggdGhhdC4KPgo+IEkgbXVzdCBtYWtlIG15c2VsZiB2ZXJ5IGNsZWFyLCBp dCB3YXMgKm5vdCogbXkgaW50ZW50aW9uIHRvIHVzZSBpbXByb3Blcgo+IHZlcnNpb24gbnVtYmVy IGFuZCB0byBmYWxzZWx5IHByb21vdGUgQXRvbSAyIHN1cHBvcnQuCj4KPiBUaGFuayB5b3UgdmVy eSBtdWNoIGZvciBwb3N0aW5nIHRoaXMsIHlldCBJIHdvdWxkIGhhdmUgYmVlbiBnbGFkIGlmIHlv dQo+IHdvdWxkJ3ZlIGNvbnRhY3RlZCBtZSBmaXJzdCB2aWEgbXkgc2l0ZS4KPgo+Cj4gLS0KPiBo dHRwOi8vd3d3LnJvYm9kZXNpZ24ucm8KPiBST0JPIERlc2lnbiAtIFdlIGJyaW5nIHlvdSB0aGUg ZnV0dXJlCj4KCgoKLS0KPE06RC8+CgpNLiBEYXZpZCBQZXRlcnNvbgpodHRwOi8vd3d3LnhzbHRi bG9nLmNvbS8K ------=_Part_69005_24193021.1146602470312 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5WZXJ5IGNvb2whJm5ic3A7IFRoYW5rcyBmb3IgdGhlIHByb21wdCByZXBseSA6KTwvZGl2 Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PnJlOiBJIG11c3QgbWFrZSBteXNlbGYgdmVyeSBjbGVh ciwgaXQgd2FzICpub3QqIG15IGludGVudGlvbiB0byB1c2UgaW1wcm9wZXI8YnI+dmVyc2lvbiBu dW1iZXIgYW5kIHRvIGZhbHNlbHkgcHJvbW90ZSBBdG9tIDIgc3VwcG9ydC4gPC9kaXY+CjxkaXY+ Jm5ic3A7PC9kaXY+CjxkaXY+TXkgYXBvbG9naWVzIGlmIEkgY2FtZSBhY3Jvc3MgdGhlIHdyb25n IHdheS4uLiBJIHdhc24ndCBtZWFuaW5nIHRvIGNhbGwgeW91IG91dCBhbmQgc3VnZ2VzdCBzb21l dGhpbmcgZXZpbCBoYWQgdGFrZW4gcGxhY2UuLi4gSSBoYXZlIGp1c3Qgc2VlbiB0aGluZ3MgbGlr ZSB0aGlzIGJlIHRha2VuIHRvIG1lYW4gJnF1b3Q7VGhlcmUncyBhIHZlcnNpb24gdHdvIG9uIGl0 cyB3YXk/JnF1b3Q7IG9yIGV2ZW4gc29tZXRoaW5nIGFzIHNpbXBsZSBhcyBhc3N1bWluZyB0aGF0 IGluIGZhY3QsIEF0b20gMiBpcyB0aGUgY3VycmVudCB2ZXJzaW9uIGFuZCBzaW1wbHkgYWNjZXB0 LCB0byB0aGVuIHByb3BvZ3JhdGUgdGhpcyBpbmZvcm1hdGlvbi4mbmJzcDsgSSBzaW1wbHkgd2Fu dGVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoaXMgZGlkbid0IHRha2UgcGxhY2UuCjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PlRoYW5rcyBhZ2FpbiBmb3IgdGhlIHJlc3BvbnNlIGFuZCBmb3Ig dGFraW5nIHRoZSBzdGVwcyB0byBnZXQgaXQgZml4ZWQhIDopPC9kaXY+CjxkaXY+PGJyPjxicj4m bmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDUvMi8wNiwgPGIg Y2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPk1paGFpIFN1Y2FuPC9iPiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1paGFpLnN1Y2FuQGdtYWlsLmNvbSI+bWloYWkuc3VjYW5AZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURE SU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNj Y2MgMXB4IHNvbGlkIj5MZSBUdWUsIDAyIE1heSAyMDA2IDIwOjUxOjQxICswMzAwLCBNLiBEYXZp ZCBQZXRlcnNvbjxicj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnhtbGhhY2tlckBnbWFpbC5jb20iPnht bGhhY2tlckBnbWFpbC5jb20KPC9hPiZndDsgYSDDqWNyaXQ6PGJyPjxicj4mZ3Q7PGJyPiZndDsg SSBjYW4gb25seSBhc3N1bWUgdGhhdCBzb21lb25lIGZyb20gT3BlcmEgaXMgb24gdGhpcyBsaXN0 LCBhbmQgSSdtIG5vdDxicj4mZ3Q7IGV2ZW4gc3VyZSB0aGlzIGlzIHRoYXQgYmlnIG9mIGEgZGVh bCwgYnV0IHRoZW4gYWdhaW4uLi4uPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEZyb206IDxhIGhy ZWY9Imh0dHA6Ly9teS5vcGVyYS5jb20vY29tbXVuaXR5L2N1c3RvbWl6ZS93aWRnZXRzL2luZm8v P2lkPTQwMjEiPgpodHRwOi8vbXkub3BlcmEuY29tL2NvbW11bml0eS9jdXN0b21pemUvd2lkZ2V0 cy9pbmZvLz9pZD00MDIxPC9hPjxicj4mZ3Q7PGJyPiZndDsgVGhpcyBmZWVkIGFsbG93cyBzdWJz Y3JpYmluZyB0byBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9mIG5ld3MgZmVlZHMuPGJyPiZndDsgU3Vw cG9ydGVkIGZvcm1hdHM6IFJTUyAyIGFuZCAmZ3Q7IEF0b20gMiAmbHQ7LiBUaHVzIHByb3ZpZGlu ZyBhbiBhZHZhbnRhZ2UKPGJyPiZndDsgb3ZlciBwZXItc2l0ZSBuZXdzIGZlZWQgYWdncmVnYXRv cnMuPGJyPiZndDsgLS0tPGJyPiZndDs8YnI+Jmd0OyBJIHJlYWxpemVkIFdlYjIgaXMgdGhlIGhv dCAmcXVvdDtuZXcmcXVvdDsgdGhpbmcsIGJ1dCBhbmQgUlNTIDIgaXMgb2J2aW91c2x5IG5vdDxi cj4mZ3Q7IGFuIGlzc3VlICh3ZWxsLCBub3QgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiBpbXByb3Bl ciBwcm9tb3Rpb24gb2YgdGhlCjxicj4mZ3Q7IHNvIGNhbGxlZCB2ZXJzaW9uICMpIGJ1dCBpZiBu b3QgbWlzdGFrZW4sIHRoZSBBdG9tIGNvbW11bml0eSB3aWxsPGJyPiZndDsgbmV2ZXIgaGF2ZSB0 aGUgbmVlZCBmb3IgYW4gQXRvbSAyLjAgc3BlYywgc28gaXQgbWlnaHQgYmUgd29ydGggcGluZ2lu Zzxicj4mZ3Q7IHdob21ldmVyIGRldmVsb3BlZCB0aGUgYWJvdmUgd2lkZ2V0IHRvIGxldCB0aGVt IGtub3cgdGhleSBuZWVkIHRvIGZpeAo8YnI+Jmd0OyB0aGlzLjxicj4mZ3Q7PGJyPiZndDsgTk9U RTogV291bGQgaGF2ZSBkb25lIHNvIG15c2VsZiwgYnV0IGNhbid0IHNlZW0gdG8gZmluZCBhIHBs YWNlIHRvPGJyPiZndDsgcG9zdCBhIG5vdGUgb3RoZXIgdGhhbiB0aHJvdWdoIHRoZSByYXRpbmdz IHBhbmVsLCBhbmQgSSBjYW4gb25seTxicj4mZ3Q7IGFzc3VtZSB0aGF0LCBsaWtlIHRoZSBGeCBj b21tdW5pdHksIHRoZSBPcGVyYSBjb21tdW5pdHkgd291bGQgcHJlZmVyCjxicj4mZ3Q7IHRoYXQg YnVnIHJlcG9ydHMgZG9uJ3QgY29tZSB0aHJvdWdoIHRoZSByYXRpbmdzIGNoYW5uZWwuPGJyPiZn dDs8YnI+Jmd0OyBUaGFua3MgaW4gYWR2YW5jZSE8YnI+Jmd0Ozxicj4mZ3Q7IC0tPGJyPiZndDsg Jmx0O006RC8mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBNLiBEYXZpZCBQZXRlcnNvbjxicj4mZ3Q7IDxh IGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20v CjwvYT48YnI+Jmd0Ozxicj48YnI+SGVsbG8hPGJyPjxicj5JIGhhcHBlbmQgdG8gYmUgc3Vic2Ny aWJlZCB0byB0aGlzIG1haWxpbmcgbGlzdC4gSnVzdCBqb2luZWQgdGhpcyB3ZWVrLjxicj48YnI+ SSBhbSB0aGUgYXV0aG9yIG9mIHRoZSB3aWRnZXQuIFllcywgbXkgbWlzdGFrZS4gQXBwb2xvZ2ll cy48YnI+PGJyPkknbGwgdXBkYXRlIHRoZSB3aWRnZXQgYW5kIEknbGwgYXNrIHRoZSBlZGl0b3Jz IG9mIE15IE9wZXJhIGNvbW11bml0eSBzaXRlCjxicj50byBmaXggdGhhdC48YnI+PGJyPkkgbXVz dCBtYWtlIG15c2VsZiB2ZXJ5IGNsZWFyLCBpdCB3YXMgKm5vdCogbXkgaW50ZW50aW9uIHRvIHVz ZSBpbXByb3Blcjxicj52ZXJzaW9uIG51bWJlciBhbmQgdG8gZmFsc2VseSBwcm9tb3RlIEF0b20g MiBzdXBwb3J0Ljxicj48YnI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgcG9zdGluZyB0aGlzLCB5 ZXQgSSB3b3VsZCBoYXZlIGJlZW4gZ2xhZCBpZiB5b3UKPGJyPndvdWxkJ3ZlIGNvbnRhY3RlZCBt ZSBmaXJzdCB2aWEgbXkgc2l0ZS48YnI+PGJyPjxicj4tLTxicj48YSBocmVmPSJodHRwOi8vd3d3 LnJvYm9kZXNpZ24ucm8iPmh0dHA6Ly93d3cucm9ib2Rlc2lnbi5ybzwvYT48YnI+Uk9CTyBEZXNp Z24gLSBXZSBicmluZyB5b3UgdGhlIGZ1dHVyZTxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxi ciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPiZsdDtNOkQvJmd0Owo8YnI+PGJyPk0uIERhdmlkIFBl dGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+aHR0cDovL3d3dy54 c2x0YmxvZy5jb20vPC9hPiAK ------=_Part_69005_24193021.1146602470312-- From owner-atom-syntax@mail.imc.org Tue May 02 16:56:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1vM-0007WP-7B for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:56:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1vK-00083T-Pr for atompub-archive@lists.ietf.org; Tue, 02 May 2006 16:56:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42KkAHt078059; Tue, 2 May 2006 13:46:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42KkAWN078058; Tue, 2 May 2006 13:46:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42Kk99E078051 for ; Tue, 2 May 2006 13:46:09 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 20:46:03 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp035) with SMTP; 02 May 2006 22:46:03 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 22:46:10 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502204610.GZ2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42KkAHt078059 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a * Robert Sayre [2006-05-02 22:00]: > I've been saying the same thing for weeks. I suppose it's par > for the course to handwave about them being "strictly > advisory", supply circular definitions for the feature in the > first place, claim no one will be implementing the feature, > then claim that someone is, etc, etc. Yes. I thought those defences were very silly as well. > You know, stuffing an idea because of who proposed it. No, not just because of who proposed it, but also because of how. You objection is not unreasonable, but you phrased it roughly as =E2=80=9Cthis is useless crap that no consumer is going to want and only clueless publishers would insist on providing.=E2=80=9D What is anyone supposed to draw from that? Nor did it help to interpret this on the level of vendor politics: implying that this extension came to be just because IBM doesn=E2=80=99t want to play ball wasn=E2=80=99t t= he most precise way to clarify its flaws. It wasn=E2=80=99t until David gave his criticism that I saw any serious problem.=20 Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 17:17:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2FR-0000Sl-Sf for atompub-archive@lists.ietf.org; Tue, 02 May 2006 17:17:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2FQ-0000Pk-Dz for atompub-archive@lists.ietf.org; Tue, 02 May 2006 17:17:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42L6w3i079063; Tue, 2 May 2006 14:06:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42L6wkX079062; Tue, 2 May 2006 14:06:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav7.bay109.hotmail.com [64.4.19.79]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42L6vZS079056 for ; Tue, 2 May 2006 14:06:57 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 May 2006 14:06:57 -0700 Message-ID: Received: from 81.179.109.21 by BAY109-DAV7.phx.gbl with DAV; Tue, 02 May 2006 21:06:53 +0000 X-Originating-IP: [81.179.109.21] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> Subject: Re: Atom Rank Extensions Date: Tue, 2 May 2006 22:06:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 02 May 2006 21:06:57.0152 (UTC) FILETIME=[58A5E000:01C66E2C] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Just looking at that example, it seems to me that an aggregator that implements Microsoft's simple list extensions would get a full-featured representation of that feed without having to know anything at all about feed rank and feed history. So why bother with them? I'm sure you can come up with cases which couldn't be handled perfectly by SLE (which I'd be the first to admit is a pretty lousy spec), but it's out there now and it more or less works. Does feed rank really offer you so much more that it justifies a competing extension? Regards James James M Snell wrote: > Just a quick heads up. To illustrate a simple example of feed rank bein > used, I put together an xslt that renders my Netflix Queue as an Atom > feed using the feed rank, feed history and MSFT simple list extensions. > > http://tinyurl.com/nxzgh From owner-atom-syntax@mail.imc.org Tue May 02 17:56:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2rE-0006Fr-Ii for atompub-archive@lists.ietf.org; Tue, 02 May 2006 17:56:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb2rD-00020b-5G for atompub-archive@lists.ietf.org; Tue, 02 May 2006 17:56:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Ljplu080975; Tue, 2 May 2006 14:45:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Ljp1w080974; Tue, 2 May 2006 14:45:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42LjnCA080967 for ; Tue, 2 May 2006 14:45:50 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 21:45:44 -0000 Received: from xdsl-213-196-249-21.netcologne.de (EHLO klangraum) [213.196.249.21] by mail.gmx.net (mp029) with SMTP; 02 May 2006 23:45:44 +0200 X-Authenticated: #163624 Date: Tue, 2 May 2006 23:45:50 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502214550.GA2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4457BD48.9070602@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42Ljplu080975 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 * James M Snell [2006-05-02 22:25]: > A. Pagaltzis wrote: > > I have to say that your architecture sounds rather > > heavyweight, >=20 > Heavyweight? It's Java. need I say more? Hehe. I stopped just short of asking =E2=80=9Cis that in Java?=E2=80=9D := -) > Does your implementation properly handle the following > (contrived) example: >=20 > > ... > > > ... > You probably wanted a trailing slash on your base URI, else the two hrefs are different. > I know for a fact that Java's built-in comparison functions for > the URI and URL classes do not. I have to normalize the URI's > after I resolve them before I can compare them. Yeah, I need to do some extra work. I=E2=80=99m using Perl, whose URI module does most of the work, but not all. Downcasing the host name, removing explicit default ports, unescaping characters which can be, and some scheme-specifics are all automatic, but some things that should be (at least resolving `..` path segments and escaping slashes in the query string) are not. I should probably read the relevant RFCs and write test cases, then file tickets=E2=80=A6 that stuff is bothersome. > What's more, for each replies link, I need to iterate through > all available thr:replies elements, resolve, normalize and > compare each href. >=20 > Pain. Yeah. At the DOM level you could use XPath to avoid iterating=E2=80=A6 :-= / > It is possible that the spec could dictate that the thr:replies > resolved href attribute MUST match the link's href attribute > character-for-character, making the above example invalid. That would be a solution. Would it be a burden on publishers? > > I can see that. Hrmf. There=E2=80=99s gotta be a better way=E2=80=A6 >=20 > ;-) Yes, there is a better way, but y'all complained about it > ;-) >=20 > (sorry, couldn't resist) Don=E2=80=99t be bitter now. :-) That particularly choice does make particular sense in your case; but that doesn=E2=80=99t mean it=E2=80=99s= the overall best. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 18:52:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3jN-0001F4-IC for atompub-archive@lists.ietf.org; Tue, 02 May 2006 18:52:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3jH-0005Lh-9b for atompub-archive@lists.ietf.org; Tue, 02 May 2006 18:52:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42MdC4Z082794; Tue, 2 May 2006 15:39:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42MdCTh082793; Tue, 2 May 2006 15:39:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42MdBY1082787 for ; Tue, 2 May 2006 15:39:12 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i2so11813wra for ; Tue, 02 May 2006 15:39:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jYPFNejnKJR+u4OolEpSE+Y87j/66qBB+NPF2GbI5mN2QXOGnS7mwHE4RuG1mQjQxsj7iAFVIiofOF6ZipiWCViWRbYHIwtc5k2V/SYjaTOB0SE7vm0Fg2pXHXVwwr+AgwlJ/fhkzwWljup1fRnpw7BKZfCcLsINUQHE7xwafzM= Received: by 10.54.80.12 with SMTP id d12mr1203685wrb; Tue, 02 May 2006 15:39:11 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm1044507wra.2006.05.02.15.39.09; Tue, 02 May 2006 15:39:10 -0700 (PDT) Message-ID: <4457DF8A.3070508@gmail.com> Date: Tue, 02 May 2006 15:39:06 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> In-Reply-To: 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 James Holderness wrote: > > Just looking at that example, it seems to me that an aggregator that > implements Microsoft's simple list extensions would get a full-featured > representation of that feed without having to know anything at all about > feed rank and feed history. > That's part of the point, actually. The extensions can work cooperatively with or independently of one another. > So why bother with them? The Feed history element and SLE's list directly compete with one another, with the exception that treatAs also defines that ordering of the entries is important. Feed Rank operates orthogonally to both. > I'm sure you can come up with cases which couldn't be handled perfectly > by SLE (which I'd be the first to admit is a pretty lousy spec), but > it's out there now and it more or less works. Does feed rank really > offer you so much more that it justifies a competing extension? > To understand where the value of Feed Rank comes in, consider adding additional ranking dimensions to each entry. For instance, an entry might contain a position rank, an average five star review rank, a average-review-from-my-friends rank, a critics ranking, a popularity ranking (e.g. number of times the movie has been rented in the last month), etc. ... 1 3.5 2.5 3.0 5 50 500 40 2 ... In this sense, feed rank shares a closer relationship to atom:category than it does to SLE. With SLE, each sort key can appear only once within an entry. In order to implement the example above, you would have to create a new namespaced extension element for each dimension you wish to sort on (not necessarily a bad thing, but opens the door to having multiple independent and non-interoperable vendor-specific namespaces that all implement the same basic feature in slightly different ways). With Feed Rank, we can have as many dimensions as we want, with a consistent definition and processing model for each, without having to define a new namespaced extension element for each dimension. Further, SLE operates only on a single feed document. Feed Rank is capable of spanning multiple feed and/or entry documents, regardless of whether they are pages in a single logical feed or are completely independent of one another. For instance, a school could offer one feed for each class in which each entry represent a test grade for an individual student. Class 1 ... ... 1.0 ... 1.3 Class 2 ... ... 4.0 ... 4.3 Class 3 ... ... 1.0 ... 1.7 Using Feed Rank, you could choose to sort the student entries within a single class feed (e.g. who are the top students in Class 1), or produce a combined view spanning all three feeds (e.g. who are the top students at the school). Also, with the SLE, the ordering is dependent on the feed in which the entry appears. Pass the entries through an aggregator (e.g. Sam's http://planet.intertwingly.net) and the order of the entries may change, breaking your list. With Feed Rank, the ranking value is attached to the entry, meaning that even if the entries are copied into aggregate feeds, reordered, etc, the original sort order can be reconstructed. Again, however, Feed Rank is not intended to compete with the simple list extensions. They serve different purposes. SLE defines a processing model for individual feed documents whose entries represent a sorted list; Feed Rank defines a way of assigning numeric rankings to entries to facilitate sorting and grouping. - James > Regards > James > > James M Snell wrote: >> Just a quick heads up. To illustrate a simple example of feed rank bein >> used, I put together an xslt that renders my Netflix Queue as an Atom >> feed using the feed rank, feed history and MSFT simple list extensions. >> >> http://tinyurl.com/nxzgh > > From owner-atom-syntax@mail.imc.org Tue May 02 19:15:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb45h-00038s-91 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:15:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb45e-0005sz-PG for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:15:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42N5hCk083803; Tue, 2 May 2006 16:05:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42N5hnd083802; Tue, 2 May 2006 16:05:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42N5e6p083795 for ; Tue, 2 May 2006 16:05:41 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060502230534.YJNL29040.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Wed, 3 May 2006 00:05:34 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060502230534.JPJ16086.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Wed, 3 May 2006 00:05:34 +0100 Date: Wed, 3 May 2006 00:05:32 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1991509855.20060503000532@djpowell.net> To: James M Snell CC: atom-syntax Subject: Re: Atom Rank Extensions In-Reply-To: <4457BD48.9070602@gmail.com> References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Tuesday, May 2, 2006, 9:12:56 PM, James Snell wrote: > Does your implementation properly handle the following (contrived) example: > > ... > > > ... > I don't think you should do URI normalisation. The ref is being used as an identifier, you don't do protocol level normalisation on namespace URIs or Atom ids why do it here? The draft should specify character-by-character comparison of the resolved URI's. [Er, I mean IRI. Everyone's using IRI datatypes, right?...] -- Dave From owner-atom-syntax@mail.imc.org Tue May 02 19:39:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4Sn-0002aP-7e for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:39:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4Sl-0006Xr-Sh for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:39:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42NSmut085419; Tue, 2 May 2006 16:28:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42NSm5j085418; Tue, 2 May 2006 16:28:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (pproxy.gmail.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42NSjFo085409 for ; Tue, 2 May 2006 16:28:47 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id c31so58116pyd for ; Tue, 02 May 2006 16:28:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jtkzXq3rloDBBVVghMq1ZqnAWv1r8rgpIzs9aForHfXC6TRuXUiEgZoq1aqfHAsAq9ZsWv6aVVbD8zyd/Mj7WxOOPb3jT3WWtMumaFJ0yqJnzQxr77G7YCRs02DEZMGWPR0jnY7LmgLFzeiCrs3pu7FOhy9jktJn1CoIgXK3OHo= Received: by 10.35.34.18 with SMTP id m18mr1581091pyj; Tue, 02 May 2006 16:28:45 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 16:28:45 -0700 (PDT) Message-ID: <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@mail.gmail.com> Date: Tue, 2 May 2006 19:28:45 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Atom Rank Extensions Cc: atom-syntax In-Reply-To: <4457DF8A.3070508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> <4457DF8A.3070508@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k42NSlFo085413 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On 5/2/06, James M Snell wrote: > > Again, however, Feed Rank is not intended to compete with the simple > list extensions. They serve different purposes. SLE defines a > processing model for individual feed documents whose entries represent a > sorted list; Feed Rank defines a way of assigning numeric rankings to > entries to facilitate sorting and grouping. I find this explanation most unconvincing. Near as I can tell, this spec serves an identical purpose, but it's much less flexible. In the Atom Syndication Format [RFC4287], the order of entries as presented in a feed is typically considered to be insignificant. This presents a challenge when the set of entries is intended to represent an ordered or ranked list. This document specifies an extension... Seems to me it's pretty darn similar. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 02 19:58:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4ks-0003hq-0e for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:58:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4kk-0006uA-Kc for atompub-archive@lists.ietf.org; Tue, 02 May 2006 19:58:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k42Njlfb086253; Tue, 2 May 2006 16:45:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k42Njl3O086252; Tue, 2 May 2006 16:45:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k42NjjkJ086238 for ; Tue, 2 May 2006 16:45:45 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 02 May 2006 23:45:39 -0000 Received: from xdsl-213-196-220-233.netcologne.de (EHLO klangraum) [213.196.220.233] by mail.gmx.net (mp032) with SMTP; 03 May 2006 01:45:39 +0200 X-Authenticated: #163624 Date: Wed, 3 May 2006 01:45:46 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060502234546.GF2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1991509855.20060503000532@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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k42Njlfb086253 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi David, * David Powell [2006-05-03 01:15]: > I don't think you should do URI normalisation. The ref is being > used as an identifier, you don't do protocol level > normalisation on namespace URIs or Atom ids why do it here? That=E2=80=99s a good point; though there=E2=80=99s a slight difference a= s namespace URIs must be absolute in the first place. The `href` isn=E2=80=99t necessarily unique, now that I think about it, if you play games with `xml:base`: Of course, it=E2=80=99s entirely reasonable to declare this madness and refuse to support it. Maybe we need something like _A Plea for Sanity_ that Joe English wrote about namespaces, for xml:base. > The draft should specify character-by-character comparison of > the resolved URI's. Yeah, probably. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 02 21:18:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb60c-0005zT-RA for atompub-archive@lists.ietf.org; Tue, 02 May 2006 21:18:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb60b-00027i-FZ for atompub-archive@lists.ietf.org; Tue, 02 May 2006 21:18:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4313mqm088767; Tue, 2 May 2006 18:03:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4313mNC088766; Tue, 2 May 2006 18:03:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (pproxy.gmail.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4313kkr088760 for ; Tue, 2 May 2006 18:03:47 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so59764pya for ; Tue, 02 May 2006 18:03:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jz1YULlkl2XqHJc4nDivKmeTB1pIM6BfLCznFtx3QnwFRpwF+K9IbjG1IAGS+lAAu82kouj5n+eqm7J8BoozJOPzEKTplu9Yx/O64ayk+Vu1lc5OrfdE3xvNi5RPmxSYnJga4Z57VDInCDlRRM0BdIqYw6nIxF3lscIsOAHCVZs= Received: by 10.35.15.11 with SMTP id s11mr200082pyi; Tue, 02 May 2006 18:03:46 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 18:03:45 -0700 (PDT) Message-ID: <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> Date: Tue, 2 May 2006 21:03:45 -0400 From: "Robert Sayre" To: atom-syntax Subject: Re: Atom Rank Extensions In-Reply-To: <20060502204610.GZ2690@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> <20060502204610.GZ2690@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4313lkr088761 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 5/2/06, A. Pagaltzis wrote: > > * Robert Sayre [2006-05-02 22:00]: > > I've been saying the same thing for weeks. I suppose it's par > > for the course to handwave about them being "strictly > > advisory", supply circular definitions for the feature in the > > first place, claim no one will be implementing the feature, > > then claim that someone is, etc, etc. > > Yes. I thought those defences were very silly as well. Not only were they "very silly", they're offensive. It's as if any truthy sounding answer is enough to brush someone off. If it's a WG draft, and not individual draft, you have to repeat the truthy-sounding answers every day for months on end. Also, it pays to scream bloody murder when someone gets upset with you. Also, it pays to make lots of irrelevant changes and claim to be responding to feedback. Of course, our chairs have made it abundantly clear that this sort of offensive, dishonest, repugnant delay tactic is perfectly acceptable, and must be treated with respect. Well, I won't use a four-letter word this time, but let's just say I'd rather deal with Microsoft than the IETF at this point. > > > You know, stuffing an idea because of who proposed it. > > No, not just because of who proposed it, but also because of how. Sorry Aristotle, you're not qualified to make that statement. I've proposed things every which way, so I know the form doesn't matter. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 02 21:45:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb6Qw-0001Mf-7v for atompub-archive@lists.ietf.org; Tue, 02 May 2006 21:45:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb6Qu-0003AG-Rr for atompub-archive@lists.ietf.org; Tue, 02 May 2006 21:45:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k431VpZA089982; Tue, 2 May 2006 18:31:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k431Vpkl089981; Tue, 2 May 2006 18:31:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k431VoJN089975 for ; Tue, 2 May 2006 18:31:50 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so65499pya for ; Tue, 02 May 2006 18:31:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BXAxcxaZNVVUXsi0e/LpOboOyS0l+DM6pkkMH41ds8J2wS0cK9Oj+mkcE4fYUOHI4GYa3gkavTaCRnWrNnxV7PMeonZJ7HUDmbJvICPp7ckecNROZZa8HmpRAexms6dym6fwH+ETmLuGQA+VMs37VYYQi6s8JUuGg1b9pz2q63w= Received: by 10.35.98.6 with SMTP id a6mr454851pym; Tue, 02 May 2006 18:31:50 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id f19sm1803044pyf.2006.05.02.18.31.48; Tue, 02 May 2006 18:31:49 -0700 (PDT) Message-ID: <44580802.7080500@gmail.com> Date: Tue, 02 May 2006 18:31:46 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Feed thread -09 (was: Re: Atom Rank Extensions) References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> In-Reply-To: <20060502234546.GF2690@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k431VpZA089982 X-Spam-Score: 1.9 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Ok, so how's this (not word-for-word as I would write it in the spec, but you should get the idea) The ref attribute MUST be an absolute URI that matches a the resolved href URI of a replies link character-for-character (case sensitive) In other words; - James A. Pagaltzis wrote: > Hi David, >=20 > * David Powell [2006-05-03 01:15]: >> I don't think you should do URI normalisation. The ref is being >> used as an identifier, you don't do protocol level >> normalisation on namespace URIs or Atom ids why do it here? >=20 > That=E2=80=99s a good point; though there=E2=80=99s a slight difference= as > namespace URIs must be absolute in the first place. >=20 > The `href` isn=E2=80=99t necessarily unique, now that I think about it, > if you play games with `xml:base`: >=20 > > >=20 > Of course, it=E2=80=99s entirely reasonable to declare this madness and > refuse to support it. >=20 > Maybe we need something like _A Plea for Sanity_ that Joe English > wrote about namespaces, for xml:base. >=20 >> The draft should specify character-by-character comparison of >> the resolved URI's. >=20 > Yeah, probably. >=20 > Regards, From owner-atom-syntax@mail.imc.org Tue May 02 23:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb87l-0004rZ-6I for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:34:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb87j-0007ce-Qo for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:34:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433Nm8t094749; Tue, 2 May 2006 20:23:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k433NmeH094748; Tue, 2 May 2006 20:23:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433Nl1O094741 for ; Tue, 2 May 2006 20:23:47 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.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 A0778519B5; Tue, 2 May 2006 23:23:36 -0400 (EDT) In-Reply-To: <4455BF00.4090605@gmail.com> References: <4455BF00.4090605@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Tools that make use of previous/next/first/last links? Date: Tue, 2 May 2006 20:23:44 -0700 To: James M Snell X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On 2006/05/01, at 12:55 AM, James M Snell wrote: > > Eric Scheid wrote: >> I thought OpenSearch results are not sorted by chronological age >> at all, but >> instead by relevance? Using "next" with OpenSearch makes sense in >> that >> context. Using "previous" for stepping back thru time in a data store >> arranged chronologically makes sense. What Eric said. > As it stands now, a single feed > cannot implement APP, OpenSearch AND Feed History. Please describe the scenario where you'd want that to happen -- show the feed. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue May 02 23:35:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb894-0005GK-6h for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:35:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb893-0007fh-Qz for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:35:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433Nfhg094738; Tue, 2 May 2006 20:23:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k433NfVa094737; Tue, 2 May 2006 20:23:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433NeYT094731 for ; Tue, 2 May 2006 20:23:40 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.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 933E6519C2; Tue, 2 May 2006 23:23:38 -0400 (EDT) In-Reply-To: <1henngd.rdufq2q68uugM%pmrobinson@gmx.net> References: <1henngd.rdufq2q68uugM%pmrobinson@gmx.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B5AC086-4051-4835-8D61-9EC702CE7ADD@mnot.net> Cc: atom-syntax@imc.org (atom-syntax) Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Tools that make use of previous/next/first/last links? Date: Tue, 2 May 2006 20:23:47 -0700 To: Peter Robinson X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Peter, Can you expand upon "being more precise about exactly what is needed"? On 2006/05/01, at 3:16 AM, Peter Robinson wrote: > > Mark Nottingham wrote: > >> One thing I did notice -- you're using URLs like this for your >> archives: >> http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? >> page=2&count=10 >> >> Are they really permanent? If they're relative to the current state >> of the feed (i.e., the above URI means "give me the ten latest >> entries"), you can get into some inconsistent states; e.g., if >> somebody adds/deletes an entry between when the client fetches the >> different archives. Also, if a client doesn't visit for a long time, >> it will see >> http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? >> page=2&count=10 >> and assume it already has all of the entries in it, because it's >> fetched that URI before. > > This is the biggest issue I have with the history spec as written. I > have urls like that, which aren't 'archive documents' as defined. > That > means I can't implement the history spec even though I have > conventional > chronologically ordered feeds with link rel="prev/next" elements where > old entries are available. > > I believe that by being more precise about exactly what is needed > by the > client to implement feed history usefully you can significantly relax > the requirements. I believe the algorithm can be written so that > clients can use history with a feed like mine. > > Regards, > > Peter > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue May 02 23:44:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb8IF-0004Au-Qs for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:44:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb8IE-0007xo-FT for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:44:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433Zd28095259; Tue, 2 May 2006 20:35:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k433ZdvN095258; Tue, 2 May 2006 20:35:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433ZchX095252 for ; Tue, 2 May 2006 20:35:38 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id 39so96913pyu for ; Tue, 02 May 2006 20:35:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KSVaC+YNX7pvUYqCOQ8cOdMLmJQQ1xB+yJxFxzc2W6yurQstxul3YxSU4LewgMWEHeb+ib0VxON6e9N8ZBeAt9H9Ta654mcFuFneOxnQiYnfPKb74sRHU/8BeoV8tMV5g66Dl0w31d6kgd8H3/b/wlS4fohvLglBdwDWh2YD1fI= Received: by 10.35.99.5 with SMTP id b5mr2254699pym; Tue, 02 May 2006 20:35:37 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 2 May 2006 20:35:37 -0700 (PDT) Message-ID: <68fba5c50605022035s5418ca7es8767aa8305aecd0a@mail.gmail.com> Date: Tue, 2 May 2006 23:35:37 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: Weekly Posting Summary MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k433ZchX095253 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Messages | Bytes | Who --------+------+--------+----------+------------------------ 29.09% | 16 | 36.32% | 83142 | jasnell@gmail.com 16.36% | 9 | 14.13% | 32346 | pagaltzis@gmx.de 12.73% | 7 | 11.57% | 26492 | sayrer@gmail.com 7.27% | 4 | 6.01% | 13765 | jpanzer@aol.net 7.27% | 4 | 5.47% | 12527 | j4_james@hotmail.com 5.45% | 3 | 5.84% | 13377 | djpowell@djpowell.net 3.64% | 2 | 6.26% | 14339 | xmlhacker@gmail.com 3.64% | 2 | 2.87% | 6578 | mnot@mnot.net 3.64% | 2 | 2.87% | 6563 | eric.scheid@ironclad.net.au 3.64% | 2 | 2.46% | 5632 | pmrobinson@gmx.net 1.82% | 1 | 1.89% | 4331 | mihai.sucan@gmail.com 1.82% | 1 | 1.53% | 3512 | sh@defuze.org 1.82% | 1 | 1.42% | 3246 | sewe@rbg.informatik.tu-darmstadt.de 1.82% | 1 | 1.34% | 3070 | hsivonen@iki.fi --------+------+--------+----------+------------------------ 100.00% | 55 |100.00% | 228920 | Total -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 02 23:53:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb8QR-0004VQ-Er for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:53:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb8QQ-0008Cg-33 for atompub-archive@lists.ietf.org; Tue, 02 May 2006 23:53:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k433i88j095553; Tue, 2 May 2006 20:44:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k433i8qf095552; Tue, 2 May 2006 20:44:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k433i6fi095544 for ; Tue, 2 May 2006 20:44:06 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 May 2006 03:44:00 -0000 Received: from xdsl-213-196-220-233.netcologne.de (EHLO klangraum) [213.196.220.233] by mail.gmx.net (mp005) with SMTP; 03 May 2006 05:44:00 +0200 X-Authenticated: #163624 Date: Wed, 3 May 2006 05:44:07 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Atom Rank Extensions Message-ID: <20060503034407.GH2690@klangraum> Mail-Followup-To: atom-syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> <20060502204610.GZ2690@klangraum> <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k433i88j095553 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a * Robert Sayre [2006-05-03 03:15]: > >> You know, stuffing an idea because of who proposed it. > > > >No, not just because of who proposed it, but also because of > >how. >=20 > Sorry Aristotle, you're not qualified to make that statement. > I've proposed things every which way, so I know the form > doesn't matter. Indeed, I=E2=80=99ve only been a witness to the discussion in a few venues, so I can=E2=80=99t pass judgement about the big picture. I have to take your word for it. However, with regard to the part of the picture in which I did participate, I will go on record to say that you almost never made it easy for me to consider your position on an issue on which I was trying to make up my mind when held a strong opinion about it. And that=E2=80=99s not for lack of willingness on my part, nor is it because your positions have been unreasonable. I often wished you=E2=80=99d argue your case better. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 03 00:26:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb8wL-0000LC-Gt for atompub-archive@lists.ietf.org; Wed, 03 May 2006 00:26:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb8wK-0001j4-4i for atompub-archive@lists.ietf.org; Wed, 03 May 2006 00:26:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k434F14x097016; Tue, 2 May 2006 21:15:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k434F1GW097015; Tue, 2 May 2006 21:15:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k434F0sd097009 for ; Tue, 2 May 2006 21:15:01 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so60621wra for ; Tue, 02 May 2006 21:15:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ORQ9N4Wvy6L3T2GvtkWMFslwfG9bWBK0NdXtrLzRkKqiSMlSYGn0RxlqKc1NFbH951bfOTpGqTBl4/h0RDhLgjnm+Un3xrN52pJADLEIIHil6U81N+4Hq58yRRvwODnuAz64Bb9SJToCerBaZ8ppg+PGUBZ2BQqgf9w8YxovZ3o= Received: by 10.54.78.12 with SMTP id a12mr13886wrb; Tue, 02 May 2006 21:15:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 33sm1224696wra.2006.05.02.21.14.59; Tue, 02 May 2006 21:14:59 -0700 (PDT) Message-ID: <44582E3E.3060201@gmail.com> Date: Tue, 02 May 2006 21:14:54 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? References: <4455BF00.4090605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Mark Nottingham wrote: >[snip] >>As it stands now, a single feed >>cannot implement APP, OpenSearch AND Feed History. > > Please describe the scenario where you'd want that to happen -- show the > feed. > > The feed(s) are part of our open activities implementation and are available via our APP interop endpoint [1]. Our APP collection feeds are also the feeds people subscribe to and search with (e.g. any of our feeds accept querystring parameters to filter the feed results). Requesters can set the page size as a querystring, if the result set is larger than the page size, the feed is automatically paged using first/last/next/previous. The fact that our entries are sorted in reverse chronological order makes us compliant with APP, but makes it impossible for clients to use the Feed History algorithm (current has a next but no previous). - James [1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html From owner-atom-syntax@mail.imc.org Wed May 03 02:08:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbAWn-00074x-H2 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 02:08:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbAWl-0005tr-2w for atompub-archive@lists.ietf.org; Wed, 03 May 2006 02:08:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k435mneW001233; Tue, 2 May 2006 22:48:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k435mnBH001232; Tue, 2 May 2006 22:48:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k435mmVG001226 for ; Tue, 2 May 2006 22:48:49 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.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 F3BCF51A34; Wed, 3 May 2006 01:48:47 -0400 (EDT) In-Reply-To: <44582E3E.3060201@gmail.com> References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Tools that make use of previous/next/first/last links? Date: Tue, 2 May 2006 22:48:55 -0700 To: James M Snell X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 If you use URIs like http://example.com/feed?start=5&num=10 changing the directionality of "next" and "previous" will not make what you're doing compatible with feed history. Such URIs have a much more fundamental problem -- they don't refer to a stable set of entries, and therefore only act as a snapshot of the *current* feed, chopped up into chunks. If the feed changes between accesses, the client will be in an inconsistent state. The client also has to walk through all of the pages every time it fetches the feed; it can't cache them -- which is a primary requirement for feed history. What are the requirements that drove you to this type of paging solution? On 2006/05/02, at 9:14 PM, James M Snell wrote: > > Mark Nottingham wrote: >> [snip] >>> As it stands now, a single feed >>> cannot implement APP, OpenSearch AND Feed History. >> >> Please describe the scenario where you'd want that to happen -- >> show the >> feed. >> >> > > The feed(s) are part of our open activities implementation and are > available via our APP interop endpoint [1]. Our APP collection feeds > are also the feeds people subscribe to and search with (e.g. any of > our > feeds accept querystring parameters to filter the feed results). > Requesters can set the page size as a querystring, if the result > set is > larger than the page size, the feed is automatically paged using > first/last/next/previous. The fact that our entries are sorted in > reverse chronological order makes us compliant with APP, but makes it > impossible for clients to use the Feed History algorithm (current > has a > next but no previous). > > - James > > [1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed May 03 05:03:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDGt-0005U4-8d for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:03:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDGo-0004rg-JJ for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:03:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k438oYBY010414; Wed, 3 May 2006 01:50:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k438oYfU010413; Wed, 3 May 2006 01:50:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k438oWxu010407 for ; Wed, 3 May 2006 01:50:33 -0700 (MST) (envelope-from mihai.sucan@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so76539nfc for ; Wed, 03 May 2006 01:50:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:cc:references:organization:content-type:mime-version:content-transfer-encoding:message-id:in-reply-to:user-agent; b=SH/8UGKs4lYV9FfEMjAPYgm1mmDCcKC902Im4xZGXMQcz+DS0kaS+SkjPAmj+QPml7rY0Qg/QQWBtk8GH+6GhZKtzn92TZrnNClNXKThT3w6UdsfmfV6nLBWoAEuKgL7eWD/DC5RaxBoxh5rvt77aWJkn/7x5K3/l85iK0uON3w= Received: by 10.49.5.14 with SMTP id h14mr1214882nfi; Wed, 03 May 2006 01:50:14 -0700 (PDT) Received: from localhost.localdomain ( [86.34.246.154]) by mx.gmail.com with ESMTP id x24sm467248nfb.2006.05.03.01.50.13; Wed, 03 May 2006 01:50:14 -0700 (PDT) Date: Wed, 03 May 2006 11:50:09 +0300 From: "Mihai Sucan" To: "M. David Peterson" Subject: Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community Cc: "Atom Syntax" References: Organization: http://www.robodesign.ro Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.51 (Linux, build 1462) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k438oYBY010414 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Le Tue, 02 May 2006 23:41:10 +0300, M. David Peterson =20 a =C3=A9crit: > Very cool! Thanks for the prompt reply :) > > re: I must make myself very clear, it was *not* my intention to use =20 > improper > version number and to falsely promote Atom 2 support. > > My apologies if I came across the wrong way... I wasn't meaning to call= =20 > you > out and suggest something evil had taken place... I have just seen thin= gs > like this be taken to mean "There's a version two on its way?" or even > something as simple as assuming that in fact, Atom 2 is the current =20 > version > and simply accept, to then propograte this information. I simply wante= d =20 > to > make sure that this didn't take place. > > Thanks again for the response and for taking the steps to get it fixed!= =20 > :) Hello! I'm glad this widget description wasn't considered something of an evil =20 nature :). I consider I made the mistake because of a typo on my behalf =20 and/or at the moment of writing the description I forgot the Atom version= =20 number (this is because I don't work with feeds too often). I was hurried= =20 to release the widget for their competition. Yes, I will take the steps to get that fixed, ASAP. Thanks for the nice reply :). --=20 http://www.robodesign.ro ROBO Design - We bring you the future From owner-atom-syntax@mail.imc.org Wed May 03 05:23:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDaL-00043K-KD for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:23:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDZk-0005W5-K0 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:23:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k439BhqH011376; Wed, 3 May 2006 02:11:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k439BhqM011375; Wed, 3 May 2006 02:11:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k439BgOY011369 for ; Wed, 3 May 2006 02:11:42 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so102348wra for ; Wed, 03 May 2006 02:11:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BkjBpxLzF9kk+AQLlNHxI0dyDdTZPsem9fgJTYYH9vURLBxJpFcIQAL6jLV6L0xpltz27mIcbJbMeAt8daKZBuRnnR7Kh/r5I2KUJVpTd4Ql3TXBwe8YMGTNdUK/peGOj+wTNTK/qws5TizjxZ0vNfCWOWhate1elXtkzeG9yHc= Received: by 10.64.10.11 with SMTP id 11mr989190qbj; Wed, 03 May 2006 02:11:41 -0700 (PDT) Received: by 10.65.210.9 with HTTP; Wed, 3 May 2006 02:11:41 -0700 (PDT) Message-ID: Date: Wed, 3 May 2006 03:11:41 -0600 From: "M. David Peterson" To: "Mihai Sucan" Subject: Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_77616_5871639.1146647501600" References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b ------=_Part_77616_5871639.1146647501600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline UmlnaHQgb24uLi4gR29vZCBsdWNrISAgVGhlIHJlYXNvbiB0aGUgd2lkZ2V0IGNhdWdodCBteSBl eWUgaW4gdGhlIGZpcnN0CnBsYWNlIHdhcyBiZWNhdXNlIG9mIHRoZSBsZWFkLWluIHN1Z2dlc3Rp bmcgaXRzIGdlbmVyaWMgYXBwcm9hY2ggKGUuZy4gbm90CnRpZWQgdG8gYW55IHNwZWNpZmljIGZl ZWQuKSAgSWYgSSdtIGdvaW5nIHRvIGhhdmUgYSB3aWRnZXQgZmVlZHJlYWRlciBpdHMKbmVlZHMg dG8gYmUgYWJsZSB0byBhY2Nlc3MgYW5kIG1ha2UgYXZhaWxhYmxlIG1vcmUgdGhhbiBvbmUgZmVl ZC4uLiAgSSdtCmFtYXplZCB0aGF0IG90aGVyIHdpZGdldCBkZXZlbG9wZXJzIGZpbmQganVzdGlm aWNhdGlvbiBpbiBkZXZlbG9waW5nCm9uZS1mZWVkIHdpZGdldHMgPiBJIGNhbiBzZWUgZnJvbSBh IG1hcmtsZXRpbmcgcGVyc3BlY3RpdmUgZm9sa3MgbWlnaHQgc2VlCnRoZSB3aWRnZXQgY3JhemUg aW4gc2ltaWxhciBsaWdodCB0byB0aGUgR29vZ2xlIHRvb2xiYXIgb3IgdGhlIHNpbWlsYXIgd2hl cmUKdGhleSBjYW4gZHJpdmUgcGVvcGxlIHRvIHRoZWlyIHNpdGUgYnkgcHJvdmlkaW5nIHRoZW0g ZGlyZWN0LWJyb3dzZXIgYWNjZXNzCnRvIHNpbXBsZSB1dGlsaXRpZXMgdGhhdCBtYWtlIGJyb3dz aW5nIG1vcmUgZW5qb3lhYmxlL2Vhc2llciB0byBmaW5kCnRoaW5ncy4gIEknbSBhbWF6ZWQsIGhv d2V2ZXIsIHRoYXQgZm9sa3MgZWl0aGVyIG1ha2UgdGhpcyB0eXBlIG9mCmNvbXBhcmlzb24sIGFu ZCB0aGVyZWZvcmUganVzdGlmeSBvbmUtb2ZmIGZlZWQgcmVhZGVyIHdpZGdldHMsIG9yIHRoZXkg aGF2ZQplbm91Z2ggb2YgYSBjdXN0b21lciBiYXNlIHRoYXQgZG9lc24ndCBjYXJlIGFib3V0IGFu eSBvdGhlciBmZWVkIGFuZAp0aGVyZWZvcmUganVzdGlmaWVzIHN1Y2ggYSBjZW50cmFsaXplZCBm b2N1cy4KCldpdGggYWxsIG9mIHRoZSBhYm92ZSwgaXRzIG5pY2UgdG8gc2VlIHRoYXQgc29tZW9u ZSBoYXMgcmVhbGl6ZWQgYSBnZW5lcmljCmZlZWQtcmVhZGVyIHdhcyBNQU5EQVRPUlkgaWYgdGhl eSB3YW50IGFueSBsZXZlbCBvZiBtYXNzIGFkb3B0aW9uLiAgVGhpcyBpcwp0aGUgZmlyc3Qgb25l IEkgaGF2ZSBzZWVuIGluIHRoZSBPcGVyYSB3aWRnZXQgbGlicmFyeSwgc28gYmVzdCBvZiBsdWNr IHRvCnlvdS4uLiB5b3UgZGVzZXJ2ZSBzb21lIGRlZmluaXRlIGV4dHJhLWNyZWRpdCBwb2ludHMg Zm9yIChhcyBmYXIgYXMgSSBrbm93CmFueXdheSkgZm9yIGJlaW5nIHRoZSBmaXJzdCBvZmYtdGhl LWxpbmUuLi4gIElmIG5vdGhpbmcgZWxzZSwgdGhlcmVzIHJld2FyZAppbiBzdWNoIGtub3dsZWRn ZSBpbiBhbmQgb2YgaXRzZWxmLCBidXQgSSBob3BlIHlvdSB3aW4gZWl0aGVyIHdheSA6KQoKT24g NS8zLzA2LCBNaWhhaSBTdWNhbiA8bWloYWkuc3VjYW5AZ21haWwuY29tPiB3cm90ZToKPgo+IExl IFR1ZSwgMDIgTWF5IDIwMDYgMjM6NDE6MTAgKzAzMDAsIE0uIERhdmlkIFBldGVyc29uCj4gPHht bGhhY2tlckBnbWFpbC5jb20+IGEgw6ljcml0Ogo+Cj4gPiBWZXJ5IGNvb2whICBUaGFua3MgZm9y IHRoZSBwcm9tcHQgcmVwbHkgOikKPiA+Cj4gPiByZTogSSBtdXN0IG1ha2UgbXlzZWxmIHZlcnkg Y2xlYXIsIGl0IHdhcyAqbm90KiBteSBpbnRlbnRpb24gdG8gdXNlCj4gPiBpbXByb3Blcgo+ID4g dmVyc2lvbiBudW1iZXIgYW5kIHRvIGZhbHNlbHkgcHJvbW90ZSBBdG9tIDIgc3VwcG9ydC4KPiA+ Cj4gPiBNeSBhcG9sb2dpZXMgaWYgSSBjYW1lIGFjcm9zcyB0aGUgd3Jvbmcgd2F5Li4uIEkgd2Fz bid0IG1lYW5pbmcgdG8gY2FsbAo+ID4geW91Cj4gPiBvdXQgYW5kIHN1Z2dlc3Qgc29tZXRoaW5n IGV2aWwgaGFkIHRha2VuIHBsYWNlLi4uIEkgaGF2ZSBqdXN0IHNlZW4KPiB0aGluZ3MKPiA+IGxp a2UgdGhpcyBiZSB0YWtlbiB0byBtZWFuICJUaGVyZSdzIGEgdmVyc2lvbiB0d28gb24gaXRzIHdh eT8iIG9yIGV2ZW4KPiA+IHNvbWV0aGluZyBhcyBzaW1wbGUgYXMgYXNzdW1pbmcgdGhhdCBpbiBm YWN0LCBBdG9tIDIgaXMgdGhlIGN1cnJlbnQKPiA+IHZlcnNpb24KPiA+IGFuZCBzaW1wbHkgYWNj ZXB0LCB0byB0aGVuIHByb3BvZ3JhdGUgdGhpcyBpbmZvcm1hdGlvbi4gIEkgc2ltcGx5IHdhbnRl ZAo+ID4gdG8KPiA+IG1ha2Ugc3VyZSB0aGF0IHRoaXMgZGlkbid0IHRha2UgcGxhY2UuCj4gPgo+ ID4gVGhhbmtzIGFnYWluIGZvciB0aGUgcmVzcG9uc2UgYW5kIGZvciB0YWtpbmcgdGhlIHN0ZXBz IHRvIGdldCBpdCBmaXhlZCEKPiA+IDopCj4KPiBIZWxsbyEKPgo+IEknbSBnbGFkIHRoaXMgd2lk Z2V0IGRlc2NyaXB0aW9uIHdhc24ndCBjb25zaWRlcmVkIHNvbWV0aGluZyBvZiBhbiBldmlsCj4g bmF0dXJlIDopLiBJIGNvbnNpZGVyIEkgbWFkZSB0aGUgbWlzdGFrZSBiZWNhdXNlIG9mIGEgdHlw byBvbiBteSBiZWhhbGYKPiBhbmQvb3IgYXQgdGhlIG1vbWVudCBvZiB3cml0aW5nIHRoZSBkZXNj cmlwdGlvbiBJIGZvcmdvdCB0aGUgQXRvbSB2ZXJzaW9uCj4gbnVtYmVyICh0aGlzIGlzIGJlY2F1 c2UgSSBkb24ndCB3b3JrIHdpdGggZmVlZHMgdG9vIG9mdGVuKS4gSSB3YXMgaHVycmllZAo+IHRv IHJlbGVhc2UgdGhlIHdpZGdldCBmb3IgdGhlaXIgY29tcGV0aXRpb24uCj4KPiBZZXMsIEkgd2ls bCB0YWtlIHRoZSBzdGVwcyB0byBnZXQgdGhhdCBmaXhlZCwgQVNBUC4KPgo+IFRoYW5rcyBmb3Ig dGhlIG5pY2UgcmVwbHkgOikuCj4KPgo+IC0tCj4gaHR0cDovL3d3dy5yb2JvZGVzaWduLnJvCj4g Uk9CTyBEZXNpZ24gLSBXZSBicmluZyB5b3UgdGhlIGZ1dHVyZQo+CgoKCi0tCjxNOkQvPgoKTS4g RGF2aWQgUGV0ZXJzb24KaHR0cDovL3d3dy54c2x0YmxvZy5jb20vCg== ------=_Part_77616_5871639.1146647501600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UmlnaHQgb24uLi4gR29vZCBsdWNrISZuYnNwOyBUaGUgcmVhc29uIHRoZSB3aWRnZXQgY2F1Z2h0 IG15IGV5ZSBpbiB0aGUgZmlyc3QgcGxhY2Ugd2FzIGJlY2F1c2Ugb2YgdGhlIGxlYWQtaW4gc3Vn Z2VzdGluZyBpdHMgZ2VuZXJpYyBhcHByb2FjaCAoZS5nLiBub3QgdGllZCB0byBhbnkgc3BlY2lm aWMgZmVlZC4pJm5ic3A7IElmIEknbSBnb2luZyB0byBoYXZlIGEgd2lkZ2V0IGZlZWRyZWFkZXIg aXRzIG5lZWRzIHRvIGJlIGFibGUgdG8gYWNjZXNzIGFuZCBtYWtlIGF2YWlsYWJsZSBtb3JlIHRo YW4gb25lIGZlZWQuLi4mbmJzcDsgSSdtIGFtYXplZCB0aGF0IG90aGVyIHdpZGdldCBkZXZlbG9w ZXJzIGZpbmQganVzdGlmaWNhdGlvbiBpbiBkZXZlbG9waW5nIG9uZS1mZWVkIHdpZGdldHMgJmd0 OyBJIGNhbiBzZWUgZnJvbSBhIG1hcmtsZXRpbmcgcGVyc3BlY3RpdmUgZm9sa3MgbWlnaHQgc2Vl IHRoZSB3aWRnZXQgY3JhemUgaW4gc2ltaWxhciBsaWdodCB0byB0aGUgR29vZ2xlIHRvb2xiYXIg b3IgdGhlIHNpbWlsYXIgd2hlcmUgdGhleSBjYW4gZHJpdmUgcGVvcGxlIHRvIHRoZWlyIHNpdGUg YnkgcHJvdmlkaW5nIHRoZW0gZGlyZWN0LWJyb3dzZXIgYWNjZXNzIHRvIHNpbXBsZSB1dGlsaXRp ZXMgdGhhdCBtYWtlIGJyb3dzaW5nIG1vcmUgZW5qb3lhYmxlL2Vhc2llciB0byBmaW5kIHRoaW5n cy4mbmJzcDsgSSdtIGFtYXplZCwgaG93ZXZlciwgdGhhdCBmb2xrcyBlaXRoZXIgbWFrZSB0aGlz IHR5cGUgb2YgY29tcGFyaXNvbiwgYW5kIHRoZXJlZm9yZSBqdXN0aWZ5IG9uZS1vZmYgZmVlZCBy ZWFkZXIgd2lkZ2V0cywgb3IgdGhleSBoYXZlIGVub3VnaCBvZiBhIGN1c3RvbWVyIGJhc2UgdGhh dCBkb2Vzbid0IGNhcmUgYWJvdXQgYW55IG90aGVyIGZlZWQgYW5kIHRoZXJlZm9yZSBqdXN0aWZp ZXMgc3VjaCBhIGNlbnRyYWxpemVkIGZvY3VzLgo8YnI+PGJyPldpdGggYWxsIG9mIHRoZSBhYm92 ZSwgaXRzIG5pY2UgdG8gc2VlIHRoYXQgc29tZW9uZSBoYXMgcmVhbGl6ZWQgYSBnZW5lcmljIGZl ZWQtcmVhZGVyIHdhcyBNQU5EQVRPUlkgaWYgdGhleSB3YW50IGFueSBsZXZlbCBvZiBtYXNzIGFk b3B0aW9uLiZuYnNwOyBUaGlzIGlzIHRoZSBmaXJzdCBvbmUgSSBoYXZlIHNlZW4gaW4gdGhlIE9w ZXJhIHdpZGdldCBsaWJyYXJ5LCBzbyBiZXN0IG9mIGx1Y2sgdG8geW91Li4uIHlvdSBkZXNlcnZl IHNvbWUgZGVmaW5pdGUgZXh0cmEtY3JlZGl0IHBvaW50cyBmb3IgKGFzIGZhciBhcyBJIGtub3cg YW55d2F5KSBmb3IgYmVpbmcgdGhlIGZpcnN0IG9mZi10aGUtbGluZS4uLiZuYnNwOyBJZiBub3Ro aW5nIGVsc2UsIHRoZXJlcyByZXdhcmQgaW4gc3VjaCBrbm93bGVkZ2UgaW4gYW5kIG9mIGl0c2Vs ZiwgYnV0IEkgaG9wZSB5b3Ugd2luIGVpdGhlciB3YXkgOikKPGJyPjxicj48ZGl2PjxzcGFuIGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gNS8zLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+ TWloYWkgU3VjYW48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86bWloYWkuc3VjYW5AZ21haWwuY29t Ij5taWhhaS5zdWNhbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0 LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyI+CkxlIFR1ZSwgMDIgTWF5IDIwMDYgMjM6NDE6MTAgKzAzMDAsIE0uIERhdmlkIFBldGVyc29u PGJyPiZsdDs8YSBocmVmPSJtYWlsdG86eG1saGFja2VyQGdtYWlsLmNvbSI+eG1saGFja2VyQGdt YWlsLmNvbTwvYT4mZ3Q7IGEgw6ljcml0Ojxicj48YnI+Jmd0OyBWZXJ5IGNvb2whJm5ic3A7Jm5i c3A7VGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlcGx5IDopPGJyPiZndDs8YnI+Jmd0OyByZTogSSBt dXN0IG1ha2UgbXlzZWxmIHZlcnkgY2xlYXIsIGl0IHdhcyAqbm90KiBteSBpbnRlbnRpb24gdG8g dXNlCjxicj4mZ3Q7IGltcHJvcGVyPGJyPiZndDsgdmVyc2lvbiBudW1iZXIgYW5kIHRvIGZhbHNl bHkgcHJvbW90ZSBBdG9tIDIgc3VwcG9ydC48YnI+Jmd0Ozxicj4mZ3Q7IE15IGFwb2xvZ2llcyBp ZiBJIGNhbWUgYWNyb3NzIHRoZSB3cm9uZyB3YXkuLi4gSSB3YXNuJ3QgbWVhbmluZyB0byBjYWxs PGJyPiZndDsgeW91PGJyPiZndDsgb3V0IGFuZCBzdWdnZXN0IHNvbWV0aGluZyBldmlsIGhhZCB0 YWtlbiBwbGFjZS4uLiBJIGhhdmUganVzdCBzZWVuIHRoaW5ncwo8YnI+Jmd0OyBsaWtlIHRoaXMg YmUgdGFrZW4gdG8gbWVhbiAmcXVvdDtUaGVyZSdzIGEgdmVyc2lvbiB0d28gb24gaXRzIHdheT8m cXVvdDsgb3IgZXZlbjxicj4mZ3Q7IHNvbWV0aGluZyBhcyBzaW1wbGUgYXMgYXNzdW1pbmcgdGhh dCBpbiBmYWN0LCBBdG9tIDIgaXMgdGhlIGN1cnJlbnQ8YnI+Jmd0OyB2ZXJzaW9uPGJyPiZndDsg YW5kIHNpbXBseSBhY2NlcHQsIHRvIHRoZW4gcHJvcG9ncmF0ZSB0aGlzIGluZm9ybWF0aW9uLiZu YnNwOyZuYnNwO0kgc2ltcGx5IHdhbnRlZAo8YnI+Jmd0OyB0bzxicj4mZ3Q7IG1ha2Ugc3VyZSB0 aGF0IHRoaXMgZGlkbid0IHRha2UgcGxhY2UuPGJyPiZndDs8YnI+Jmd0OyBUaGFua3MgYWdhaW4g Zm9yIHRoZSByZXNwb25zZSBhbmQgZm9yIHRha2luZyB0aGUgc3RlcHMgdG8gZ2V0IGl0IGZpeGVk ITxicj4mZ3Q7IDopPGJyPjxicj5IZWxsbyE8YnI+PGJyPkknbSBnbGFkIHRoaXMgd2lkZ2V0IGRl c2NyaXB0aW9uIHdhc24ndCBjb25zaWRlcmVkIHNvbWV0aGluZyBvZiBhbiBldmlsCjxicj5uYXR1 cmUgOikuIEkgY29uc2lkZXIgSSBtYWRlIHRoZSBtaXN0YWtlIGJlY2F1c2Ugb2YgYSB0eXBvIG9u IG15IGJlaGFsZjxicj5hbmQvb3IgYXQgdGhlIG1vbWVudCBvZiB3cml0aW5nIHRoZSBkZXNjcmlw dGlvbiBJIGZvcmdvdCB0aGUgQXRvbSB2ZXJzaW9uPGJyPm51bWJlciAodGhpcyBpcyBiZWNhdXNl IEkgZG9uJ3Qgd29yayB3aXRoIGZlZWRzIHRvbyBvZnRlbikuIEkgd2FzIGh1cnJpZWQKPGJyPnRv IHJlbGVhc2UgdGhlIHdpZGdldCBmb3IgdGhlaXIgY29tcGV0aXRpb24uPGJyPjxicj5ZZXMsIEkg d2lsbCB0YWtlIHRoZSBzdGVwcyB0byBnZXQgdGhhdCBmaXhlZCwgQVNBUC48YnI+PGJyPlRoYW5r cyBmb3IgdGhlIG5pY2UgcmVwbHkgOikuPGJyPjxicj48YnI+LS08YnI+PGEgaHJlZj0iaHR0cDov L3d3dy5yb2JvZGVzaWduLnJvIj5odHRwOi8vd3d3LnJvYm9kZXNpZ24ucm8KPC9hPjxicj5ST0JP IERlc2lnbiAtIFdlIGJyaW5nIHlvdSB0aGUgZnV0dXJlPGJyPjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5NLiBEYXZp ZCBQZXRlcnNvbjxicj48YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iPmh0dHA6Ly93 d3cueHNsdGJsb2cuY29tLzwvYT4K ------=_Part_77616_5871639.1146647501600-- From owner-atom-syntax@mail.imc.org Wed May 03 05:23:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDaP-00043K-LT for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:23:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDYI-0005UC-TY for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:21:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4397l6q011106; Wed, 3 May 2006 02:07:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4397loP011105; Wed, 3 May 2006 02:07:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout03-winn.ispmail.ntl.com (mta09-winn.ispmail.ntl.com [81.103.221.49]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4397jeS011080 for ; Wed, 3 May 2006 02:07:46 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20060503090739.HDTJ27969.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Wed, 3 May 2006 10:07:39 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060503090739.EGDL16086.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Wed, 3 May 2006 10:07:39 +0100 Date: Wed, 3 May 2006 10:07:37 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1171557976.20060503100737@djpowell.net> To: Mark Nottingham CC: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? In-Reply-To: <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote: > If you use URIs like > http://example.com/feed?start=5&num=10 > changing the directionality of "next" and "previous" will not make > what you're doing compatible with feed history. > Such URIs have a much more fundamental problem -- they don't refer to > a stable set of entries, and therefore only act as a snapshot of the > *current* feed, chopped up into chunks. If the feed changes between > accesses, the client will be in an inconsistent state. The client > also has to walk through all of the pages every time it fetches the > feed; it can't cache them -- which is a primary requirement for feed > history. I think it would be worth recommending the use of stable URIs in the draft. -- Dave From owner-atom-syntax@mail.imc.org Wed May 03 05:42:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDsA-0006Wn-L6 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:42:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDs9-0006jK-9A for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:42:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k439QZeK011932; Wed, 3 May 2006 02:26:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k439QZh4011931; Wed, 3 May 2006 02:26:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k439QXOT011920 for ; Wed, 3 May 2006 02:26:34 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 May 2006 09:26:27 -0000 Received: from xdsl-213-196-220-233.netcologne.de (EHLO klangraum) [213.196.220.233] by mail.gmx.net (mp018) with SMTP; 03 May 2006 11:26:27 +0200 X-Authenticated: #163624 Date: Wed, 3 May 2006 11:26:35 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? Message-ID: <20060503092635.GM2690@klangraum> Mail-Followup-To: Atom Syntax References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> <1171557976.20060503100737@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1171557976.20060503100737@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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k439QZeK011932 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 * David Powell [2006-05-03 11:20]: > Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote: > > Such URIs have a much more fundamental problem -- they don't > > refer to a stable set of entries, and therefore only act as a > > snapshot of the *current* feed, chopped up into chunks. If > > the feed changes between accesses, the client will be in an > > inconsistent state. The client also has to walk through all > > of the pages every time it fetches the feed; it can't cache > > them -- which is a primary requirement for feed history. >=20 > I think it would be worth recommending the use of stable URIs > in the draft. Considering how fundamental stable URIs are to the FH extension and how much of the previous discussion has revolved around them, I=E2=80=99m surprised there isn=E2=80=99t already language to that effect= in the text. In fact, I would have expected a SHOULD or two on this subject. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 03 05:44:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDuL-0007EY-5R for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:44:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDuK-0006px-PN for atompub-archive@lists.ietf.org; Wed, 03 May 2006 05:44:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k439WG32012496; Wed, 3 May 2006 02:32:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k439WGY0012495; Wed, 3 May 2006 02:32:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k439WFPI012489 for ; Wed, 3 May 2006 02:32:15 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1FbDiQ-0002lZ-Dp; Wed, 03 May 2006 11:32:14 +0200 Received: from ultra16.rbg.informatik.tu-darmstadt.de ([130.83.160.106]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1FbDiQ-00066o-BF; Wed, 03 May 2006 11:32:14 +0200 Message-ID: <4458789C.1060802@rbg.informatik.tu-darmstadt.de> Date: Wed, 03 May 2006 11:32:12 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> <4457DF8A.3070508@gmail.com> <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@mail.gmail.com> In-Reply-To: <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Robert Sayre wrote: > James M Snell wrote: >> Again, however, Feed Rank is not intended to compete with the >> simple list extensions. They serve different purposes. SLE >> defines a processing model for individual feed documents whose >> entries represent a sorted list; Feed Rank defines a way of >> assigning numeric rankings to entries to facilitate sorting and >> grouping. > > I find this explanation most unconvincing. Near as I can tell, this > spec serves an identical purpose, but it's much less flexible. > > In the Atom Syndication Format [RFC4287], the order of entries as > presented in a feed is typically considered to be insignificant. This > presents a challenge when the set of entries is intended to > represent an ordered or ranked list. This document specifies an > extension... > > Seems to me it's pretty darn similar. Your observation is correct. However, this only means that we need to revise Feed Rank's introductory section to state its use applications clearly. The second sentence of the introduction, which you unfortunately dropped in your quote, should definitly mention the fact that Feed Rank allows several, independent order relations to be defined on the set of entries. ... This document specifies an extension that allows feed publishers to establish numeric rankings for entries within a feed to be used as a means of organizing and sorting those entries. IMHO, the following would be an improvement on this, highlighting the purpose Feed Rank is meant to serve: This document specifies an extension that allows feed publishers to establish one or more numeric rankings for entries within a feed, each of which can be used, independently or in conjunction with the others, to sort those entries according to different criteria. But does this sound like an improvement to you, too? Best wishes, Andreas Sewe From owner-atom-syntax@mail.imc.org Wed May 03 07:05:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbFAu-0001Fj-7C for atompub-archive@lists.ietf.org; Wed, 03 May 2006 07:05:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbFAs-0001yx-Ei for atompub-archive@lists.ietf.org; Wed, 03 May 2006 07:05:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43Agppx016410; Wed, 3 May 2006 03:42:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43Agpds016409; Wed, 3 May 2006 03:42:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43Agppa016399 for ; Wed, 3 May 2006 03:42:51 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (83-70-165-76.b-ras1.prp.dublin.eircom.net [83.70.165.76]) by chilco.textdrive.com (Postfix) with ESMTP id 2F67CDBCD5; Wed, 3 May 2006 10:42:58 +0000 (UTC) Message-ID: <44588921.8090702@dehora.net> Date: Wed, 03 May 2006 11:42:41 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Mark Nottingham CC: Atom Syntax Subject: addition to next rev of FH?[was Tools that make use of previous/next/first/last links?] References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> In-Reply-To: <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 (ot for the last thread) Hi Mark, I've just specced out an app that uses FH and this idea of an archived feed hadn't quite come across to me as "safe" - I had some what ifs about server resets that affected the feed. However, the URL: http://example.com/feed?start=5&num=10 nails that concern for me and thus your point about "chunky URLs" which dynamically generated feeds rings true. Would you consider calling this out thing directly in a future rev? I think it might be helpful for robust server designs if some guidance were given. cheers Bill Mark Nottingham wrote: > > If you use URIs like > http://example.com/feed?start=5&num=10 > changing the directionality of "next" and "previous" will not make what > you're doing compatible with feed history. > > Such URIs have a much more fundamental problem -- they don't refer to a > stable set of entries, and therefore only act as a snapshot of the > *current* feed, chopped up into chunks. If the feed changes between > accesses, the client will be in an inconsistent state. The client also > has to walk through all of the pages every time it fetches the feed; it > can't cache them -- which is a primary requirement for feed history. > > What are the requirements that drove you to this type of paging solution? > > > On 2006/05/02, at 9:14 PM, James M Snell wrote: > >> >> Mark Nottingham wrote: >>> [snip] >>>> As it stands now, a single feed >>>> cannot implement APP, OpenSearch AND Feed History. >>> >>> Please describe the scenario where you'd want that to happen -- show the >>> feed. >>> >>> >> >> The feed(s) are part of our open activities implementation and are >> available via our APP interop endpoint [1]. Our APP collection feeds >> are also the feeds people subscribe to and search with (e.g. any of our >> feeds accept querystring parameters to filter the feed results). >> Requesters can set the page size as a querystring, if the result set is >> larger than the page size, the feed is automatically paged using >> first/last/next/previous. The fact that our entries are sorted in >> reverse chronological order makes us compliant with APP, but makes it >> impossible for clients to use the Feed History algorithm (current has a >> next but no previous). >> >> - James >> >> [1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > From owner-atom-syntax@mail.imc.org Wed May 03 08:50:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGoV-00028x-TL for atompub-archive@lists.ietf.org; Wed, 03 May 2006 08:50:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbGoS-0006jP-8f for atompub-archive@lists.ietf.org; Wed, 03 May 2006 08:50:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43CWm8x021886; Wed, 3 May 2006 05:32:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43CWm14021885; Wed, 3 May 2006 05:32:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43CWk2m021877 for ; Wed, 3 May 2006 05:32:47 -0700 (MST) (envelope-from mihai.sucan@gmail.com) Received: by ug-out-1314.google.com with SMTP id c2so47011ugf for ; Wed, 03 May 2006 05:32:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:cc:references:organization:content-type:mime-version:content-transfer-encoding:message-id:in-reply-to:user-agent; b=B6rdE2pWUOITdVE/w7Z0ghMssgA3NG/wXYdP058vMC0cMjGOHDWozPo7dQmOfSoCn4E4kjVBnRnrlUkayikwZXGeiTCHsxz3JwLHlkdjRpHkrUxx+YsszNCdqI5wzGpiqD0AMB1s6e5sDfWh3WQ4NDvcjSjAS5TpRz1QG5TIyy0= Received: by 10.66.166.7 with SMTP id o7mr454319uge; Wed, 03 May 2006 05:32:45 -0700 (PDT) Received: from localhost.localdomain ( [86.34.246.154]) by mx.gmail.com with ESMTP id j2sm505833ugf.2006.05.03.05.32.43; Wed, 03 May 2006 05:32:45 -0700 (PDT) Date: Wed, 03 May 2006 15:32:41 +0300 From: "Mihai Sucan" To: "M. David Peterson" Subject: Re: NOTE TO OPERA STAFF : Problem with misrepresentation of Atom version number in Widget community Cc: "Atom Syntax" References: Organization: http://www.robodesign.ro Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.51 (Linux, build 1462) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k43CWm8x021886 X-Spam-Score: 1.9 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Le Wed, 03 May 2006 12:11:41 +0300, M. David Peterson =20 a =C3=A9crit: > Right on... Good luck! The reason the widget caught my eye in the firs= t > place was because of the lead-in suggesting its generic approach (e.g. = =20 > not > tied to any specific feed.) If I'm going to have a widget feedreader i= ts > needs to be able to access and make available more than one feed... I'= m > amazed that other widget developers find justification in developing > one-feed widgets > I can see from a markleting perspective folks might = =20 > see > the widget craze in similar light to the Google toolbar or the similar = =20 > where > they can drive people to their site by providing them direct-browser =20 > access > to simple utilities that make browsing more enjoyable/easier to find > things. I'm amazed, however, that folks either make this type of > comparison, and therefore justify one-off feed reader widgets, or they = =20 > have > enough of a customer base that doesn't care about any other feed and > therefore justifies such a centralized focus. > > With all of the above, its nice to see that someone has realized a =20 > generic > feed-reader was MANDATORY if they want any level of mass adoption. Thi= s =20 > is > the first one I have seen in the Opera widget library, so best of luck = to > you... you deserve some definite extra-credit points for (as far as I =20 > know > anyway) for being the first off-the-line... If nothing else, theres =20 > reward > in such knowledge in and of itself, but I hope you win either way :) Hello! Yes, true. I also don't see the justification to make a single per-site =20 feed reader widget. It's ... uhm ... useless since (almost) nobody is =20 interested only in, say, slashdot.org. Having many widgets for all sites = =20 I'm interested is *way* too much. The only advantage for such widgets are= =20 marketing advantages. Yes, I also see it important to have a generic feed reader. Thank you for your appreciation. The widget does much better parsing of =20 Atom and RSS 2 feeds than what you see graphically. In the interface I ha= d =20 no time to add all the features and things I wanted. The second version o= f =20 the widget will try to provide as many features as possible. The only =20 problem I have is ... not enough spare time. I have the knowledge I need = =20 to make the Raggregator widget as powerful as dedicated feed readers =20 (podcasting, photocasting, feed grouping, etc). If you look into the =20 source code of the widget, you see I've tried to make it as clean as =20 possible, commented and easy to read. As for the contest. I lost. Maybe I lost because I sent the widget too =20 late (not sure). In regards to the Atom 2 problem. I have updated my blog post and sent a = =20 message to a guy from Opera Software to update the description of the =20 widget. He has already answered me: problem fixed. Thanks again. --=20 http://www.robodesign.ro ROBO Design - We bring you the future From owner-atom-syntax@mail.imc.org Wed May 03 12:02:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJo2-0006MN-Iv for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:02:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbJo2-00065V-4t for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:02:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43Fhui6033626; Wed, 3 May 2006 08:43:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43FhusO033625; Wed, 3 May 2006 08:43:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43FhtsU033617 for ; Wed, 3 May 2006 08:43:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so152225wra for ; Wed, 03 May 2006 08:43:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GU51ORjroUtQcR3eAq89z5jbku3KaY+yi0KuRnElJgCxA2kvpvOBHTQXps1Clw5bYiZpZuVbXU2k3bmUP0nT1wVtmi8DTgzQOuQCdTgRhQlFEuWSS1xmwKqON45mSAplATsrjZk5f0T3ZrXKYG7iqSGlVFmduZ3AIbib6Y0CFco= Received: by 10.54.66.4 with SMTP id o4mr1030238wra; Wed, 03 May 2006 08:43:54 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 8sm117134wrl.2006.05.03.08.43.53; Wed, 03 May 2006 08:43:53 -0700 (PDT) Message-ID: <4458CFB6.9040900@gmail.com> Date: Wed, 03 May 2006 08:43:50 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Tools that make use of previous/next/first/last links? References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> <1171557976.20060503100737@djpowell.net> In-Reply-To: <1171557976.20060503100737@djpowell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 +1, I'd also highly recommend introducing an "archive" link relation that can be used to cleanly separate paged feed documents used for state reconstruction from paged feed documents used for other purposes (e.g. searching) === Attribute Value: archive Description: A URI that, when dereferenced, returns a feed document containing a fixed set of entries that does not change over time. Expected display characteristics: The archive relation may be used for background processing without displaying its value, or, a user agent may support displaying a hyperlink, button or other GUI element for accessing or subscribing to the linked feed document. Security Considerations: Automated agents should take care when this relation crossed administrative domains (e.g. the URI has a different authority than the current document) === Example; - James David Powell wrote: > > Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote: > >> If you use URIs like >> http://example.com/feed?start=5&num=10 >> changing the directionality of "next" and "previous" will not make >> what you're doing compatible with feed history. > >> Such URIs have a much more fundamental problem -- they don't refer to >> a stable set of entries, and therefore only act as a snapshot of the >> *current* feed, chopped up into chunks. If the feed changes between >> accesses, the client will be in an inconsistent state. The client >> also has to walk through all of the pages every time it fetches the >> feed; it can't cache them -- which is a primary requirement for feed >> history. > > I think it would be worth recommending the use of stable URIs in the > draft. > > From owner-atom-syntax@mail.imc.org Wed May 03 12:35:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKKF-0000Ih-JR for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:35:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKKE-0007Sv-5c for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:35:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GMP2A035365; Wed, 3 May 2006 09:22:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43GMPrL035364; Wed, 3 May 2006 09:22:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] ([45.25.131.134]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GMOQL035357 for ; Wed, 3 May 2006 09:22:24 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> <20060502204610.GZ2690@klangraum> <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> Date: Wed, 3 May 2006 09:22:23 -0700 To: atom-syntax From: Paul Hoffman Subject: Re: Atom Rank Extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 At 9:03 PM -0400 5/2/06, Robert Sayre wrote: >If it's a WG >draft, and not individual draft, It is an individual draft. >Of course, our chairs have made it abundantly clear I'm not sure that Tim and I have made much abundantly clear in a while. >but let's just say I'd rather deal with Microsoft than the >IETF at this point. Works for me. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 03 12:50:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKYE-0002uJ-83 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:50:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKYC-00081d-TE for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:50:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GZsEx036060; Wed, 3 May 2006 09:35:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43GZs18036059; Wed, 3 May 2006 09:35:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GZplu036045 for ; Wed, 3 May 2006 09:35:54 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so259579pya for ; Wed, 03 May 2006 09:35:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LP4W+deC8YGZqBlPbf3dLcHpO/JzPCxtiyDJQOhstX7NtUhiD+njqmmqi/H+l3LD9sPAwokKrqfwuj/eqMuf5C54TJHkPt0jyeQaNM4mv9x0+Q9bA6ZgjenGSdtMl8ByQ5dvTL6kDMEPLMw45BY7Sfy/ZB1Nw2RhOGrUZFomDxQ= Received: by 10.35.40.10 with SMTP id s10mr37752pyj; Wed, 03 May 2006 09:35:51 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Wed, 3 May 2006 09:35:51 -0700 (PDT) Message-ID: <68fba5c50605030935q2ded55cfx3e6e9a3cd379e8b5@mail.gmail.com> Date: Wed, 3 May 2006 12:35:51 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Atom Rank Extensions Cc: atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <68fba5c50605021243gbdf07a6n61392538fa849029@mail.gmail.com> <20060502204610.GZ2690@klangraum> <68fba5c50605021803s7be141aci4a562a32c906b5e9@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k43GZslu036054 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On 5/3/06, Paul Hoffman wrote: > > Works for me. > -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 03 12:59:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKhS-0007Zc-QT for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:59:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKhR-0008WF-Cf for atompub-archive@lists.ietf.org; Wed, 03 May 2006 12:59:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GhFhq036287; Wed, 3 May 2006 09:43:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43GhFdm036286; Wed, 3 May 2006 09:43:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GhEHi036280 for ; Wed, 3 May 2006 09:43:14 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.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 E4418519CE; Wed, 3 May 2006 12:43:12 -0400 (EDT) In-Reply-To: <44588921.8090702@dehora.net> References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> <44588921.8090702@dehora.net> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7C32D9C6-D639-4ED3-9A58-15D4C224BC47@mnot.net> Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: addition to next rev of FH?[was Tools that make use of previous/next/first/last links?] Date: Wed, 3 May 2006 09:43:22 -0700 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.749.3) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k43GhEHi036281 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k43GhFhq036287 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 I had this already: "Archive document" refers to a feed document that is archived; i.e., the set of entries inside it does not change over time. Entries within an archive MAY themselves change, however. but if this is catching people by surprise, it obviously isn't =20 prominent enough. I'll hammer it home with some examples, SHOULDs, etc. Thanks! On 2006/05/03, at 3:42 AM, Bill de h=D3ra wrote: > (ot for the last thread) > > Hi Mark, > > I've just specced out an app that uses FH and this idea of an =20 > archived feed hadn't quite come across to me as "safe" - I had some =20 > what ifs about server resets that affected the feed. > > However, the URL: > > http://example.com/feed?start=3D5&num=3D10 > > nails that concern for me and thus your point about "chunky URLs" =20 > which dynamically generated feeds rings true. Would you consider =20 > calling this out thing directly in a future rev? I think it might =20 > be helpful for robust server designs if some guidance were given. > > cheers > Bill > > Mark Nottingham wrote: >> If you use URIs like >> http://example.com/feed?start=3D5&num=3D10 >> changing the directionality of "next" and "previous" will not make =20 >> what you're doing compatible with feed history. >> Such URIs have a much more fundamental problem -- they don't refer =20 >> to a stable set of entries, and therefore only act as a snapshot =20 >> of the *current* feed, chopped up into chunks. If the feed changes =20 >> between accesses, the client will be in an inconsistent state. The =20 >> client also has to walk through all of the pages every time it =20 >> fetches the feed; it can't cache them -- which is a primary =20 >> requirement for feed history. >> What are the requirements that drove you to this type of paging =20 >> solution? >> On 2006/05/02, at 9:14 PM, James M Snell wrote: >>> >>> Mark Nottingham wrote: >>>> [snip] >>>>> As it stands now, a single feed >>>>> cannot implement APP, OpenSearch AND Feed History. >>>> >>>> Please describe the scenario where you'd want that to happen -- =20 >>>> show the >>>> feed. >>>> >>>> >>> >>> The feed(s) are part of our open activities implementation and are >>> available via our APP interop endpoint [1]. Our APP collection =20 >>> feeds >>> are also the feeds people subscribe to and search with (e.g. any =20 >>> of our >>> feeds accept querystring parameters to filter the feed results). >>> Requesters can set the page size as a querystring, if the result =20 >>> set is >>> larger than the page size, the feed is automatically paged using >>> first/last/next/previous. The fact that our entries are sorted in >>> reverse chronological order makes us compliant with APP, but =20 >>> makes it >>> impossible for clients to use the Feed History algorithm =20 >>> (current has a >>> next but no previous). >>> >>> - James >>> >>> [1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html >>> >>> >> --=20 >> Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed May 03 13:10:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKrz-0008Om-9F for atompub-archive@lists.ietf.org; Wed, 03 May 2006 13:10:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbKry-0000i5-SQ for atompub-archive@lists.ietf.org; Wed, 03 May 2006 13:10:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GqPh4036641; Wed, 3 May 2006 09:52:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43GqP0Z036640; Wed, 3 May 2006 09:52:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43GqOtb036634 for ; Wed, 3 May 2006 09:52:24 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.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 90032519AC; Wed, 3 May 2006 12:52:23 -0400 (EDT) In-Reply-To: <4458CFB6.9040900@gmail.com> References: <4455BF00.4090605@gmail.com> <44582E3E.3060201@gmail.com> <094ECE1A-092A-4E3D-8366-991DC43FA9F5@mnot.net> <1171557976.20060503100737@djpowell.net> <4458CFB6.9040900@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E5DAF5F-8225-4786-A131-3E080D0E3B89@mnot.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Tools that make use of previous/next/first/last links? Date: Wed, 3 May 2006 09:52:33 -0700 To: James M Snell X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Any extension that uses "previous" and "next" has to account for the stablity of the underlying resources; if you use *any* paging application and the set of entries in "previous" and "next" changes over time, you're going to potentially end up with a reconstructed feed in inconsistent state. Or do you have use cases where it's OK to have sloppy feed reconstruction? On 2006/05/03, at 8:43 AM, James M Snell wrote: > > +1, I'd also highly recommend introducing an "archive" link relation > that can be used to cleanly separate paged feed documents used for > state > reconstruction from paged feed documents used for other purposes (e.g. > searching) > > === > Attribute Value: archive > > Description: A URI that, when dereferenced, returns a feed document > containing a fixed set of entries that does not change over time. > > Expected display characteristics: The archive relation may be used > for background processing without displaying its value, or, a user > agent may support displaying a hyperlink, button or other GUI > element > for accessing or subscribing to the linked feed document. > > Security Considerations: Automated agents should take care when this > relation crossed administrative domains (e.g. the URI has a > different > authority than the current document) > === > > Example; > > > > - James > > David Powell wrote: >> >> Wednesday, May 3, 2006, 6:48:55 AM, Mark Nottingham wrote: >> >>> If you use URIs like >>> http://example.com/feed?start=5&num=10 >>> changing the directionality of "next" and "previous" will not make >>> what you're doing compatible with feed history. >> >>> Such URIs have a much more fundamental problem -- they don't >>> refer to >>> a stable set of entries, and therefore only act as a snapshot of the >>> *current* feed, chopped up into chunks. If the feed changes between >>> accesses, the client will be in an inconsistent state. The client >>> also has to walk through all of the pages every time it fetches the >>> feed; it can't cache them -- which is a primary requirement for feed >>> history. >> >> I think it would be worth recommending the use of stable URIs in the >> draft. >> >> > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed May 03 14:19:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLwN-0002me-7r for atompub-archive@lists.ietf.org; Wed, 03 May 2006 14:19:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbLwK-0003ik-Hx for atompub-archive@lists.ietf.org; Wed, 03 May 2006 14:19:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43I2TWB040058; Wed, 3 May 2006 11:02:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43I2Tk9040057; Wed, 3 May 2006 11:02:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43I2RLn040051 for ; Wed, 3 May 2006 11:02:28 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so283106pya for ; Wed, 03 May 2006 11:02:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uNcWcHvp6/LAML0vGE3JaJi6O87waErc6sruoLAVx1CzWB0l1KdYWLnLTbm7WsamEyuivEJ0xy79CzRieK1I5nVGybzbJPkn1n1qjoLZGIBWIb6i6GX7OgS9s+wjbmPW3nni9X8CFmPFlApEfkcfDr7l9DI9Dv10rckdZud71Eo= Received: by 10.35.70.17 with SMTP id x17mr1657929pyk; Wed, 03 May 2006 11:02:26 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Wed, 3 May 2006 11:02:26 -0700 (PDT) Message-ID: <68fba5c50605031102r8d0031g6f458db357711b87@mail.gmail.com> Date: Wed, 3 May 2006 14:02:26 -0400 From: "Robert Sayre" To: "Andreas Sewe" Subject: Re: Atom Rank Extensions Cc: "Atom Syntax" In-Reply-To: <4458789C.1060802@rbg.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> <4457DF8A.3070508@gmail.com> <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@mail.gmail.com> <4458789C.1060802@rbg.informatik.tu-darmstadt.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k43I2SLn040052 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 On 5/3/06, Andreas Sewe wrote: > But does this sound like an improvement to you, too? Sort of. I did a deep dive on this, and I think it's really huge. It's had little community input, it's not at all clear that the approach is correct, and it's not clear that clients will implement it, as the space is so new. However, I do understand you want to ship something, and it's nice that you want to document it openly. So, Information or Experimental seems like a good fit here. I think the document needs *a lot* of work. My comments follow: draft-index-09: > 1. Introduction > > In the Atom Syndication Format [RFC4287], the order of entries as > presented in a feed is typically considered to be insignificant. > This presents a challenge when the set of entries is intended to > represent an ordered or ranked list. This document specifies an > extension that allows feed publishers to establish numeric rankings > for entries within a feed to be used as a means of organizing and > sorting those entries. Even with the alternative intro you've supplied, it's not clear what problem this document solves. It seems to claim almost unlimited powers. :) There are quite a few sections that seem to have a very low return to me. I think you need to cut, and cut a lot. I think the value evaporates very quickly outside of the 'ranking' element. > The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML > elements and attributes described in this specification is: > http://purl.org/syndication/rank/1.0 Is this an appropriate namespace for an IETF document? > > 3. Ranking Domains and Schemes > > A "Ranking Domain" is a uniquely identifiable logical set of entries > with associated numeric ranking values. I can parse the sentence, but I don't understand what this means. > A "Ranking Scheme" identifies specific rules on how to interpret the > numeric ranking values within one or more "Ranking Domains". Same here. I suggest avoiding the new terminiology. A more plain-spoken, concrete, operational approach would work better. > 3.1. The 'r:scheme' Element > > Ranking Schemes are defined using the r:scheme element. A scheme > includes zero or more r:value and r:range elements that define the > set of possible values for the Ranking Scheme. > > rankingScheme = element r:scheme { > atomCommonAttributes, > attribute name { IRI }?, > attribute label { text }?, > attribute significance { 'ascending' | 'descending' }?, > ( value | range )* > } > > The "name" attribute provides a universally unique identifier for the > scheme in the form of an absolute IRI. This conflicts with the atom:author field. Why not @id, @domain, etc. > The "label" attribute specifies a Language-Sensitive, human-readable > label for the scheme. OK... > The "significance" attribute indicates how implementations are to > interpret the significance of a numeric ranking value. A value of > "descending" indicates that the significance of the rank decreases as > the numeric ranking value increases. A value of "ascending" > indicates that the significance of the rank increases as the numeric > ranking value increases. If not specified, the significance is > considered to be "ascending". @significance is also confusing. Suggest changing to @order or similar. > An Atom feed element MAY contain any number of r:scheme elements. A > feed MUST NOT contain more than one r:scheme element with the same > name. Well, you have all of these child elements that can change the effect of the element, so why would you want to ban this behavior? > xmlns:r="http://purl.org/syndication/rank/1.0"> > ... > name="tag:example.org,2006:movie_reviews" > xml:lang="en-us" > label="Five Star Reviews" > significance="ascending"> > step="0.5" > minimum="0.0" > maximum="5.0" /> > > ... > This example is confusing because you haven't defined r:range yet. I also suggest grouping some attributes on the same line, if possible. > 3.1.1. The 'r:value' and 'r:range' Elements > > A Ranking Scheme is defined by a collection of zero or more r:value > and r:range elements that constrain the set of values considered > significant by the Scheme. > The value element defines a discreet decimal value. The element's > content value MUST NOT contain and leading or trailing whitespace. 'discreet decimal value' is underspecified. UPDATE: I see you define it later. I suggest using xsd:decimal in the RNC and calling out XML Schema Datatypes at this point. > value = element r:value { > atomCommonAttributes, > attribute label { text }?, > attribute scale { decimal }?, > ( decimal ) > } > > The value element is useful for defining Ranking Schemes consisting > of a set of absolute values as in the example below, This seems really complicated to me. It's not clear to me how an application would apply this data, though I admit to having a fuzzy notion. > The range element defines a range of decimal values that MAY be > bounded by minimum and maximum values. Explain the consequences of including or omitting a boundary. > > The "scale" attribute on both the value and range elements specifies > the total number of decimal digits to the right of the decimal > indicator in the value of the numeric ranking value. The scale is I don't understand this. > > expressed as a non-negative integer. If not specified, the value is > considered to be zero. Ranking Schemes that are based on fractional > numeric ranking values SHOULD specify a scale. Numeric ranking > values that use a larger scale than defined for the scheme MUST be > rounded to the nearest in-scale value (e.g. with scale=2, the rank > 0.123 is rounded down to 0.12, the rank 0.125 is rounded up to 0.13.) ... > The "step" attribute specifies the minimum significant increment for ... > The "origin" attribute specifies the base from which steps in a range ... > Ranges and values defined within a Scheme MUST NOT overlap one > another. This section is really, really dense. I have a hard time understanding any of it. Perhaps some Excel-like ASCII table illustrations would help. > rankingValue = element r:rank { > atomCommonAttributes, > attribute domain { IRI }?, > attribute scheme { IRI }?, > attribute label { text }?, > { decimal } > } Given this definition, it's not clear to me why the feed-level stuff is necessary. Is the idea that clients have to know that to edit? > Ranking Domains group entries with attached numeric ranking values to > logical sets. Ranking Domains are uniquely identified by IRIs. "Ranking Domains" come back to haunt us. I'm lost here. > Domain Scopes SHOULD be considered open sets consistings of entries > from any number of feeds. More strange terminology. > Processing a Ranking Domain to produce an ordered set involves the > following steps: > o Select the Ranking Scheme. > o Identify the Ranking Domain > o Identify the available set of entries containing numeric ranking > values within the identified Ranking Domain using the selected > Ranking Scheme. > o Remove from the set all entries whose rankings fall outside the > minimum and maximum values set by the selected Ranking Scheme. > o Sort the remaining set of ranked entries according to the > significance and step of the numeric ranking as defined by the > Ranking Scheme. Ah, some enlightenment here. You definitely need to get this text up front, expand it, and intersperse this text with illustrations. This is the text that tells implementers what they're supposed to do. > Feeds MAY contain ranked entries that have no specified scheme. In > such cases the Default Ranking Scheme should be applied. This seems like overkill. > The Default Ranking Scheme assumes ascending significance and a > single range with no minimum or maximum value, no significant step, > unspecified scale, and an origin of 0. Oh wait, is this the introduction of this term? It doesn't seem useful to me. I suggest text along the lines of "If there is no scheme specified, [explain default processing]." No terminology necessary. > 8. Well-Known Ranking Schemes > > Feeds MAY contain ranked entries whose ranking scheme cannot be > resolved (i.e., no r:scheme with a "name" attribute matching the > rankings "scheme" attribute can be found). In such cases software > implementations MAY attempt to match such rankings to well-known > schemes. For instance, an online search engine may choose to define > a ranking scheme that is reflective of the relevance of a given > result to a search query; rather than require that a r:scheme element > be included in every feed where the Ranking Scheme may be used, the > search engine may separately publish its Ranking Scheme and > associated Ranking Domain. (The format of such a publication is > beyond the scope of this specification.) > > A hypothetical search engine ranking using a well-known scheme > > 5 > > If a Ranking Scheme cannot be resolved this way (e.g., no r:scheme > with a matching "name" attribute can be found and the scheme is not > well-known), the Default Ranking Scheme should be applied. > > Further, it is possible that a processor may resolve multiple Ranking > Schemes for a given Ranking. For instance, a feed may contain an > "r:scheme" that redefines a scheme well-known to the processor. In > such cases, processors should issue a warning to the user. This capability seems like total overkill. > > Because this specification defines an extension to the Atom > Syndication Format [RFC4287], it is subject to the same security > consideration as defined in section 8 of that specification. > > Appendix A. Acknowledgements > > The authors gratefully acknowledge the feedback from the Atom > Publishing working group during the development of this > specification. You should also acknowledge verbatim copies of text from RFC4287. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed May 03 15:52:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNOr-0002Ih-8E for atompub-archive@lists.ietf.org; Wed, 03 May 2006 15:52:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbNOn-0007Sy-Mm for atompub-archive@lists.ietf.org; Wed, 03 May 2006 15:52:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43JVIL4044247; Wed, 3 May 2006 12:31:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43JVIEt044246; Wed, 3 May 2006 12:31:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43JVHM9044240 for ; Wed, 3 May 2006 12:31:17 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060503193111.KRNO29040.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Wed, 3 May 2006 20:31:11 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060503193111.PPGZ16086.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Wed, 3 May 2006 20:31:11 +0100 Date: Wed, 3 May 2006 20:31:09 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1429274794.20060503203109@djpowell.net> To: "James Holderness" CC: "atom-syntax" Subject: Re: Atom Rank Extensions In-Reply-To: References: <44569816.6090708@gmail.com> <4457BE72.5050100@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Tuesday, May 2, 2006, 10:06:51 PM, James Holderness wrote: > Just looking at that example, it seems to me that an aggregator that > implements Microsoft's simple list extensions would get a full-featured > representation of that feed without having to know anything at all about > feed rank and feed history. So why bother with them? I made a suggestion for avoiding implicit ordering in SLE on the FEED-TECH list[1]. Basically to allow the cf:treatAs to use the @element and @data-type attributes that are used in cf:sort and cf:group elements, so that entries could include a datestamp, or index, which could be used for the ordering of the list rather than the natural ordering. [1] http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0603d&L=feed-tech&T=0&F=&S=&P=312 Actually - can cf:list be used together with cf:sort@default='true'?, I think I'll ask... -- Dave From owner-atom-syntax@mail.imc.org Wed May 03 18:39:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQ01-00035D-Eg for atompub-archive@lists.ietf.org; Wed, 03 May 2006 18:39:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbQ00-00069m-01 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 18:39:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MQuip050336; Wed, 3 May 2006 15:26:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43MQuRH050335; Wed, 3 May 2006 15:26:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MQrBo050312 for ; Wed, 3 May 2006 15:26:55 -0700 (MST) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay06.plus.net with esmtp (Exim) id 1FbPo0-0003UW-3M for atom-syntax@imc.org; Wed, 03 May 2006 23:26:48 +0100 To: atom-syntax@imc.org (Atom Syntax) In-Reply-To: Subject: Re: Tools that make use of previous/next/first/last links? From: pmrobinson@gmx.net (Peter Robinson) Date: Wed, 3 May 2006 23:26:45 +0100 Message-ID: <1hesbmp.17odc7i1498a17M%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.4.6) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Mark Nottingham wrote: > On 2006/05/01, at 12:55 AM, James M Snell wrote: > > > As it stands now, a single feed > > cannot implement APP, OpenSearch AND Feed History. > > Please describe the scenario where you'd want that to happen -- show > the feed. I don't use APP, but this feed implements OpenSearch and would like to allow clients to maintain a history: The OpenSearch description is here: (The name is a holdover from when OpenSearch was rss-only.) Regards, Peter From owner-atom-syntax@mail.imc.org Wed May 03 18:39:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQ02-000382-2t for atompub-archive@lists.ietf.org; Wed, 03 May 2006 18:39:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbQ01-00069n-Ng for atompub-archive@lists.ietf.org; Wed, 03 May 2006 18:39:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MQuko050334; Wed, 3 May 2006 15:26:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k43MQupO050333; Wed, 3 May 2006 15:26:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k43MQrsB050311 for ; Wed, 3 May 2006 15:26:55 -0700 (MST) (envelope-from pmrobinson@gmx.net) Received: from [80.229.20.190] (helo=[192.168.0.8]) by pih-relay06.plus.net with esmtp (Exim) id 1FbPny-0003UW-VB for atom-syntax@imc.org; Wed, 03 May 2006 23:26:47 +0100 To: atom-syntax@imc.org (atom-syntax) In-Reply-To: <4B5AC086-4051-4835-8D61-9EC702CE7ADD@mnot.net> Subject: Re: Tools that make use of previous/next/first/last links? From: pmrobinson@gmx.net (Peter Robinson) Date: Wed, 3 May 2006 23:26:44 +0100 Message-ID: <1hesa4h.19kcnzs13dnopwM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.4.6) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Mark Nottingham wrote: > Can you expand upon "being more precise about exactly what is needed"? I don't have time to go into very much detail right now, but basically it's about what people are calling 'stable urls' in another part of this thread. The draft calls feeds where it's sensible to maintain a history 'incremental feeds', but defines an incremental feed as a 'subscription document' plus a series of 'archive documents'. An archive document is defined as a feed (url) whose entry set doesn't change. It was necessary for you to require 'archive documents' with fixed element sets because your history reconstruction algorithm's state is stored as feed urls. If you rework the algorithm so its state is stored in terms of s or s then you no longer require archive documents to have fixed entry sets (and they probably shouldn't be called archive documents in that case). I need to write down a concrete algorithm that remembers s instead of feed urls, but I believe that is perfectly possible (without any particular extra burden on the client) if you have these two requirements (which need more formal wording): - new entries can only be inserted at the start of the 'logical feed' - old entries can only be deleted at the end of the 'logical feed' (you can weaken these to make no requirement of the order within a single feed document's xml as long as the 'real' order is preserved on the server) The simplest way to satisfy those two requirements is to have a conventional feed where the entries are ordered by publication date and none are ever removed. For a feed that satisfies those requirements whose pages are all 'sliding windows' it's not possible to miss any entries if you traverse the next/prev links in the right direction. Regards, Peter From owner-atom-syntax@mail.imc.org Wed May 03 22:14:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbTM7-000156-B6 for atompub-archive@lists.ietf.org; Wed, 03 May 2006 22:14:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbTM5-0007ls-TF for atompub-archive@lists.ietf.org; Wed, 03 May 2006 22:14:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4421lfu061238; Wed, 3 May 2006 19:01:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4421l5I061237; Wed, 3 May 2006 19:01:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.exchange.microsoft.com (mail4.exchange.microsoft.com [131.107.1.99]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4421jZb061231 for ; Wed, 3 May 2006 19:01:46 -0700 (MST) (envelope-from seanlynd@exchange.microsoft.com) Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:01:40 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.536.10; Wed, 3 May 2006 19:01:39 -0700 Received: from df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 19:01:39 -0700 From: Sean Lyndersay To: David Powell , James Holderness CC: atom-syntax Date: Wed, 3 May 2006 18:59:12 -0700 Subject: RE: Atom Rank Extensions Thread-Topic: Atom Rank Extensions Thread-Index: AcZu6a0Sq0Z06Av2Rg2VKRBoyEAG/wAMj6pw Message-ID: <9138FF9DE9175C489F6F5477262E4FA8DDB9A8@DF-TERRIER-MSG.exchange.corp.microsoft.com> In-Reply-To: <1429274794.20060503203109@djpowell.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: x-microsoft-aal: 22 x-microsoft-cal: 11 x-microsoft-multilevel-authmechanism: SecureMapiSubmit x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginalArrivalTime: 04 May 2006 02:01:39.0602 (UTC) FILETIME=[AE9F5F20:01C66F1E] X-MS-Exchange-Organization-SCL: -1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4421kZb061232 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 David, Looks like I picked a good time to catch up on Atom-syntax mail. > Actually - can cf:list be used together with cf:sort@default='true'?, Yes, it can. See the example in the explanatory doc we posted a while back. http://blogs.msdn.com/rssteam/articles/SimpleListExtensionsExplained.aspx That example feed is online here: http://sean.members.winisp.net/lists/bookexample.xml -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of David Powell Sent: Wednesday, May 03, 2006 12:31 PM To: James Holderness Cc: atom-syntax Subject: Re: Atom Rank Extensions Tuesday, May 2, 2006, 10:06:51 PM, James Holderness wrote: > Just looking at that example, it seems to me that an aggregator that > implements Microsoft's simple list extensions would get a full-featured > representation of that feed without having to know anything at all about > feed rank and feed history. So why bother with them? I made a suggestion for avoiding implicit ordering in SLE on the FEED-TECH list[1]. Basically to allow the cf:treatAs to use the @element and @data-type attributes that are used in cf:sort and cf:group elements, so that entries could include a datestamp, or index, which could be used for the ordering of the list rather than the natural ordering. [1] http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0603d&L=feed-tech&T=0&F=&S=&P=312 Actually - can cf:list be used together with cf:sort@default='true'?, I think I'll ask... -- Dave From owner-atom-syntax@mail.imc.org Thu May 04 09:14:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbdf0-0001sA-Dh for atompub-archive@lists.ietf.org; Thu, 04 May 2006 09:14:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbdes-0002bZ-N3 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 09:14:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44CwBX7090506; Thu, 4 May 2006 05:58:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44CwB3M090505; Thu, 4 May 2006 05:58:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k44Cw7em090496 for ; Thu, 4 May 2006 05:58:10 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 May 2006 12:57:52 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp029) with SMTP; 04 May 2006 14:57:52 +0200 X-Authenticated: #163624 Date: Thu, 4 May 2006 14:57:54 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread -09 (was: Re: Atom Rank Extensions) Message-ID: <20060504125754.GR2690@klangraum> Mail-Followup-To: atom-syntax References: <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <44580802.7080500@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k44CwBX7090506 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 * James M Snell [2006-05-03 03:45]: > Ok, so how's this (not word-for-word as I would write it in the > spec, but you should get the idea) >=20 > The ref attribute MUST be an absolute URI that matches a the > resolved href URI of a replies link character-for-character > (case sensitive) >=20 > In other words; >=20 > xml:base=3D"http://example.org/foo" /> > I don=E2=80=99t know if I like it. It really, *really* departs from =E2=80=9Csomething that=E2=80=99s as simple to implement as possible,=E2=80= =9D doesn=E2=80=99t it? Not only is this just as hard for consumers to implement as previous sketches, it=E2=80=99ll *also* annoy publishers, I think. Question: what is the reason you are so staunchly opposed to cloning `atom:link` for the extension=E2=80=99s purposes? I=E2=80=99m starting to think that that is the only sane answer. If you want to provide additional information about a link, you need to associate this information with the link somehow. If you want to stick to the spec mechanisms for extending the format, then you have to provide this information in extension elements and you must not add attributes to the link. So you must identify the link by one of its attributes. The only attribute of `atom:link` by which you can identify it at all is `href`. However, if you factor in xml:base, you=E2=80=99re in a world of pain, and I don=E2=80=99= t see any way out of that. The only other option I see is a very ugly hack: ride on the back the `rel` attribute, abusing the fact that a relation may be a URI to provide an identifier, ie. something like But that=E2=80=99s so awful and dirty on so many levels that that I have to go wash my hands now. Ugh. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 04 12:05:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgK5-000234-H6 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 12:05:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbgK5-0001nO-3H for atompub-archive@lists.ietf.org; Thu, 04 May 2006 12:05:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44Fm55I098651; Thu, 4 May 2006 08:48:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44Fm5M2098650; Thu, 4 May 2006 08:48:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44Fm4Yk098643 for ; Thu, 4 May 2006 08:48:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id t15so351098wxc for ; Thu, 04 May 2006 08:48:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=UumFmTcNaUSWTWsX57Inqvda221OckYwrSvEqBtQeEmfi9ptFEd+IStxFBOOAi8jWWDU3VoogyqkKbHb/nkTFecTY/NI8xxwL3VB7tawicsH7te5L+Q5+9b1DCZa0RVDtvUaERBRNQ5DDhV5y1SLNIlTU0QCWYfWaV5LC+43lFg= Received: by 10.70.100.14 with SMTP id x14mr866111wxb; Thu, 04 May 2006 08:48:03 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id h9sm7773399wxd.2006.05.04.08.48.02; Thu, 04 May 2006 08:48:03 -0700 (PDT) Message-ID: <445A222F.3050805@gmail.com> Date: Thu, 04 May 2006 08:47:59 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed thread -09 References: <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> In-Reply-To: <20060504125754.GR2690@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k44Fm55I098651 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 A. Pagaltzis wrote: >[snip] > I don=E2=80=99t know if I like it. It really, *really* departs from > =E2=80=9Csomething that=E2=80=99s as simple to implement as possible,=E2= =80=9D doesn=E2=80=99t > it? Not only is this just as hard for consumers to implement as > previous sketches, it=E2=80=99ll *also* annoy publishers, I think. >=20 Yep. > Question: what is the reason you are so staunchly opposed to > cloning `atom:link` for the extension=E2=80=99s purposes? >=20 I am very much against the idea of encouraging extension developers to go off and clone core Atom elements whenever they want to provide some additional piece of information. e.g., Say I create a thr:link. what value would that add to end users and feed reader implementors? OpenSearch already has their own os:link. Gdata has entryLink and feedLink (which aren't clones of atom:link, but are still links nonetheless). The more we clone and duplicate the function of atom:link, the less valuable and useful atom:link becomes, and the more we put undue burden on feed consumers. > I=E2=80=99m starting to think that that is the only sane answer. If you The only sane answer would have been to make link extensible. If I thought it would actually be a fruitful exercise, I would suggest that we amend rfc4287 to make it extensible, per section 4.1.1 of RFC2026: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change ... of the specification before it advances. However, for now, I think I'll proceed by simply dropping the count and when from the draft. The folks who want those things can add them back under a different namespace. It's not worth chasing our tails over two pieces of optional metadata. I've already prepared a draft -10 that removes the attributes complete, I just haven't sent it off yet. - James From owner-atom-syntax@mail.imc.org Thu May 04 13:32:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhgc-00069b-Bu for atompub-archive@lists.ietf.org; Thu, 04 May 2006 13:32:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbhgb-0005Uu-06 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 13:32:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44HJ8uA005221; Thu, 4 May 2006 10:19:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44HJ8X7005220; Thu, 4 May 2006 10:19:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k44HJ6XX005213 for ; Thu, 4 May 2006 10:19:07 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 May 2006 17:18:59 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp006) with SMTP; 04 May 2006 19:18:59 +0200 X-Authenticated: #163624 Date: Thu, 4 May 2006 19:19:07 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread -09 Message-ID: <20060504171907.GU2690@klangraum> Mail-Followup-To: atom-syntax References: <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <20060502164902.GN2690@klangraum> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <445A222F.3050805@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k44HJ8uA005221 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * James M Snell [2006-05-04 18:00]: > The only sane answer would have been to make link extensible. There=E2=80=99s no doubt about that at this point. Non-extensibility of links has caused us a lot of pain in several different extensions at this point. Unfortunately, only hindsight is 20/20=E2=80=A6 > However, for now, I think I'll proceed by simply dropping the > count and when from the draft. Okay. It=E2=80=99s a pity, since folks were obviously getting value from that information, but it=E2=80=99s an acceptable move. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 04 17:30:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblP8-0003f5-Py for atompub-archive@lists.ietf.org; Thu, 04 May 2006 17:30:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblP5-00083R-7b for atompub-archive@lists.ietf.org; Thu, 04 May 2006 17:30:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44LI8MC016753; Thu, 4 May 2006 14:18:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44LI8Xc016752; Thu, 4 May 2006 14:18:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44LI6kZ016746 for ; Thu, 4 May 2006 14:18:07 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so557806nzf for ; Thu, 04 May 2006 14:18:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZVbZEFuE/nbvgjqbyPPTHbWlcHb1mI+CAeA0Rd54uXlJK8+NxM9QpepwcCHP6zWLyi94B6/fcCYow13JMSPTAvH/RQ1U8lvItJO71X/RBS015fGUrByJgqKMx5BtjCy+mXyRu7qfDUVXwM/t7IWizyvTfKM0Hr3eXfo817JJ/Mw= Received: by 10.65.235.17 with SMTP id m17mr7304qbr; Thu, 04 May 2006 14:18:01 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Thu, 4 May 2006 14:18:01 -0700 (PDT) Message-ID: Date: Thu, 4 May 2006 15:18:01 -0600 From: "M. David Peterson" To: atom-syntax Subject: Re: Feed thread -09 In-Reply-To: <20060504171907.GU2690@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1953_32091774.1146777481192" References: <68fba5c50605012016if7d500bnb82d52dd05186a6c@mail.gmail.com> <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> <20060504171907.GU2690@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 ------=_Part_1953_32091774.1146777481192 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBhIG5vdGU6ICBXaGVuIHlvdSBjb25zaWRlciB0aGF0IHdoYXQgcGVvcGxlIGdhaW4gaXMs IGluIGVzc2VuY2UsIGEKc2ltcGxpZmllZCB3YXkgdG8gZ2FpbiBhY2Nlc3MgdG8gaW5mb3JtYXRp b24gdGhhdCBpcyBvdGhlcndpc2UgYWNjZXNzaWJsZSwKanVzdCBhdCBhIGhpZ2hlciBvdmVyLXRo ZS13aXJlICwgYW5kIHByb2Nlc3NvciBpbnRlbnNpdmUgY29zdCwgdGhlbiBpdCBtYWtlcwphIGxv dCBvZiBzZW5zZSB0byBjcmVhdGUgYW4gZXh0ZW5zaWJsZSBuYW1lc3BhY2Uvc3BlY2lmaWNhdGlv biBkZXZvdGVkCnN0cmljdGx5IHRvIHRoZXNlIHR5cGVzIG9mIHRoaW5ncy4gIFRoaXMgd291bGQg YWxsb3cgZm9yIGF0IGxlYXN0IHR3bwp0aGluZ3M6CgotIHRoZSBhYmlsaXR5IGZvciBleHBlcmll bmNlICJmcm9tLXRoZS1maWVsZCIsIG9yIGluIG90aGVyIHdvcmRzLCBhcmVhcyBvZgpvcHRpbWl6 YXRpb24gYW5kL29yIGNvbnZlbmllbmNlIHRoYXQgaGF2ZSBiZWVuIGRpc2NvdmVyZWQgcGFzdCB0 aGUgcG9pbnQgb2YKYSBzcGVjaWZpY2F0aW9uIGxhc3QtY2FsbCwgYW5kIHlldCBhZGQgdmFsdWUg dG8gbW9yZSB0aGFuIG9uZSBpbXBsZW1lbnRvciwKYW5kIGFzIHN1Y2gganVzdGlmaWNhdGlvbiBm b3IgY29sbGFib3JhdGlvbiBvbiBob3cgdG8gZ28gYWJvdXQgdGhpbmdzIGluIGEKd2F5IHRoYXQg bWFrZXMgc2Vuc2UgdG8gbW9yZSB0aGFuIG9uZSBpbXBsZW1lbnRvci4KCi0gVGhlIGFiaWxpdHkg dG8gcHVzaCBvZmYgY29udHJvdmVyc2lhbCwgcXVlc3Rpb25hYmxlLCBhbmQvb3IganVzdCBwbGFp bgp1Z2x5IHBpZWNlcyBvZiBhbnkgZ2l2ZW4gc3BlYyB0aGF0IGRvIGxpdHRsZSBtb3JlIHRoYW4g Y2F1c2UgYSBuZWVkIGZvciB0aGUKc3BlYyBlZGl0b3IgdG8gc3BlbmQgYSBiaXQgb2YgdGltZSB0 byBwcmUtZnVuayBiZWZvcmUgYXBwcm9hY2hpbmcgaGlzL2hlcgppbmJveCwga25vd2luZyBleGFj dGx5IHdoYXQgaXQgaXMgdGhhdCByZXF1aXJlcyBoaW0vaGVyIHRvIGdldCBoYWxmIHdheSB0bwpo aXMvaGVyIGhvbWUgb2ZmaWNlIGJlZm9yZSByZXR1cm5pbmcgdG8gdGhlIGZyaWRnZSBmb3IgYW4g ZXh0cmEgdHdvIGJvdHRsZXMKdG8ga2lsbCB0aGUgcGFpbiB0aGF0cyBib3VuZCB0byBlbnN1ZSBX RUxMIGFmdGVyIHRoZSBwcmUtZnVuayBoYXMgd29ya2VkIGl0cwp3YXkgdGhyb3VnaCB0aGUgc3lz dGVtLiA7KQoKU29tZXRoaW5nIGxpa2UgdGhpcyBjb3VsZCBzdGFydCBhdCB0aGUgQXRvbSB3aWtp IHdpdGggYQoiUG9zdFNwZWNPcHRpbWl6YXRpb25zIiBwYWdlIHNldC11cCB3aGVyZSBmb2xrcyBj YW4gYXR0YWNoIGRhdGEgc2hlZXRzIHdpdGgKdGVzdCByZXN1bHRzLCBvciByZWFsIHdvcmxkIHVz ZS1jYXNlIHN0dWRpZXMgdGhhdCBzaG93Y2FzZSBuZWVkcyBpbgpwYXJ0aWN1bGFyIGFyZWFzIHRo YXQgYXJlIG5vdCBlbm91Z2ggdG8ganVzdGlmeSB0aGVpciBvd24gc3BlYywgYnV0IGVub3VnaAp0 byBvZmZlciBnYWlucyB0byB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUsIGFuZCBhcyBzdWNoLCBq dXN0aWZpY2F0aW9uIHRvCndvcmsgaW4gYSBtb3JlIGNlbnRyYWxpemVkIG1hbm5lciBzdWNoIGFz IHRoaXMgbGlzdCBvbmNlIGl0IGhhcyBnb3R0ZW4gcGFzdAp0aGUgInllYWgsIHRoaXMgbWFrZXMg c2Vuc2UgdG8gbWUgdG9vLi4uIGxldHMgcHJvcG9zZSBpdCIgc3RhZ2UuCgpPciBpcyBzb21ldGhp bmcgbGlrZSB0aGlzIHNpbXBseSBpbnZpdGluZyBXQVkgVE9PIE1BTlkgbGl0dGxlIHRoaW5ncyB0 byBmaW5kCmp1c3RpZmljYXRpb24gdG8gcGx1ZyB1cCB0aGUgY29sbGVjdGl2ZSBpbmJveCBvZiB0 aGUgY29tbXVuaXR5IG1lbWJlcnM/CgoKT24gNS80LzA2LCBBLiBQYWdhbHR6aXMgPHBhZ2FsdHpp c0BnbXguZGU+IHdyb3RlOgo+Cj4KPiAqIEphbWVzIE0gU25lbGwgPGphc25lbGxAZ21haWwuY29t PiBbMjAwNi0wNS0wNCAxODowMF06Cj4gPiBUaGUgb25seSBzYW5lIGFuc3dlciB3b3VsZCBoYXZl IGJlZW4gdG8gbWFrZSBsaW5rIGV4dGVuc2libGUuCj4KPiBUaGVyZSdzIG5vIGRvdWJ0IGFib3V0 IHRoYXQgYXQgdGhpcyBwb2ludC4gTm9uLWV4dGVuc2liaWxpdHkgb2YKPiBsaW5rcyBoYXMgY2F1 c2VkIHVzIGEgbG90IG9mIHBhaW4gaW4gc2V2ZXJhbCBkaWZmZXJlbnQgZXh0ZW5zaW9ucwo+IGF0 IHRoaXMgcG9pbnQuCj4KPiBVbmZvcnR1bmF0ZWx5LCBvbmx5IGhpbmRzaWdodCBpcyAyMC8yMOKA pgo+Cj4gPiBIb3dldmVyLCBmb3Igbm93LCBJIHRoaW5rIEknbGwgcHJvY2VlZCBieSBzaW1wbHkg ZHJvcHBpbmcgdGhlCj4gPiBjb3VudCBhbmQgd2hlbiBmcm9tIHRoZSBkcmFmdC4KPgo+IE9rYXku IEl0J3MgYSBwaXR5LCBzaW5jZSBmb2xrcyB3ZXJlIG9idmlvdXNseSBnZXR0aW5nIHZhbHVlIGZy b20KPiB0aGF0IGluZm9ybWF0aW9uLCBidXQgaXQncyBhbiBhY2NlcHRhYmxlIG1vdmUuCj4KPiBS ZWdhcmRzLAo+IC0tCj4gQXJpc3RvdGxlIFBhZ2FsdHppcyAvLyA8aHR0cDovL3BsYXNtYXN0dXJt Lm9yZy8+Cj4KPgoKCi0tCjxNOkQvPgoKTS4gRGF2aWQgUGV0ZXJzb24KaHR0cDovL3d3dy54c2x0 YmxvZy5jb20vCg== ------=_Part_1953_32091774.1146777481192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SnVzdCBhIG5vdGU6Jm5ic3A7IFdoZW4geW91IGNvbnNpZGVyIHRoYXQgd2hhdCBwZW9wbGUgZ2Fp biBpcywgaW4gZXNzZW5jZSwgYSBzaW1wbGlmaWVkIHdheSB0byBnYWluIGFjY2VzcyB0byBpbmZv cm1hdGlvbiB0aGF0IGlzIG90aGVyd2lzZSBhY2Nlc3NpYmxlLCBqdXN0IGF0IGEgaGlnaGVyIG92 ZXItdGhlLXdpcmUgLCBhbmQgcHJvY2Vzc29yIGludGVuc2l2ZSBjb3N0LCB0aGVuIGl0IG1ha2Vz IGEgbG90IG9mIHNlbnNlIHRvIGNyZWF0ZSBhbiBleHRlbnNpYmxlIG5hbWVzcGFjZS9zcGVjaWZp Y2F0aW9uIGRldm90ZWQgc3RyaWN0bHkgdG8gdGhlc2UgdHlwZXMgb2YgdGhpbmdzLiZuYnNwOyBU aGlzIHdvdWxkIGFsbG93IGZvciBhdCBsZWFzdCB0d28gdGhpbmdzOgo8YnI+PGJyPi0gdGhlIGFi aWxpdHkgZm9yIGV4cGVyaWVuY2UgJnF1b3Q7ZnJvbS10aGUtZmllbGQmcXVvdDssIG9yIGluIG90 aGVyIHdvcmRzLCBhcmVhcyBvZiBvcHRpbWl6YXRpb24gYW5kL29yIGNvbnZlbmllbmNlIHRoYXQg aGF2ZSBiZWVuIGRpc2NvdmVyZWQgcGFzdCB0aGUgcG9pbnQgb2YgYSBzcGVjaWZpY2F0aW9uIGxh c3QtY2FsbCwgYW5kIHlldCBhZGQgdmFsdWUgdG8gbW9yZSB0aGFuIG9uZSBpbXBsZW1lbnRvciwg YW5kIGFzIHN1Y2gganVzdGlmaWNhdGlvbiBmb3IgY29sbGFib3JhdGlvbiBvbiBob3cgdG8gZ28g YWJvdXQgdGhpbmdzIGluIGEgd2F5IHRoYXQgbWFrZXMgc2Vuc2UgdG8gbW9yZSB0aGFuIG9uZSBp bXBsZW1lbnRvci4KPGJyPjxicj4tIFRoZSBhYmlsaXR5IHRvIHB1c2ggb2ZmIGNvbnRyb3ZlcnNp YWwsIHF1ZXN0aW9uYWJsZSwgYW5kL29yIGp1c3QgcGxhaW4gdWdseSBwaWVjZXMgb2YgYW55IGdp dmVuIHNwZWMgdGhhdCBkbyBsaXR0bGUgbW9yZSB0aGFuIGNhdXNlIGEgbmVlZCBmb3IgdGhlIHNw ZWMgZWRpdG9yIHRvIHNwZW5kIGEgYml0IG9mIHRpbWUgdG8gcHJlLWZ1bmsgYmVmb3JlIGFwcHJv YWNoaW5nIGhpcy9oZXIgaW5ib3gsIGtub3dpbmcgZXhhY3RseSB3aGF0IGl0IGlzIHRoYXQgcmVx dWlyZXMgaGltL2hlciB0byBnZXQgaGFsZiB3YXkgdG8gaGlzL2hlciBob21lIG9mZmljZSBiZWZv cmUgcmV0dXJuaW5nIHRvIHRoZSBmcmlkZ2UgZm9yIGFuIGV4dHJhIHR3byBib3R0bGVzIHRvIGtp bGwgdGhlIHBhaW4gdGhhdHMgYm91bmQgdG8gZW5zdWUgV0VMTCBhZnRlciB0aGUgcHJlLWZ1bmsg aGFzIHdvcmtlZCBpdHMgd2F5IHRocm91Z2ggdGhlIHN5c3RlbS4gOykKPGJyPjxicj5Tb21ldGhp bmcgbGlrZSB0aGlzIGNvdWxkIHN0YXJ0IGF0IHRoZSBBdG9tIHdpa2kgd2l0aCBhICZxdW90O1Bv c3RTcGVjT3B0aW1pemF0aW9ucyZxdW90OyBwYWdlIHNldC11cCB3aGVyZSBmb2xrcyBjYW4gYXR0 YWNoIGRhdGEgc2hlZXRzIHdpdGggdGVzdCByZXN1bHRzLCBvciByZWFsIHdvcmxkIHVzZS1jYXNl IHN0dWRpZXMgdGhhdCBzaG93Y2FzZSBuZWVkcyBpbiBwYXJ0aWN1bGFyIGFyZWFzIHRoYXQgYXJl IG5vdCBlbm91Z2ggdG8ganVzdGlmeSB0aGVpciBvd24gc3BlYywgYnV0IGVub3VnaCB0byBvZmZl ciBnYWlucyB0byB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUsIGFuZCBhcyBzdWNoLCBqdXN0aWZp Y2F0aW9uIHRvIHdvcmsgaW4gYSBtb3JlIGNlbnRyYWxpemVkIG1hbm5lciBzdWNoIGFzIHRoaXMg bGlzdCBvbmNlIGl0IGhhcyBnb3R0ZW4gcGFzdCB0aGUgJnF1b3Q7eWVhaCwgdGhpcyBtYWtlcyBz ZW5zZSB0byBtZSB0b28uLi4gbGV0cyBwcm9wb3NlIGl0JnF1b3Q7IHN0YWdlLgo8YnI+PGJyPk9y IGlzIHNvbWV0aGluZyBsaWtlIHRoaXMgc2ltcGx5IGludml0aW5nIFdBWSBUT08gTUFOWSBsaXR0 bGUgdGhpbmdzIHRvIGZpbmQganVzdGlmaWNhdGlvbiB0byBwbHVnIHVwIHRoZSBjb2xsZWN0aXZl IGluYm94IG9mIHRoZSBjb21tdW5pdHkgbWVtYmVycz88YnI+PGJyPjxicj48ZGl2PjxzcGFuIGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gNS80LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+ CkEuIFBhZ2FsdHppczwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpwYWdhbHR6aXNAZ214LmRlIj5w YWdhbHR6aXNAZ214LmRlPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy MDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8YnI+ KiBKYW1lcyBNIFNuZWxsICZsdDs8YSBocmVmPSJtYWlsdG86amFzbmVsbEBnbWFpbC5jb20iPmph c25lbGxAZ21haWwuY29tPC9hPiZndDsgWzIwMDYtMDUtMDQgMTg6MDBdOjxicj4mZ3Q7IFRoZSBv bmx5IHNhbmUgYW5zd2VyIHdvdWxkIGhhdmUgYmVlbiB0byBtYWtlIGxpbmsgZXh0ZW5zaWJsZS48 YnI+PGJyPlRoZXJlJ3Mgbm8gZG91YnQgYWJvdXQgdGhhdCBhdCB0aGlzIHBvaW50LiBOb24tZXh0 ZW5zaWJpbGl0eSBvZgo8YnI+bGlua3MgaGFzIGNhdXNlZCB1cyBhIGxvdCBvZiBwYWluIGluIHNl dmVyYWwgZGlmZmVyZW50IGV4dGVuc2lvbnM8YnI+YXQgdGhpcyBwb2ludC48YnI+PGJyPlVuZm9y dHVuYXRlbHksIG9ubHkgaGluZHNpZ2h0IGlzIDIwLzIw4oCmPGJyPjxicj4mZ3Q7IEhvd2V2ZXIs IGZvciBub3csIEkgdGhpbmsgSSdsbCBwcm9jZWVkIGJ5IHNpbXBseSBkcm9wcGluZyB0aGU8YnI+ Jmd0OyBjb3VudCBhbmQgd2hlbiBmcm9tIHRoZSBkcmFmdC4KPGJyPjxicj5Pa2F5LiBJdCdzIGEg cGl0eSwgc2luY2UgZm9sa3Mgd2VyZSBvYnZpb3VzbHkgZ2V0dGluZyB2YWx1ZSBmcm9tPGJyPnRo YXQgaW5mb3JtYXRpb24sIGJ1dCBpdCdzIGFuIGFjY2VwdGFibGUgbW92ZS48YnI+PGJyPlJlZ2Fy ZHMsPGJyPi0tPGJyPkFyaXN0b3RsZSBQYWdhbHR6aXMgLy8gJmx0OzxhIGhyZWY9Imh0dHA6Ly9w bGFzbWFzdHVybS5vcmcvIj5odHRwOi8vcGxhc21hc3R1cm0ub3JnLwo8L2E+Jmd0Ozxicj48YnI+ PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj4mbHQ7TTpE LyZndDs8YnI+PGJyPk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNs dGJsb2cuY29tLyI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPgo= ------=_Part_1953_32091774.1146777481192-- From owner-atom-syntax@mail.imc.org Thu May 04 18:54:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbmiR-0004aN-Ra for atompub-archive@lists.ietf.org; Thu, 04 May 2006 18:54:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbmiR-0003lG-Ff for atompub-archive@lists.ietf.org; Thu, 04 May 2006 18:54:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44MhCmu020807; Thu, 4 May 2006 15:43:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44MhC2x020806; Thu, 4 May 2006 15:43:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44MhBEm020800 for ; Thu, 4 May 2006 15:43:11 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id j2so606880nzf for ; Thu, 04 May 2006 15:43:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tH9P9iFhWq8+UPkZ0RMt5ws250ViUGFtWNAr7Ukfm57CIqlLznkggnqwsm+ry4pEsDD2xkgmaRQwLLuEYQDtJSSAlLMkYTosfQ/DOE+hQNfmE4LeRI4K4vYtVse0RZ6aNgJgC2tidyzE3+BBzR3cu0WG5h3lLSTmTk6cvVWU9CI= Received: by 10.36.17.20 with SMTP id 20mr2108163nzq; Thu, 04 May 2006 15:43:11 -0700 (PDT) Received: by 10.36.133.7 with HTTP; Thu, 4 May 2006 15:43:11 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 00:43:11 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Feed thread update In-Reply-To: <445771A5.1020101@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k44MhCEm020801 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k44MhCmu020807 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 2006/5/2, James M Snell : > Regarding the ref vs. href, issue, I really want to discourage client > implementors from using the thr:replies as a link to the comment feed. Why? From what I read this week in other threads (about cloning the atom:link element, etc.), I think it could work. 1. define a "replies" link relation, so there is an atom:link pointing to the replies feed 2. define a thr:replies element with an @href and additional metadata (count, updated), clients are invited to use the thr:replies/@href and *not* to try to match the thr:replies element with an atom:link[@rel=3D"replies"] ; if a "reader" processes thr:replies elements it should then ignore each and every atom:link[@rel=3D"replies"]. Step 1 is either optional (do not define this "replies" link relation) or mandatory (require that there is an atom:link[@rel=3D"replies"] matching each thr:replies element). Those three elements would have equivalent meaning, the last one adding extra metadata: Things would have been far easier if either a) atom:link were extensible or b) xml:base wasn't allowed on every element but only on "sections" (namely, atom:feed, atom:entry and atom:content) that can be included from other documents, so that you don't have to rewrite relative IRIs (I think that's the original rational behind xml:base), but that's not the case=85 To conclude, I think using attributes directly on atom:link is the thing to do, waiting for an amendment to RFC4287 to invite processors/parsers not to discard that extra metadata. The other choice is to totally remove those attributes, which is what you finally chose, I can't blame you. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu May 04 19:33:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbnKX-0004gw-Gk for atompub-archive@lists.ietf.org; Thu, 04 May 2006 19:33:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbnKW-0004ps-5E for atompub-archive@lists.ietf.org; Thu, 04 May 2006 19:33:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44NKOi9022728; Thu, 4 May 2006 16:20:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44NKOWO022727; Thu, 4 May 2006 16:20:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k44NKMcI022720 for ; Thu, 4 May 2006 16:20:23 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 04 May 2006 23:20:16 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp030) with SMTP; 05 May 2006 01:20:16 +0200 X-Authenticated: #163624 Date: Fri, 5 May 2006 01:20:25 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread -09 Message-ID: <20060504232025.GB2690@klangraum> Mail-Followup-To: atom-syntax References: <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> <20060504171907.GU2690@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k44NKOi9022728 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 * M. David Peterson [2006-05-04 23:30]: > Or is something like this simply inviting WAY TOO MANY little > things to find justification to plug up the collective inbox of > the community members? I don=E2=80=99t know. So far during extension development discussions, only the missing extensibility for links has stuck out as a real sore point in RFC 4287. Other than that, the spec has stood up very well with only a few minor errata reported here and there. At least, that=E2=80=99s my impression; I don=E2=80=99t know what others = think, of course. Frankly, I would hope there won=E2=80=99t be much interest =E2=80=93 caus= e if there is, what else would that mean than that we did a shoddy job? :-) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 04 19:51:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbnbd-0003yf-FY for atompub-archive@lists.ietf.org; Thu, 04 May 2006 19:51:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbnbY-0005Sr-0u for atompub-archive@lists.ietf.org; Thu, 04 May 2006 19:51:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44NXvdA023640; Thu, 4 May 2006 16:33:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k44NXv9v023639; Thu, 4 May 2006 16:33:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44NXtUH023633 for ; Thu, 4 May 2006 16:33:56 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k44NXtIH028266 for ; Thu, 4 May 2006 17:33:55 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYR00C01L3CZ100@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 04 May 2006 17:33:55 -0600 (MDT) Received: from [10.192.1.102] ([192.18.45.134]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYR0001MLGJWP85@mail-amer.sun.com>; Thu, 04 May 2006 17:33:55 -0600 (MDT) Date: Thu, 04 May 2006 16:34:10 -0700 From: Tim Bray Subject: Re: Feed thread update In-reply-to: To: Thomas Broyer Cc: Atom-Syntax Message-id: <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: > Things would have been far easier if either a) atom:link were > extensible This assertion that atom:link is not extensible is simply, flatly, completely, wrong. I just went and reviewed 4287 and I think it is perfectly clear on this. I suggest that interested parties review sections 4.2.7, 6.3, and 6.4 and, if they still think there is any problem with child elements of , find language in the RFC which says something other than what those sections say. -Tim From owner-atom-syntax@mail.imc.org Thu May 04 20:22:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbo59-0000dg-74 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:22:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbo57-0006EB-Qc for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:22:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45086fr025025; Thu, 4 May 2006 17:08:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45086oF025024; Thu, 4 May 2006 17:08:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k450847b025017 for ; Thu, 4 May 2006 17:08:05 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 May 2006 00:07:59 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp036) with SMTP; 05 May 2006 02:07:59 +0200 X-Authenticated: #163624 Date: Fri, 5 May 2006 02:08:08 +0200 From: "A. Pagaltzis" To: Atom-Syntax Subject: Re: Feed thread update Message-ID: <20060505000808.GE2690@klangraum> Mail-Followup-To: Atom-Syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4135B840-3FCC-4DB0-A74F-0981EAE45A80@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 * Tim Bray [2006-05-05 01:50]: > This assertion that atom:link is not extensible is simply, > flatly, completely, wrong. I just went and reviewed 4287 and I > think it is perfectly clear on this. I suggest that interested > parties review sections 4.2.7, 6.3, and 6.4 and, if they still > think there is any problem with child elements of , > find language in the RFC which says something other than what > those sections say. The assertion is not that atom:link may not have child elements or namespaced attributes. The assertion is that the list of locations for Metadata elements in Section 6.4 should have included atom:link. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 04 20:25:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbo81-0003DB-8K for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:25:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbo80-0006M5-Tf for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:25:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k450DofE025260; Thu, 4 May 2006 17:13:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k450DoD5025259; Thu, 4 May 2006 17:13:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k450Dng3025252 for ; Thu, 4 May 2006 17:13:49 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id i75so690426pye for ; Thu, 04 May 2006 17:13:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G8GdD3JTHpAhTh5owOwDf939Eg/bIs9OM/a3/zmHlhCU0iC1ytztIzQs5t6omixi0SnCBwn9vavP5p/mXs+dI0mjvIIp+5w/yVovyA63y15uqDvuEZ+OuS7+9TgAF08pp0aYkma8wS9DN1R4Z6OtBdNR9gqam6bspjM/Oj0J9as= Received: by 10.35.78.9 with SMTP id f9mr180102pyl; Thu, 04 May 2006 17:13:49 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Thu, 4 May 2006 17:13:49 -0700 (PDT) Message-ID: <68fba5c50605041713q1ee5655an3cdc47b96dc0831c@mail.gmail.com> Date: Thu, 4 May 2006 20:13:49 -0400 From: "Robert Sayre" To: "Tim Bray" Subject: Re: Feed thread update Cc: "Thomas Broyer" , Atom-Syntax In-Reply-To: <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k450Dog3025254 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On 5/4/06, Tim Bray wrote: > > This assertion that atom:link is not extensible is simply, flatly, > completely, wrong. I agree that it's not an especially convincing or interesting argument, given that 6.4 starts with "Atom allows foreign markup anywhere in an Atom document" We certainly don't want consumers to barf on foreign markup anywhere, so it has to be allowed everywhere. Of course, you'd be foolish to put extension attributes on things like atom:updated, and lots of other places, because then you're going to force people to dive into the feedparser/feedtools/gdata/etc implementation layer. Secondly, we might not like it for strange pseudo-nationalistic reasons, but some implementers find it convenient to transcode Atom to RSS2. when you're doing that, it's more difficult to preserve markup in areas left undefined by the specification. If you want to make a point, and carp on how crappy those applications are, you'll look for an excuse to do it. In reality, those extension points haven't proven that interesting or necessary, and the current thread is a particularly forceful example of that reality for those of who aren't participating. So, it really is that most common of syndication archetypes: the tempest in a teacup. -- Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 04 20:40:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FboMl-0006Kq-FP for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:40:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FboMk-0007S6-41 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 20:40:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k450QCf4025656; Thu, 4 May 2006 17:26:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k450QCWO025655; Thu, 4 May 2006 17:26:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k450QAHm025646 for ; Thu, 4 May 2006 17:26:11 -0700 (MST) (envelope-from kmarvin@google.com) Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id k450Q4Es008491 for ; Fri, 5 May 2006 01:26:05 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=kHANYYwY4Rv67PJRXNDnQyOGXsG6meiRNooIeowba3Ddltq0zxYmtgHdnWahzxOdW NyvTPy49Q9pXYzB776Bgg== Received: from smtp-out2.google.com (epb7.prod.google.com [10.253.130.7]) by lois.corp.google.com with ESMTP id k450P5Wu004902 for ; Thu, 4 May 2006 17:25:58 -0700 Received: by smtp-out2.google.com with SMTP id 7so23403epb for ; Thu, 04 May 2006 17:25:58 -0700 (PDT) Received: by 10.253.130.16 with SMTP id 16mr2925epb; Thu, 04 May 2006 17:25:58 -0700 (PDT) Received: by 10.253.130.17 with HTTP; Thu, 4 May 2006 17:25:58 -0700 (PDT) Message-ID: <192fc9640605041725r1ceda216nc2a33fac7d9fd60a@mail.google.com> Date: Thu, 4 May 2006 19:25:58 -0500 From: "Kyle Marvin" To: "Tim Bray" Subject: Re: Feed thread update Cc: "Thomas Broyer" , Atom-Syntax In-Reply-To: <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k450QCHm025648 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 5/4/06, Tim Bray wrote: > > On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: > > > Things would have been far easier if either a) atom:link were > > extensible > > This assertion that atom:link is not extensible is simply, flatly, > completely, wrong. I just went and reviewed 4287 and I think it is > perfectly clear on this. I suggest that interested parties review > sections 4.2.7, 6.3, and 6.4 and, if they still think there is any > problem with child elements of , find language in the RFC > which says something other than what those sections say. -Tim I'll admit that I was unclear on this point: the motivation behind sometimes using 'extensionElement' and other times 'undefinedContext' in the Relax-NG schemas for various 4287 elements is a point of confusion. But as Tim says, literally speaking I don't think either one precludes elements in a foreign namespace. -- Kyle From owner-atom-syntax@mail.imc.org Thu May 04 21:54:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbpWC-0000fG-UQ for atompub-archive@lists.ietf.org; Thu, 04 May 2006 21:54:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpW9-0001me-AD for atompub-archive@lists.ietf.org; Thu, 04 May 2006 21:54:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k451g8wW029804; Thu, 4 May 2006 18:42:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k451g8mU029803; Thu, 4 May 2006 18:42:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k451g78K029796 for ; Thu, 4 May 2006 18:42:07 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k451g5IH017644 for ; Thu, 4 May 2006 19:42:06 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYR00D01QJE2D00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 04 May 2006 19:42:05 -0600 (MDT) Received: from [10.192.1.102] ([192.18.45.134]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYR000KDRE5YV20@mail-amer.sun.com>; Thu, 04 May 2006 19:42:05 -0600 (MDT) Date: Thu, 04 May 2006 18:42:16 -0700 From: Tim Bray Subject: Re: Feed thread update In-reply-to: <192fc9640605041725r1ceda216nc2a33fac7d9fd60a@mail.google.com> To: Kyle Marvin Cc: Thomas Broyer , Atom-Syntax Message-id: <25C297F1-AD72-4A6B-A0DE-0BCB139E125E@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> <192fc9640605041725r1ceda216nc2a33fac7d9fd60a@mail.google.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On May 4, 2006, at 5:25 PM, Kyle Marvin wrote: > the motivation behind > sometimes using 'extensionElement' and other times 'undefinedContext' > in the Relax-NG schemas for various 4287 elements is a point of > confusion. Agreed. Fortunately the schema's non-normative. -Tim From owner-atom-syntax@mail.imc.org Thu May 04 21:57:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbpZF-0002mh-Ii for atompub-archive@lists.ietf.org; Thu, 04 May 2006 21:57:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpZD-0001oV-4k for atompub-archive@lists.ietf.org; Thu, 04 May 2006 21:57:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k451hRT8029850; Thu, 4 May 2006 18:43:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k451hRLI029849; Thu, 4 May 2006 18:43:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k451hQ9x029843 for ; Thu, 4 May 2006 18:43:26 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k451hQIH018077 for ; Thu, 4 May 2006 19:43:26 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYR00601PGET800@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 04 May 2006 19:43:26 -0600 (MDT) Received: from [10.192.1.102] ([192.18.45.134]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYR00JF3RGE4J20@mail-amer.sun.com>; Thu, 04 May 2006 19:43:26 -0600 (MDT) Date: Thu, 04 May 2006 18:43:41 -0700 From: Tim Bray Subject: Re: Feed thread update In-reply-to: <20060505000808.GE2690@klangraum> To: "A. Pagaltzis" Cc: Atom-Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> <20060505000808.GE2690@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote: > The assertion is not that atom:link may not have child elements > or namespaced attributes. The assertion is that the list of > locations for Metadata elements in Section 6.4 should have > included atom:link. Mountain, meet molehill. If it turns out to be useful, it'll stick. Otherwise not. -Tim From owner-atom-syntax@mail.imc.org Thu May 04 22:39:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbq96-0006Am-Mn for atompub-archive@lists.ietf.org; Thu, 04 May 2006 22:34:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpxR-0002DZ-SJ for atompub-archive@lists.ietf.org; Thu, 04 May 2006 22:22:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k452Aw5N031203; Thu, 4 May 2006 19:10:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k452AwbN031202; Thu, 4 May 2006 19:10:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k452Av6t031196 for ; Thu, 4 May 2006 19:10:57 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so473690wra for ; Thu, 04 May 2006 19:10:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NuDAfe7jdU6bF17oZlmFN/ScfWGe7LxAwfYBE45aON1nxD4IqUxOOwszfDmvnacFh4nQPRJEcnrtwojuvUQzJzERcz1Pny22rFlyddR758ZcPAuaTv1dDLpTD37tz8pP3hpk6rPe012npGswQdTvoMEB2zM0R3jpoZnvMbKf2S4= Received: by 10.54.124.14 with SMTP id w14mr462742wrc; Thu, 04 May 2006 19:10:56 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 12sm396905wrl.2006.05.04.19.10.55; Thu, 04 May 2006 19:10:56 -0700 (PDT) Message-ID: <445AB42B.4060507@gmail.com> Date: Thu, 04 May 2006 19:10:51 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Feed thread update References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> In-Reply-To: <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Tim, Just to be clear, when I say that link should have been extensible, I mean that link should have used extensionElement* rather than undefinedContent. In fact, to be completely honest, I don't think undefinedContent should have been in the spec at all. atom:link and atom:category are the only two elements that use it, and there does not appear to be any rationale given as to why. With that said, the real question here is not whether namespaced attributes and elements can or can not appear on the atom:link element. As you point out, and as I've mentioned in the past, the spec is very clear on this point. At issue is whether or not authors of standardized extensions should extend elements with undefinedContent when we know full well that there are API implementations out there that have made the extremely shortsighted decision to completely ignore such content. - James p.s. I wonder how many folks realize that the following examples are perfectly legal and valid according to the spec. This is some text Foo! This entry belongs to category foo! Tim Bray wrote: > > On May 4, 2006, at 3:43 PM, Thomas Broyer wrote: > >> Things would have been far easier if either a) atom:link were >> extensible > > This assertion that atom:link is not extensible is simply, flatly, > completely, wrong. I just went and reviewed 4287 and I think it is > perfectly clear on this. I suggest that interested parties review > sections 4.2.7, 6.3, and 6.4 and, if they still think there is any > problem with child elements of , find language in the RFC > which says something other than what those sections say. -Tim > > From owner-atom-syntax@mail.imc.org Thu May 04 22:39:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbq96-0006AL-O2 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 22:34:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbpvG-00027k-I0 for atompub-archive@lists.ietf.org; Thu, 04 May 2006 22:20:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4529DWS031137; Thu, 4 May 2006 19:09:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4529DS5031136; Thu, 4 May 2006 19:09:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4529Bo0031128 for ; Thu, 4 May 2006 19:09:12 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 05 May 2006 02:09:05 -0000 Received: from xdsl-213-196-241-118.netcologne.de (EHLO klangraum) [213.196.241.118] by mail.gmx.net (mp039) with SMTP; 05 May 2006 04:09:05 +0200 X-Authenticated: #163624 Date: Fri, 5 May 2006 04:09:15 +0200 From: "A. Pagaltzis" To: Atom-Syntax Subject: Re: Feed thread update Message-ID: <20060505020915.GG2690@klangraum> Mail-Followup-To: Atom-Syntax References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> <20060505000808.GE2690@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 * Tim Bray [2006-05-05 03:50]: > If it turns out to be useful, it'll stick. Otherwise not. No doubt; but then why did we need so much verbiage in Sec. 6.4. and subsections anyway? Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 04 23:15:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbqnC-0000Vi-SS for atompub-archive@lists.ietf.org; Thu, 04 May 2006 23:15:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbqnB-0004GW-Ee for atompub-archive@lists.ietf.org; Thu, 04 May 2006 23:15:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45353bF033313; Thu, 4 May 2006 20:05:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45353jp033312; Thu, 4 May 2006 20:05:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45350l2033304 for ; Thu, 4 May 2006 20:05:00 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k45350SX001148 for ; Thu, 4 May 2006 21:05:00 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IYR00H01ULNJE00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Thu, 04 May 2006 21:05:00 -0600 (MDT) Received: from [63.172.10.63] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IYR003GTV8BZS20@mail-amer.sun.com>; Thu, 04 May 2006 21:04:59 -0600 (MDT) Date: Thu, 04 May 2006 20:05:15 -0700 From: Tim Bray Subject: Re: Feed thread update In-reply-to: <445AB42B.4060507@gmail.com> To: James M Snell Cc: Atom-Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> <445AB42B.4060507@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On May 4, 2006, at 7:10 PM, James M Snell wrote: > At issue is whether or not authors of standardized > extensions should extend elements with undefinedContent when we know > full well that there are API implementations out there that have made > the extremely shortsighted decision to completely ignore such content. Give me a break, we're in the first *days* of something that will be used for at least decades. Todays' APIs will have a vanishingly- small lifespan in comparison; crippling our expressiveness in deference to them is, frankly, silly. -Tim From owner-atom-syntax@mail.imc.org Fri May 05 05:32:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbwfL-0003po-Tq for atompub-archive@lists.ietf.org; Fri, 05 May 2006 05:32:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbwfL-0002ed-0T for atompub-archive@lists.ietf.org; Fri, 05 May 2006 05:32:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k459Id8e048713; Fri, 5 May 2006 02:18:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k459Idgg048712; Fri, 5 May 2006 02:18:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k459IbLW048705 for ; Fri, 5 May 2006 02:18:37 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.55.190] (helo=mx6.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1FbwSJ-0000YP-Rb; Fri, 05 May 2006 11:18:35 +0200 Received: from ultra19.rbg.informatik.tu-darmstadt.de ([130.83.160.109]) by mx6.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1FbwSJ-0003Pk-Lx; Fri, 05 May 2006 11:18:35 +0200 Message-ID: <445B186B.8010007@rbg.informatik.tu-darmstadt.de> Date: Fri, 05 May 2006 11:18:35 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Atom Rank Extensions References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> <4457DF8A.3070508@gmail.com> <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@mail.gmail.com> <4458789C.1060802@rbg.informatik.tu-darmstadt.de> <68fba5c50605031102r8d0031g6f458db357711b87@mail.gmail.com> In-Reply-To: <68fba5c50605031102r8d0031g6f458db357711b87@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Robert Sayre wrote: > Andreas Sewe wrote: >> But does this sound like an improvement to you, too? > > Sort of. I did a deep dive on this, and I think it's really huge. > It's had little community input, it's not at all clear that the > approach is correct, and it's not clear that clients will implement > it, as the space is so new. I am inclined to agree with your diagnosis that the spec is quite heavyweight for what looks seemingly like a rather straight-forward task, namely ordering entries. And the draft has indeed gained some weight after I joined James as a co-author. :-( This is mostly due to the fact that we tried to cover one use case, which seemed to us like the archetypical case of rankings: grades. So we had a look at the different grading schemes out there at schools and universities worldwide (thanks to wikipedia) and tried to find a common pattern. And this is, unfortunately, not easy (as everyone will know who has spend a term abroad ;-). > However, I do understand you want to ship something, and it's nice > that you want to document it openly. So, Information or Experimental > seems like a good fit here. That would be fine with me. A don't know about James, though. > Even with the alternative intro you've supplied, it's not clear what > problem this document solves. It seems to claim almost unlimited > powers. :) There are quite a few sections that seem to have a very > low return to me. I think you need to cut, and cut a lot. I think the > value evaporates very quickly outside of the 'ranking' element. You mean r:rank, right? Well, the purpose of r:scheme (and its child elements) is to describe the ordered set from which r:rank's values a picked. Think of it as a datatype definition geared specifically at describing those sets of numbers commonly encountered in grading schemes. >> 3. Ranking Domains and Schemes >> >> A "Ranking Domain" is a uniquely identifiable logical set of >> entries with associated numeric ranking values. > > I can parse the sentence, but I don't understand what this means. > >> A "Ranking Scheme" identifies specific rules on how to interpret >> the numeric ranking values within one or more "Ranking Domains". > > Same here. I suggest avoiding the new terminiology. A more > plain-spoken, concrete, operational approach would work better. James has made a change to that respect. The draft now stars an Overview section instead of the more formal language above -- and it is still shorter than the previous one. :-) >> 3.1. The 'r:scheme' Element >> >> Ranking Schemes are defined using the r:scheme element. A scheme >> includes zero or more r:value and r:range elements that define the >> set of possible values for the Ranking Scheme. >> >> rankingScheme = element r:scheme { atomCommonAttributes, attribute >> name { IRI }?, attribute label { text }?, attribute significance { >> 'ascending' | 'descending' }?, ( value | range )* } >> >> The "name" attribute provides a universally unique identifier for >> the scheme in the form of an absolute IRI. > > This conflicts with the atom:author field. Why not @id, @domain, etc. Well, I am not sure what you mean here, but as for @domain you have to realize that a single scheme can be used to rank entries within more than one Ranking Domain (e.g.., within several feeds). Changing @name to @id might cause confusion, since attributes called "id" commonly contain NCNames, not IRIs. I suggest to James using an r:id child element of r:scheme, instead, to mimic atom:id, but somehow he doesn't like the idea. But maybe you can come up with a better name for @name (no pun intended). >> The "significance" attribute indicates how implementations are to >> interpret the significance of a numeric ranking value. A value of >> "descending" indicates that the significance of the rank decreases >> as the numeric ranking value increases. A value of "ascending" >> indicates that the significance of the rank increases as the >> numeric ranking value increases. If not specified, the >> significance is considered to be "ascending". > > @significance is also confusing. Suggest changing to @order or > similar. I don't think it is the term "significance" that is confusing but the way the above paragraph is phrased. I could probably be simplified. (IMHO, "significance" is a more precise term than "order", since the latter refers to the order of *entries* as presented to the user, whereas the former refers to the order of *rank values* within the scheme/set.) >> An Atom feed element MAY contain any number of r:scheme elements. >> A feed MUST NOT contain more than one r:scheme element with the >> same name. > > Well, you have all of these child elements that can change the effect > of the element, so why would you want to ban this behavior? I don't understand the above. :-( Can you please clarify your objection. Thanks. >> The "scale" attribute on both the value and range elements >> specifies the total number of decimal digits to the right of the >> decimal indicator in the value of the numeric ranking value. The >> scale is > > I don't understand this. > >> expressed as a non-negative integer. If not specified, the value >> is considered to be zero. Ranking Schemes that are based on >> fractional numeric ranking values SHOULD specify a scale. Numeric >> ranking values that use a larger scale than defined for the scheme >> MUST be rounded to the nearest in-scale value (e.g. with scale=2, >> the rank 0.123 is rounded down to 0.12, the rank 0.125 is rounded >> up to 0.13.) I don't see the usefulness of @scale either. I probably need to argue some more with James about it. ;-) > .. > >> The "step" attribute specifies the minimum significant increment >> for > > ... > >> The "origin" attribute specifies the base from which steps in a >> range > > ... > >> Ranges and values defined within a Scheme MUST NOT overlap one >> another. > > This section is really, really dense. I have a hard time > understanding any of it. Perhaps some Excel-like ASCII table > illustrations would help. I will try to prepare an alternative section on r:rank and r:value later today and post it to atom-syntax to see whether it is easier to understand. >> rankingValue = element r:rank { >> atomCommonAttributes, >> attribute domain { IRI }?, >> attribute scheme { IRI }?, >> attribute label { text }?, >> { decimal } >> } > > Given this definition, it's not clear to me why the feed-level stuff > is necessary. Is the idea that clients have to know that to edit? Well, for one thing you do not want specify whether the significance of a ranking is "ascending" or "descending" on each and every element. And what r:value and r:range are supposed to provide is some kind of datatype definition for r:rank's value, so that an application might for example adjust its "Filter" GUI accordingly. >> Ranking Domains group entries with attached numeric ranking values >> to logical sets. Ranking Domains are uniquely identified by IRIs. > > "Ranking Domains" come back to haunt us. I'm lost here. :-) The notion of Ranking Domains is going to be much simplified in the next draft. >> Feeds MAY contain ranked entries that have no specified scheme. In >> such cases the Default Ranking Scheme should be applied. > > This seems like overkill. Why? It is just a convenient shorthand that takes almost no time to implement. >> The Default Ranking Scheme assumes ascending significance and a >> single range with no minimum or maximum value, no significant step, >> unspecified scale, and an origin of 0. > > Oh wait, is this the introduction of this term? It doesn't seem > useful to me. I suggest text along the lines of "If there is no > scheme specified, [explain default processing]." No terminology > necessary. Personally I find it easier to think about default data instead of default processing; that's a "Show me your flowcharts [...]. Show me your tables [...]" thing. >> The authors gratefully acknowledge the feedback from the Atom >> Publishing working group during the development of this >> specification. > > You should also acknowledge verbatim copies of text from RFC4287. Done Best wishes, Andreas Sewe From owner-atom-syntax@mail.imc.org Fri May 05 07:39:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyeu-0001fj-94 for atompub-archive@lists.ietf.org; Fri, 05 May 2006 07:39:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbyes-00086R-LI for atompub-archive@lists.ietf.org; Fri, 05 May 2006 07:39:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45BQxU6055015; Fri, 5 May 2006 04:26:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45BQxkM055014; Fri, 5 May 2006 04:26:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45BQwZ2055003 for ; Fri, 5 May 2006 04:26:58 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060505112652.PLWR29343.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Fri, 5 May 2006 12:26:52 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060505112650.SIJO16086.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Fri, 5 May 2006 12:26:50 +0100 Date: Fri, 5 May 2006 12:26:37 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <753628742.20060505122637@djpowell.net> To: Tim Bray CC: James M Snell , Atom-Syntax Subject: Re: Feed thread update In-Reply-To: References: <44569816.6090708@gmail.com> <68fba5c50605011839g2eef51c7r1157e57d6912fff6@mail.gmail.com> <20060502024448.GK2690@klangraum> <4456E86A.5020702@gmail.com> <20060502134759.GL2690@klangraum> <445771A5.1020101@gmail.com> <4135B840-3FCC-4DB0-A74F-0981EAE45A80@sun.com> <445AB42B.4060507@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Friday, May 5, 2006, 4:05:15 AM, Tim Bray wrote: > Give me a break, we're in the first *days* of something that will be > used for at least decades. Todays' APIs will have a vanishingly- > small lifespan in comparison The issue isn't that an implementation is at fault. The issue is that a implementation is not at fault, is behaving reasonably, and yet still wouldn't be compatible with the extension. As I said 12 months ago : | 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. | [...] | 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. Section 6 was received inadequate review. Perhaps someone can tell me now, why there are three different classes of non-Atom markup? Section 6 came about due to a clash between people who see Atom as an XML document format like XHTML ([1] choice 1), and people who see Atom as a serialisation of feed and entry concepts, that span multiple XML documents ([1] choice 2). Section 6 satisfies neither party. [1] http://www.mnot.net/blog/2004/05/12/on_infosets The distinction between Simple and Structured extensions was a well meaning, but misguided, effort to provide a lower bar for extension support for implementations that would find it unfeasible to preserve the full Infoset and xml:lang/xml:base context. > crippling our expressiveness "...and conservative in what you send". That is the point here. What percent of stateful feed stores do you think support all of Atom's core elements? How many handle xml:lang and xml:base correctly for core elements? - less? How many handle simple extensions? - less? How many handle structured extensions, including ones that require that the xml:base and xml:lang context is preserved? - less? How many handle arbitrary attributes on any Atom element, and arbitrary XML in atom:link? - less? How many preserve the order of elements for any future extensions that choose to make order significant? - less? How many cope with extensions that follow our example of "inheritance", and maintain feed extensions as they were at the time of the document that the entry was last delivered with for the benefit of "inheritable" feed extensions, whilst also maintaining an association with the latest feed metadata for the benefit of "true" feed extensions? - less? How many preserve the namespace mappings for any future extensions that choose to use QNames in content? - less? How many preserve PIs and comments for any future extensions that make use of them? - less? Atom doesn't define any conformance levels for the preservation of content and extensions, so extension designers are forced to consider the consequences themselves. If you're happy working with XML APIs over a set of polled feed documents (together with their preserved URIs, Content-Locations, entity headers and retrieval dates), then none of this matters. If you see a benefit of providing a higher level abstraction over feeds and entries, an OO API, an RDBMS schema, an APP implementation, or any value-added feed processing service, then it is worth considering the practicalities of such support and employing a bit of conservatism. -- Dave From owner-atom-syntax@mail.imc.org Fri May 05 08:59:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzu9-0008CD-GC for atompub-archive@lists.ietf.org; Fri, 05 May 2006 08:59:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbzu9-000335-4W for atompub-archive@lists.ietf.org; Fri, 05 May 2006 08:59:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45CfQv1057192; Fri, 5 May 2006 05:41:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45CfPup057191; Fri, 5 May 2006 05:41:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45CfO5o057185 for ; Fri, 5 May 2006 05:41:25 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so773483pya for ; Fri, 05 May 2006 05:41:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YjgROHJwKewvZdd/wld30Lds4trqg8DSd14HeEp4qma3fL2B1jAF6Y2OIh8rGVP4cmaTGcEiRi70WCFyyrFg1rMGzB1rL1yeQCGsVatZ6aW9xB93AVHTV3XsdIotqSTHgvhnQCYAgvTny7H9I+mlwshJDNSsxjjAXgKy8vjXhTc= Received: by 10.35.91.15 with SMTP id t15mr353372pyl; Fri, 05 May 2006 05:41:24 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Fri, 5 May 2006 05:41:24 -0700 (PDT) Message-ID: <68fba5c50605050541k386a1fa7x7f251979d54c777@mail.gmail.com> Date: Fri, 5 May 2006 08:41:24 -0400 From: "Robert Sayre" To: "Andreas Sewe" Subject: Re: Atom Rank Extensions Cc: "Atom Syntax" In-Reply-To: <445B186B.8010007@rbg.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44569816.6090708@gmail.com> <4457BE72.5050100@gmail.com> <4457DF8A.3070508@gmail.com> <68fba5c50605021628k45ce6c4cocca8f109890eb9a9@mail.gmail.com> <4458789C.1060802@rbg.informatik.tu-darmstadt.de> <68fba5c50605031102r8d0031g6f458db357711b87@mail.gmail.com> <445B186B.8010007@rbg.informatik.tu-darmstadt.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k45CfP5o057186 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On 5/5/06, Andreas Sewe wrote: > > You mean r:rank, right? Well, the purpose of r:scheme (and its child > elements) is to describe the ordered set from which r:rank's values a > picked. Think of it as a datatype definition geared specifically at > describing those sets of numbers commonly encountered in grading schemes. Why don't you call it that in the draft? > > This conflicts with the atom:author field. Why not @id, @domain, etc. > > Well, I am not sure what you mean here, but as for @domain you have to > realize that a single scheme can be used to rank entries within more > than one Ranking Domain (e.g.., within several feeds). > > Changing @name to @id might cause confusion, since attributes called > "id" commonly contain NCNames, not IRIs. I suggest to James using an > r:id child element of r:scheme, instead, to mimic atom:id, but somehow > he doesn't like the idea. But maybe you can come up with a better name > for @name (no pun intended). Ranking Domain. I'm still not sure what that means. > >> An Atom feed element MAY contain any number of r:scheme elements. > >> A feed MUST NOT contain more than one r:scheme element with the > >> same name. > > > > Well, you have all of these child elements that can change the effect > > of the element, so why would you want to ban this behavior? > > I don't understand the above. :-( Can you please clarify your objection. > Thanks. I don't see the interoperation problem the MUST NOT is preventing. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Fri May 05 09:24:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0Hq-00024l-Ab for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:24:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0Ho-0003oP-WF for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:24:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DBQAQ059097; Fri, 5 May 2006 06:11:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45DBQsW059096; Fri, 5 May 2006 06:11:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DBP3J059090 for ; Fri, 5 May 2006 06:11:26 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so780311pya for ; Fri, 05 May 2006 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:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TpCLMW9cDmmKZdXcE87gCT+6iFUy/6mPZQzgwVKSOktrwo+CGIEz1orsN1QkCisSazclmOfGteqdnFWBbfk7sM/4tkoywu6dzvA/CZuIgbLgE2b+3jldxvb6wN9N++AXUBxl2i+eG3MFGgkld1sQPGdEYfwgMKBcs9mKif0KGY8= Received: by 10.35.53.18 with SMTP id f18mr667957pyk; Fri, 05 May 2006 06:11:25 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Fri, 5 May 2006 06:11:25 -0700 (PDT) Message-ID: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> Date: Fri, 5 May 2006 09:11:25 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: What Atom software are you working on? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k45DBQ3J059091 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad I've been working to add Atom support to Firefox 2. Some other Firefox devs are toying with exposing internal data like history and bookmarks as Atom feeds. What software are you writing? -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Fri May 05 09:28:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0Mb-0003TX-Sx for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:28:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0Mb-00045o-GM for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:28:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DFego059220; Fri, 5 May 2006 06:15:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45DFeY4059219; Fri, 5 May 2006 06:15:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DFZ5Q059210 for ; Fri, 5 May 2006 06:15:39 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060505131530.TOVD29343.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Fri, 5 May 2006 14:15:30 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060505131529.TUME16086.aamtaout04-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Fri, 5 May 2006 14:15:29 +0100 Date: Fri, 5 May 2006 14:15:15 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <805263360.20060505141515@djpowell.net> To: "A. Pagaltzis" CC: atom-syntax Subject: Re: Feed thread -09 In-Reply-To: <20060504232025.GB2690@klangraum> References: <44579A33.3030404@gmail.com> <20060502185655.GW2690@klangraum> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> <20060504171907.GU2690@klangraum> <20060504232025.GB2690@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k45DFd5Q059213 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k45DFego059220 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Friday, May 5, 2006, 12:20:25 AM, A. Pagaltzis wrote: > * M. David Peterson [2006-05-04 23:30]: >> Or is something like this simply inviting WAY TOO MANY little >> things to find justification to plug up the collective inbox of >> the community members? > I don=E2=80=99t know. So far during extension development discussions, > only the missing extensibility for links has stuck out as a real > sore point in RFC 4287. Other than that, the spec has stood up > very well with only a few minor errata reported here and there. > At least, that=E2=80=99s my impression; I don=E2=80=99t know what other= s think, > of course. > Frankly, I would hope there won=E2=80=99t be much interest =E2=80=93 ca= use if > there is, what else would that mean than that we did a shoddy > job? :-) The RFC does a good job of saying what is and isn't a valid Atom document. What is out of scope of the RFC though, is the behaviour of processors that provide access to, store, or act as intermediaries for Atom streams, wrt what elements and extensions are retained. Not that all processors should behave the same, or that processors that retain the most information are necessarily "the best" (ones that retain less information are probably likely to offer more usable interfaces), just that extension authors need to be mindful of typical behaviours of processors, and vice versa. As the processing behaviour is not defined (not even in APP), application of the robustness principle is particularly relevant. I started on a document describing some checklists for the preservation of data required to meet several arbitrary conformance levels - intended more as considerations for extension authors, than for processor implementations. --=20 Dave From owner-atom-syntax@mail.imc.org Fri May 05 09:36:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0Tj-0006vS-7Z for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:36:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0Th-0004NK-NF for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:36:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DNCMN059630; Fri, 5 May 2006 06:23:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45DNCb5059629; Fri, 5 May 2006 06:23:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DNBVu059623 for ; Fri, 5 May 2006 06:23:11 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so677977nzf for ; Fri, 05 May 2006 06:23:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=V4+cShWhuKnoUfzGzeSvfiUIVtAZgbUuKqc9ScNSdrnr90xfpl0o/KN+0INGvEd5TWgUZT0UrOFjzO6C8yOXeXyrgDEPfbvOegNDT9nTyaNKEf2p1FtHU+awCgDSVPgciRzb/eNC56VGe37AEfXGzvXQru6SGXG8144mzTMtUDw= Received: by 10.65.186.4 with SMTP id n4mr498000qbp; Fri, 05 May 2006 06:23:10 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Fri, 5 May 2006 06:23:10 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 07:23:10 -0600 From: "M. David Peterson" To: atom-syntax Subject: Re: Feed thread -09 In-Reply-To: <20060504232025.GB2690@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12107_18659607.1146835390898" References: <44579A33.3030404@gmail.com> <4457BD48.9070602@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> <20060504171907.GU2690@klangraum> <20060504232025.GB2690@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a ------=_Part_12107_18659607.1146835390898 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SG1tbS4uLiB5ZWFoLCB0aGF0cyBhIGdvb2QgcG9pbnQuICBUaGUgb3B0aW1pemF0aW9ucyBwYXJ0 IHdvdWxkbid0IHJlcHJlc2VudAp0aGlzIChlLmcuIHRocjpjb3VudCAtLSBhbHRob3VnaCB0aGlz IGRvZXNuJ3QgcmVmbGVjdCBvbiB0aGUgQXRvbSBzcGVjKSBidXQKYmV5b25kIHRoYXQgdGhlcmUg d291bGRuJ3QgYmUgbXVjaCBwb2ludC4gIFlvdSBmb2xrcyBIQVZFIGRvbmUgYSBpbmNyZWRpYmx5 CmNvbXBsZXRlIGpvYiB3aXRoIHRoZSBzcGVjLCBzbyBpZiB0aGVyZSB3YXMgaW50ZXJlc3QgaXQg d291bGQgb25seSBiZQphcnRpZmljaWFsLgoKSXMgYW4gb3B0aW1pemF0aW9ucyByZXNlYXJjaCBh cmVhIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlIGRvYWJsZSBiZXlvbmQgdGhlCm5vdGlvbiBvZiBm aXhpbmcgb3IgYWRkaW5nIHdoYXRzIG5vdCBhbHJlYWR5IHRoZXJlLCBhbmQgaW5zdGVhZCBmb2N1 c2VkIG9uCnRoaW5ncyBsaWtlIHRocjpjb3VudCB3aGVyZSBpdHMgbmljZSB0byBoYXZlLCBidXQg bm90IG1hbmRhdG9yeSwgeWV0IGEKY29uc29saWRhdGVkIGVmZm9ydCB3b3VsZCBtYWtlIHNlbnNl PwoKCk9uIDUvNC8wNiwgQS4gUGFnYWx0emlzIDxwYWdhbHR6aXNAZ214LmRlPiB3cm90ZToKPgo+ Cj4gKiBNLiBEYXZpZCBQZXRlcnNvbiA8eG1saGFja2VyQGdtYWlsLmNvbT4gWzIwMDYtMDUtMDQg MjM6MzBdOgo+ID4gT3IgaXMgc29tZXRoaW5nIGxpa2UgdGhpcyBzaW1wbHkgaW52aXRpbmcgV0FZ IFRPTyBNQU5ZIGxpdHRsZQo+ID4gdGhpbmdzIHRvIGZpbmQganVzdGlmaWNhdGlvbiB0byBwbHVn IHVwIHRoZSBjb2xsZWN0aXZlIGluYm94IG9mCj4gPiB0aGUgY29tbXVuaXR5IG1lbWJlcnM/Cj4K PiBJIGRvbid0IGtub3cuIFNvIGZhciBkdXJpbmcgZXh0ZW5zaW9uIGRldmVsb3BtZW50IGRpc2N1 c3Npb25zLAo+IG9ubHkgdGhlIG1pc3NpbmcgZXh0ZW5zaWJpbGl0eSBmb3IgbGlua3MgaGFzIHN0 dWNrIG91dCBhcyBhIHJlYWwKPiBzb3JlIHBvaW50IGluIFJGQyA0Mjg3LiBPdGhlciB0aGFuIHRo YXQsIHRoZSBzcGVjIGhhcyBzdG9vZCB1cAo+IHZlcnkgd2VsbCB3aXRoIG9ubHkgYSBmZXcgbWlu b3IgZXJyYXRhIHJlcG9ydGVkIGhlcmUgYW5kIHRoZXJlLgo+Cj4gQXQgbGVhc3QsIHRoYXQncyBt eSBpbXByZXNzaW9uOyBJIGRvbid0IGtub3cgd2hhdCBvdGhlcnMgdGhpbmssCj4gb2YgY291cnNl Lgo+Cj4gRnJhbmtseSwgSSB3b3VsZCBob3BlIHRoZXJlIHdvbid0IGJlIG11Y2ggaW50ZXJlc3Qg 4oCTIGNhdXNlIGlmCj4gdGhlcmUgaXMsIHdoYXQgZWxzZSB3b3VsZCB0aGF0IG1lYW4gdGhhbiB0 aGF0IHdlIGRpZCBhIHNob2RkeQo+IGpvYj8gOi0pCj4KPiBSZWdhcmRzLAo+IC0tCj4gQXJpc3Rv dGxlIFBhZ2FsdHppcyAvLyA8aHR0cDovL3BsYXNtYXN0dXJtLm9yZy8+Cj4KPgoKCi0tCjxNOkQv PgoKTS4gRGF2aWQgUGV0ZXJzb24KaHR0cDovL3d3dy54c2x0YmxvZy5jb20vCg== ------=_Part_12107_18659607.1146835390898 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IbW1tLi4uIHllYWgsIHRoYXRzIGEgZ29vZCBwb2ludC4mbmJzcDsgVGhlIG9wdGltaXph dGlvbnMgcGFydCB3b3VsZG4ndCByZXByZXNlbnQgdGhpcyAoZS5nLiB0aHI6Y291bnQgLS0gYWx0 aG91Z2ggdGhpcyBkb2Vzbid0IHJlZmxlY3Qgb24gdGhlIEF0b20gc3BlYykgYnV0IGJleW9uZCB0 aGF0Jm5ic3A7dGhlcmUgd291bGRuJ3QgYmUgbXVjaCBwb2ludC4mbmJzcDsgWW91IGZvbGtzIEhB VkUgZG9uZSBhIGluY3JlZGlibHkgY29tcGxldGUgam9iIHdpdGggdGhlIHNwZWMsIHNvIGlmIHRo ZXJlIHdhcyBpbnRlcmVzdCBpdCB3b3VsZCBvbmx5IGJlIGFydGlmaWNpYWwuCjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PklzIGFuIG9wdGltaXphdGlvbnMgcmVzZWFyY2ggYXJlYSBzb21l dGhpbmcgdGhhdCBtaWdodCBiZSBkb2FibGUgYmV5b25kIHRoZSBub3Rpb24gb2YgZml4aW5nIG9y IGFkZGluZyB3aGF0cyBub3QgYWxyZWFkeSB0aGVyZSwgYW5kIGluc3RlYWQgZm9jdXNlZCBvbiB0 aGluZ3MgbGlrZSB0aHI6Y291bnQgd2hlcmUgaXRzIG5pY2UgdG8gaGF2ZSwgYnV0IG5vdCBtYW5k YXRvcnksIHlldCBhIGNvbnNvbGlkYXRlZCBlZmZvcnQgd291bGQgbWFrZSBzZW5zZT8KPGJyPjxi cj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDUvNC8wNiwg PGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkEuIFBhZ2FsdHppczwvYj4gJmx0OzxhIGhyZWY9 Im1haWx0bzpwYWdhbHR6aXNAZ214LmRlIj5wYWdhbHR6aXNAZ214LmRlPC9hPiZndDsgd3JvdGU6 PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxF RlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4 IHNvbGlkIj48YnI+KiBNLiBEYXZpZCBQZXRlcnNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnhtbGhh Y2tlckBnbWFpbC5jb20iPnhtbGhhY2tlckBnbWFpbC5jb208L2E+Jmd0OyBbMjAwNi0wNS0wNCAy MzozMF06Cjxicj4mZ3Q7IE9yIGlzIHNvbWV0aGluZyBsaWtlIHRoaXMgc2ltcGx5IGludml0aW5n IFdBWSBUT08gTUFOWSBsaXR0bGU8YnI+Jmd0OyB0aGluZ3MgdG8gZmluZCBqdXN0aWZpY2F0aW9u IHRvIHBsdWcgdXAgdGhlIGNvbGxlY3RpdmUgaW5ib3ggb2Y8YnI+Jmd0OyB0aGUgY29tbXVuaXR5 IG1lbWJlcnM/PGJyPjxicj5JIGRvbid0IGtub3cuIFNvIGZhciBkdXJpbmcgZXh0ZW5zaW9uIGRl dmVsb3BtZW50IGRpc2N1c3Npb25zLAo8YnI+b25seSB0aGUgbWlzc2luZyBleHRlbnNpYmlsaXR5 IGZvciBsaW5rcyBoYXMgc3R1Y2sgb3V0IGFzIGEgcmVhbDxicj5zb3JlIHBvaW50IGluIFJGQyA0 Mjg3LiBPdGhlciB0aGFuIHRoYXQsIHRoZSBzcGVjIGhhcyBzdG9vZCB1cDxicj52ZXJ5IHdlbGwg d2l0aCBvbmx5IGEgZmV3IG1pbm9yIGVycmF0YSByZXBvcnRlZCBoZXJlIGFuZCB0aGVyZS48YnI+ PGJyPkF0IGxlYXN0LCB0aGF0J3MgbXkgaW1wcmVzc2lvbjsgSSBkb24ndCBrbm93IHdoYXQgb3Ro ZXJzIHRoaW5rLAo8YnI+b2YgY291cnNlLjxicj48YnI+RnJhbmtseSwgSSB3b3VsZCBob3BlIHRo ZXJlIHdvbid0IGJlIG11Y2ggaW50ZXJlc3Qg4oCTIGNhdXNlIGlmPGJyPnRoZXJlIGlzLCB3aGF0 IGVsc2Ugd291bGQgdGhhdCBtZWFuIHRoYW4gdGhhdCB3ZSBkaWQgYSBzaG9kZHk8YnI+am9iPyA6 LSk8YnI+PGJyPlJlZ2FyZHMsPGJyPi0tPGJyPkFyaXN0b3RsZSBQYWdhbHR6aXMgLy8gJmx0Ozxh IGhyZWY9Imh0dHA6Ly9wbGFzbWFzdHVybS5vcmcvIj4KaHR0cDovL3BsYXNtYXN0dXJtLm9yZy88 L2E+Jmd0Ozxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJy Pi0tIDxicj4mbHQ7TTpELyZndDs8YnI+PGJyPk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9 Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPiAK ------=_Part_12107_18659607.1146835390898-- From owner-atom-syntax@mail.imc.org Fri May 05 10:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Bd-0002UA-E6 for atompub-archive@lists.ietf.org; Fri, 05 May 2006 10:21:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0yC-0005Xs-IA for atompub-archive@lists.ietf.org; Fri, 05 May 2006 10:07:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc0XG-0003RG-0T for atompub-archive@lists.ietf.org; Fri, 05 May 2006 09:39:59 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DPGWO059690; Fri, 5 May 2006 06:25:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45DPG0Y059689; Fri, 5 May 2006 06:25:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45DPErb059683 for ; Fri, 5 May 2006 06:25:15 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so678395nzf for ; Fri, 05 May 2006 06:25:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=HT+RICiMcPb74kBqTVA3BiwCeHOwf6XmRlUjYTc2GyA9DaXazm/bYUk4D9OU7mFHolMratLL+sw+F/RoHtikfDoRTqk0kDfw3+jmWiFZs0hCiRsPeu37dOt/+U6vvYpSU5Bg7ia7QzsMKu2Yk144dbzApacEHifRu/dVJC/aXFY= Received: by 10.64.233.12 with SMTP id f12mr186404qbh; Fri, 05 May 2006 06:25:14 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Fri, 5 May 2006 06:25:14 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 07:25:14 -0600 From: "M. David Peterson" To: "David Powell" Subject: Re: Feed thread -09 Cc: "A. Pagaltzis" , atom-syntax In-Reply-To: <805263360.20060505141515@djpowell.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12139_1992047.1146835514348" References: <44579A33.3030404@gmail.com> <1991509855.20060503000532@djpowell.net> <20060502234546.GF2690@klangraum> <44580802.7080500@gmail.com> <20060504125754.GR2690@klangraum> <445A222F.3050805@gmail.com> <20060504171907.GU2690@klangraum> <20060504232025.GB2690@klangraum> <805263360.20060505141515@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 ------=_Part_12139_1992047.1146835514348 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline U28ga2luZCBvZiBsaWtlIGEgYmVzdCBwcmFjdGljZSBkb2M/CgpPbiA1LzUvMDYsIERhdmlkIFBv d2VsbCA8ZGpwb3dlbGxAZGpwb3dlbGwubmV0PiB3cm90ZToKPgo+Cj4KPiBGcmlkYXksIE1heSA1 LCAyMDA2LCAxMjoyMDoyNSBBTSwgQS4gUGFnYWx0emlzIHdyb3RlOgo+Cj4gPiAqIE0uIERhdmlk IFBldGVyc29uIDx4bWxoYWNrZXJAZ21haWwuY29tPiBbMjAwNi0wNS0wNCAyMzozMF06Cj4gPj4g T3IgaXMgc29tZXRoaW5nIGxpa2UgdGhpcyBzaW1wbHkgaW52aXRpbmcgV0FZIFRPTyBNQU5ZIGxp dHRsZQo+ID4+IHRoaW5ncyB0byBmaW5kIGp1c3RpZmljYXRpb24gdG8gcGx1ZyB1cCB0aGUgY29s bGVjdGl2ZSBpbmJveCBvZgo+ID4+IHRoZSBjb21tdW5pdHkgbWVtYmVycz8KPgo+ID4gSSBkb24n dCBrbm93LiBTbyBmYXIgZHVyaW5nIGV4dGVuc2lvbiBkZXZlbG9wbWVudCBkaXNjdXNzaW9ucywK PiA+IG9ubHkgdGhlIG1pc3NpbmcgZXh0ZW5zaWJpbGl0eSBmb3IgbGlua3MgaGFzIHN0dWNrIG91 dCBhcyBhIHJlYWwKPiA+IHNvcmUgcG9pbnQgaW4gUkZDIDQyODcuIE90aGVyIHRoYW4gdGhhdCwg dGhlIHNwZWMgaGFzIHN0b29kIHVwCj4gPiB2ZXJ5IHdlbGwgd2l0aCBvbmx5IGEgZmV3IG1pbm9y IGVycmF0YSByZXBvcnRlZCBoZXJlIGFuZCB0aGVyZS4KPgo+ID4gQXQgbGVhc3QsIHRoYXQncyBt eSBpbXByZXNzaW9uOyBJIGRvbid0IGtub3cgd2hhdCBvdGhlcnMgdGhpbmssCj4gPiBvZiBjb3Vy c2UuCj4KPiA+IEZyYW5rbHksIEkgd291bGQgaG9wZSB0aGVyZSB3b24ndCBiZSBtdWNoIGludGVy ZXN0IOKAkyBjYXVzZSBpZgo+ID4gdGhlcmUgaXMsIHdoYXQgZWxzZSB3b3VsZCB0aGF0IG1lYW4g dGhhbiB0aGF0IHdlIGRpZCBhIHNob2RkeQo+ID4gam9iPyA6LSkKPgo+IFRoZSBSRkMgZG9lcyBh IGdvb2Qgam9iIG9mIHNheWluZyB3aGF0IGlzIGFuZCBpc24ndCBhIHZhbGlkIEF0b20KPiBkb2N1 bWVudC4gV2hhdCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIFJGQyB0aG91Z2gsIGlzIHRoZSBiZWhh dmlvdXIgb2YKPiBwcm9jZXNzb3JzIHRoYXQgcHJvdmlkZSBhY2Nlc3MgdG8sIHN0b3JlLCBvciBh Y3QgYXMgaW50ZXJtZWRpYXJpZXMgZm9yCj4gQXRvbSBzdHJlYW1zLCB3cnQgd2hhdCBlbGVtZW50 cyBhbmQgZXh0ZW5zaW9ucyBhcmUgcmV0YWluZWQuCj4KPiBOb3QgdGhhdCBhbGwgcHJvY2Vzc29y cyBzaG91bGQgYmVoYXZlIHRoZSBzYW1lLCBvciB0aGF0IHByb2Nlc3NvcnMKPiB0aGF0IHJldGFp biB0aGUgbW9zdCBpbmZvcm1hdGlvbiBhcmUgbmVjZXNzYXJpbHkgInRoZSBiZXN0IiAob25lcyB0 aGF0Cj4gcmV0YWluIGxlc3MgaW5mb3JtYXRpb24gYXJlIHByb2JhYmx5IGxpa2VseSB0byBvZmZl ciBtb3JlIHVzYWJsZQo+IGludGVyZmFjZXMpLCBqdXN0IHRoYXQgZXh0ZW5zaW9uIGF1dGhvcnMg bmVlZCB0byBiZSBtaW5kZnVsIG9mIHR5cGljYWwKPiBiZWhhdmlvdXJzIG9mIHByb2Nlc3NvcnMs IGFuZCB2aWNlIHZlcnNhLiBBcyB0aGUgcHJvY2Vzc2luZyBiZWhhdmlvdXIKPiBpcyBub3QgZGVm aW5lZCAobm90IGV2ZW4gaW4gQVBQKSwgYXBwbGljYXRpb24gb2YgdGhlIHJvYnVzdG5lc3MKPiBw cmluY2lwbGUgaXMgcGFydGljdWxhcmx5IHJlbGV2YW50Lgo+Cj4gSSBzdGFydGVkIG9uIGEgZG9j dW1lbnQgZGVzY3JpYmluZyBzb21lIGNoZWNrbGlzdHMgZm9yIHRoZQo+IHByZXNlcnZhdGlvbiBv ZiBkYXRhIHJlcXVpcmVkIHRvIG1lZXQgc2V2ZXJhbCBhcmJpdHJhcnkgY29uZm9ybWFuY2UKPiBs ZXZlbHMgLSBpbnRlbmRlZCBtb3JlIGFzIGNvbnNpZGVyYXRpb25zIGZvciBleHRlbnNpb24gYXV0 aG9ycywgdGhhbgo+IGZvciBwcm9jZXNzb3IgaW1wbGVtZW50YXRpb25zLgo+Cj4gLS0KPiBEYXZl Cj4KPgo+CgoKLS0KPE06RC8+CgpNLiBEYXZpZCBQZXRlcnNvbgpodHRwOi8vd3d3LnhzbHRibG9n LmNvbS8K ------=_Part_12139_1992047.1146835514348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U28ga2luZCBvZiBsaWtlIGEgYmVzdCBwcmFjdGljZSBkb2M/PGJyPjxicj4KPGRpdj48c3BhbiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIDUvNS8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUi PkRhdmlkIFBvd2VsbDwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpkanBvd2VsbEBkanBvd2VsbC5u ZXQiPmRqcG93ZWxsQGRqcG93ZWxsLm5ldDwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj4KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjog MHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+PGJyPjxicj5G cmlkYXksIE1heSA1LCAyMDA2LCAxMjoyMDoyNSBBTSwgQS4gUGFnYWx0emlzIHdyb3RlOjxicj48 YnI+Jmd0OyAqIE0uIERhdmlkIFBldGVyc29uICZsdDs8YSBocmVmPSJtYWlsdG86eG1saGFja2Vy QGdtYWlsLmNvbSI+CnhtbGhhY2tlckBnbWFpbC5jb208L2E+Jmd0OyBbMjAwNi0wNS0wNCAyMzoz MF06PGJyPiZndDsmZ3Q7IE9yIGlzIHNvbWV0aGluZyBsaWtlIHRoaXMgc2ltcGx5IGludml0aW5n IFdBWSBUT08gTUFOWSBsaXR0bGU8YnI+Jmd0OyZndDsgdGhpbmdzIHRvIGZpbmQganVzdGlmaWNh dGlvbiB0byBwbHVnIHVwIHRoZSBjb2xsZWN0aXZlIGluYm94IG9mPGJyPiZndDsmZ3Q7IHRoZSBj b21tdW5pdHkgbWVtYmVycz8KPGJyPjxicj4mZ3Q7IEkgZG9uJ3Qga25vdy4gU28gZmFyIGR1cmlu ZyBleHRlbnNpb24gZGV2ZWxvcG1lbnQgZGlzY3Vzc2lvbnMsPGJyPiZndDsgb25seSB0aGUgbWlz c2luZyBleHRlbnNpYmlsaXR5IGZvciBsaW5rcyBoYXMgc3R1Y2sgb3V0IGFzIGEgcmVhbDxicj4m Z3Q7IHNvcmUgcG9pbnQgaW4gUkZDIDQyODcuIE90aGVyIHRoYW4gdGhhdCwgdGhlIHNwZWMgaGFz IHN0b29kIHVwPGJyPgomZ3Q7IHZlcnkgd2VsbCB3aXRoIG9ubHkgYSBmZXcgbWlub3IgZXJyYXRh IHJlcG9ydGVkIGhlcmUgYW5kIHRoZXJlLjxicj48YnI+Jmd0OyBBdCBsZWFzdCwgdGhhdCdzIG15 IGltcHJlc3Npb247IEkgZG9uJ3Qga25vdyB3aGF0IG90aGVycyB0aGluayw8YnI+Jmd0OyBvZiBj b3Vyc2UuPGJyPjxicj4mZ3Q7IEZyYW5rbHksIEkgd291bGQgaG9wZSB0aGVyZSB3b24ndCBiZSBt dWNoIGludGVyZXN0IOKAkyBjYXVzZSBpZgo8YnI+Jmd0OyB0aGVyZSBpcywgd2hhdCBlbHNlIHdv dWxkIHRoYXQgbWVhbiB0aGFuIHRoYXQgd2UgZGlkIGEgc2hvZGR5PGJyPiZndDsgam9iPyA6LSk8 YnI+PGJyPlRoZSBSRkMgZG9lcyBhIGdvb2Qgam9iIG9mIHNheWluZyB3aGF0IGlzIGFuZCBpc24n dCBhIHZhbGlkIEF0b208YnI+ZG9jdW1lbnQuIFdoYXQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoZSBS RkMgdGhvdWdoLCBpcyB0aGUgYmVoYXZpb3VyIG9mCjxicj5wcm9jZXNzb3JzIHRoYXQgcHJvdmlk ZSBhY2Nlc3MgdG8sIHN0b3JlLCBvciBhY3QgYXMgaW50ZXJtZWRpYXJpZXMgZm9yPGJyPkF0b20g c3RyZWFtcywgd3J0IHdoYXQgZWxlbWVudHMgYW5kIGV4dGVuc2lvbnMgYXJlIHJldGFpbmVkLjxi cj48YnI+Tm90IHRoYXQgYWxsIHByb2Nlc3NvcnMgc2hvdWxkIGJlaGF2ZSB0aGUgc2FtZSwgb3Ig dGhhdCBwcm9jZXNzb3JzPGJyPnRoYXQgcmV0YWluIHRoZSBtb3N0IGluZm9ybWF0aW9uIGFyZSBu ZWNlc3NhcmlseSAmcXVvdDt0aGUgYmVzdCZxdW90OyAob25lcyB0aGF0Cjxicj5yZXRhaW4gbGVz cyBpbmZvcm1hdGlvbiBhcmUgcHJvYmFibHkgbGlrZWx5IHRvIG9mZmVyIG1vcmUgdXNhYmxlPGJy PmludGVyZmFjZXMpLCBqdXN0IHRoYXQgZXh0ZW5zaW9uIGF1dGhvcnMgbmVlZCB0byBiZSBtaW5k ZnVsIG9mIHR5cGljYWw8YnI+YmVoYXZpb3VycyBvZiBwcm9jZXNzb3JzLCBhbmQgdmljZSB2ZXJz YS4gQXMgdGhlIHByb2Nlc3NpbmcgYmVoYXZpb3VyPGJyPmlzIG5vdCBkZWZpbmVkIChub3QgZXZl biBpbiBBUFApLCBhcHBsaWNhdGlvbiBvZiB0aGUgcm9idXN0bmVzcwo8YnI+cHJpbmNpcGxlIGlz IHBhcnRpY3VsYXJseSByZWxldmFudC48YnI+PGJyPkkgc3RhcnRlZCBvbiBhIGRvY3VtZW50IGRl c2NyaWJpbmcgc29tZSBjaGVja2xpc3RzIGZvciB0aGU8YnI+cHJlc2VydmF0aW9uIG9mIGRhdGEg cmVxdWlyZWQgdG8gbWVldCBzZXZlcmFsIGFyYml0cmFyeSBjb25mb3JtYW5jZTxicj5sZXZlbHMg LSBpbnRlbmRlZCBtb3JlIGFzIGNvbnNpZGVyYXRpb25zIGZvciBleHRlbnNpb24gYXV0aG9ycywg dGhhbgo8YnI+Zm9yIHByb2Nlc3NvciBpbXBsZW1lbnRhdGlvbnMuPGJyPjxicj4tLTxicj5EYXZl PGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0t IDxicj4mbHQ7TTpELyZndDs8YnI+PGJyPk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9Imh0 dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPiAK ------=_Part_12139_1992047.1146835514348-- From owner-atom-syntax@mail.imc.org Fri May 05 10:23:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Dk-0003ju-BV for atompub-archive@lists.ietf.org; Fri, 05 May 2006 10:23:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1Di-000629-MR for atompub-archive@lists.ietf.org; Fri, 05 May 2006 10:23:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45E3wCd061060; Fri, 5 May 2006 07:03:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45E3wSH061059; Fri, 5 May 2006 07:03:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45E3vbO061053 for ; Fri, 5 May 2006 07:03:57 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so686568nzf for ; Fri, 05 May 2006 07:03:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=OPNDJT9cRdSgZiJloYKhmorlgPOtAHwcdJimJZzmmMLGXaT9BDIaBkkQTlY8DjQC1Qf/knzQoqL0Os1PneQgwgdG/d9/LOhH065x4fWy+83rPgQP0o29mDcwyiG9p2hKlb80Hl6L8joi4GiSYNevGf64CUSuN0RYajgJaEdQZRU= Received: by 10.65.242.2 with SMTP id u2mr543870qbr; Fri, 05 May 2006 07:03:56 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Fri, 5 May 2006 07:03:55 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 08:03:56 -0600 From: "M. David Peterson" To: "Robert Sayre" Subject: Re: What Atom software are you working on? Cc: "Atom Syntax" In-Reply-To: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12913_9340404.1146837836126" References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f ------=_Part_12913_9340404.1146837836126 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSd2ZSBnb3Qgc2V2ZXJhbC4KCkdsb2JhbENsaXAgKHRyYWM6aHR0cDovL2Rldi5leHRlbnNpYmxl Zm9yZ2UubmV0L3dpa2kvR2xvYmFsQ2xpcCBzdm46CnN2bjovL3NyYy5leHRlbnNpYmxlZm9yZ2Uu bmV0L3RydW5rL0dsb2JhbENsaXApCgpBbiBpbXBsZW1lbnRhdGlvbiBvZiBNUydzIExpdmVDbGlw Ym9hcmQgdGhhdCAoZm9yIHRoZSBtb21lbnQpIHVzZXMgUzMgYXMgYQp3YXkgb2Ygc3RvcmluZyBh bmQgYWNjZXNzaW5nIGNvbnRlbnQgdGhhdCBzb21lb25lIHdhbnRzIHRvIGVpdGhlciBhbGxvdwpw dWJsaWMgYWNjZXNzLCBzaGFyZWQgYnV0IGNvbnRyb2xsZWQgYWNjZXNzLCBvciBwcml2YXRlIGFj Y2VzcyAobXVsdGlwbGUKbWFjaGluZXMpIHRvIHRoaXMgY29udGVudC4KCkknbSB3b3JraW5nIG9u IHRpZWluZyB0aGlzIGludG8gYSBkZW1vIHdoaWNoIHlvdSBjYW4gYWNjZXNzIHZpYQpodHRwOi8v ZXh0Zi5uZXQvc2F4b24vZG90bmV0L2FzcC5uZXQvbGl2ZWNsaXBib2FyZC8KClRoZSBVSSBmb3Ig dGhlIGRlbW8gaXMgZmluaXNoZWQgKGZpbmlzaGVkIHRoYXQgeWVzdGVyZGF5KSwgdGhlIGJhY2tl bmQgaXMKd29ya2luZyAoZmluaXNoZWQgdGhlIGRheSBiZWZvcmUpLCBhbHRob3VnaCB0aGVyZSBp cyBhIGxvdCBvZiBzcGl0IGFuZApwb2xpc2ggd29yayB0aGF0IG5lZWRzIHRvIGJlIGRvbmUsIGFu ZCBzb21lIGFyZWFzIHRoYXQgSSB3YW50IHRvIGV4dGVuZAppbnRvLiAgTm9uZS10aGUtbGVzcywg aXQgd2lsbCB3b3JrIGZyb20gdGhlIHN0YW5kcG9pbnQgb2YgdXNpbmcKTGl2ZUNsaXBib2FyZCBh cyB0aGUgYnJvd3Nlci1iYXNlZCBlbmdpbmUgdG8gdGhlIHRha2UgdGhlIGNvbnRlbnQgZnJvbSB0 aGUKaW5zdGFuY2Ugb2YgbGl2ZWNsaXAsIHB1dCBpdCB0byBTMywgYW5kIHRoZW4gbWFrZSBhdmFp bGFibGUgYW4gYXRvbSBmZWVkIG9mCnRoZSBjb250ZW50cyBvZiB0aGUgY3VycmVudCBjbGlwYm9h cmQgYmFzZWQgb24gY2VydGFpbiBjcml0ZXJpYSAoZS5nLiBzb3J0CmJ5IGRhdGUsIGNvbnRlbnQt dHlwZSwgZXRjLi4uKQoKWW91IGNhbiBhY2Nlc3MgdGhlIEFTUC5ORVQtYmFzZWQgdHJhYyA+Cmh0 dHA6Ly9kZXYuZXh0ZW5zaWJsZWZvcmdlLm5ldC93aWtpL1Jlc2VhcmNoL1NheG9uL2RvdG5ldC9B U1AuTkVUL2xpdmVjbGlwYm9hcmQKPAppbnRlcmZhY2Ugd2hlcmUgeW91IHdpbGwgZmluZCB0aGUg cHJvcGVyIFNWTiBsb2NhdGlvbiBvZiB0aGUgc291cmNlLgoKVGhpcyB3aWxsIGFsbCB0aWUgaW50 byBBdG9taWNYTUwgd2hpY2ggaW4gZXNzZW5jZSB1c2VzICdmZWVkJy1iYXNlZCBBdG9tCmZlZWRz IGFzIHdheSBvZiBjb25maWd1cmluZyBhbiBhcHBsaWNhdGlvbiBhcyB3ZWxsIGFzIHN0b3Jpbmcg YSBjb2xsZWN0aW9uCm9mIGVpdGhlciBvbmUgcmVzb3VyY2UgKGhpc3RvcmljYWwpIG9yIG1hbnkg cmVzb3VyY2VzIChjb2xsZWN0aW9uKSB0aGF0IHRoZW4KcmVmZXJlbmNlcyBtb2R1bGVzIGNvbnRh aW5lZCBpbiBleHRlcm5hbCAnZW50cnknLWJhc2VkIEF0b20gZmlsZXMgd2hpY2gKcmVmZXJlbmNl cyBhIHBhcnRpY3VsYXIgaW5zdGFuY2Ugb2YgYSByZXNvdXJjZS4gIFRoZXNlIHJlc291cmNlcyBj YW4gYmUKYW55dGhpbmcgZnJvbSBleGlzdGluZyBDU1Mgb3IgSmF2YXNjcmlwdCBmaWxlcywgdG8g WE1MIHRoYXQgaXMgdXNlZCB0b2dldGhlcgp3aXRoIHRoZSBBc3BlY3RYTUwgY29kZSBiYXNlIHRv IHdlYXZlIHRvZ2V0aGVyIHByZS1jb25maWd1cmVkIHRlbXBsYXRlcyB3aXRoCmRhdGEgdGhhdCBy ZWxhdGVzIHRvIHRoZSBzcGVjaWZpYyBpbnN0YW5jZSAoZS5nLiBzb21ldGhpbmcgYXMgc2ltcGxl IGFzCndlYXZpbmcgdGhlIGxpbmsgYW5kIG5hbWUgb2YgdGhlIGNyZWF0aXZlIGNvbW1vbnMgbGlj ZW5zZWQgdXNlZCBmb3IgYQpwYXJ0aWN1bGFyIHBhZ2UsIG9yIGFzIGNvbXBsZXggYXMgd2Vhdmlu ZyBpbnRvIGFuIGVudGlyZSBhcHBsaWNhdGlvbiBhbGwgb2YKdGhlIHNwZWNpZmljIHVzZXItc3Bl Y2lmaWVkIHNldHRpbmdzLCBldGMuLi4pCgpUaGUgaWRlYSB3aXRoIGNvbWJpbmluZyB0aGUgR2xv YmFsQ2xpcC1iYXNlZCB3aXRoIHRoZSBBdG9taWNYTUwtYmFzZSBpcyB0bwphbGxvdyBmb2xrcyB0 byBiZSBhYmxlIHRvIHNoYXJlIHRoZSBzb3VyY2UgZm9yIGEgcGFydGljdWxhciBzaXRlLCBwYWdl LCBvcgplbGVtZW50IG9mIHRoYXQgc2l0ZS9wYWdlLCBjb3B5IGl0IHRvIHRoZWlyIGNsaXBib2Fy ZCwgYW5kIHRoZW4gcGFzdGUgaXQKaW50byBlaXRoZXIgYW5vdGhlciBzaXRlIChwcmUtZXhpc3Rp bmcgQXRvbWljWE1MLWJhc2VkIHNpdGUpIG9yIGNyZWF0ZSBhCmJyYW5kIG5ldyBzaXRlIGJhc2Vk IG9uIHRoZSB0ZW1wbGF0ZSBvbiB0aGUgY2xpcGJvYXJkIHdoaWNoIHdvdWxkIHRoZW4KYWNjZXNz IGFsbCBvZiB0aGUgcmVmZXJlbmNlZCByZXNvdXJjZXMsIHdlYXZlIGl0IHRvZ2V0aGVyIHdpdGgg YW55CnByZS1jb25maWd1cmVkIHVzZXIgZGF0YSwgYW5kIG1ha2UgdGhpcyBzaXRlIGF2YWlsYWJs ZSBpbW1lZGlhdGVsbHkgdXBvbgpmaW5pc2hpbmcgdGhlIGJ1aWxkIG91dCBvZiB0aGlzIHBhcnRp Y3VsYXIgaW5zdGFuY2UuCgpJZiB5b3UgdmlzaXQgdGhlIGFib3ZlIGxpbmtlZCBkZW1vIGludGVy ZmFjZSBpdCBzaG91bGQgYmUgYSBiaXQgbW9yZSBjbGVhcgphcyB0byB3aGF0IHRoZSBjb250ZW50 IG9mIHRoYXQgZGVtbyB3aWxsIGV2ZW50dWFsbHkgbWFrZSBhdmFpbGFibGUgdG8KdmlzaXRvcnMu CgpJIHdvbid0IGdldCBhcyBmYXIgYXMgYSBmdWxsIGltcGxlbWVudGF0aW9uIG9mIHRoZSBhYm92 ZSBkZXNjcmlwdGlvbiB0b2RheSwKYnV0IEkgd2lsbCBoYXZlIGl0IHRvIHRoZSBwb2ludCBvZiBj b3B5aW5nIGNsaXBib2FyZCBkYXRhLCBwYXN0aW5nIGl0IHRvIHRoZQpHbG9iYWxDbGlwIGluc3Rh bmNlIChjdXJyZW50bHkgUzMsIGV2ZW50dWFsbHksIGFueSBzdG9yYWdlIG1lZGl1bSAoZS5nLgpH RHJpdmUsIExpdmVEcml2ZSwgQW55T3RoZXJEcml2ZSBpbmNsdWRpbmcgeW91ciBsb2NhbCBoYXJk IGRyaXZlKSkgYW5kIHRoZW4KbGlzdGluZyB0aGUgZGF0YSBvbiB0aGUgY2xpcGJvYXJkLgoKSSds bCBwaW5nIGJhY2sgdGhpcyB0aHJlYWQgbGF0ZXIgdG9kYXkgd2hlbiBpdHMgcmVhZHkgdG8gdmll dyBhbmQgcGxheSB3aXRoLgoKCk9uIDUvNS8wNiwgUm9iZXJ0IFNheXJlIDxzYXlyZXJAZ21haWwu Y29tPiB3cm90ZToKPgo+Cj4gSSd2ZSBiZWVuIHdvcmtpbmcgdG8gYWRkIEF0b20gc3VwcG9ydCB0 byBGaXJlZm94IDIuIFNvbWUgb3RoZXIgRmlyZWZveAo+IGRldnMgYXJlIHRveWluZyB3aXRoIGV4 cG9zaW5nIGludGVybmFsIGRhdGEgbGlrZSBoaXN0b3J5IGFuZCBib29rbWFya3MKPiBhcyBBdG9t IGZlZWRzLgo+Cj4gV2hhdCBzb2Z0d2FyZSBhcmUgeW91IHdyaXRpbmc/Cj4KPiAtLQo+Cj4gUm9i ZXJ0IFNheXJlCj4KPiAiSSB3b3VsZCBoYXZlIHdyaXR0ZW4gYSBzaG9ydGVyIGxldHRlciwgYnV0 IEkgZGlkIG5vdCBoYXZlIHRoZSB0aW1lLiIKPgo+CgoKLS0KPE06RC8+CgpNLiBEYXZpZCBQZXRl cnNvbgpodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8K ------=_Part_12913_9340404.1146837836126 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5JJ3ZlIGdvdCBzZXZlcmFsLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pkdsb2Jh bENsaXAgKHRyYWM6PGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kv R2xvYmFsQ2xpcCI+aHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvR2xvYmFsQ2xp cDwvYT4mbmJzcDtzdm46IHN2bjovL3NyYy5leHRlbnNpYmxlZm9yZ2UubmV0L3RydW5rL0dsb2Jh bENsaXApPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+QW4gaW1wbGVtZW50YXRpb24gb2Yg TVMncyBMaXZlQ2xpcGJvYXJkIHRoYXQgKGZvciB0aGUgbW9tZW50KSB1c2VzIFMzIGFzIGEgd2F5 IG9mIHN0b3JpbmcgYW5kIGFjY2Vzc2luZyBjb250ZW50IHRoYXQgc29tZW9uZSB3YW50cyB0byBl aXRoZXIgYWxsb3cgcHVibGljIGFjY2Vzcywgc2hhcmVkIGJ1dCBjb250cm9sbGVkIGFjY2Vzcywg b3IgcHJpdmF0ZSBhY2Nlc3MgKG11bHRpcGxlIG1hY2hpbmVzKSB0byB0aGlzIGNvbnRlbnQuCjwv ZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkknbSB3b3JraW5nIG9uIHRpZWluZyB0aGlzIGlu dG8gYSBkZW1vIHdoaWNoIHlvdSBjYW4gYWNjZXNzIHZpYSA8YSBocmVmPSJodHRwOi8vZXh0Zi5u ZXQvc2F4b24vZG90bmV0L2FzcC5uZXQvbGl2ZWNsaXBib2FyZC8iPmh0dHA6Ly9leHRmLm5ldC9z YXhvbi9kb3RuZXQvYXNwLm5ldC9saXZlY2xpcGJvYXJkLzwvYT48L2Rpdj4KPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj5UaGUgVUkgZm9yIHRoZSBkZW1vIGlzIGZpbmlzaGVkIChmaW5pc2hlZCB0aGF0 IHllc3RlcmRheSksIHRoZSBiYWNrZW5kIGlzIHdvcmtpbmcgKGZpbmlzaGVkIHRoZSBkYXkgYmVm b3JlKSwgYWx0aG91Z2ggdGhlcmUgaXMgYSBsb3Qgb2Ygc3BpdCBhbmQgcG9saXNoIHdvcmsgdGhh dCBuZWVkcyB0byBiZSBkb25lLCBhbmQgc29tZSBhcmVhcyB0aGF0IEkgd2FudCB0byBleHRlbmQg aW50by4mbmJzcDsgTm9uZS10aGUtbGVzcywgaXQgd2lsbCB3b3JrIGZyb20gdGhlIHN0YW5kcG9p bnQgb2YgdXNpbmcgTGl2ZUNsaXBib2FyZCBhcyB0aGUgYnJvd3Nlci1iYXNlZCBlbmdpbmUgdG8g dGhlIHRha2UgdGhlIGNvbnRlbnQgZnJvbSB0aGUgaW5zdGFuY2Ugb2YgbGl2ZWNsaXAsIHB1dCBp dCB0byBTMywgYW5kIHRoZW4gbWFrZSBhdmFpbGFibGUgYW4gYXRvbSBmZWVkIG9mIHRoZSBjb250 ZW50cyBvZiB0aGUgY3VycmVudCBjbGlwYm9hcmQgYmFzZWQgb24gY2VydGFpbiBjcml0ZXJpYSAo CmUuZy4gc29ydCBieSBkYXRlLCBjb250ZW50LXR5cGUsIGV0Yy4uLik8L2Rpdj4KPGRpdj4mbmJz cDs8L2Rpdj4KPGRpdj5Zb3UgY2FuIGFjY2VzcyB0aGUgQVNQLk5FVC1iYXNlZCB0cmFjICZndDsg PGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvUmVzZWFyY2gvU2F4 b24vZG90bmV0L0FTUC5ORVQvbGl2ZWNsaXBib2FyZCI+aHR0cDovL2Rldi5leHRlbnNpYmxlZm9y Z2UubmV0L3dpa2kvUmVzZWFyY2gvU2F4b24vZG90bmV0L0FTUC5ORVQvbGl2ZWNsaXBib2FyZDwv YT4KJm5ic3A7Jmx0OyBpbnRlcmZhY2Ugd2hlcmUgeW91IHdpbGwgZmluZCB0aGUgcHJvcGVyIFNW TiBsb2NhdGlvbiBvZiB0aGUgc291cmNlLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRo aXMgd2lsbCBhbGwgdGllIGludG8gQXRvbWljWE1MIHdoaWNoIGluIGVzc2VuY2UgdXNlcyAnZmVl ZCctYmFzZWQgQXRvbSBmZWVkcyBhcyB3YXkgb2YgY29uZmlndXJpbmcgYW4gYXBwbGljYXRpb24g YXMgd2VsbCBhcyBzdG9yaW5nJm5ic3A7YSBjb2xsZWN0aW9uIG9mIGVpdGhlciBvbmUgcmVzb3Vy Y2UgKGhpc3RvcmljYWwpIG9yIG1hbnkgcmVzb3VyY2VzIChjb2xsZWN0aW9uKSZuYnNwO3RoYXQg dGhlbiByZWZlcmVuY2VzIG1vZHVsZXMgY29udGFpbmVkIGluIGV4dGVybmFsICdlbnRyeSctYmFz ZWQgQXRvbSBmaWxlcyB3aGljaCByZWZlcmVuY2VzIGEgcGFydGljdWxhciBpbnN0YW5jZSBvZiBh IHJlc291cmNlLiZuYnNwOyBUaGVzZSByZXNvdXJjZXMgY2FuIGJlIGFueXRoaW5nIGZyb20gZXhp c3RpbmcgQ1NTIG9yIEphdmFzY3JpcHQgZmlsZXMsIHRvIFhNTCB0aGF0IGlzIHVzZWQgdG9nZXRo ZXIgd2l0aCB0aGUgQXNwZWN0WE1MIGNvZGUgYmFzZSB0byB3ZWF2ZSB0b2dldGhlciBwcmUtY29u ZmlndXJlZCB0ZW1wbGF0ZXMgd2l0aCBkYXRhIHRoYXQgcmVsYXRlcyB0byB0aGUgc3BlY2lmaWMg aW5zdGFuY2UgKAplLmcuIHNvbWV0aGluZyBhcyBzaW1wbGUgYXMgd2VhdmluZyB0aGUgbGluayBh bmQgbmFtZSBvZiB0aGUgY3JlYXRpdmUgY29tbW9ucyBsaWNlbnNlZCB1c2VkIGZvciBhIHBhcnRp Y3VsYXIgcGFnZSwgb3IgYXMgY29tcGxleCBhcyB3ZWF2aW5nIGludG8gYW4gZW50aXJlIGFwcGxp Y2F0aW9uIGFsbCBvZiB0aGUgc3BlY2lmaWMgdXNlci1zcGVjaWZpZWQgc2V0dGluZ3MsIGV0Yy4u Lik8L2Rpdj4KCjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+VGhlIGlkZWEgd2l0aCBjb21iaW5pbmcg dGhlIEdsb2JhbENsaXAtYmFzZWQgd2l0aCB0aGUgQXRvbWljWE1MLWJhc2UgaXMgdG8gYWxsb3cg Zm9sa3MgdG8gYmUgYWJsZSB0byBzaGFyZSB0aGUgc291cmNlIGZvciBhIHBhcnRpY3VsYXIgc2l0 ZSwgcGFnZSwmbmJzcDtvciBlbGVtZW50IG9mIHRoYXQgc2l0ZS9wYWdlLCBjb3B5IGl0IHRvIHRo ZWlyIGNsaXBib2FyZCwgYW5kIHRoZW4gcGFzdGUgaXQgaW50byBlaXRoZXIgYW5vdGhlciBzaXRl IChwcmUtZXhpc3RpbmcgQXRvbWljWE1MLWJhc2VkIHNpdGUpIG9yIGNyZWF0ZSBhIGJyYW5kIG5l dyBzaXRlIGJhc2VkIG9uIHRoZSB0ZW1wbGF0ZSBvbiB0aGUgY2xpcGJvYXJkIHdoaWNoIHdvdWxk IHRoZW4gYWNjZXNzIGFsbCBvZiB0aGUgcmVmZXJlbmNlZCByZXNvdXJjZXMsIHdlYXZlIGl0IHRv Z2V0aGVyIHdpdGggYW55IHByZS1jb25maWd1cmVkIHVzZXIgZGF0YSwgYW5kIG1ha2UgdGhpcyBz aXRlIGF2YWlsYWJsZSBpbW1lZGlhdGVsbHkgdXBvbiBmaW5pc2hpbmcgdGhlIGJ1aWxkIG91dCBv ZiB0aGlzIHBhcnRpY3VsYXIgaW5zdGFuY2UuCjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2 PklmIHlvdSB2aXNpdCB0aGUgYWJvdmUgbGlua2VkJm5ic3A7ZGVtbyBpbnRlcmZhY2UgaXQgc2hv dWxkIGJlIGEgYml0IG1vcmUgY2xlYXIgYXMgdG8gd2hhdCB0aGUgY29udGVudCBvZiB0aGF0IGRl bW8gd2lsbCBldmVudHVhbGx5IG1ha2UgYXZhaWxhYmxlIHRvIHZpc2l0b3JzLjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2Pkkgd29uJ3QgZ2V0IGFzIGZhciBhcyBhIGZ1bGwgaW1wbGVtZW50 YXRpb24gb2YgdGhlIGFib3ZlIGRlc2NyaXB0aW9uIHRvZGF5LCBidXQgSSB3aWxsIGhhdmUgaXQg dG8gdGhlIHBvaW50IG9mIGNvcHlpbmcgY2xpcGJvYXJkIGRhdGEsIHBhc3RpbmcgaXQgdG8gdGhl IEdsb2JhbENsaXAgaW5zdGFuY2UgKGN1cnJlbnRseSBTMywgZXZlbnR1YWxseSwgYW55IHN0b3Jh Z2UgbWVkaXVtICgKZS5nLiBHRHJpdmUsIExpdmVEcml2ZSwgQW55T3RoZXJEcml2ZSBpbmNsdWRp bmcgeW91ciBsb2NhbCBoYXJkIGRyaXZlKSkgYW5kIHRoZW4gbGlzdGluZyB0aGUgZGF0YSBvbiB0 aGUgY2xpcGJvYXJkLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkknbGwgcGluZyBiYWNr IHRoaXMgdGhyZWFkIGxhdGVyIHRvZGF5IHdoZW4gaXRzIHJlYWR5IHRvIHZpZXcgYW5kIHBsYXkg d2l0aC48YnI+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gNS81LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Um9iZXJ0IFNheXJlPC9iPiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNheXJlckBnbWFpbC5jb20iPnNheXJlckBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVG VDogI2NjYyAxcHggc29saWQiPjxicj5JJ3ZlIGJlZW4gd29ya2luZyB0byBhZGQgQXRvbSBzdXBw b3J0IHRvIEZpcmVmb3ggMi4gU29tZSBvdGhlciBGaXJlZm94PGJyPmRldnMgYXJlIHRveWluZyB3 aXRoIGV4cG9zaW5nIGludGVybmFsIGRhdGEgbGlrZSBoaXN0b3J5IGFuZCBib29rbWFya3MKPGJy PmFzIEF0b20gZmVlZHMuPGJyPjxicj5XaGF0IHNvZnR3YXJlIGFyZSB5b3Ugd3JpdGluZz88YnI+ PGJyPi0tPGJyPjxicj5Sb2JlcnQgU2F5cmU8YnI+PGJyPiZxdW90O0kgd291bGQgaGF2ZSB3cml0 dGVuIGEgc2hvcnRlciBsZXR0ZXIsIGJ1dCBJIGRpZCBub3QgaGF2ZSB0aGUgdGltZS4mcXVvdDs8 YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4KLS0gPGJy PiZsdDtNOkQvJmd0Ozxicj48YnI+TS4gRGF2aWQgUGV0ZXJzb248YnI+PGEgaHJlZj0iaHR0cDov L3d3dy54c2x0YmxvZy5jb20vIj5odHRwOi8vd3d3LnhzbHRibG9nLmNvbS88L2E+IAo= ------=_Part_12913_9340404.1146837836126-- From owner-atom-syntax@mail.imc.org Fri May 05 11:06:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1tM-0002xe-6L for atompub-archive@lists.ietf.org; Fri, 05 May 2006 11:06:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1tL-0007sw-Gm for atompub-archive@lists.ietf.org; Fri, 05 May 2006 11:06:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45EmwsS062694; Fri, 5 May 2006 07:48:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45EmwoT062693; Fri, 5 May 2006 07:48:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45EmvgZ062679 for ; Fri, 5 May 2006 07:48:57 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1Fc1c0-0001Rl-HN for atom-syntax@imc.org; Fri, 05 May 2006 16:48:56 +0200 Received: from ultra17.rbg.informatik.tu-darmstadt.de ([130.83.160.107]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1Fc1c0-0003jn-DY for atom-syntax@imc.org; Fri, 05 May 2006 16:48:56 +0200 Message-ID: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> Date: Fri, 05 May 2006 16:48:51 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Having ended up as co-author of the Atom Rank Extensions draft I would like to encourage some more discussion on the extension's features. I would especially like to know whether they are flexible enough to cope with all the major use cases while being at the same time reasonably simple to implement. The extension should, e.g., be able to cope with most grading schemes in use; it needs to be able to describe the set of permissible rank values (grades). So we are talking (totally) ordered sets here. Now the order part is easy; that is what @significance (="ascending"/"descending") is for. The hard part is to describe the underlying set of numbers. Now the current draft defines two elements, r:value and r:range, for this purpose. Those two elements can be, however, be collapsed into a single one, and, with cleverly chosen defaults, defining sets using this new r:values element is IMHO as simple, if not simpler, as with the old approach. Others might have different opinions, though, which I would really like to hear about. At any rate, the proposed change looks basically as follows (Note, however, that the issue of rounding rank values has intentionally been left out, since this would only distract from the design issue at hand.) The r:scheme Element Ranking Schemes are defined using the r:scheme element. Each scheme defines the set of rank values permissible for all r:rank elements with the associated scheme. [...] The set of rank values defined by an r:scheme element is the union of the sets of rank values defined by each of its r:values elements. Note that those sets may overlap. The r:values Element The r:values elements defines a set of rank values, each of which has to conform to the XML Schema decimal data type [W3C.REC-xmlschema-2-20041028]. values = element r:values { atomCommonAttributes, attribute minimum { xsd:decimal | "unbounded" }?, attribute maximum { xsd:decimal | "unbounded" }?, attribute steps { xsd:decimal | "continuous" }?, attribute origin { xsd:decimal }?, undefinedContent } The "minimum" attribute specifies an inclusive lower bound on the set of rank values defined by the r:values element. Here, the special value of "unbounded" denotes negative infinity. If not specified, the value of the "minimum" attribute is considered to be "unbounded". The "maximum" attribute specifies an inclusive upper bound on the set of rank values defined by the r:values element. Here, the special value of "unbounded" denotes positive infinity. If not specified, the value of the "minimum" attribute is considered to be "unbounded". The "steps" attribute specifies either an increment or has the special value "continuous". If not specified, the value of the "steps" attribute is considered to be 0. The "origin" element specifies the base from which steps are to be calculated. If not specified, the value of the "origin" attribute is considered to be 0. If the value of the "steps" attribute is "continuous" the set of rank values defined by the r:values element is { x | minimum <= x <= maximum }. Otherwise the set of rank values defined by the r:values element is { x | minimum <= x <= maximum, x = (origin + i * steps) for some integer i }. The following examples illustrate how different sets of rank values can be defined by means of a single r:value element: That's all. Also note that this approach allows overlapping r:values sets. For example, one is now able to define, in a reasonable concise way, the following grading scheme common in Germany: Of course one could alternatively list all 11 values explicitly, but the above is rather more concise. (In fact, the definition of 5.0 could even be moved into the first r:values element.) But as I said above, others might see this differently... Also, I would like to know whether a definition in terms of set notation is fine with you, or whether we should expand on the natural language explanations. Describing precisely what "origin" and "steps" do, in plain English, is unfortunately surprisingly difficult. :-( Looking forwards to your feedback, Andreas Sewe From owner-atom-syntax@mail.imc.org Fri May 05 12:21:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc33f-0008El-2M for atompub-archive@lists.ietf.org; Fri, 05 May 2006 12:21:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc33e-0002Ml-L9 for atompub-archive@lists.ietf.org; Fri, 05 May 2006 12:21:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45G68Ya066810; Fri, 5 May 2006 09:06:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45G68Xa066809; Fri, 5 May 2006 09:06:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45G65mE066803 for ; Fri, 5 May 2006 09:06:07 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id j2so753360nzf for ; Fri, 05 May 2006 09:05:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mo9cdI3PN4h4Hhnfc5bwD+yJJrK2mtbgpXD1cUTo83zeWOcMLRwroLfu+3nVL+57Kh5ASx9HzDDFOUzDjrpbM/6iND7HBD/cEf/uk86eBae+4i+5M3+459k8b0ZYExA+EO+naBcZmo8fXrGwEcMt3EPQQO2M8NJCkbn1HkVpmYs= Received: by 10.36.133.17 with SMTP id g17mr488787nzd; Fri, 05 May 2006 09:05:57 -0700 (PDT) Received: by 10.36.133.7 with HTTP; Fri, 5 May 2006 09:05:56 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 18:05:56 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) In-Reply-To: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k45G67mE066804 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 2006/5/5, Andreas Sewe : > If the value of the "steps" attribute is "continuous" the set of rank > values defined by the r:values element is > > { x | minimum <= x <= maximum }. And @origin is ignored? > Otherwise the set of rank values defined by the r:values element is > > { x | minimum <= x <= maximum, > x = (origin + i * steps) for some integer i }. If "i" and "steps" are positive values, then "x" will always be superior to "origin". If "origin" is superior to "minimum", then "minimum" is not needed, as "origin" *is* the minimum value. If "origin" is less than "minimum", then "x" will always be superior to "origin + i*steps" for which "i" is the minimum integer value verifying "origin + i*steps >= minimum"; this is quite easy to compute, so there's no real need for "minimum" either in this case: the following r:values are all equivalent: If "steps" is a negative value, its easy to compute the same set of values using the minimum allowable value as the "origin" (or "minimum") and a positive "steps". The following r:values are all equivalent: So: there is no need for "origin" and negative "steps" values. There is however one case where that (converting a negative "steps" value into a positive one) could not be possible: when "minimum" equals "unbounded". Couldn't it be spec'd that: - if "minimum" is provided and not "unbounded", then "steps" counts upwards from "minimum" to the greatest value inferior to "maximum" - if "minimum" is not provided or "unbounded", then "steps" counts downwards from "maximum" to negative infinity. In other words, people transitioning from origin and/or negative-steps have to do the following: - if "steps" is negative and "minimum" is not "unbounded", replace "minimum" with the smallest allowable value and use a positive "steps" value - if "steps" is negative and "minimum" is "unbounded", replace "maximum" with the value of "origin" and use a positive "steps" value (which will count downwards to negative infinity) - if "steps" is positive, replace "minimum" with the value of "origin" > The following examples illustrate how different sets of rank values can > be defined by means of a single r:value element: > > > Could be expressed as: or or with the following r:values: -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri May 05 12:23:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc355-0000Y7-Cv for atompub-archive@lists.ietf.org; Fri, 05 May 2006 12:23:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc354-0002YZ-Tn for atompub-archive@lists.ietf.org; Fri, 05 May 2006 12:23:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45G44vl066747; Fri, 5 May 2006 09:04:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45G44Gv066746; Fri, 5 May 2006 09:04:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45G44JA066739 for ; Fri, 5 May 2006 09:04:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so574655wra for ; Fri, 05 May 2006 09:04:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qR8C6UE3gPMD7LLMrz2LurFGGF8Dv4wGZyk7NrgNHzrr2UlvzBN2TybwXgnagDm7EuG2P3zUh6+l9iBwFEM9qla4v6lQBYHznnxVJdevhrTHTYvtUi/eAa5dIhwwxlATN/zVElerUKI1pgFhN5GuU6km+MsIsYkWD+uEOs8oits= Received: by 10.54.156.11 with SMTP id d11mr2541556wre; Fri, 05 May 2006 09:04:03 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 64sm57518wra.2006.05.05.09.04.02; Fri, 05 May 2006 09:04:02 -0700 (PDT) Message-ID: <445B776F.90106@gmail.com> Date: Fri, 05 May 2006 09:03:59 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> In-Reply-To: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Andreas Sewe wrote: >[snip] > Now the current draft defines two elements, r:value and r:range, for > this purpose. Those two elements can be, however, be collapsed into a > single one, and, with cleverly chosen defaults, defining sets using this > new r:values element is IMHO as simple, if not simpler, as with the old > approach. Others might have different opinions, though, which I would > really like to hear about. > Just to note, this seems to be the key disagreement between Andreas and I on the spec. IMHO, for schemes consisting of a constrained set of fixed absolute values (like the German grading system which uses 1.0, 1.3, 1.7, 2.0 etc), specifying a collection of overlapping ranges just doesn't feel right. >[snip] > values = element r:values { > atomCommonAttributes, > attribute minimum { xsd:decimal | "unbounded" }?, > attribute maximum { xsd:decimal | "unbounded" }?, > attribute steps { xsd:decimal | "continuous" }?, > attribute origin { xsd:decimal }?, > undefinedContent > } > >[snip] > > > > > > > > >[snip] > Of course one could alternatively list all 11 values explicitly, but the > above is rather more concise. (In fact, the definition of 5.0 could > even be moved into the first r:values element.) > > But as I said above, others might see this differently... > The alternative: 1.0 1.3 1.7 2.0 2.3 2.7 3.0 3.3 3.7 4.0 4.3 4.7 5.0 To me, this is a whole lot less complicated because I don't have to deal with step sizes, origins, minimum and maximum values, overlapping ranges, etc. There's just a set of explicitly defined values. Also note that in the German grading scheme, each of the values are generally associated with labels (e.g. 1, 1-, 2+, etc) much in the same way that the U.S. grading scheme associates percentages with labels (A, B, C, etc). Using the overlapping ranges approach, it would not be possible to specify the labels for the values. That said, there are cases in which a set of ranges are appropriate. For example, the typical US grading system. 1.00 In this case, it is obvious that the set of acceptable values is too large to list individually. > Also, I would like to know whether a definition in terms of set notation > is fine with you, or whether we should expand on the natural language > explanations. Describing precisely what "origin" and "steps" do, in > plain English, is unfortunately surprisingly difficult. :-( > We're working on the language in the spec. I've never really been happy with it and had been planning on a scrub for some time, but I wanted our initial focus to be on the elements and the basic mechanism for defining the schemes. - James From owner-atom-syntax@mail.imc.org Fri May 05 13:05:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3jv-0001oX-Dl for atompub-archive@lists.ietf.org; Fri, 05 May 2006 13:05:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3jp-00048b-Uf for atompub-archive@lists.ietf.org; Fri, 05 May 2006 13:05:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45GrTrq068432; Fri, 5 May 2006 09:53:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45GrTkc068431; Fri, 5 May 2006 09:53:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rack19.fast-web-servers.com (rack19.fast-web-servers.com [67.131.250.107]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45GrStC068425 for ; Fri, 5 May 2006 09:53:28 -0700 (MST) (envelope-from nick@socklabs.com) Received: from [204.9.178.253] (helo=ron.dhcp-sfo.sixapart.com) by rack19.fast-web-servers.com with esmtp (Exim 4.42) id 1Fc3YR-0001pP-JR; Fri, 05 May 2006 09:53:23 -0700 Date: Fri, 5 May 2006 09:57:21 -0700 From: Nick Gerakines To: Robert Sayre Cc: atom-syntax@imc.org Subject: Re: What Atom software are you working on? Message-ID: <20060505165721.GB12876@ron.dhcp-sfo.sixapart.com> References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-URL: http://blog.socklabs.com/ X-FOAF: http://blog.socklabs.com/foaf.rdf Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 This my first post, feels like a good time to pipe in. I've got a few things on my plate, some of you may be interested in. * TypePad Atom API - Updating and overhauling the Atom API for TypePad. I've been working with Byrne Reese internally to get a really solid spec hammered out. So far things are looking really good. * TypePad Atom feed support - TypePad Currently has Atom (v1.0) feeds for blogs but I've been extending that quite a bit. The general idea is that TypePad will provide the following atom feeds: recent blog entries, recent blog comments, individual entry + comments, blog category feeds, photo gallery, individual image + comments + meta info, TypeList feeds, etc etc. I'm also adding support for the threading extension provide by James Snell. The entire process has been very fun and educational. * Fence - Fence is a small application that was originally a proof-of-concept learning project to interact with the TypePad Atom API but has become a full project. It is written in cocoa/objective-c (my first cocoa app) and uses a home grown Atom framework resembling the perl module XML::Atom. I've put a project blog out that has more information and screenshots ( http://blog.socklabs.com/typepad-uploader ). The Atom cocoa framework can interact with any Atom API friendly website so its not just TypePad specific. * iPhoto export tools - I've also created a few different iPhoto plugins that export to TypePad using the Atom cocoa framework as mentioned above. Thats it for me, as you can see most of my development is in Perl but I do some mac os x and cocoa stuff as well. Questions? Comments? # Nick Gerakines On Fri, May 05, 2006 at 09:11:25AM -0400, Robert Sayre (sayrer@gmail.com) wrote: > > I've been working to add Atom support to Firefox 2. Some other Firefox > devs are toying with exposing internal data like history and bookmarks > as Atom feeds. > > What software are you writing? > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > > From owner-atom-syntax@mail.imc.org Fri May 05 13:20:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3yx-00055n-2a for atompub-archive@lists.ietf.org; Fri, 05 May 2006 13:20:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3yw-0004mu-HE for atompub-archive@lists.ietf.org; Fri, 05 May 2006 13:20:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45H4Io3069272; Fri, 5 May 2006 10:04:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k45H4IRG069271; Fri, 5 May 2006 10:04:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k45H4HE3069264 for ; Fri, 5 May 2006 10:04:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so586156wra for ; Fri, 05 May 2006 10:04:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gDRyrunRjgOr4AVYgUFiVv3QIoz0yJOy/w1DdgQuzwffCq2kXTvKHwk8uo79VhwJiXQ//s1KZIhkijBgtD1mwYrAGcgyBpcOXHbKdXZCR1nbFjtNpFe81RxUheYr46giAXTJrK2+LPoxPDn8gVY3L+3tGY6w5xGFMZqA3/B8B0g= Received: by 10.54.95.11 with SMTP id s11mr2798265wrb; Fri, 05 May 2006 10:04:17 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 38sm2032933wrl.2006.05.05.10.04.15; Fri, 05 May 2006 10:04:16 -0700 (PDT) Message-ID: <445B858D.8010408@gmail.com> Date: Fri, 05 May 2006 10:04:13 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom-Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Thomas, Everything you write below speaks precisely to the point as to why I would prefer *not* always defining r:scheme in terms of ranges -- especially potentially overlapping ranges. Ranges can be complicated. In the current spec, the use of origin is dependent both on the significance of the scheme (ascending or descending) and on whether or not minimum/maximum values are specified. If significance=descending and maximum is specified, then origin == maximum and step counts backwards. Larger numbers have lower significance. If significance=ascending and minimum is specified, then origin == minimum and step counts forwards. Larger numbers have greater significance. Stepped range values should always be calculated relative to the least significant value. If the least significant value is not specified, origin may be used to provide an alternative starting point. If the least significant value is specified, specifying an origin is unnecessary. One point that needs to be clarified in the spec. Step MUST be a positive decimal value. Also note that in the current spec, the step is used only to identify the increment at which values in the range are considered significant for purposes of comparing ranks. When producing ordered sets of ranked entries, intermediate values that fall in-between steps are considered equivalent to the nearest least-significant, in-step value. For instance, given the following range in a scheme with ascending significance, <:range minimum="0.00" maximum="1.00" step="0.10" /> The set of values 0.01...0.09 is considered equivalent to the value 0.10. This is a point that Andreas and I have disagreed on. His argument has been that feed publishers should only output r:rank values that precisely match the step and origin. e.g. a rank of 0.15 would be invalid given the above scheme. With this approach, overlapping ranges are less of a problem so long as all of those ranges use the same size step and specify different origins. I, on the other hand, feel that intermediate rank values are acceptable, in which case, ranges MUST NOT overlap because you'd never be able to precisely determine the range to which the value belongs. For schemes consisting of a constrained set of fixed, absolute values, dealing with all this range stuff is just overkill. If there are only a handle of acceptable values, we should just list those specific values and be done with it. - James Thomas Broyer wrote: > > 2006/5/5, Andreas Sewe : >> If the value of the "steps" attribute is "continuous" the set of rank >> values defined by the r:values element is >> >> { x | minimum <= x <= maximum }. > > And @origin is ignored? > >> Otherwise the set of rank values defined by the r:values element is >> >> { x | minimum <= x <= maximum, >> x = (origin + i * steps) for some integer i }. > > If "i" and "steps" are positive values, then "x" will always be > superior to "origin". > > If "origin" is superior to "minimum", then "minimum" is not needed, as > "origin" *is* the minimum value. > If "origin" is less than "minimum", then "x" will always be superior > to "origin + i*steps" for which "i" is the minimum integer value > verifying "origin + i*steps >= minimum"; this is quite easy to > compute, so there's no real need for "minimum" either in this case: > the following r:values are all equivalent: > > > > > > If "steps" is a negative value, its easy to compute the same set of > values using the minimum allowable value as the "origin" (or > "minimum") and a positive "steps". The following r:values are all > equivalent: > > > > So: there is no need for "origin" and negative "steps" values. > > There is however one case where that (converting a negative "steps" > value into a positive one) could not be possible: when "minimum" > equals "unbounded". > Couldn't it be spec'd that: > - if "minimum" is provided and not "unbounded", then "steps" counts > upwards from "minimum" to the greatest value inferior to "maximum" > - if "minimum" is not provided or "unbounded", then "steps" counts > downwards from "maximum" to negative infinity. > > In other words, people transitioning from origin and/or negative-steps > have to do the following: > - if "steps" is negative and "minimum" is not "unbounded", replace > "minimum" with the smallest allowable value and use a positive "steps" > value > - if "steps" is negative and "minimum" is "unbounded", replace > "maximum" with the value of "origin" and use a positive "steps" value > (which will count downwards to negative infinity) > - if "steps" is positive, replace "minimum" with the value of "origin" > >> The following examples illustrate how different sets of rank values can >> be defined by means of a single r:value element: >> >> >> > > Could be expressed as: > > or > > or with the following r:values: > > > -- > Thomas Broyer > > From owner-atom-syntax@mail.imc.org Sat May 06 00:09:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcE6u-0000wc-Jr for atompub-archive@lists.ietf.org; Sat, 06 May 2006 00:09:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcE6s-0002L8-Qs for atompub-archive@lists.ietf.org; Sat, 06 May 2006 00:09:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k463rpUe095544; Fri, 5 May 2006 20:53:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k463rpws095543; Fri, 5 May 2006 20:53:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k463roue095537 for ; Fri, 5 May 2006 20:53:50 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so813208nzf for ; Fri, 05 May 2006 20:53:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ud/ogaqhKtnHK5SogAQqJthzWCH5Oiy3cIfi6muHyDX5fr1xhwBPldibl+AFcwQn8CfXbT88hc2LwSzuXF3np0q68pYYHFaqgRJuoHQa9gHolE583wQNKPMJSVk5VcDYtRxBEeAUtDVZZ/IjyhBsuplt7+pzaKtmmlrN6LhATNg= Received: by 10.65.220.19 with SMTP id x19mr873345qbq; Fri, 05 May 2006 20:53:49 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Fri, 5 May 2006 20:53:49 -0700 (PDT) Message-ID: Date: Fri, 5 May 2006 21:53:49 -0600 From: "M. David Peterson" To: "Robert Sayre" Subject: Re: What Atom software are you working on? Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23410_33249211.1146887629663" References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 ------=_Part_23410_33249211.1146887629663 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGV5IEZvbGtzLAoKQXMgcGVyIG15IGVtYWlsIHRoaXMgbW9ybmluZywgYSBxdWljayB1cGRhdGU6 CgpBcyBwb3N0ZWQgdG8gdGhlIG1haW4gc2FtcGxlIHNpdGU6CgpbaHR0cDovL2V4dGYubmV0L3Nh eG9uL2RvdG5ldC9hc3AubmV0L2xpdmVjbGlwYm9hcmQvXQoKUExFQVNFIE5PVEU6IEkgYW0gY3Vy cmVudGx5IHdvcmtpbmcgdGhyb3VnaCB2YXJpb3VzIGlzc3VlcyB3aXRoIENTUwo+IGNvbGxpc2lv bnMsIGlzc3VlcyB3aXRoIHdoeSBGeCB3aWxsIHJlY29nbml6ZSB0aGUgdG9wIG1hcmdpbiBvZiB0 aGUgY29udGVudAo+IGNvbnRhaW5lciBidXQgcmVmdXNlcyB0byByZWNvZ25pemUgdGhlIGJvdHRv bSBtYXJnaW4gd2hlbiBJIGFkZCBjb250ZW50IHRvCj4gdGhpcyBjb250YWluZXIsIHdoeSBJRSB3 aWxsIHJlY29nbml6ZSB0aGUgYm90dG9tIG1hcmdpbiwgYnV0IHJlZnVzZSB0bwo+IHJlY29nbml6 ZSB0aGUgdG9wIG1hcmdpbiByZWdhcmRsZXNzIG9mIHdoZXRoZXIgSSBwdXQgY29udGVudCBpbiB0 aGUgY29udGVudAo+IGNvbnRhaW5lci4uLiB5b3Uga25vdywgdGhlIHVzdWFsIHN0dWZmIHRoYXQg bWFrZXMgeW91IHdhbnQgdG8gcmlwIGVhY2ggYW5kCj4gZXZlcnkgaGFpciBvdXQgb2YgeW91ciBv d24gaGVhZCwgYW5kIHRoZSBoZWFkcyBvZiB0aG9zZSB3aG8gaW52ZW50ZWQgdGhpcwo+IGNyYXAu Li4gZXJyLCBJIG1lYW4uLi4gdGhpcy4uLiBuZWF0Li4uLiB0ZWNobm9sb2d5LiAgU28gdGhlcmUg eWEgaGF2ZS4KPiBQZWFjZSBiZSB1bnRvIHlvdSBhbGwgd2hpbGUgSSBjb250aW51ZSBteSBlZmZv cnRzIHRvIGluZHVjZSBwcmVtYXR1cmUgbWFsZQo+IHBhdHRlcm4gYmFsZG5lc3MgdXBvbiBteXNl bGYuCgoKU28gdGhlcmUgeWEgaGF2ZSBpdC4uLiAgSSdsbCB1cGRhdGUgeW91IHdoZW4gSSBoYXZl IGxlc3MgaGFpciwgYnV0IGJldHRlcgpyZXN1bHRzIHRvIHNob3djYXNlLgoKCk9uIDUvNS8wNiwg TS4gRGF2aWQgUGV0ZXJzb24gPHhtbGhhY2tlckBnbWFpbC5jb20+IHdyb3RlOgo+Cj4gSSd2ZSBn b3Qgc2V2ZXJhbC4KPgo+IEdsb2JhbENsaXAgKHRyYWM6aHR0cDovL2Rldi5leHRlbnNpYmxlZm9y Z2UubmV0L3dpa2kvR2xvYmFsQ2xpcCBzdm46Cj4gc3ZuOi8vc3JjLmV4dGVuc2libGVmb3JnZS5u ZXQvdHJ1bmsvR2xvYmFsQ2xpcCkKPgo+IEFuIGltcGxlbWVudGF0aW9uIG9mIE1TJ3MgTGl2ZUNs aXBib2FyZCB0aGF0IChmb3IgdGhlIG1vbWVudCkgdXNlcyBTMyBhcyBhCj4gd2F5IG9mIHN0b3Jp bmcgYW5kIGFjY2Vzc2luZyBjb250ZW50IHRoYXQgc29tZW9uZSB3YW50cyB0byBlaXRoZXIgYWxs b3cKPiBwdWJsaWMgYWNjZXNzLCBzaGFyZWQgYnV0IGNvbnRyb2xsZWQgYWNjZXNzLCBvciBwcml2 YXRlIGFjY2VzcyAobXVsdGlwbGUKPiBtYWNoaW5lcykgdG8gdGhpcyBjb250ZW50Lgo+Cj4gSSdt IHdvcmtpbmcgb24gdGllaW5nIHRoaXMgaW50byBhIGRlbW8gd2hpY2ggeW91IGNhbiBhY2Nlc3Mg dmlhCj4gaHR0cDovL2V4dGYubmV0L3NheG9uL2RvdG5ldC9hc3AubmV0L2xpdmVjbGlwYm9hcmQv Cj4KPiBUaGUgVUkgZm9yIHRoZSBkZW1vIGlzIGZpbmlzaGVkIChmaW5pc2hlZCB0aGF0IHllc3Rl cmRheSksIHRoZSBiYWNrZW5kIGlzCj4gd29ya2luZyAoZmluaXNoZWQgdGhlIGRheSBiZWZvcmUp LCBhbHRob3VnaCB0aGVyZSBpcyBhIGxvdCBvZiBzcGl0IGFuZAo+IHBvbGlzaCB3b3JrIHRoYXQg bmVlZHMgdG8gYmUgZG9uZSwgYW5kIHNvbWUgYXJlYXMgdGhhdCBJIHdhbnQgdG8gZXh0ZW5kCj4g aW50by4gIE5vbmUtdGhlLWxlc3MsIGl0IHdpbGwgd29yayBmcm9tIHRoZSBzdGFuZHBvaW50IG9m IHVzaW5nCj4gTGl2ZUNsaXBib2FyZCBhcyB0aGUgYnJvd3Nlci1iYXNlZCBlbmdpbmUgdG8gdGhl IHRha2UgdGhlIGNvbnRlbnQgZnJvbSB0aGUKPiBpbnN0YW5jZSBvZiBsaXZlY2xpcCwgcHV0IGl0 IHRvIFMzLCBhbmQgdGhlbiBtYWtlIGF2YWlsYWJsZSBhbiBhdG9tIGZlZWQgb2YKPiB0aGUgY29u dGVudHMgb2YgdGhlIGN1cnJlbnQgY2xpcGJvYXJkIGJhc2VkIG9uIGNlcnRhaW4gY3JpdGVyaWEg KCBlLmcuCj4gc29ydCBieSBkYXRlLCBjb250ZW50LXR5cGUsIGV0Yy4uLikKPgo+IFlvdSBjYW4g YWNjZXNzIHRoZSBBU1AuTkVULWJhc2VkIHRyYWMgPgo+IGh0dHA6Ly9kZXYuZXh0ZW5zaWJsZWZv cmdlLm5ldC93aWtpL1Jlc2VhcmNoL1NheG9uL2RvdG5ldC9BU1AuTkVUL2xpdmVjbGlwYm9hcmQg PCBpbnRlcmZhY2Ugd2hlcmUgeW91IHdpbGwgZmluZCB0aGUgcHJvcGVyIFNWTiBsb2NhdGlvbiBv ZiB0aGUgc291cmNlLgo+Cj4gVGhpcyB3aWxsIGFsbCB0aWUgaW50byBBdG9taWNYTUwgd2hpY2gg aW4gZXNzZW5jZSB1c2VzICdmZWVkJy1iYXNlZCBBdG9tCj4gZmVlZHMgYXMgd2F5IG9mIGNvbmZp Z3VyaW5nIGFuIGFwcGxpY2F0aW9uIGFzIHdlbGwgYXMgc3RvcmluZyBhIGNvbGxlY3Rpb24KPiBv ZiBlaXRoZXIgb25lIHJlc291cmNlIChoaXN0b3JpY2FsKSBvciBtYW55IHJlc291cmNlcyAoY29s bGVjdGlvbikgdGhhdCB0aGVuCj4gcmVmZXJlbmNlcyBtb2R1bGVzIGNvbnRhaW5lZCBpbiBleHRl cm5hbCAnZW50cnknLWJhc2VkIEF0b20gZmlsZXMgd2hpY2gKPiByZWZlcmVuY2VzIGEgcGFydGlj dWxhciBpbnN0YW5jZSBvZiBhIHJlc291cmNlLiAgVGhlc2UgcmVzb3VyY2VzIGNhbiBiZQo+IGFu eXRoaW5nIGZyb20gZXhpc3RpbmcgQ1NTIG9yIEphdmFzY3JpcHQgZmlsZXMsIHRvIFhNTCB0aGF0 IGlzIHVzZWQgdG9nZXRoZXIKPiB3aXRoIHRoZSBBc3BlY3RYTUwgY29kZSBiYXNlIHRvIHdlYXZl IHRvZ2V0aGVyIHByZS1jb25maWd1cmVkIHRlbXBsYXRlcyB3aXRoCj4gZGF0YSB0aGF0IHJlbGF0 ZXMgdG8gdGhlIHNwZWNpZmljIGluc3RhbmNlICggZS5nLiBzb21ldGhpbmcgYXMgc2ltcGxlIGFz Cj4gd2VhdmluZyB0aGUgbGluayBhbmQgbmFtZSBvZiB0aGUgY3JlYXRpdmUgY29tbW9ucyBsaWNl bnNlZCB1c2VkIGZvciBhCj4gcGFydGljdWxhciBwYWdlLCBvciBhcyBjb21wbGV4IGFzIHdlYXZp bmcgaW50byBhbiBlbnRpcmUgYXBwbGljYXRpb24gYWxsIG9mCj4gdGhlIHNwZWNpZmljIHVzZXIt c3BlY2lmaWVkIHNldHRpbmdzLCBldGMuLi4pCj4KPiBUaGUgaWRlYSB3aXRoIGNvbWJpbmluZyB0 aGUgR2xvYmFsQ2xpcC1iYXNlZCB3aXRoIHRoZSBBdG9taWNYTUwtYmFzZSBpcyB0bwo+IGFsbG93 IGZvbGtzIHRvIGJlIGFibGUgdG8gc2hhcmUgdGhlIHNvdXJjZSBmb3IgYSBwYXJ0aWN1bGFyIHNp dGUsIHBhZ2UsIG9yCj4gZWxlbWVudCBvZiB0aGF0IHNpdGUvcGFnZSwgY29weSBpdCB0byB0aGVp ciBjbGlwYm9hcmQsIGFuZCB0aGVuIHBhc3RlIGl0Cj4gaW50byBlaXRoZXIgYW5vdGhlciBzaXRl IChwcmUtZXhpc3RpbmcgQXRvbWljWE1MLWJhc2VkIHNpdGUpIG9yIGNyZWF0ZSBhCj4gYnJhbmQg bmV3IHNpdGUgYmFzZWQgb24gdGhlIHRlbXBsYXRlIG9uIHRoZSBjbGlwYm9hcmQgd2hpY2ggd291 bGQgdGhlbgo+IGFjY2VzcyBhbGwgb2YgdGhlIHJlZmVyZW5jZWQgcmVzb3VyY2VzLCB3ZWF2ZSBp dCB0b2dldGhlciB3aXRoIGFueQo+IHByZS1jb25maWd1cmVkIHVzZXIgZGF0YSwgYW5kIG1ha2Ug dGhpcyBzaXRlIGF2YWlsYWJsZSBpbW1lZGlhdGVsbHkgdXBvbgo+IGZpbmlzaGluZyB0aGUgYnVp bGQgb3V0IG9mIHRoaXMgcGFydGljdWxhciBpbnN0YW5jZS4KPgo+IElmIHlvdSB2aXNpdCB0aGUg YWJvdmUgbGlua2VkIGRlbW8gaW50ZXJmYWNlIGl0IHNob3VsZCBiZSBhIGJpdCBtb3JlIGNsZWFy Cj4gYXMgdG8gd2hhdCB0aGUgY29udGVudCBvZiB0aGF0IGRlbW8gd2lsbCBldmVudHVhbGx5IG1h a2UgYXZhaWxhYmxlIHRvCj4gdmlzaXRvcnMuCj4KPiBJIHdvbid0IGdldCBhcyBmYXIgYXMgYSBm dWxsIGltcGxlbWVudGF0aW9uIG9mIHRoZSBhYm92ZSBkZXNjcmlwdGlvbgo+IHRvZGF5LCBidXQg SSB3aWxsIGhhdmUgaXQgdG8gdGhlIHBvaW50IG9mIGNvcHlpbmcgY2xpcGJvYXJkIGRhdGEsIHBh c3RpbmcgaXQKPiB0byB0aGUgR2xvYmFsQ2xpcCBpbnN0YW5jZSAoY3VycmVudGx5IFMzLCBldmVu dHVhbGx5LCBhbnkgc3RvcmFnZSBtZWRpdW0gKAo+IGUuZy4gR0RyaXZlLCBMaXZlRHJpdmUsIEFu eU90aGVyRHJpdmUgaW5jbHVkaW5nIHlvdXIgbG9jYWwgaGFyZCBkcml2ZSkpCj4gYW5kIHRoZW4g bGlzdGluZyB0aGUgZGF0YSBvbiB0aGUgY2xpcGJvYXJkLgo+Cj4gSSdsbCBwaW5nIGJhY2sgdGhp cyB0aHJlYWQgbGF0ZXIgdG9kYXkgd2hlbiBpdHMgcmVhZHkgdG8gdmlldyBhbmQgcGxheQo+IHdp dGguCj4KPgo+IE9uIDUvNS8wNiwgUm9iZXJ0IFNheXJlIDxzYXlyZXJAZ21haWwuY29tPiB3cm90 ZToKPiA+Cj4gPgo+ID4gSSd2ZSBiZWVuIHdvcmtpbmcgdG8gYWRkIEF0b20gc3VwcG9ydCB0byBG aXJlZm94IDIuIFNvbWUgb3RoZXIgRmlyZWZveAo+ID4gZGV2cyBhcmUgdG95aW5nIHdpdGggZXhw b3NpbmcgaW50ZXJuYWwgZGF0YSBsaWtlIGhpc3RvcnkgYW5kIGJvb2ttYXJrcwo+ID4gYXMgQXRv bSBmZWVkcy4KPiA+Cj4gPiBXaGF0IHNvZnR3YXJlIGFyZSB5b3Ugd3JpdGluZz8KPiA+Cj4gPiAt LQo+ID4KPiA+IFJvYmVydCBTYXlyZQo+ID4KPiA+ICJJIHdvdWxkIGhhdmUgd3JpdHRlbiBhIHNo b3J0ZXIgbGV0dGVyLCBidXQgSSBkaWQgbm90IGhhdmUgdGhlIHRpbWUuIgo+ID4KPiA+Cj4KPgo+ IC0tCj4gPE06RC8+Cj4KPiBNLiBEYXZpZCBQZXRlcnNvbgo+IGh0dHA6Ly93d3cueHNsdGJsb2cu Y29tLwo+CgoKCi0tCjxNOkQvPgoKTS4gRGF2aWQgUGV0ZXJzb24KaHR0cDovL3d3dy54c2x0Ymxv Zy5jb20vCg== ------=_Part_23410_33249211.1146887629663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGV5IEZvbGtzLDxicj48YnI+QXMgcGVyIG15IGVtYWlsIHRoaXMgbW9ybmluZywgYSBxdWljayB1 cGRhdGU6PGJyPjxicj5BcyBwb3N0ZWQgdG8gdGhlIG1haW4gc2FtcGxlIHNpdGU6PGJyPjxicj5b PGEgaHJlZj0iaHR0cDovL2V4dGYubmV0L3NheG9uL2RvdG5ldC9hc3AubmV0L2xpdmVjbGlwYm9h cmQvIj5odHRwOi8vZXh0Zi5uZXQvc2F4b24vZG90bmV0L2FzcC5uZXQvbGl2ZWNsaXBib2FyZC8K PC9hPl08YnI+PGJyPjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUiPlBMRUFTRSBOT1RFOiBJIGFtIGN1cnJlbnRseSB3 b3JraW5nIHRocm91Z2ggdmFyaW91cyBpc3N1ZXMgd2l0aCBDU1MgY29sbGlzaW9ucywgaXNzdWVz IHdpdGggd2h5IEZ4IHdpbGwgcmVjb2duaXplIHRoZSB0b3AgbWFyZ2luIG9mIHRoZSBjb250ZW50 IGNvbnRhaW5lciBidXQgcmVmdXNlcyB0byByZWNvZ25pemUgdGhlIGJvdHRvbSBtYXJnaW4gd2hl biBJIGFkZCBjb250ZW50IHRvIHRoaXMgY29udGFpbmVyLCB3aHkgSUUgd2lsbCByZWNvZ25pemUg dGhlIGJvdHRvbSBtYXJnaW4sIGJ1dCByZWZ1c2UgdG8gcmVjb2duaXplIHRoZSB0b3AgbWFyZ2lu IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBJIHB1dCBjb250ZW50IGluIHRoZSBjb250ZW50IGNvbnRh aW5lci4uLiB5b3Uga25vdywgdGhlIHVzdWFsIHN0dWZmIHRoYXQgbWFrZXMgeW91IHdhbnQgdG8g cmlwIGVhY2ggYW5kIGV2ZXJ5IGhhaXIgb3V0IG9mIHlvdXIgb3duIGhlYWQsIGFuZCB0aGUgaGVh ZHMgb2YgdGhvc2Ugd2hvIGludmVudGVkIHRoaXMgY3JhcC4uLiBlcnIsIEkgbWVhbi4uLiB0aGlz Li4uIG5lYXQuLi4uIHRlY2hub2xvZ3kuJm5ic3A7IFNvIHRoZXJlIHlhIGhhdmUuJm5ic3A7IFBl YWNlIGJlIHVudG8geW91IGFsbCB3aGlsZSBJIGNvbnRpbnVlIG15IGVmZm9ydHMgdG8gaW5kdWNl IHByZW1hdHVyZSBtYWxlIHBhdHRlcm4gYmFsZG5lc3MgdXBvbiBteXNlbGYuCjwvYmxvY2txdW90 ZT48ZGl2Pjxicj5TbyB0aGVyZSB5YSBoYXZlIGl0Li4uJm5ic3A7IEknbGwgdXBkYXRlIHlvdSB3 aGVuIEkgaGF2ZSBsZXNzIGhhaXIsIGJ1dCBiZXR0ZXIgcmVzdWx0cyB0byBzaG93Y2FzZS48YnI+ PC9kaXY+PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNS81LzA2LCA8 YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+TS4gRGF2aWQgUGV0ZXJzb24KPC9iPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnhtbGhhY2tlckBnbWFpbC5jb20iPnhtbGhhY2tlckBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i Ym9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBs dHI7Ij4KPGRpdj5JJ3ZlIGdvdCBzZXZlcmFsLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2 Pkdsb2JhbENsaXAgKHRyYWM6PGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0 L3dpa2kvR2xvYmFsQ2xpcCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMu T3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vZGV2LmV4dGVuc2libGVmb3Jn ZS5uZXQvd2lraS9HbG9iYWxDbGlwPC9hPiZuYnNwO3N2bjogc3ZuOi8vc3JjLmV4dGVuc2libGVm b3JnZS5uZXQvdHJ1bmsvR2xvYmFsQ2xpcCkKPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+ QW4gaW1wbGVtZW50YXRpb24gb2YgTVMncyBMaXZlQ2xpcGJvYXJkIHRoYXQgKGZvciB0aGUgbW9t ZW50KSB1c2VzIFMzIGFzIGEgd2F5IG9mIHN0b3JpbmcgYW5kIGFjY2Vzc2luZyBjb250ZW50IHRo YXQgc29tZW9uZSB3YW50cyB0byBlaXRoZXIgYWxsb3cgcHVibGljIGFjY2Vzcywgc2hhcmVkIGJ1 dCBjb250cm9sbGVkIGFjY2Vzcywgb3IgcHJpdmF0ZSBhY2Nlc3MgKG11bHRpcGxlIG1hY2hpbmVz KSB0byB0aGlzIGNvbnRlbnQuCjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkknbSB3b3Jr aW5nIG9uIHRpZWluZyB0aGlzIGludG8gYSBkZW1vIHdoaWNoIHlvdSBjYW4gYWNjZXNzIHZpYSA8 YSBocmVmPSJodHRwOi8vZXh0Zi5uZXQvc2F4b24vZG90bmV0L2FzcC5uZXQvbGl2ZWNsaXBib2Fy ZC8iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSI+aHR0cDovL2V4dGYubmV0L3NheG9uL2RvdG5ldC9hc3AubmV0L2xp dmVjbGlwYm9hcmQvCjwvYT48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5UaGUgVUkgZm9y IHRoZSBkZW1vIGlzIGZpbmlzaGVkIChmaW5pc2hlZCB0aGF0IHllc3RlcmRheSksIHRoZSBiYWNr ZW5kIGlzIHdvcmtpbmcgKGZpbmlzaGVkIHRoZSBkYXkgYmVmb3JlKSwgYWx0aG91Z2ggdGhlcmUg aXMgYSBsb3Qgb2Ygc3BpdCBhbmQgcG9saXNoIHdvcmsgdGhhdCBuZWVkcyB0byBiZSBkb25lLCBh bmQgc29tZSBhcmVhcyB0aGF0IEkgd2FudCB0byBleHRlbmQgaW50by4mbmJzcDsgTm9uZS10aGUt bGVzcywgaXQgd2lsbCB3b3JrIGZyb20gdGhlIHN0YW5kcG9pbnQgb2YgdXNpbmcgTGl2ZUNsaXBi b2FyZCBhcyB0aGUgYnJvd3Nlci1iYXNlZCBlbmdpbmUgdG8gdGhlIHRha2UgdGhlIGNvbnRlbnQg ZnJvbSB0aGUgaW5zdGFuY2Ugb2YgbGl2ZWNsaXAsIHB1dCBpdCB0byBTMywgYW5kIHRoZW4gbWFr ZSBhdmFpbGFibGUgYW4gYXRvbSBmZWVkIG9mIHRoZSBjb250ZW50cyBvZiB0aGUgY3VycmVudCBj bGlwYm9hcmQgYmFzZWQgb24gY2VydGFpbiBjcml0ZXJpYSAoCmUuZy4gc29ydCBieSBkYXRlLCBj b250ZW50LXR5cGUsIGV0Yy4uLik8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5Zb3UgY2Fu IGFjY2VzcyB0aGUgQVNQLk5FVC1iYXNlZCB0cmFjICZndDsgPGEgaHJlZj0iaHR0cDovL2Rldi5l eHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvUmVzZWFyY2gvU2F4b24vZG90bmV0L0FTUC5ORVQvbGl2 ZWNsaXBib2FyZCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vZGV2LmV4dGVuc2libGVmb3JnZS5uZXQv d2lraS9SZXNlYXJjaC9TYXhvbi9kb3RuZXQvQVNQLk5FVC9saXZlY2xpcGJvYXJkCjwvYT4KJm5i c3A7Jmx0OyBpbnRlcmZhY2Ugd2hlcmUgeW91IHdpbGwgZmluZCB0aGUgcHJvcGVyIFNWTiBsb2Nh dGlvbiBvZiB0aGUgc291cmNlLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRoaXMgd2ls bCBhbGwgdGllIGludG8gQXRvbWljWE1MIHdoaWNoIGluIGVzc2VuY2UgdXNlcyAnZmVlZCctYmFz ZWQgQXRvbSBmZWVkcyBhcyB3YXkgb2YgY29uZmlndXJpbmcgYW4gYXBwbGljYXRpb24gYXMgd2Vs bCBhcyBzdG9yaW5nJm5ic3A7YSBjb2xsZWN0aW9uIG9mIGVpdGhlciBvbmUgcmVzb3VyY2UgKGhp c3RvcmljYWwpIG9yIG1hbnkgcmVzb3VyY2VzIChjb2xsZWN0aW9uKSZuYnNwO3RoYXQgdGhlbiBy ZWZlcmVuY2VzIG1vZHVsZXMgY29udGFpbmVkIGluIGV4dGVybmFsICdlbnRyeSctYmFzZWQgQXRv bSBmaWxlcyB3aGljaCByZWZlcmVuY2VzIGEgcGFydGljdWxhciBpbnN0YW5jZSBvZiBhIHJlc291 cmNlLiZuYnNwOyBUaGVzZSByZXNvdXJjZXMgY2FuIGJlIGFueXRoaW5nIGZyb20gZXhpc3Rpbmcg Q1NTIG9yIEphdmFzY3JpcHQgZmlsZXMsIHRvIFhNTCB0aGF0IGlzIHVzZWQgdG9nZXRoZXIgd2l0 aCB0aGUgQXNwZWN0WE1MIGNvZGUgYmFzZSB0byB3ZWF2ZSB0b2dldGhlciBwcmUtY29uZmlndXJl ZCB0ZW1wbGF0ZXMgd2l0aCBkYXRhIHRoYXQgcmVsYXRlcyB0byB0aGUgc3BlY2lmaWMgaW5zdGFu Y2UgKAplLmcuIHNvbWV0aGluZyBhcyBzaW1wbGUgYXMgd2VhdmluZyB0aGUgbGluayBhbmQgbmFt ZSBvZiB0aGUgY3JlYXRpdmUgY29tbW9ucyBsaWNlbnNlZCB1c2VkIGZvciBhIHBhcnRpY3VsYXIg cGFnZSwgb3IgYXMgY29tcGxleCBhcyB3ZWF2aW5nIGludG8gYW4gZW50aXJlIGFwcGxpY2F0aW9u IGFsbCBvZiB0aGUgc3BlY2lmaWMgdXNlci1zcGVjaWZpZWQgc2V0dGluZ3MsIGV0Yy4uLik8L2Rp dj4KCgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRoZSBpZGVhIHdpdGggY29tYmluaW5nIHRoZSBH bG9iYWxDbGlwLWJhc2VkIHdpdGggdGhlIEF0b21pY1hNTC1iYXNlIGlzIHRvIGFsbG93IGZvbGtz IHRvIGJlIGFibGUgdG8gc2hhcmUgdGhlIHNvdXJjZSBmb3IgYSBwYXJ0aWN1bGFyIHNpdGUsIHBh Z2UsJm5ic3A7b3IgZWxlbWVudCBvZiB0aGF0IHNpdGUvcGFnZSwgY29weSBpdCB0byB0aGVpciBj bGlwYm9hcmQsIGFuZCB0aGVuIHBhc3RlIGl0IGludG8gZWl0aGVyIGFub3RoZXIgc2l0ZSAocHJl LWV4aXN0aW5nIEF0b21pY1hNTC1iYXNlZCBzaXRlKSBvciBjcmVhdGUgYSBicmFuZCBuZXcgc2l0 ZSBiYXNlZCBvbiB0aGUgdGVtcGxhdGUgb24gdGhlIGNsaXBib2FyZCB3aGljaCB3b3VsZCB0aGVu IGFjY2VzcyBhbGwgb2YgdGhlIHJlZmVyZW5jZWQgcmVzb3VyY2VzLCB3ZWF2ZSBpdCB0b2dldGhl ciB3aXRoIGFueSBwcmUtY29uZmlndXJlZCB1c2VyIGRhdGEsIGFuZCBtYWtlIHRoaXMgc2l0ZSBh dmFpbGFibGUgaW1tZWRpYXRlbGx5IHVwb24gZmluaXNoaW5nIHRoZSBidWlsZCBvdXQgb2YgdGhp cyBwYXJ0aWN1bGFyIGluc3RhbmNlLgo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5JZiB5 b3UgdmlzaXQgdGhlIGFib3ZlIGxpbmtlZCZuYnNwO2RlbW8gaW50ZXJmYWNlIGl0IHNob3VsZCBi ZSBhIGJpdCBtb3JlIGNsZWFyIGFzIHRvIHdoYXQgdGhlIGNvbnRlbnQgb2YgdGhhdCBkZW1vIHdp bGwgZXZlbnR1YWxseSBtYWtlIGF2YWlsYWJsZSB0byB2aXNpdG9ycy48L2Rpdj4KPGRpdj4mbmJz cDs8L2Rpdj4KPGRpdj5JIHdvbid0IGdldCBhcyBmYXIgYXMgYSBmdWxsIGltcGxlbWVudGF0aW9u IG9mIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiB0b2RheSwgYnV0IEkgd2lsbCBoYXZlIGl0IHRvIHRo ZSBwb2ludCBvZiBjb3B5aW5nIGNsaXBib2FyZCBkYXRhLCBwYXN0aW5nIGl0IHRvIHRoZSBHbG9i YWxDbGlwIGluc3RhbmNlIChjdXJyZW50bHkgUzMsIGV2ZW50dWFsbHksIGFueSBzdG9yYWdlIG1l ZGl1bSAoCmUuZy4gR0RyaXZlLCBMaXZlRHJpdmUsIEFueU90aGVyRHJpdmUgaW5jbHVkaW5nIHlv dXIgbG9jYWwgaGFyZCBkcml2ZSkpIGFuZCB0aGVuIGxpc3RpbmcgdGhlIGRhdGEgb24gdGhlIGNs aXBib2FyZC48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5JJ2xsIHBpbmcgYmFjayB0aGlz IHRocmVhZCBsYXRlciB0b2RheSB3aGVuIGl0cyByZWFkeSB0byB2aWV3IGFuZCBwbGF5IHdpdGgu PGJyPjxicj4mbmJzcDs8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjxz cGFuIGNsYXNzPSJlIiBpZD0icV8xMGIwNGRjYTEwNTdlYjE2XzEiPgo8ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gNS81LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Um9i ZXJ0IFNheXJlPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNheXJlckBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+c2F5cmVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOgo8L3NwYW4+CjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdi KDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6 IDFleDsiPjxicj5JJ3ZlIGJlZW4gd29ya2luZyB0byBhZGQgQXRvbSBzdXBwb3J0IHRvIEZpcmVm b3ggMi4gU29tZSBvdGhlciBGaXJlZm94PGJyPmRldnMgYXJlIHRveWluZyB3aXRoIGV4cG9zaW5n IGludGVybmFsIGRhdGEgbGlrZSBoaXN0b3J5IGFuZCBib29rbWFya3MKPGJyPmFzIEF0b20gZmVl ZHMuPGJyPjxicj5XaGF0IHNvZnR3YXJlIGFyZSB5b3Ugd3JpdGluZz88YnI+PGJyPi0tPGJyPjxi cj5Sb2JlcnQgU2F5cmU8YnI+PGJyPiZxdW90O0kgd291bGQgaGF2ZSB3cml0dGVuIGEgc2hvcnRl ciBsZXR0ZXIsIGJ1dCBJIGRpZCBub3QgaGF2ZSB0aGUgdGltZS4mcXVvdDs8YnI+PGJyPjwvYmxv Y2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPgo8YnI+PC9zcGFuPjwvZGl2PjxkaXYg c3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+Ci0tIDxicj4mbHQ7TTpELyZndDs8YnI+PC9kaXY+PGRp diBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Ij48c3BhbiBjbGFzcz0ic2ciPjxicj5NLiBEYXZpZCBQ ZXRlcnNvbjxicj48YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iIHRhcmdldD0iX2Js YW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20vCjwvYT4gCjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPiZsdDtNOkQvJmd0Ozxicj48 YnI+TS4gRGF2aWQgUGV0ZXJzb248YnI+PGEgaHJlZj0iaHR0cDovL3d3dy54c2x0YmxvZy5jb20v Ij5odHRwOi8vd3d3LnhzbHRibG9nLmNvbS88L2E+Cg== ------=_Part_23410_33249211.1146887629663-- From owner-atom-syntax@mail.imc.org Sat May 06 22:08:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcYhb-00072v-Qb for atompub-archive@lists.ietf.org; Sat, 06 May 2006 22:08:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcYhZ-0007N1-Dm for atompub-archive@lists.ietf.org; Sat, 06 May 2006 22:08:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k471wCPk054994; Sat, 6 May 2006 18:58:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k471wC9I054993; Sat, 6 May 2006 18:58:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k471wBKh054987 for ; Sat, 6 May 2006 18:58:11 -0700 (MST) (envelope-from jtauber@jtauber.com) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id D8050D58BA7; Sat, 6 May 2006 21:58:09 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Sat, 06 May 2006 21:58:11 -0400 X-Sasl-enc: X5VqoKHq86ExQgWszP/9IWnJXCvMM/fHd/4jrVVh5K6u 1146967090 Received: from [198.18.100.111] (unknown [65.91.105.130]) by mail.messagingengine.com (Postfix) with ESMTP id AE09F4C9E; Sat, 6 May 2006 21:58:10 -0400 (EDT) In-Reply-To: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <96DBDF27-B7C2-469A-AC68-4A894EB3DCEA@jtauber.com> Cc: "Atom Syntax" Content-Transfer-Encoding: 7bit From: James Tauber Subject: Re: What Atom software are you working on? Date: Sat, 6 May 2006 21:58:07 -0400 To: Robert Sayre X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Demokritos - APP server and Python library. http://jtauber.com/demokritos Currently implementing basic auth support for 0.4 release. Also recently started on a AJAX-based APP client to go with it. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ On 05/05/2006, at 9:11 AM, Robert Sayre wrote: > > I've been working to add Atom support to Firefox 2. Some other Firefox > devs are toying with exposing internal data like history and bookmarks > as Atom feeds. > > What software are you writing? > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > From owner-atom-syntax@mail.imc.org Sun May 07 16:14:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcpdq-0004CP-MO for atompub-archive@lists.ietf.org; Sun, 07 May 2006 16:14:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcpdn-0007HE-0I for atompub-archive@lists.ietf.org; Sun, 07 May 2006 16:14:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k47Jxe0w002507; Sun, 7 May 2006 12:59:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k47JxdvV002506; Sun, 7 May 2006 12:59:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k47Jxckq002500 for ; Sun, 7 May 2006 12:59:39 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so1018729nzf for ; Sun, 07 May 2006 12:59:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rclAiQFMYUZ1gb8DfEp3RIPHBjCS5Kr3Z5aIrWeAbfewsXCh0tVg+vwtigNGpwNbrXqqvLOttsQbz+6WiuPVM80teVXtwXxAsPfJv8VuuJRAKHO80eAShu4B3XA1fOsJXZRtHttWXIwp/s0yv4bO1luN0L9CMaIj/K0aF2hmc6Q= Received: by 10.65.216.2 with SMTP id t2mr665525qbq; Sun, 07 May 2006 12:59:06 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Sun, 7 May 2006 12:59:06 -0700 (PDT) Message-ID: Date: Sun, 7 May 2006 13:59:06 -0600 From: "M. David Peterson" To: "James Tauber" Subject: Re: What Atom software are you working on? Cc: "Robert Sayre" , "Atom Syntax" , "Bruce D'Arcus" , "Sean Lyndersay" In-Reply-To: <96DBDF27-B7C2-469A-AC68-4A894EB3DCEA@jtauber.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39713_18106468.1147031946071" References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> <96DBDF27-B7C2-469A-AC68-4A894EB3DCEA@jtauber.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 ------=_Part_39713_18106468.1147031946071 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline PiBBbHNvIHJlY2VudGx5IHN0YXJ0ZWQgb24gYSBBSkFYLWJhc2VkIEFQUCBjbGllbnQgdG8gZ28g d2l0aCBpdC4KClZlcnkgY29vbCEgIFRoaXMgaXMgc29tZXRoaW5nIEkgY2FuIGhlbHAgd2l0aCBp ZiBuZWVkcyBiZS4uLiAgSSdtIHN0aWxsCnRyeWluZyB0byBnZXQgbXkgbGVncyBpbiBQeXRob24s IGFuZCB3aXRoIHNvbWUgbWlzc2luZyBob2xlcyBpbiBJcm9uUHl0aG9uCnRvIGFsbG93IERlbW9r cml0b3MgdG8gcnVuIG5hdGl2ZWx5IGhhdmUgaGVsZCB0aGUgQXRvbWljUlNTLk5FVCBwcm9qZWN0 IG9mZgpmb3Igbm93IGFuZCBtb3ZlZCBmb3J3YXJkIHdpdGggR2xvYmFsQ2xpcC4KCkp1c3QgdG8g Y29ubmVjdCB0aGUgZG90cywgaWRlYWxseSBJIHdvdWxkIGxpa2UgdG8gY291cGxlIHN1cHBvcnQg Zm9yIEFQUAppbnRvIEdsb2JhbENsaXAsIGFzIHRoZSBhYmlsaXR5IHRvIGNvcHkgdGV4dCBmcm9t IGEgYmxvZyBlbnRyeSwgc3VjayBpbiBhbGwKb2YgdGhlIG5lY2Vzc2FyeSBtZXRhLWRhdGEsIHRv IHRoZW4gcGFzdGUgdGhpcyBpbnRvIGEgYmxvZyBlbnRyeSwgb3IKYSByZXNlYXJjaCBwYXBlciwg b3IgYW55dGhpbmcgZWxzZSB0aGF0IG9uZSBtaWdodCB3YW50IHRvIG1ha2UgcmVmZXJlbmNlCnRv IHNvbWV0aGluZyBlbHNlIG9uIHRoZSB3ZWIsIHNlZW1zIHRvIG1hdGNoIHdlbGwgd2l0aCB3aGF0 IEFQUCBpcyBhbGwKYWJvdXQuICBPZiBjb3Vyc2UsIHRoZSBtZXRhLWRhdGEgd291bGQgaW5jbHVk ZSBhdCB2ZXJ5IGxlYXN0IHRoZSByZWZlcmVuY2UKVVJJIChyZWFkOiBub2JvZHkgaGFzIHRvIGRv IGFueXRoaW5nIGV4Y2VwdCBwb3N0IHNvbWV0aGluZyB0byB0aGUgd2ViLCBhbmQKdGhpcyBpcyBl bm91Z2ggaW5mb3JtYXRpb24gdG8gYXQgdmVyeSBsZWFzdCBlbnN1cmUgcHJvcGVyIGNyZWRpdCB0 byB0aGUKcmVmZXJlbmNpbmcgVVJJIGlzIGVuY2xvc2VkLikgYnV0IHdvdWxkIGhvcGVmdWxseSBj b250YWluIGFsbCB0aGUgcHJvcGVyCmNvcHlyaWdodCBpbmZvcm1hdGlvbiwgd2hldGhlciB0aGlz IGJlIGEgQ3JlYXRpdmUgQ29tbW9ucyBsaWNlbnNlIG9yCnNvbWV0aGluZyBlbHNlIGFsbCB0b2dl dGhlciwgYXMgd2VsbCBhcyBvdGhlciByZWxhdGVkIG1ldGEtZGF0YSwgc3VjaCBhcwp0aGF0IGZv dW5kIGluIHRoZSB3b3JsZCBvZiBjaXRhdGlvbnMuCgpJJ3ZlIGNvcGllZCBCcnVjZSBEJ0FyY3Vz IG9uIHRoaXMgYXMgaGUgYW5kIEkgaGF2ZSBiZWVuIHRhbGtpbmcgYWJvdXQKYnVpbGRpbmcgaW50 byB0aGUgTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlwIGV4dGVuc2lvbiBvZmZlcmluZ3MgdGhlIGFi aWxpdHkKdG8gaW1wbGVtZW50IHN1cHBvcnQgZm9yIGNvbXBsZXRlIGNpdGF0aW9uIG1ldGEtZGF0 YSB0byB0aGVuIGJ1aWxkIHRoZQpuZWNlc3NhcnkgY29ubmVjdG9yIHRvIGVuYWJsZSBhIHNpbXBs ZSBwYXN0ZSBvcGVyYXRpb24gaW5zaWRlIG9mIGEgV29yZApkb2N1bWVudCAoT0RGIHZpYSBPTy5v IGlzIG9idmlvdXMsIGdpdmVuIHRoZSBmYWN0IHRoYXQgQnJ1Y2UgaXMgYSBwYXJ0IG9mCmxlYWRp bmcgdGhpcyBlZmZvcnQgYWxyZWFkeSkuCgoqQnJ1Y2UqOiBIYXZlIGEgbG9vayBACmh0dHA6Ly9l eHRmLm5ldC9TYXhvbi9kb3RuZXQvQVNQLk5FVC9MaXZlQ2xpcGJvYXJkL0dsb2JhbENsaXAvIGFz IHdlbGwgYXMKaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvR2xvYmFsQ2xpcCBp ZiB5b3UgaGF2ZW4ndCBzZWVuIHRoZW0KcmVjZW50bHkuLi4gSSB0aGluayB3ZSdyZSBhYm91dCBy ZWFkeSB0byBzdGFydCBleHBhbmRpbmcgaW50byB0aGUgY2l0YXRpb25zCnNpZGUgb2YgdGhpcy4K CkNvbm5lY3RpbmcgdGhpcyBiYWNrIHRvIHRoZSBBdG9taWNSU1MuTkVUIHByb2plY3QgKG9yIHdo YXRldmVyIHRoZSBmaW5hbApuYW1lIHR1cm5zIG91dCB0byBiZSAoTk9URTogSSd2ZSBvZmZpY2lh bGx5IG1vdmVkIHRoaXMgcHJvamVjdCB0bwpleHRlbnNpYmxlZm9yZ2Ugd2hpY2ggaXMgdGhlIG5l dyBob21lIG9mIEFMTCBvZiBteSBvbmdvaW5nIHByb2plY3RzIDopID4KaHR0cDovL2Rldi5leHRl bnNpYmxlZm9yZ2UubmV0L3dpa2kvQXRvbWljUlNTLk5FVCApLCB0aGUgYWJpbGl0eSB0byB0dXJu IHRoZQpNUyBXZWIgRmVlZCBlbmdpbmUgaW50byBhbiBBUFAgZGF0YSBzdG9yZSBpcyBzaW1wbGUg ZW5vdWdoLiAgQnV0IHVzaW5nCkRlbW9rcml0b3MgYXMgdGhlIHByaW1hcnkgZGF0YSBzdG9yZSwg YW5kIHN5bmNyb25pemluZyB3aXRoIHRoZSBXZWIgRmVlZAplbmdpbmUgYnJpbmdzIGFsbCBvZiB0 aGUgd29uZGVyZnVsbmVzcyB0aGF0IGNvbWVzIGFsb25nIHdpdGggdGhlIHBlcnNpc3RlbmNlCmxh eWVyIHZpYSBTVk4gKGFuZCB0aGVyZWZvcmUgaGlzdG9yaWNhbCBwZXJzaXN0ZW5jZSwgYXMgbG9u ZyBhcyBJIHVuZGVyc3RhbmQKY29ycmVjdGx5IGhvdyBEZW1va3JpdG8ncyBoYW5kbGVzIHBlcnNp c3RlbmNlIHZpYSBTVk4pIHRoYXRzIGJ1aWx0IGRpcmVjdGx5CmludG8gRGVtb2tyaXRvcy4KClVu bGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcgWwpodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2xp YnJhcnkvZGVmYXVsdC5hc3A/dXJsPS9saWJyYXJ5L2VuLXVzL2ZlZWRzYXBpL3Jzcy9vdmVydmll d3MvbXNmZWVkc19vdncuYXNwXQp0aGVyZSBpcyBubyBkaXJlY3QgY29uY2VwdCBvZiBoaXN0b3Jp Y2FsIHBlcnNpc3RlbmNlIGluIHRoZSBXZWIgRmVlZCBlbmdpbmUuCgoqU2VhbiAqKGFsc28gY29w aWVkKSwgY2FuIHlvdSBjbGFyaWZ5IHRoaXMgb25lIHdheSBvciB0aGUgb3RoZXI/CgpPbiA1LzYv MDYsIEphbWVzIFRhdWJlciA8anRhdWJlckBqdGF1YmVyLmNvbT4gd3JvdGU6Cj4KPgo+IERlbW9r cml0b3MgLSBBUFAgc2VydmVyIGFuZCBQeXRob24gbGlicmFyeS4KPgo+IGh0dHA6Ly9qdGF1YmVy LmNvbS9kZW1va3JpdG9zCj4KPiBDdXJyZW50bHkgaW1wbGVtZW50aW5nIGJhc2ljIGF1dGggc3Vw cG9ydCBmb3IgMC40IHJlbGVhc2UuCj4KPiBBbHNvIHJlY2VudGx5IHN0YXJ0ZWQgb24gYSBBSkFY LWJhc2VkIEFQUCBjbGllbnQgdG8gZ28gd2l0aCBpdC4KPgo+IEphbWVzCj4gLS0KPiBKYW1lcyBU YXViZXIgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9qdGF1YmVyLmNvbS8KPiBqb3VybmV5 bWFuIG9mIHNvbWUgICBodHRwOi8vanRhdWJlci5jb20vYmxvZy8KPgo+Cj4gT24gMDUvMDUvMjAw NiwgYXQgOToxMSBBTSwgUm9iZXJ0IFNheXJlIHdyb3RlOgo+Cj4gPgo+ID4gSSd2ZSBiZWVuIHdv cmtpbmcgdG8gYWRkIEF0b20gc3VwcG9ydCB0byBGaXJlZm94IDIuIFNvbWUgb3RoZXIgRmlyZWZv eAo+ID4gZGV2cyBhcmUgdG95aW5nIHdpdGggZXhwb3NpbmcgaW50ZXJuYWwgZGF0YSBsaWtlIGhp c3RvcnkgYW5kIGJvb2ttYXJrcwo+ID4gYXMgQXRvbSBmZWVkcy4KPiA+Cj4gPiBXaGF0IHNvZnR3 YXJlIGFyZSB5b3Ugd3JpdGluZz8KPiA+Cj4gPiAtLQo+ID4KPiA+IFJvYmVydCBTYXlyZQo+ID4K PiA+ICJJIHdvdWxkIGhhdmUgd3JpdHRlbiBhIHNob3J0ZXIgbGV0dGVyLCBidXQgSSBkaWQgbm90 IGhhdmUgdGhlIHRpbWUuIgo+ID4KPgo+CgoKLS0KPE06RC8+CgpNLiBEYXZpZCBQZXRlcnNvbgpo dHRwOi8vd3d3LnhzbHRibG9nLmNvbS8K ------=_Part_39713_18106468.1147031946071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4mZ3Q7IEFsc28gcmVjZW50bHkgc3RhcnRlZCBvbiBhIEFKQVgtYmFzZWQgQVBQIGNsaWVu dCB0byBnbyB3aXRoIGl0LjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlZlcnkgY29vbCEm bmJzcDsgVGhpcyBpcyBzb21ldGhpbmcgSSBjYW4gaGVscCB3aXRoIGlmIG5lZWRzIGJlLi4uJm5i c3A7IEknbSBzdGlsbCB0cnlpbmcgdG8gZ2V0IG15IGxlZ3MgaW4gUHl0aG9uLCBhbmQgd2l0aCBz b21lIG1pc3NpbmcgaG9sZXMgaW4gSXJvblB5dGhvbiB0byBhbGxvdyBEZW1va3JpdG9zIHRvIHJ1 biBuYXRpdmVseSBoYXZlIGhlbGQgdGhlIEF0b21pY1JTUy5ORVQgcHJvamVjdCBvZmYgZm9yIG5v dyBhbmQgbW92ZWQgZm9yd2FyZCB3aXRoIEdsb2JhbENsaXAuIAo8L2Rpdj4KPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj5KdXN0IHRvIGNvbm5lY3QgdGhlIGRvdHMsIGlkZWFsbHkgSSB3b3VsZCBsaWtl IHRvIGNvdXBsZSBzdXBwb3J0IGZvciBBUFAgaW50byBHbG9iYWxDbGlwLCBhcyB0aGUgYWJpbGl0 eSB0byBjb3B5IHRleHQgZnJvbSZuYnNwO2EgYmxvZyBlbnRyeSwgc3VjayBpbiBhbGwgb2YgdGhl IG5lY2Vzc2FyeSBtZXRhLWRhdGEsIHRvIHRoZW4gcGFzdGUgdGhpcyZuYnNwO2ludG8gYSBibG9n IGVudHJ5LCBvciBhJm5ic3A7cmVzZWFyY2ggcGFwZXIsIG9yJm5ic3A7YW55dGhpbmcgZWxzZSB0 aGF0IG9uZSBtaWdodCB3YW50IHRvIG1ha2UgcmVmZXJlbmNlIHRvJm5ic3A7c29tZXRoaW5nIGVs c2Ugb24gdGhlIHdlYiwgc2VlbXMgdG8gbWF0Y2ggd2VsbCB3aXRoIHdoYXQgQVBQIGlzIGFsbCBh Ym91dC4mbmJzcDsgT2YgY291cnNlLCB0aGUgbWV0YS1kYXRhIHdvdWxkIGluY2x1ZGUgYXQgdmVy eSBsZWFzdCB0aGUgcmVmZXJlbmNlIFVSSSAocmVhZDogbm9ib2R5IGhhcyB0byBkbyBhbnl0aGlu ZyBleGNlcHQgcG9zdCBzb21ldGhpbmcgdG8gdGhlIHdlYiwgYW5kIHRoaXMgaXMgZW5vdWdoIGlu Zm9ybWF0aW9uIHRvIGF0IHZlcnkgbGVhc3QgZW5zdXJlIHByb3BlciBjcmVkaXQgdG8gdGhlIHJl ZmVyZW5jaW5nIFVSSSBpcyBlbmNsb3NlZC4pIGJ1dCB3b3VsZCBob3BlZnVsbHkgY29udGFpbiBh bGwgdGhlIHByb3BlciBjb3B5cmlnaHQgaW5mb3JtYXRpb24sIHdoZXRoZXIgdGhpcyBiZSBhIENy ZWF0aXZlIENvbW1vbnMgbGljZW5zZSBvciBzb21ldGhpbmcgZWxzZSBhbGwgdG9nZXRoZXIsIGFz IHdlbGwgYXMgb3RoZXIgcmVsYXRlZCBtZXRhLWRhdGEsIHN1Y2ggYXMgdGhhdCBmb3VuZCBpbiB0 aGUgd29ybGQgb2YgY2l0YXRpb25zLiZuYnNwOwo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRp dj5JJ3ZlIGNvcGllZCBCcnVjZSBEJ0FyY3VzIG9uIHRoaXMgYXMgaGUgYW5kIEkgaGF2ZSBiZWVu IHRhbGtpbmcgYWJvdXQgYnVpbGRpbmcgaW50byB0aGUgTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlw IGV4dGVuc2lvbiZuYnNwO29mZmVyaW5ncyB0aGUgYWJpbGl0eSB0byBpbXBsZW1lbnQgc3VwcG9y dCBmb3IgY29tcGxldGUgY2l0YXRpb24gbWV0YS1kYXRhIHRvIHRoZW4gYnVpbGQgdGhlIG5lY2Vz c2FyeSBjb25uZWN0b3IgdG8gZW5hYmxlIGEgc2ltcGxlIHBhc3RlIG9wZXJhdGlvbiBpbnNpZGUg b2YgYSBXb3JkIGRvY3VtZW50IChPREYgdmlhIApPTy5vIGlzIG9idmlvdXMsIGdpdmVuIHRoZSBm YWN0IHRoYXQgQnJ1Y2UgaXMgYSBwYXJ0IG9mIGxlYWRpbmcgdGhpcyBlZmZvcnQgYWxyZWFkeSku PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+PHN0cm9uZz5CcnVjZTwvc3Ryb25nPjogSGF2 ZSBhIGxvb2sgQCA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL2V4dGYubmV0L1NheG9uL2RvdG5ldC9BU1AuTkVUL0xp dmVDbGlwYm9hcmQvR2xvYmFsQ2xpcC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXh0Zi5uZXQv U2F4b24vZG90bmV0L0FTUC5ORVQvTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlwLwo8L2E+Jm5ic3A7 YXMgd2VsbCBhcyA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvR2xv YmFsQ2xpcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kZXYuZXh0ZW5zaWJsZWZvcmdlLm5ldC93 aWtpL0dsb2JhbENsaXA8L2E+Jm5ic3A7aWYgeW91IGhhdmVuJ3Qgc2VlbiB0aGVtIHJlY2VudGx5 Li4uIEkgdGhpbmsgd2UncmUgYWJvdXQgcmVhZHkgdG8gc3RhcnQgZXhwYW5kaW5nIGludG8gdGhl IGNpdGF0aW9ucyBzaWRlIG9mIHRoaXMuCjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkNv bm5lY3RpbmcgdGhpcyBiYWNrIHRvIHRoZSBBdG9taWNSU1MuTkVUIHByb2plY3QgKG9yIHdoYXRl dmVyIHRoZSBmaW5hbCBuYW1lIHR1cm5zIG91dCB0byBiZSAoTk9URTogSSd2ZSBvZmZpY2lhbGx5 IG1vdmVkIHRoaXMgcHJvamVjdCB0byBleHRlbnNpYmxlZm9yZ2Ugd2hpY2ggaXMgdGhlIG5ldyBo b21lIG9mIEFMTCBvZiBteSBvbmdvaW5nIHByb2plY3RzIDopJm5ic3A7Jmd0OyAKPGEgaHJlZj0i aHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvQXRvbWljUlNTLk5FVCI+aHR0cDov L2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3dpa2kvQXRvbWljUlNTLk5FVDwvYT4mbmJzcDspLCB0 aGUgYWJpbGl0eSB0byB0dXJuIHRoZSBNUyBXZWIgRmVlZCBlbmdpbmUgaW50byBhbiBBUFAgZGF0 YSBzdG9yZSBpcyBzaW1wbGUmbmJzcDtlbm91Z2guJm5ic3A7IEJ1dCZuYnNwO3VzaW5nIERlbW9r cml0b3MgYXMgdGhlIHByaW1hcnkmbmJzcDtkYXRhIHN0b3JlLCBhbmQmbmJzcDtzeW5jcm9uaXpp bmcmbmJzcDt3aXRoIHRoZSBXZWIgRmVlZCBlbmdpbmUgYnJpbmdzIGFsbCBvZiB0aGUgd29uZGVy ZnVsbmVzcyZuYnNwO3RoYXQgY29tZXMgYWxvbmcgd2l0aCB0aGUgcGVyc2lzdGVuY2UgbGF5ZXIg dmlhIFNWTiAoYW5kIHRoZXJlZm9yZSBoaXN0b3JpY2FsIHBlcnNpc3RlbmNlLCBhcyBsb25nIGFz IEkmbmJzcDt1bmRlcnN0YW5kIGNvcnJlY3RseSBob3cgRGVtb2tyaXRvJ3MgaGFuZGxlcyZuYnNw O3BlcnNpc3RlbmNlIHZpYSBTVk4pJm5ic3A7dGhhdHMgYnVpbHQgZGlyZWN0bHkgaW50byBEZW1v a3JpdG9zLgo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5Vbmxlc3MgSSdtIG1pc3Npbmcg c29tZXRoaW5nIFs8YSBocmVmPSJodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2xpYnJhcnkvZGVm YXVsdC5hc3A/dXJsPS9saWJyYXJ5L2VuLXVzL2ZlZWRzYXBpL3Jzcy9vdmVydmlld3MvbXNmZWVk c19vdncuYXNwIj5odHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2xpYnJhcnkvZGVmYXVsdC5hc3A/ dXJsPS9saWJyYXJ5L2VuLXVzL2ZlZWRzYXBpL3Jzcy9vdmVydmlld3MvbXNmZWVkc19vdncuYXNw CjwvYT5dIHRoZXJlIGlzIG5vIGRpcmVjdCBjb25jZXB0IG9mJm5ic3A7aGlzdG9yaWNhbCBwZXJz aXN0ZW5jZSBpbiB0aGUgV2ViIEZlZWQgZW5naW5lLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8 ZGl2PjxzdHJvbmc+U2VhbiA8L3N0cm9uZz4oYWxzbyBjb3BpZWQpLCBjYW4geW91IGNsYXJpZnkg dGhpcyBvbmUgd2F5IG9yIHRoZSBvdGhlcj88YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiA1LzYvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5K YW1lcyBUYXViZXI8L2I+ICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5r KHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOmp0YXViZXJAanRhdWJlci5jb20iIHRh cmdldD0iX2JsYW5rIj5qdGF1YmVyQGp0YXViZXIuY29tPC9hPgomZ3Q7IHdyb3RlOjwvc3Bhbj4g CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4 OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQi Pjxicj5EZW1va3JpdG9zIC0gQVBQIHNlcnZlciBhbmQgUHl0aG9uIGxpYnJhcnkuPGJyPjxicj48 YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIg aHJlZj0iaHR0cDovL2p0YXViZXIuY29tL2RlbW9rcml0b3MiIHRhcmdldD0iX2JsYW5rIj4KaHR0 cDovL2p0YXViZXIuY29tL2RlbW9rcml0b3MgPC9hPjxicj48YnI+Q3VycmVudGx5IGltcGxlbWVu dGluZyBiYXNpYyBhdXRoIHN1cHBvcnQgZm9yIDAuNCByZWxlYXNlLjxicj48YnI+QWxzbyByZWNl bnRseSBzdGFydGVkIG9uIGEgQUpBWC1iYXNlZCBBUFAgY2xpZW50IHRvIGdvIHdpdGggaXQuPGJy Pjxicj5KYW1lczxicj4tLTxicj5KYW1lcyBUYXViZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCjxhIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVm PSJodHRwOi8vanRhdWJlci5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2p0YXViZXIuY29t LzwvYT48YnI+am91cm5leW1hbiBvZiBzb21lJm5ic3A7Jm5ic3A7IDxhIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwOi8vanRh dWJlci5jb20vYmxvZy8iIHRhcmdldD0iX2JsYW5rIj4KaHR0cDovL2p0YXViZXIuY29tL2Jsb2cv PC9hPjxicj48YnI+PGJyPk9uIDA1LzA1LzIwMDYsIGF0IDk6MTEgQU0sIFJvYmVydCBTYXlyZSB3 cm90ZTo8YnI+PGJyPiZndDs8YnI+Jmd0OyBJJ3ZlIGJlZW4gd29ya2luZyB0byBhZGQgQXRvbSBz dXBwb3J0IHRvIEZpcmVmb3ggMi4gU29tZSBvdGhlciBGaXJlZm94IDxicj4mZ3Q7IGRldnMgYXJl IHRveWluZyB3aXRoIGV4cG9zaW5nIGludGVybmFsIGRhdGEgbGlrZSBoaXN0b3J5IGFuZCBib29r bWFya3MKPGJyPiZndDsgYXMgQXRvbSBmZWVkcy48YnI+Jmd0Ozxicj4mZ3Q7IFdoYXQgc29mdHdh cmUgYXJlIHlvdSB3cml0aW5nPzxicj4mZ3Q7PGJyPiZndDsgLS08YnI+Jmd0Ozxicj4mZ3Q7IFJv YmVydCBTYXlyZTxicj4mZ3Q7PGJyPiZndDsgJnF1b3Q7SSB3b3VsZCBoYXZlIHdyaXR0ZW4gYSBz aG9ydGVyIGxldHRlciwgYnV0IEkgZGlkIG5vdCBoYXZlIHRoZSB0aW1lLiZxdW90OyA8YnI+Jmd0 Owo8YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8 YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5NLiBEYXZpZCBQZXRlcnNvbjxicj48YSBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cDov L3d3dy54c2x0YmxvZy5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy54c2x0YmxvZy5j b20vCjwvYT4gCg== ------=_Part_39713_18106468.1147031946071-- From owner-atom-syntax@mail.imc.org Mon May 08 10:15:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6W8-0001aC-DI for atompub-archive@lists.ietf.org; Mon, 08 May 2006 10:15:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6W7-0002vq-Kv for atompub-archive@lists.ietf.org; Mon, 08 May 2006 10:15:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48E1GiL046098; Mon, 8 May 2006 07:01:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48E1GlR046097; Mon, 8 May 2006 07:01:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48E1ECR046090 for ; Mon, 8 May 2006 07:01:15 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1Fd6IT-0006D2-QJ; Mon, 08 May 2006 16:01:13 +0200 Received: from ultra12.rbg.informatik.tu-darmstadt.de ([130.83.160.102]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1Fd6IT-0000sU-Ll; Mon, 08 May 2006 16:01:13 +0200 Message-ID: <445F4F21.6030401@rbg.informatik.tu-darmstadt.de> Date: Mon, 08 May 2006 16:01:05 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Atom-Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Thomas Broyer wrote: > Andreas Sewe wrote: >> If the value of the "steps" attribute is "continuous" the set of rank >> values defined by the r:values element is >> >> { x | minimum <= x <= maximum }. > > And @origin is ignored? Well, it is not really ignored but irrelevant, since a value for @steps of "continuous" can be read as making infinitesimal steps. And then @origin doesn't really matter. You are covering the entire real line, no matter where you start -- but of course @minimum and @maximum have a say in this, too. (Note that defaulting @origin to 0 does no harm, though. No need to make that another special case.) >> Otherwise the set of rank values defined by the r:values element is >> >> { x | minimum <= x <= maximum, >> x = (origin + i * steps) for some integer i }. > > If "i" and "steps" are positive values, then "x" will always be > superior to "origin". Note that i is assumed to be an integer, not a natural number; it can be negative. You are right, however, with your observation that a negative value for "steps" should be disallowed. As James already replied, the next revision of the spec will rectify this. > If "origin" is superior to "minimum", then "minimum" is not needed, as > "origin" *is* the minimum value. > If "origin" is less than "minimum", then "x" will always be superior > to "origin + i*steps" for which "i" is the minimum integer value > verifying "origin + i*steps >= minimum"; this is quite easy to > compute, so there's no real need for "minimum" either in this case: > the following r:values are all equivalent: > > > > [...] > So: there is no need for "origin" and negative "steps" values. I agree about the negative @steps. @origin is useful, however, even when its use can be optimized away in some cases. This is because the above conversion will not work if @minimum is "unbounded". As you recognized yourself below you, to describe the set {..., -2.7, -1,7, -0.7, +0.3, +1.7, +2,7, ...}, you need Note that @minimum defaults to "unbounded" -- and is thus not even needed in the above definition. This is precisely to allow this case to be written concisely. (For similar reasons @steps defaults to 0, making it easy to define singleton sets. That @minimum and @maximum are -- per default -- still "unbounded" doesn't matter when @steps is 0. Similar reasoning lead to a default of 0 for @origin. In practice you should rarely need to specify all four attributes explicitly.) > There is however one case where that (converting a negative "steps" > value into a positive one) could not be possible: when "minimum" > equals "unbounded". > Couldn't it be spec'd that: > - if "minimum" is provided and not "unbounded", then "steps" counts > upwards from "minimum" to the greatest value inferior to "maximum" > - if "minimum" is not provided or "unbounded", then "steps" counts > downwards from "maximum" to negative infinity. But what about both @minimum and @maximum being "unbounded"? In this case you need an origin. In most other cases, however, you can simply rely on the default of 0. (I expect non-zero origins, except for singleton sets and a few odd cases like {0.3, 1.3, 2.3, ...}, to be quite rare in practice.) > In other words, people transitioning from origin and/or negative-steps > have to do the following: > - if "steps" is negative and "minimum" is not "unbounded", replace > "minimum" with the smallest allowable value and use a positive "steps" > value > - if "steps" is negative and "minimum" is "unbounded", replace > "maximum" with the value of "origin" and use a positive "steps" value > (which will count downwards to negative infinity) > - if "steps" is positive, replace "minimum" with the value of "origin" The first two cases will be eliminated from the next revision of the spec; negative steps are not only counter-intuitive but redundant. The last falsely assumes that i, in (origin + i * steps), is only non-negative. >> The following examples illustrate how different sets of rank values can >> be defined by means of a single r:value element: >> >> >> > > > Could be expressed as: > > or > > or with the following r:values: > All true. This proposal, however, deliberately replaces the two elements r:value and r:range (as present in the current spec) by a single r:values element, with carefully chosen defaults to make all the common use cases just as easy to define. So its purpose is simply to find out which approach -- two elements (r:value really being redundant) or a single one -- is easier to understand and implement. (I guess the workings of the attributes might be a little bit easier to comprehend if I could find a better name, suitable for the singleton set case as well, for @origin. Maybe you have a suggestion.) At any rate, thanks for your comments. Andreas Sewe From owner-atom-syntax@mail.imc.org Mon May 08 10:38:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6sT-0007yj-91 for atompub-archive@lists.ietf.org; Mon, 08 May 2006 10:38:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6sQ-000441-9z for atompub-archive@lists.ietf.org; Mon, 08 May 2006 10:38:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48ENDp6046952; Mon, 8 May 2006 07:23:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48ENDVv046951; Mon, 8 May 2006 07:23:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.exchange.microsoft.com (mail4.exchange.microsoft.com [131.107.1.99]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48ENCBI046942 for ; Mon, 8 May 2006 07:23:12 -0700 (MST) (envelope-from seanlynd@exchange.microsoft.com) Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 07:23:06 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.536.10; Mon, 8 May 2006 07:23:05 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 07:23:05 -0700 X-MS-Exchange-Organization-AuthDomain: From: Sean Lyndersay To: "M. David Peterson" , James Tauber CC: Robert Sayre , Atom Syntax , "Bruce D'Arcus" Date: Mon, 8 May 2006 07:20:33 -0700 Subject: RE: What Atom software are you working on? Thread-Topic: What Atom software are you working on? Thread-Index: AcZyEMnWqJqo/IECSeyFbikYI1/C8AAl80Og Message-ID: <9138FF9DE9175C489F6F5477262E4FA8DDBDD0@DF-TERRIER-MSG.exchange.corp.microsoft.com> References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> <96DBDF27-B7C2-469A-AC68-4A894EB3DCEA@jtauber.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: AcceptLanguage: en-US x-ms-exchange-organization-authmechanism: SecureMapiSubmit x-ms-exchange-organization-authsource: df-bhd-02.exchange.corp.microsoft.com x-ms-exchange-organization-authas: Internal x-recipient-p2-type: Cc Content-Type: multipart/alternative; boundary="_000_9138FF9DE9175C489F6F5477262E4FA8DDBDD0DFTERRIERMSGexcha_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 May 2006 14:23:05.0660 (UTC) FILETIME=[EC081FC0:01C672AA] X-MS-Exchange-Organization-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df --_000_9138FF9DE9175C489F6F5477262E4FA8DDBDD0DFTERRIERMSGexcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Sean (also copied), can you clarify this one way or the other? On the concept of persistence, the feed platform in Windows persists downlo= aded entries from feeds for as long as the user wants them. Nothing more co= mplicated than that. From: M. David Peterson [mailto:xmlhacker@gmail.com] Sent: Sunday, May 07, 2006 12:59 PM To: James Tauber Cc: Robert Sayre; Atom Syntax; Bruce D'Arcus; Sean Lyndersay Subject: Re: What Atom software are you working on? > Also recently started on a AJAX-based APP client to go with it. Very cool! This is something I can help with if needs be... I'm still try= ing to get my legs in Python, and with some missing holes in IronPython to = allow Demokritos to run natively have held the AtomicRSS.NET project off fo= r now and moved forward with GlobalClip. Just to connect the dots, ideally I would like to couple support for APP in= to GlobalClip, as the ability to copy text from a blog entry, suck in all o= f the necessary meta-data, to then paste this into a blog entry, or a resea= rch paper, or anything else that one might want to make reference to someth= ing else on the web, seems to match well with what APP is all about. Of co= urse, the meta-data would include at very least the reference URI (read: no= body has to do anything except post something to the web, and this is enoug= h information to at very least ensure proper credit to the referencing URI = is enclosed.) but would hopefully contain all the proper copyright informat= ion, whether this be a Creative Commons license or something else all toget= her, as well as other related meta-data, such as that found in the world of= citations. I've copied Bruce D'Arcus on this as he and I have been talking about build= ing into the LiveClipboard/GlobalClip extension offerings the ability to im= plement support for complete citation meta-data to then build the necessary= connector to enable a simple paste operation inside of a Word document (OD= F via OO.o is obvious, given the fact that Bruce is a part of leading this = effort already). Bruce: Have a look @ http://extf.net/Saxon/dotnet/ASP.NET/LiveClipboard/Glo= balClip/ as well as http://dev.extensibleforge.net/wiki/GlobalClip if you = haven't seen them recently... I think we're about ready to start expanding = into the citations side of this. Connecting this back to the AtomicRSS.NET project (or whatever the final na= me turns out to be (NOTE: I've officially moved this project to extensiblef= orge which is the new home of ALL of my ongoing projects :) > http://dev.ex= tensibleforge.net/wiki/AtomicRSS.NET ), the ability to turn the MS Web Feed= engine into an APP data store is simple enough. But using Demokritos as t= he primary data store, and syncronizing with the Web Feed engine brings all= of the wonderfulness that comes along with the persistence layer via SVN (= and therefore historical persistence, as long as I understand correctly how= Demokrito's handles persistence via SVN) thats built directly into Demokri= tos. Unless I'm missing something [http://msdn.microsoft.com/library/default.asp= ?url=3D/library/en-us/feedsapi/rss/overviews/msfeeds_ovw.asp ] there is no = direct concept of historical persistence in the Web Feed engine. Sean (also copied), can you clarify this one way or the other? On 5/6/06, James Tauber > = wrote: Demokritos - APP server and Python library. http://jtauber.com/demokritos Currently implementing basic auth support for 0.4 release. Also recently started on a AJAX-based APP client to go with it. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ On 05/05/2006, at 9:11 AM, Robert Sayre wrote: > > I've been working to add Atom support to Firefox 2. Some other Firefox > devs are toying with exposing internal data like history and bookmarks > as Atom feeds. > > What software are you writing? > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > -- M. David Peterson http://www.xsltblog.com/ --_000_9138FF9DE9175C489F6F5477262E4FA8DDBDD0DFTERRIERMSGexcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

> Sean (also copied), can you clar= ify this one way or the other?

 

On the concept of persistence, the feed platform in Wi= ndows persists downloaded entries from feeds for as long as the user wants them. = Nothing more complicated than that.

 

 <= /a>

From:= M. David Peterson [mailto:xmlhacker@gmail.com]
Sent: Sunday, May 07, 2006 12:59 PM
To: James Tauber
Cc: Robert Sayre; Atom Syntax; Bruce D'Arcus; Sean Lyndersay
Subject: Re: What Atom software are you working on?

 

> Also recently started on a AJAX-based APP client = to go with it.

 

Very cool!  This is something I can help with if = needs be...  I'm still trying to get my legs in Python, and with some missin= g holes in IronPython to allow Demokritos to run natively have held the AtomicRSS.NET project off for now and moved forward with GlobalClip. <= /o:p>

 

Just to connect the dots, ideally I would like to coup= le support for APP into GlobalClip, as the ability to copy text from a bl= og entry, suck in all of the necessary meta-data, to then paste this into= a blog entry, or a research paper, or anything else that one might = want to make reference to something else on the web, seems to match well wi= th what APP is all about.  Of course, the meta-data would include at very least the reference URI (read: nobody has to do anything except post someth= ing to the web, and this is enough information to at very least ensure proper credit to the referencing URI is enclosed.) but would hopefully contain all= the proper copyright information, whether this be a Creative Commons license or something else all together, as well as other related meta-data, such as th= at found in the world of citations. 

 

I've copied Bruce D'Arcus on this as he and I have bee= n talking about building into the LiveClipboard/GlobalClip extension off= erings the ability to implement support for complete citation meta-data to then bu= ild the necessary connector to enable a simple paste operation inside of a Word document (ODF via OO.o is obvious, given the fact that Bruce is a part of leading this effort already).

 

Bruce: Have a look @ http://extf.net/Saxon/dotnet/ASP.NET/LiveClipboard/Global= Clip/  as well as http://dev.extensibleforge.net/wiki/GlobalClip if you haven't seen them recently... I think we're about ready to start expand= ing into the citations side of this.

 

Connecting this back to the AtomicRSS.NET project (or whatever the final name turns out to be (NOTE: I've officially moved this project to extensibleforge which is the new home of ALL of my ongoing proje= cts :) > = http://dev.extensibleforge.net/wiki/AtomicRSS.NET ), the ability to turn the MS Web Feed engine into an APP data store is simple enough.  But using Demokritos as the primary dat= a store, and syncronizing with the Web Feed engine brings all of th= e wonderfulness that comes along with the persistence layer via SVN (and therefore historical persistence, as long as I understand correctly ho= w Demokrito's handles persistence via SVN) thats built directly int= o Demokritos.

 

Unless I'm missing something [http://msdn.microsoft.com/library/d= efault.asp?url=3D/library/en-us/feedsapi/rss/overviews/msfeeds_ovw.asp ] there is no direct concept of historical persistence in the Web = Feed engine.

 

Sean (also copied), can you clarify t= his one way or the other?
 

On 5/6/06, James Tauber <jtauber@jtauber.com > wrote:


Demokritos - APP server and Python library.

http://jtauber.= com/demokritos

Currently implementing basic auth support for 0.4 release.

Also recently started on a AJAX-based APP client to go with it.

James
--
James Tauber           &nb= sp;           http://jtauber.com/ journeyman of some   http://jtauber.com/blog/


On 05/05/2006, at 9:11 AM, Robert Sayre wrote:

>
> I've been working to add Atom support to Firefox 2. Some other Firefox=
> devs are toying with exposing internal data like history and bookmarks=
> as Atom feeds.
>
> What software are you writing?
>
> --
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."
>




--
<M:D/>

M. David Peterson
http://www.xsltblog.= com/

--_000_9138FF9DE9175C489F6F5477262E4FA8DDBDD0DFTERRIERMSGexcha_-- From owner-atom-syntax@mail.imc.org Mon May 08 11:12:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7PT-0002DA-UX for atompub-archive@lists.ietf.org; Mon, 08 May 2006 11:12:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7PT-0006Kk-A7 for atompub-archive@lists.ietf.org; Mon, 08 May 2006 11:12:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48F0sUx048338; Mon, 8 May 2006 08:00:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48F0sL8048337; Mon, 8 May 2006 08:00:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48F0qHu048330 for ; Mon, 8 May 2006 08:00:53 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.55.242] (helo=mx9.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1Fd7EB-0007ub-ER; Mon, 08 May 2006 17:00:51 +0200 Received: from ultra12.rbg.informatik.tu-darmstadt.de ([130.83.160.102]) by mx9.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1Fd7EB-0004pA-5z; Mon, 08 May 2006 17:00:51 +0200 Message-ID: <445F5D1F.7060801@rbg.informatik.tu-darmstadt.de> Date: Mon, 08 May 2006 17:00:47 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James M Snell CC: Atom Syntax Subject: Atom Rank Extension Design Issues (was: Feedback on r:value and r:range elements wanted) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> <445B776F.90106@gmail.com> In-Reply-To: <445B776F.90106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.8 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 James M Snell wrote: > Andreas Sewe wrote: >>Now the current draft defines two elements, r:value and r:range, for >>this purpose. Those two elements can be, however, be collapsed into a >>single one, and, with cleverly chosen defaults, defining sets using this >>new r:values element is IMHO as simple, if not simpler, as with the old >>approach. Others might have different opinions, though, which I would >>really like to hear about. > > Just to note, this seems to be the key disagreement between Andreas and > I on the spec. IMHO, for schemes consisting of a constrained set of > fixed absolute values (like the German grading system which uses 1.0, > 1.3, 1.7, 2.0 etc), specifying a collection of overlapping ranges just > doesn't feel right. Yes, the key disagreement is not whether we should use a single element or two (I wrote the original proposal to find out atom-syntax's preference on this), but whether ranges should be allowed to overlap. Actually, we disagree on three overlapping (pun intended) questions: 1.) Does r:scheme define anything beyond a set of valid rank values (and an order on them)? Personally I consider r:scheme's child elements as a specialized datatype definition language; since we know what use cases we want to support, so we can come up with a nice, little language to specify how valid and invalid rank values have to look like. Now James, AFAIK, additionally wants to be able to attach labels to r:values and r:ranges. But r:rank's @label attribute does the same job! The current spec, however, does not state how conflicts are to be resolved. Furthermore, since you can only reasonably stick labels like "Good" on non-overlapping ranges, James wants to disallow overlaps. This somewhat limits the expressiveness of our datatyping mini-language. IMHO, it is entirely reasonable to attach different r:rank @labels to different entries, even if they have been rated the same: 1.5 1.5 In other words, I do not see the need for being able to mechanically look up a label for every value or range. 2.) How do we handle rank values which do not conform to r:schemes definitions. I would simply consider them, r:scheme defining a datatype, as invalid. (Currently this is already done if a rank value is outside the bounds defined by its scheme's minimum and maximum.) James, however, wants to introduce rounding rules: an invalid (as per r:scheme) rank value is rounded to the nearest valid rank value. Here, overlapping ranges make it again difficult for the implementer to determine what the nearest valid value actually is. So James want to disallow them. Admitted, there are real-world examples where being able to use invalid rank values would be nice: The local university, for example, internally uses grades like 1.19. On your diploma they only ever show up as 1.0, 1.3, 1.7, and so on. So why do we require the publisher to throw away some information, namely the exact grade? Because one rounding rule cannot deal with all the bizarre rounding schemes in use at schools and universities worldwide. (The above would be rounded to 1.0, for instance, although 1.3 would be the nearest valid value.) So, allowing rounding does not gain us that much. The receiver has to deal with it nevertheless. 3.) And, when it comes to rounding, the issue of @scale comes up. Do we really need it? I think not; it just complicates things. So, those are the three main design issues we are currently facing (at least those I am aware of) -- and feedback from atom-syntax is really appreciated. Best wishes, Andreas Sewe From owner-atom-syntax@mail.imc.org Mon May 08 11:48:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7n9-0001T8-UD for atompub-archive@lists.ietf.org; Mon, 08 May 2006 11:36:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7gv-00079c-5S for atompub-archive@lists.ietf.org; Mon, 08 May 2006 11:30:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd7R6-000810-Dd for atompub-archive@lists.ietf.org; Mon, 08 May 2006 11:14:16 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48EtcD3048139; Mon, 8 May 2006 07:55:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48EtcxN048138; Mon, 8 May 2006 07:55:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48EtaTO048125 for ; Mon, 8 May 2006 07:55:37 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so1165487nzf for ; Mon, 08 May 2006 07:55:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LqILk4nqge1Gx3c5rRwjM1T6jkyz3BH6J0N1rKR6KmuTzobdj+6iAQIffUMubuMkxtNuCwti92CqvpszMdPLN0k9Agye8bJig2SBwTq1gYFHf8Nge7h8rG3lCVQZN6uXVf08/x7yzDIkaA8NtL93IaSL2MVxVv+mqFXStUUYBzE= Received: by 10.64.232.11 with SMTP id e11mr1019504qbh; Mon, 08 May 2006 07:55:13 -0700 (PDT) Received: by 10.65.210.10 with HTTP; Mon, 8 May 2006 07:55:13 -0700 (PDT) Message-ID: Date: Mon, 8 May 2006 08:55:13 -0600 From: "M. David Peterson" To: "Sean Lyndersay" Subject: Re: What Atom software are you working on? Cc: "James Tauber" , "Robert Sayre" , "Atom Syntax" , "Bruce D'Arcus" In-Reply-To: <9138FF9DE9175C489F6F5477262E4FA8DDBDD0@DF-TERRIER-MSG.exchange.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_51819_29412588.1147100113665" References: <68fba5c50605050611x32511226m92b57d198b57aa9c@mail.gmail.com> <96DBDF27-B7C2-469A-AC68-4A894EB3DCEA@jtauber.com> <9138FF9DE9175C489F6F5477262E4FA8DDBDD0@DF-TERRIER-MSG.exchange.corp.microsoft.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 ------=_Part_51819_29412588.1147100113665 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGV5IFNlYW4sCgpTbyBpbiBtb3JlIHVzZXIgY29udHJvbGxlZCBmb3JtYXQgKG5vdCBhIGJhZCB0 aGluZywgb2J2aW91c2x5IDopKSB0aGVuIHRoZXJlCmlzIGhpc3RvcmljYWwgcGVyc2lzdGVuY2Uu Li4KCk15IGFwb2xvZ2llcyBmb3Igc3VnZ2VzdGluZyB0aGluZ3Mgd2VyZSBtb3JlIGNvbXBsaWNh dGVkIHRoYW4gdGhleSBhY3R1YWxseQphcmUuLi4gIEkgZ3Vlc3MgSSBzaG91bGQgaGF2ZSBkdWcg YSBiaXQgZGVlcGVyLgoKTG9va3MgbGlrZSBJIGhhdmUgc29tZSBtb3JlIHN0dWR5aW5nIHRvIGRv Li4uICBBbnkgcG9pbnRlcnM/CgpUaGFua3MgaW4gYWR2YW5jZSEKCk9uZSB0aGluZyB3b3J0aCBu b3RpbmcuLiBJIHJlYWxpemVkIGFmdGVyIHNlbmRpbmcgeWVzdGVyZGF5cyBlbWFpbCB0aGF0IGlm IEkKZG9uJ3Qgc2ltcGx5IGRldmVsb3AgdGhlIEF0b21pY1JTUy5ORVQgQXRvbSA+IFdlYiBGZWVk IEVuZ2luZSA+IEF0b20gZW5naW5lZApwcm9udG8sIEknbSBnb2luZyB0byBtaXNzIGFueSBwb3Nz aWJsZSB3aW5kb3cgb2Ygb3Bwb3J0dW5pdHkgZm9yIGFueSBzb3J0IG9mCmludGVybmFsIGNoYW5n ZXMgdG8gbWFrZSB0aGUgY29udmVyc2lvbiBwcm9jZXNzIGFzIGxvc2xlc3MgYXMgcG9zc2libGUg KGlmIEkKaGF2ZW4ndCBsb3N0IHRoYXQgd2luZG93IGFscmVhZHkpLiAgQXMgc3VjaCwgSSBzdGFy dGVkIGluIG9uIHRoZSBiYXNpYwplbmdpbmUgbGFzdCBuaWdodCB1c2luZyBDIywgYW5kIGFtIGFj dHVhbGx5IHVzaW5nIHRoaXMgYXMgdGhlIGJhc2lzIGZvcgpkZXZlbG9waW5nIHRoZSBkYXRhIHN0 cnVjdHVyZSBvZiB0aGUgQ2xpcGJvYXJkWzFdLCBDbGlwRGF0YVsyXSwgYW5kCkNsaXBJdGVtWzJd IGRhdGEgc3RydWN0dXJlcyB0aGF0IGFyZSB0aGVuIG1hcHBlZCB0byB0aGUgUHJvdmlkZXJbNF0g Y2xhc3MKKHNvb24gdG8gYmUgYW4gaW50ZXJmYWNlKSBvZiB3aGljaCBhbnkgZ2l2ZW4gZGF0YSBz dG9yZSBjYW4gYmUgbWFwIGRpcmVjdGx5CnRvIHRoZSBQcm92aWRlciBpbnRlcmZhY2UgdGhhdCBt YXBzIGRpcmVjdGx5IGludG8gdGhlIGFib3ZlIG1lbnRpb25lZApjbGFzc2VzLgoKSSBhbSBzdGls bCB3b3JraW5nIHRocm91Z2ggYWxsIG9mIHRoaXMsIGFuZCB0byBrZWVwIHRoZSBjdXJyZW50CnRl c3RjbGlwYm9hcmQuYXNweFs1XSBkZW1vIEkgaGFja2VkIHRvZ2V0aGVyIGEgZnVuY3Rpb25hbCBz b3VyY2UgY29kZSBiYXNlCnRoYXQsIHdoaWxlIGl0IGxvb2tzIGEgYml0IGhvcnJpZCBhdCB0aGUg bW9tZW50LCBpdCBhbGxvd3MgbWUgdG8ga2VlcAp3b3JraW5nIG9uIHRoZSBhYm92ZSBtZW50aW9u ZWQgZmlsZXMgYW5kIGFsbG93IHRoZSBkZW1vIGl0c2VsZiB0byBtb3ZlCmZvcndhcmRba2luZGEg OildLCBhdCBsZWFzdCBzaG93Y2FzaW5nIHNvbWUgb2YgdGhlIGJhc2ljIGZlYXR1cmVzLiAgSSB3 aWxsCnBpbmcgdGhpcyB0aHJlYWQgYmFjayB3aXRoIHNpZ25pZmljYW50IHVwZGF0ZXMuICBUaGUg dGltZWxpbmUgZmVlZCBpcwphdmFpbGFibGUgWzZdIGZvciB0aG9zZSB3aG8gZGVzaXJlIGEgYml0 IG1vcmUgdXAtdG8tbWludXRlIGRldGFpbCBvZiB3aGF0cwpiZWluZyBjaGVja2VkIGluLCB3aGVu IGl0cyBiZWluZyBjaGVja2VkIGluLgoKWzFdID4KaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2Uu bmV0L2Jyb3dzZXIvdHJ1bmsvR2xvYmFsQ2xpcC9HbG9iYWxDbGlwL0dsb2JhbENsaXBfQ2xpcGJv YXJkLmNzCgpbMl0gPgpodHRwOi8vZGV2LmV4dGVuc2libGVmb3JnZS5uZXQvYnJvd3Nlci90cnVu ay9HbG9iYWxDbGlwL0dsb2JhbENsaXAvR2xvYmFsQ2xpcF9DbGlwRGF0YS5jcwoKWzNdID4KaHR0 cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L2Jyb3dzZXIvdHJ1bmsvR2xvYmFsQ2xpcC9HbG9i YWxDbGlwL0dsb2JhbENsaXBfQ2xpcEl0ZW0uY3MKCls0XSA+Cmh0dHA6Ly9kZXYuZXh0ZW5zaWJs ZWZvcmdlLm5ldC9icm93c2VyL3RydW5rL0dsb2JhbENsaXAvR2xvYmFsQ2xpcC9HbG9iYWxDbGlw X1Byb3ZpZGVyLmNzCgpbNV0gPgpodHRwOi8vZGV2LmV4dGVuc2libGVmb3JnZS5uZXQvYnJvd3Nl ci90cnVuay9SZXNlYXJjaC9HbG9iYWxDbGlwL3NyYy94Lkluc3RhbmNlL3Rlc3RjbGlwYm9hcmQu YXNweAoKWzZdID4KaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3RpbWVsaW5lP3dpa2k9 b24mbWlsZXN0b25lPW9uJnRpY2tldD1vbiZjaGFuZ2VzZXQ9b24mbWF4PTUwJmRheXNiYWNrPTkw JmZvcm1hdD1yc3MKCk9uIDUvOC8wNiwgU2VhbiBMeW5kZXJzYXkgPHNlYW5seW5kQGV4Y2hhbmdl Lm1pY3Jvc29mdC5jb20+IHdyb3RlOgo+Cj4KPgo+ICo+IFNlYW4gKihhbHNvIGNvcGllZCksIGNh biB5b3UgY2xhcmlmeSB0aGlzIG9uZSB3YXkgb3IgdGhlIG90aGVyPwo+Cj4KPgo+IE9uIHRoZSBj b25jZXB0IG9mIHBlcnNpc3RlbmNlLCB0aGUgZmVlZCBwbGF0Zm9ybSBpbiBXaW5kb3dzIHBlcnNp c3RzCj4gZG93bmxvYWRlZCBlbnRyaWVzIGZyb20gZmVlZHMgZm9yIGFzIGxvbmcgYXMgdGhlIHVz ZXIgd2FudHMgdGhlbS4gTm90aGluZwo+IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGF0Lgo+Cj4K Pgo+Cj4KPiAqRnJvbToqIE0uIERhdmlkIFBldGVyc29uIFttYWlsdG86eG1saGFja2VyQGdtYWls LmNvbV0KPiAqU2VudDoqIFN1bmRheSwgTWF5IDA3LCAyMDA2IDEyOjU5IFBNCj4gKlRvOiogSmFt ZXMgVGF1YmVyCj4gKkNjOiogUm9iZXJ0IFNheXJlOyBBdG9tIFN5bnRheDsgQnJ1Y2UgRCdBcmN1 czsgU2VhbiBMeW5kZXJzYXkKPiAqU3ViamVjdDoqIFJlOiBXaGF0IEF0b20gc29mdHdhcmUgYXJl IHlvdSB3b3JraW5nIG9uPwo+Cj4KPgo+ID4gQWxzbyByZWNlbnRseSBzdGFydGVkIG9uIGEgQUpB WC1iYXNlZCBBUFAgY2xpZW50IHRvIGdvIHdpdGggaXQuCj4KPgo+Cj4gVmVyeSBjb29sISAgVGhp cyBpcyBzb21ldGhpbmcgSSBjYW4gaGVscCB3aXRoIGlmIG5lZWRzIGJlLi4uICBJJ20gc3RpbGwK PiB0cnlpbmcgdG8gZ2V0IG15IGxlZ3MgaW4gUHl0aG9uLCBhbmQgd2l0aCBzb21lIG1pc3Npbmcg aG9sZXMgaW4gSXJvblB5dGhvbgo+IHRvIGFsbG93IERlbW9rcml0b3MgdG8gcnVuIG5hdGl2ZWx5 IGhhdmUgaGVsZCB0aGUgQXRvbWljUlNTLk5FVCBwcm9qZWN0Cj4gb2ZmIGZvciBub3cgYW5kIG1v dmVkIGZvcndhcmQgd2l0aCBHbG9iYWxDbGlwLgo+Cj4KPgo+IEp1c3QgdG8gY29ubmVjdCB0aGUg ZG90cywgaWRlYWxseSBJIHdvdWxkIGxpa2UgdG8gY291cGxlIHN1cHBvcnQgZm9yIEFQUAo+IGlu dG8gR2xvYmFsQ2xpcCwgYXMgdGhlIGFiaWxpdHkgdG8gY29weSB0ZXh0IGZyb20gYSBibG9nIGVu dHJ5LCBzdWNrIGluIGFsbAo+IG9mIHRoZSBuZWNlc3NhcnkgbWV0YS1kYXRhLCB0byB0aGVuIHBh c3RlIHRoaXMgaW50byBhIGJsb2cgZW50cnksIG9yCj4gYSByZXNlYXJjaCBwYXBlciwgb3IgYW55 dGhpbmcgZWxzZSB0aGF0IG9uZSBtaWdodCB3YW50IHRvIG1ha2UgcmVmZXJlbmNlCj4gdG8gc29t ZXRoaW5nIGVsc2Ugb24gdGhlIHdlYiwgc2VlbXMgdG8gbWF0Y2ggd2VsbCB3aXRoIHdoYXQgQVBQ IGlzIGFsbAo+IGFib3V0LiAgT2YgY291cnNlLCB0aGUgbWV0YS1kYXRhIHdvdWxkIGluY2x1ZGUg YXQgdmVyeSBsZWFzdCB0aGUgcmVmZXJlbmNlCj4gVVJJIChyZWFkOiBub2JvZHkgaGFzIHRvIGRv IGFueXRoaW5nIGV4Y2VwdCBwb3N0IHNvbWV0aGluZyB0byB0aGUgd2ViLCBhbmQKPiB0aGlzIGlz IGVub3VnaCBpbmZvcm1hdGlvbiB0byBhdCB2ZXJ5IGxlYXN0IGVuc3VyZSBwcm9wZXIgY3JlZGl0 IHRvIHRoZQo+IHJlZmVyZW5jaW5nIFVSSSBpcyBlbmNsb3NlZC4pIGJ1dCB3b3VsZCBob3BlZnVs bHkgY29udGFpbiBhbGwgdGhlIHByb3Blcgo+IGNvcHlyaWdodCBpbmZvcm1hdGlvbiwgd2hldGhl ciB0aGlzIGJlIGEgQ3JlYXRpdmUgQ29tbW9ucyBsaWNlbnNlIG9yCj4gc29tZXRoaW5nIGVsc2Ug YWxsIHRvZ2V0aGVyLCBhcyB3ZWxsIGFzIG90aGVyIHJlbGF0ZWQgbWV0YS1kYXRhLCBzdWNoIGFz Cj4gdGhhdCBmb3VuZCBpbiB0aGUgd29ybGQgb2YgY2l0YXRpb25zLgo+Cj4KPgo+IEkndmUgY29w aWVkIEJydWNlIEQnQXJjdXMgb24gdGhpcyBhcyBoZSBhbmQgSSBoYXZlIGJlZW4gdGFsa2luZyBh Ym91dAo+IGJ1aWxkaW5nIGludG8gdGhlIExpdmVDbGlwYm9hcmQvR2xvYmFsQ2xpcCBleHRlbnNp b24gb2ZmZXJpbmdzIHRoZSBhYmlsaXR5Cj4gdG8gaW1wbGVtZW50IHN1cHBvcnQgZm9yIGNvbXBs ZXRlIGNpdGF0aW9uIG1ldGEtZGF0YSB0byB0aGVuIGJ1aWxkIHRoZQo+IG5lY2Vzc2FyeSBjb25u ZWN0b3IgdG8gZW5hYmxlIGEgc2ltcGxlIHBhc3RlIG9wZXJhdGlvbiBpbnNpZGUgb2YgYSBXb3Jk Cj4gZG9jdW1lbnQgKE9ERiB2aWEgT08ubyBpcyBvYnZpb3VzLCBnaXZlbiB0aGUgZmFjdCB0aGF0 IEJydWNlIGlzIGEgcGFydCBvZgo+IGxlYWRpbmcgdGhpcyBlZmZvcnQgYWxyZWFkeSkuCj4KPgo+ Cj4gKkJydWNlKjogSGF2ZSBhIGxvb2sgQCBodHRwOi8vZXh0Zi5uZXQvU2F4b24vZG90bmV0L0FT UC5ORVQvTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlwLwo+ICBhcyB3ZWxsIGFzIGh0dHA6Ly9kZXYu ZXh0ZW5zaWJsZWZvcmdlLm5ldC93aWtpL0dsb2JhbENsaXAgaWYgeW91IGhhdmVuJ3QKPiBzZWVu IHRoZW0gcmVjZW50bHkuLi4gSSB0aGluayB3ZSdyZSBhYm91dCByZWFkeSB0byBzdGFydCBleHBh bmRpbmcgaW50byB0aGUKPiBjaXRhdGlvbnMgc2lkZSBvZiB0aGlzLgo+Cj4KPgo+IENvbm5lY3Rp bmcgdGhpcyBiYWNrIHRvIHRoZSBBdG9taWNSU1MuTkVUIHByb2plY3QgKG9yIHdoYXRldmVyIHRo ZSBmaW5hbAo+IG5hbWUgdHVybnMgb3V0IHRvIGJlIChOT1RFOiBJJ3ZlIG9mZmljaWFsbHkgbW92 ZWQgdGhpcyBwcm9qZWN0IHRvCj4gZXh0ZW5zaWJsZWZvcmdlIHdoaWNoIGlzIHRoZSBuZXcgaG9t ZSBvZiBBTEwgb2YgbXkgb25nb2luZyBwcm9qZWN0cyA6KSA+Cj4gaHR0cDovL2Rldi5leHRlbnNp YmxlZm9yZ2UubmV0L3dpa2kvQXRvbWljUlNTLk5FVCApLCB0aGUgYWJpbGl0eSB0byB0dXJuCj4g dGhlIE1TIFdlYiBGZWVkIGVuZ2luZSBpbnRvIGFuIEFQUCBkYXRhIHN0b3JlIGlzIHNpbXBsZSBl bm91Z2guICBCdXQgdXNpbmcKPiBEZW1va3JpdG9zIGFzIHRoZSBwcmltYXJ5IGRhdGEgc3RvcmUs IGFuZCBzeW5jcm9uaXppbmcgd2l0aCB0aGUgV2ViIEZlZWQKPiBlbmdpbmUgYnJpbmdzIGFsbCBv ZiB0aGUgd29uZGVyZnVsbmVzcyB0aGF0IGNvbWVzIGFsb25nIHdpdGggdGhlIHBlcnNpc3RlbmNl Cj4gbGF5ZXIgdmlhIFNWTiAoYW5kIHRoZXJlZm9yZSBoaXN0b3JpY2FsIHBlcnNpc3RlbmNlLCBh cyBsb25nIGFzIEkgdW5kZXJzdGFuZAo+IGNvcnJlY3RseSBob3cgRGVtb2tyaXRvJ3MgaGFuZGxl cyBwZXJzaXN0ZW5jZSB2aWEgU1ZOKSB0aGF0cyBidWlsdCBkaXJlY3RseQo+IGludG8gRGVtb2ty aXRvcy4KPgo+Cj4KPiBVbmxlc3MgSSdtIG1pc3Npbmcgc29tZXRoaW5nIFtodHRwOi8vbXNkbi5t aWNyb3NvZnQuY29tL2xpYnJhcnkvZGVmYXVsdC5hc3A/dXJsPS9saWJyYXJ5L2VuLXVzL2ZlZWRz YXBpL3Jzcy9vdmVydmlld3MvbXNmZWVkc19vdncuYXNwCj4gXSB0aGVyZSBpcyBubyBkaXJlY3Qg Y29uY2VwdCBvZiBoaXN0b3JpY2FsIHBlcnNpc3RlbmNlIGluIHRoZSBXZWIgRmVlZAo+IGVuZ2lu ZS4KPgo+Cj4KPiAqU2VhbiAqKGFsc28gY29waWVkKSwgY2FuIHlvdSBjbGFyaWZ5IHRoaXMgb25l IHdheSBvciB0aGUgb3RoZXI/Cj4KPgo+IE9uIDUvNi8wNiwgKkphbWVzIFRhdWJlciogPGp0YXVi ZXJAanRhdWJlci5jb20gPiB3cm90ZToKPgo+Cj4gRGVtb2tyaXRvcyAtIEFQUCBzZXJ2ZXIgYW5k IFB5dGhvbiBsaWJyYXJ5Lgo+Cj4gaHR0cDovL2p0YXViZXIuY29tL2RlbW9rcml0b3MKPgo+IEN1 cnJlbnRseSBpbXBsZW1lbnRpbmcgYmFzaWMgYXV0aCBzdXBwb3J0IGZvciAwLjQgcmVsZWFzZS4K Pgo+IEFsc28gcmVjZW50bHkgc3RhcnRlZCBvbiBhIEFKQVgtYmFzZWQgQVBQIGNsaWVudCB0byBn byB3aXRoIGl0Lgo+Cj4gSmFtZXMKPiAtLQo+IEphbWVzIFRhdWJlciAgICAgICAgICAgICAgICAg ICAgICAgaHR0cDovL2p0YXViZXIuY29tLwo+IGpvdXJuZXltYW4gb2Ygc29tZSAgIGh0dHA6Ly9q dGF1YmVyLmNvbS9ibG9nLwo+Cj4KPiBPbiAwNS8wNS8yMDA2LCBhdCA5OjExIEFNLCBSb2JlcnQg U2F5cmUgd3JvdGU6Cj4KPiA+Cj4gPiBJJ3ZlIGJlZW4gd29ya2luZyB0byBhZGQgQXRvbSBzdXBw b3J0IHRvIEZpcmVmb3ggMi4gU29tZSBvdGhlciBGaXJlZm94Cj4gPiBkZXZzIGFyZSB0b3lpbmcg d2l0aCBleHBvc2luZyBpbnRlcm5hbCBkYXRhIGxpa2UgaGlzdG9yeSBhbmQgYm9va21hcmtzCj4g PiBhcyBBdG9tIGZlZWRzLgo+ID4KPiA+IFdoYXQgc29mdHdhcmUgYXJlIHlvdSB3cml0aW5nPwo+ ID4KPiA+IC0tCj4gPgo+ID4gUm9iZXJ0IFNheXJlCj4gPgo+ID4gIkkgd291bGQgaGF2ZSB3cml0 dGVuIGEgc2hvcnRlciBsZXR0ZXIsIGJ1dCBJIGRpZCBub3QgaGF2ZSB0aGUgdGltZS4iCj4gPgo+ Cj4KPgo+Cj4gLS0KPiA8TTpELz4KPgo+IE0uIERhdmlkIFBldGVyc29uCj4gaHR0cDovL3d3dy54 c2x0YmxvZy5jb20vCj4KCgoKLS0KPE06RC8+CgpNLiBEYXZpZCBQZXRlcnNvbgpodHRwOi8vd3d3 LnhzbHRibG9nLmNvbS8K ------=_Part_51819_29412588.1147100113665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGV5IFNlYW4sPGJyPjxicj5TbyBpbiBtb3JlIHVzZXIgY29udHJvbGxlZCBmb3JtYXQgKG5vdCBh IGJhZCB0aGluZywgb2J2aW91c2x5IDopKSB0aGVuIHRoZXJlIGlzIGhpc3RvcmljYWwgcGVyc2lz dGVuY2UuLi48YnI+PGJyPk15IGFwb2xvZ2llcyBmb3Igc3VnZ2VzdGluZyB0aGluZ3Mgd2VyZSBt b3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhleSBhY3R1YWxseSBhcmUuLi4mbmJzcDsgSSBndWVzcyBJ IHNob3VsZCBoYXZlIGR1ZyBhIGJpdCBkZWVwZXIuCjxicj48YnI+TG9va3MgbGlrZSBJIGhhdmUg c29tZSBtb3JlIHN0dWR5aW5nIHRvIGRvLi4uJm5ic3A7IEFueSBwb2ludGVycz88YnI+PGJyPlRo YW5rcyBpbiBhZHZhbmNlITxicj48YnI+T25lIHRoaW5nIHdvcnRoIG5vdGluZy4uIEkgcmVhbGl6 ZWQgYWZ0ZXIgc2VuZGluZyB5ZXN0ZXJkYXlzIGVtYWlsIHRoYXQgaWYgSSBkb24ndCBzaW1wbHkg ZGV2ZWxvcCB0aGUgQXRvbWljUlNTLk5FVCBBdG9tICZndDsgV2ViIEZlZWQgRW5naW5lICZndDsg QXRvbSBlbmdpbmVkIHByb250bywgSSdtIGdvaW5nIHRvIG1pc3MgYW55IHBvc3NpYmxlIHdpbmRv dyBvZiBvcHBvcnR1bml0eSBmb3IgYW55IHNvcnQgb2YgaW50ZXJuYWwgY2hhbmdlcyB0byBtYWtl IHRoZSBjb252ZXJzaW9uIHByb2Nlc3MgYXMgbG9zbGVzcyBhcyBwb3NzaWJsZSAoaWYgSSBoYXZl bid0IGxvc3QgdGhhdCB3aW5kb3cgYWxyZWFkeSkuJm5ic3A7IEFzIHN1Y2gsIEkgc3RhcnRlZCBp biBvbiB0aGUgYmFzaWMgZW5naW5lIGxhc3QgbmlnaHQgdXNpbmcgQyMsIGFuZCBhbSBhY3R1YWxs eSB1c2luZyB0aGlzIGFzIHRoZSBiYXNpcyBmb3IgZGV2ZWxvcGluZyB0aGUgZGF0YSBzdHJ1Y3R1 cmUgb2YgdGhlIENsaXBib2FyZFsxXSwgQ2xpcERhdGFbMl0sIGFuZCBDbGlwSXRlbVsyXSBkYXRh IHN0cnVjdHVyZXMgdGhhdCBhcmUgdGhlbiBtYXBwZWQgdG8gdGhlIFByb3ZpZGVyWzRdIGNsYXNz IChzb29uIHRvIGJlIGFuIGludGVyZmFjZSkgb2Ygd2hpY2ggYW55IGdpdmVuIGRhdGEgc3RvcmUg Y2FuIGJlIG1hcCBkaXJlY3RseSB0byB0aGUgUHJvdmlkZXIgaW50ZXJmYWNlIHRoYXQgbWFwcyBk aXJlY3RseSBpbnRvIHRoZSBhYm92ZSBtZW50aW9uZWQgY2xhc3Nlcy4gCjxicj48YnI+SSBhbSBz dGlsbCB3b3JraW5nIHRocm91Z2ggYWxsIG9mIHRoaXMsIGFuZCB0byBrZWVwIHRoZSBjdXJyZW50 IHRlc3RjbGlwYm9hcmQuYXNweFs1XSBkZW1vIEkgaGFja2VkIHRvZ2V0aGVyIGEgZnVuY3Rpb25h bCBzb3VyY2UgY29kZSBiYXNlIHRoYXQsIHdoaWxlIGl0IGxvb2tzIGEgYml0IGhvcnJpZCBhdCB0 aGUgbW9tZW50LCBpdCBhbGxvd3MgbWUgdG8ga2VlcCB3b3JraW5nIG9uIHRoZSBhYm92ZSBtZW50 aW9uZWQgZmlsZXMgYW5kIGFsbG93IHRoZSBkZW1vIGl0c2VsZiB0byBtb3ZlIGZvcndhcmRba2lu ZGEgOildLCBhdCBsZWFzdCBzaG93Y2FzaW5nIHNvbWUgb2YgdGhlIGJhc2ljIGZlYXR1cmVzLiZu YnNwOyBJIHdpbGwgcGluZyB0aGlzIHRocmVhZCBiYWNrIHdpdGggc2lnbmlmaWNhbnQgdXBkYXRl cy4mbmJzcDsgVGhlIHRpbWVsaW5lIGZlZWQgaXMgYXZhaWxhYmxlIFs2XSBmb3IgdGhvc2Ugd2hv IGRlc2lyZSBhIGJpdCBtb3JlIHVwLXRvLW1pbnV0ZSBkZXRhaWwgb2Ygd2hhdHMgYmVpbmcgY2hl Y2tlZCBpbiwgd2hlbiBpdHMgYmVpbmcgY2hlY2tlZCBpbi4KPGJyPjxicj5bMV0gJmd0OyA8YSBo cmVmPSJodHRwOi8vZGV2LmV4dGVuc2libGVmb3JnZS5uZXQvYnJvd3Nlci90cnVuay9HbG9iYWxD bGlwL0dsb2JhbENsaXAvR2xvYmFsQ2xpcF9DbGlwYm9hcmQuY3MiPmh0dHA6Ly9kZXYuZXh0ZW5z aWJsZWZvcmdlLm5ldC9icm93c2VyL3RydW5rL0dsb2JhbENsaXAvR2xvYmFsQ2xpcC9HbG9iYWxD bGlwX0NsaXBib2FyZC5jczwvYT48YnI+PGJyPlsyXSAmZ3Q7IAo8YSBocmVmPSJodHRwOi8vZGV2 LmV4dGVuc2libGVmb3JnZS5uZXQvYnJvd3Nlci90cnVuay9HbG9iYWxDbGlwL0dsb2JhbENsaXAv R2xvYmFsQ2xpcF9DbGlwRGF0YS5jcyI+aHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L2Jy b3dzZXIvdHJ1bmsvR2xvYmFsQ2xpcC9HbG9iYWxDbGlwL0dsb2JhbENsaXBfQ2xpcERhdGEuY3M8 L2E+PGJyPjxicj5bM10gJmd0OyA8YSBocmVmPSJodHRwOi8vZGV2LmV4dGVuc2libGVmb3JnZS5u ZXQvYnJvd3Nlci90cnVuay9HbG9iYWxDbGlwL0dsb2JhbENsaXAvR2xvYmFsQ2xpcF9DbGlwSXRl bS5jcyI+Cmh0dHA6Ly9kZXYuZXh0ZW5zaWJsZWZvcmdlLm5ldC9icm93c2VyL3RydW5rL0dsb2Jh bENsaXAvR2xvYmFsQ2xpcC9HbG9iYWxDbGlwX0NsaXBJdGVtLmNzPC9hPjxicj48YnI+WzRdICZn dDsgPGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L2Jyb3dzZXIvdHJ1bmsv R2xvYmFsQ2xpcC9HbG9iYWxDbGlwL0dsb2JhbENsaXBfUHJvdmlkZXIuY3MiPmh0dHA6Ly9kZXYu ZXh0ZW5zaWJsZWZvcmdlLm5ldC9icm93c2VyL3RydW5rL0dsb2JhbENsaXAvR2xvYmFsQ2xpcC9H bG9iYWxDbGlwX1Byb3ZpZGVyLmNzCjwvYT48YnI+PGJyPls1XSAmZ3Q7IDxhIGhyZWY9Imh0dHA6 Ly9kZXYuZXh0ZW5zaWJsZWZvcmdlLm5ldC9icm93c2VyL3RydW5rL1Jlc2VhcmNoL0dsb2JhbENs aXAvc3JjL3guSW5zdGFuY2UvdGVzdGNsaXBib2FyZC5hc3B4Ij5odHRwOi8vZGV2LmV4dGVuc2li bGVmb3JnZS5uZXQvYnJvd3Nlci90cnVuay9SZXNlYXJjaC9HbG9iYWxDbGlwL3NyYy94Lkluc3Rh bmNlL3Rlc3RjbGlwYm9hcmQuYXNweAo8L2E+PGJyPjxicj5bNl0gJmd0OyA8YSBocmVmPSJodHRw Oi8vZGV2LmV4dGVuc2libGVmb3JnZS5uZXQvdGltZWxpbmU/d2lraT1vbiZhbXA7bWlsZXN0b25l PW9uJmFtcDt0aWNrZXQ9b24mYW1wO2NoYW5nZXNldD1vbiZhbXA7bWF4PTUwJmFtcDtkYXlzYmFj az05MCZhbXA7Zm9ybWF0PXJzcyI+aHR0cDovL2Rldi5leHRlbnNpYmxlZm9yZ2UubmV0L3RpbWVs aW5lP3dpa2k9b24mYW1wO21pbGVzdG9uZT1vbiZhbXA7dGlja2V0PW9uJmFtcDtjaGFuZ2VzZXQ9 b24mYW1wO21heD01MCZhbXA7ZGF5c2JhY2s9OTAmYW1wO2Zvcm1hdD1yc3MKPC9hPjxicj48YnI+ PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDUvOC8wNiwgPGIgY2xhc3M9ImdtYWls X3NlbmRlcm5hbWUiPlNlYW4gTHluZGVyc2F5PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5s eW5kQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20iPnNlYW5seW5kQGV4Y2hhbmdlLm1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjog MHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CjxkaXYgc3R5bGU9ImRpcmVj dGlvbjogbHRyOyI+CgoKCgoKCgoKCgo8ZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImRpcmVjdGlvbjog bHRyOyI+PHNwYW4gY2xhc3M9InEiPgoKPHA+Jm5ic3A7PC9wPgoKPHA+PHN0cm9uZz4mZ3Q7IFNl YW4gPC9zdHJvbmc+KGFsc28gY29waWVkKSwgY2FuIHlvdSBjbGFyaWZ5CnRoaXMgb25lIHdheSBv ciB0aGUgb3RoZXI/PC9wPgoKPHA+Jm5ic3A7PC9wPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJk aXJlY3Rpb246IGx0cjsiPgoKPHA+T24gdGhlIGNvbmNlcHQgb2YgcGVyc2lzdGVuY2UsIHRoZSBm ZWVkIHBsYXRmb3JtIGluIFdpbmRvd3MKcGVyc2lzdHMgZG93bmxvYWRlZCBlbnRyaWVzIGZyb20g ZmVlZHMgZm9yIGFzIGxvbmcgYXMgdGhlIHVzZXIgd2FudHMgdGhlbS4gTm90aGluZwptb3JlIGNv bXBsaWNhdGVkIHRoYW4gdGhhdC4gPC9wPgoKPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PC9wPgoKPHA+PGEgbmFt ZT0iMTBiMTQ2ODRhYzAyZTM1Nl9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvYT48L3A+ Cgo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9y OiByZ2IoMTQ1LCAxOTIsIDI1NSkgLW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNv bG9yOyBib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBwYWRkaW5nOiAzcHQgMGNtIDBj bTsiPgoKPHA+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyIgbGFuZz0iRU4tVVMiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IiBsYW5nPSJFTi1VUyI+ IE0uCkRhdmlkIFBldGVyc29uIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnhtbGhhY2tlckBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5r KHdpbmRvdyxldmVudCx0aGlzKSI+eG1saGFja2VyQGdtYWlsLmNvbTwvYT5dIDxicj4KPGI+U2Vu dDo8L2I+IFN1bmRheSwgTWF5IDA3LCAyMDA2IDEyOjU5IFBNPGJyPgo8Yj5Ubzo8L2I+IEphbWVz IFRhdWJlcjxicj4KPGI+Q2M6PC9iPiBSb2JlcnQgU2F5cmU7IEF0b20gU3ludGF4OyBCcnVjZSBE J0FyY3VzOyBTZWFuIEx5bmRlcnNheTxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBXaGF0IEF0b20g c29mdHdhcmUgYXJlIHlvdSB3b3JraW5nIG9uPzwvc3Bhbj48L3A+Cgo8L2Rpdj48L2Rpdj48ZGl2 IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjxzcGFuIGNsYXNzPSJlIiBpZD0icV8xMGIxNDY4NGFj MDJlMzU2XzMiPgoKPHA+Jm5ic3A7PC9wPgoKPGRpdj4KCjxwPiZndDsgQWxzbyByZWNlbnRseSBz dGFydGVkIG9uIGEgQUpBWC1iYXNlZCBBUFAgY2xpZW50IHRvIGdvCndpdGggaXQuPC9wPgoKPC9k aXY+Cgo8ZGl2PgoKPHA+Jm5ic3A7PC9wPgoKPC9kaXY+Cgo8ZGl2PgoKPHA+VmVyeSBjb29sISZu YnNwOyBUaGlzIGlzIHNvbWV0aGluZyBJIGNhbiBoZWxwIHdpdGggaWYgbmVlZHMKYmUuLi4mbmJz cDsgSSdtIHN0aWxsIHRyeWluZyB0byBnZXQgbXkgbGVncyBpbiBQeXRob24sIGFuZCB3aXRoIHNv bWUgbWlzc2luZwpob2xlcyBpbiBJcm9uUHl0aG9uIHRvIGFsbG93IERlbW9rcml0b3MgdG8gcnVu IG5hdGl2ZWx5IGhhdmUgaGVsZCB0aGUKQXRvbWljUlNTLk5FVCBwcm9qZWN0IG9mZiBmb3Igbm93 IGFuZCBtb3ZlZCBmb3J3YXJkIHdpdGggR2xvYmFsQ2xpcC4gPC9wPgoKPC9kaXY+Cgo8ZGl2PgoK PHA+Jm5ic3A7PC9wPgoKPC9kaXY+Cgo8ZGl2PgoKPHA+SnVzdCB0byBjb25uZWN0IHRoZSBkb3Rz LCBpZGVhbGx5IEkgd291bGQgbGlrZSB0byBjb3VwbGUKc3VwcG9ydCBmb3IgQVBQIGludG8gR2xv YmFsQ2xpcCwgYXMgdGhlIGFiaWxpdHkgdG8gY29weSB0ZXh0IGZyb20mbmJzcDthIGJsb2cKZW50 cnksIHN1Y2sgaW4gYWxsIG9mIHRoZSBuZWNlc3NhcnkgbWV0YS1kYXRhLCB0byB0aGVuIHBhc3Rl IHRoaXMmbmJzcDtpbnRvIGEKYmxvZyBlbnRyeSwgb3IgYSZuYnNwO3Jlc2VhcmNoIHBhcGVyLCBv ciZuYnNwO2FueXRoaW5nIGVsc2UgdGhhdCBvbmUgbWlnaHQgd2FudAp0byBtYWtlIHJlZmVyZW5j ZSB0byZuYnNwO3NvbWV0aGluZyBlbHNlIG9uIHRoZSB3ZWIsIHNlZW1zIHRvIG1hdGNoIHdlbGwg d2l0aAp3aGF0IEFQUCBpcyBhbGwgYWJvdXQuJm5ic3A7IE9mIGNvdXJzZSwgdGhlIG1ldGEtZGF0 YSB3b3VsZCBpbmNsdWRlIGF0IHZlcnkKbGVhc3QgdGhlIHJlZmVyZW5jZSBVUkkgKHJlYWQ6IG5v Ym9keSBoYXMgdG8gZG8gYW55dGhpbmcgZXhjZXB0IHBvc3Qgc29tZXRoaW5nCnRvIHRoZSB3ZWIs IGFuZCB0aGlzIGlzIGVub3VnaCBpbmZvcm1hdGlvbiB0byBhdCB2ZXJ5IGxlYXN0IGVuc3VyZSBw cm9wZXIKY3JlZGl0IHRvIHRoZSByZWZlcmVuY2luZyBVUkkgaXMgZW5jbG9zZWQuKSBidXQgd291 bGQgaG9wZWZ1bGx5IGNvbnRhaW4gYWxsIHRoZQpwcm9wZXIgY29weXJpZ2h0IGluZm9ybWF0aW9u LCB3aGV0aGVyIHRoaXMgYmUgYSBDcmVhdGl2ZSBDb21tb25zIGxpY2Vuc2Ugb3IKc29tZXRoaW5n IGVsc2UgYWxsIHRvZ2V0aGVyLCBhcyB3ZWxsIGFzIG90aGVyIHJlbGF0ZWQgbWV0YS1kYXRhLCBz dWNoIGFzIHRoYXQKZm91bmQgaW4gdGhlIHdvcmxkIG9mIGNpdGF0aW9ucy4mbmJzcDsgPC9wPgoK PC9kaXY+Cgo8ZGl2PgoKPHA+Jm5ic3A7PC9wPgoKPC9kaXY+Cgo8ZGl2PgoKPHA+SSd2ZSBjb3Bp ZWQgQnJ1Y2UgRCdBcmN1cyBvbiB0aGlzIGFzIGhlIGFuZCBJIGhhdmUgYmVlbgp0YWxraW5nIGFi b3V0IGJ1aWxkaW5nIGludG8gdGhlIExpdmVDbGlwYm9hcmQvR2xvYmFsQ2xpcCBleHRlbnNpb24m bmJzcDtvZmZlcmluZ3MKdGhlIGFiaWxpdHkgdG8gaW1wbGVtZW50IHN1cHBvcnQgZm9yIGNvbXBs ZXRlIGNpdGF0aW9uIG1ldGEtZGF0YSB0byB0aGVuIGJ1aWxkCnRoZSBuZWNlc3NhcnkgY29ubmVj dG9yIHRvIGVuYWJsZSBhIHNpbXBsZSBwYXN0ZSBvcGVyYXRpb24gaW5zaWRlIG9mIGEgV29yZApk b2N1bWVudCAoT0RGIHZpYSBPTy5vIGlzIG9idmlvdXMsIGdpdmVuIHRoZSBmYWN0IHRoYXQgQnJ1 Y2UgaXMgYSBwYXJ0IG9mCmxlYWRpbmcgdGhpcyBlZmZvcnQgYWxyZWFkeSkuPC9wPgoKPC9kaXY+ Cgo8ZGl2PgoKPHA+Jm5ic3A7PC9wPgoKPC9kaXY+Cgo8ZGl2PgoKPHA+PHN0cm9uZz5CcnVjZTwv c3Ryb25nPjogSGF2ZSBhIGxvb2sgQCA8YSBocmVmPSJodHRwOi8vZXh0Zi5uZXQvU2F4b24vZG90 bmV0L0FTUC5ORVQvTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlwLyIgdGFyZ2V0PSJfYmxhbmsiIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRw Oi8vZXh0Zi5uZXQvU2F4b24vZG90bmV0L0FTUC5ORVQvTGl2ZUNsaXBib2FyZC9HbG9iYWxDbGlw LyAKPC9hPiZuYnNwO2FzCndlbGwgYXMgPGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxlZm9y Z2UubmV0L3dpa2kvR2xvYmFsQ2xpcCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vZGV2LmV4dGVuc2li bGVmb3JnZS5uZXQvd2lraS9HbG9iYWxDbGlwPC9hPiZuYnNwO2lmCnlvdSBoYXZlbid0IHNlZW4g dGhlbSByZWNlbnRseS4uLiBJIHRoaW5rIHdlJ3JlIGFib3V0IHJlYWR5IHRvIHN0YXJ0IGV4cGFu ZGluZwppbnRvIHRoZSBjaXRhdGlvbnMgc2lkZSBvZiB0aGlzLiA8L3A+Cgo8L2Rpdj4KCjxkaXY+ Cgo8cD4mbmJzcDs8L3A+Cgo8L2Rpdj4KCjxkaXY+Cgo8cD5Db25uZWN0aW5nIHRoaXMgYmFjayB0 byB0aGUgQXRvbWljUlNTLk5FVCBwcm9qZWN0IChvcgp3aGF0ZXZlciB0aGUgZmluYWwgbmFtZSB0 dXJucyBvdXQgdG8gYmUgKE5PVEU6IEkndmUgb2ZmaWNpYWxseSBtb3ZlZCB0aGlzCnByb2plY3Qg dG8gZXh0ZW5zaWJsZWZvcmdlIHdoaWNoIGlzIHRoZSBuZXcgaG9tZSBvZiBBTEwgb2YgbXkgb25n b2luZyBwcm9qZWN0cwo6KSZuYnNwOyZndDsgPGEgaHJlZj0iaHR0cDovL2Rldi5leHRlbnNpYmxl Zm9yZ2UubmV0L3dpa2kvQXRvbWljUlNTLk5FVCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vZGV2LmV4 dGVuc2libGVmb3JnZS5uZXQvd2lraS9BdG9taWNSU1MuTkVUPC9hPiZuYnNwOyksCnRoZSBhYmls aXR5IHRvIHR1cm4gdGhlIE1TIFdlYiBGZWVkIGVuZ2luZSBpbnRvIGFuIEFQUCBkYXRhIHN0b3Jl IGlzCnNpbXBsZSZuYnNwO2Vub3VnaC4mbmJzcDsgQnV0Jm5ic3A7dXNpbmcgRGVtb2tyaXRvcyBh cyB0aGUgcHJpbWFyeSZuYnNwO2RhdGEKc3RvcmUsIGFuZCZuYnNwO3N5bmNyb25pemluZyZuYnNw O3dpdGggdGhlIFdlYiBGZWVkIGVuZ2luZSBicmluZ3MgYWxsIG9mIHRoZQp3b25kZXJmdWxuZXNz Jm5ic3A7dGhhdCBjb21lcyBhbG9uZyB3aXRoIHRoZSBwZXJzaXN0ZW5jZSBsYXllciB2aWEgU1ZO IChhbmQKdGhlcmVmb3JlIGhpc3RvcmljYWwgcGVyc2lzdGVuY2UsIGFzIGxvbmcgYXMgSSZuYnNw O3VuZGVyc3RhbmQgY29ycmVjdGx5IGhvdwpEZW1va3JpdG8ncyBoYW5kbGVzJm5ic3A7cGVyc2lz dGVuY2UgdmlhIFNWTikmbmJzcDt0aGF0cyBidWlsdCBkaXJlY3RseSBpbnRvCkRlbW9rcml0b3Mu IDwvcD4KCjwvZGl2PgoKPGRpdj4KCjxwPiZuYnNwOzwvcD4KCjwvZGl2PgoKPGRpdj4KCjxwPlVu bGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcgWzxhIGhyZWY9Imh0dHA6Ly9tc2RuLm1pY3Jvc29m dC5jb20vbGlicmFyeS9kZWZhdWx0LmFzcD91cmw9L2xpYnJhcnkvZW4tdXMvZmVlZHNhcGkvcnNz L292ZXJ2aWV3cy9tc2ZlZWRzX292dy5hc3AiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1 cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL21zZG4ubWlj cm9zb2Z0LmNvbS9saWJyYXJ5L2RlZmF1bHQuYXNwP3VybD0vbGlicmFyeS9lbi11cy9mZWVkc2Fw aS9yc3Mvb3ZlcnZpZXdzL21zZmVlZHNfb3Z3LmFzcAo8L2E+XSB0aGVyZSBpcyBubyBkaXJlY3Qg Y29uY2VwdCBvZiZuYnNwO2hpc3RvcmljYWwgcGVyc2lzdGVuY2UgaW4gdGhlIFdlYiBGZWVkCmVu Z2luZS48L3A+Cgo8L2Rpdj4KCjxkaXY+Cgo8cD4mbmJzcDs8L3A+Cgo8L2Rpdj4KCjxkaXY+Cgo8 cD48c3Ryb25nPlNlYW4gPC9zdHJvbmc+KGFsc28gY29waWVkKSwgY2FuIHlvdSBjbGFyaWZ5IHRo aXMKb25lIHdheSBvciB0aGUgb3RoZXI/PGJyPgombmJzcDs8L3A+Cgo8L2Rpdj4KCjxkaXY+Cgo8 cD48c3Bhbj5PbiA1LzYvMDYsIDxiPkphbWVzIFRhdWJlcjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0 bzpqdGF1YmVyQGp0YXViZXIuY29tIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmp0YXViZXJAanRhdWJlci5jb208 L2E+ICZndDsKd3JvdGU6PC9zcGFuPiA8L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJw dDsiPjxicj4KRGVtb2tyaXRvcyAtIEFQUCBzZXJ2ZXIgYW5kIFB5dGhvbiBsaWJyYXJ5Ljxicj4K PGJyPgo8YSBocmVmPSJodHRwOi8vanRhdWJlci5jb20vZGVtb2tyaXRvcyIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5odHRwOi8vanRhdWJlci5jb20vZGVtb2tyaXRvcwo8L2E+PGJyPgo8YnI+CkN1cnJlbnRseSBp bXBsZW1lbnRpbmcgYmFzaWMgYXV0aCBzdXBwb3J0IGZvciAwLjQgcmVsZWFzZS48YnI+Cjxicj4K QWxzbyByZWNlbnRseSBzdGFydGVkIG9uIGEgQUpBWC1iYXNlZCBBUFAgY2xpZW50IHRvIGdvIHdp dGggaXQuPGJyPgo8YnI+CkphbWVzPGJyPgotLTxicj4KSmFtZXMKVGF1YmVyJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7CjxhIGhyZWY9Imh0dHA6Ly9qdGF1YmVyLmNvbS8iIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDov L2p0YXViZXIuY29tLzwvYT48YnI+CmpvdXJuZXltYW4gb2Ygc29tZSZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vanRhdWJlci5jb20vYmxvZy8iIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL2p0YXVi ZXIuY29tL2Jsb2cvPC9hPjxicj4KPGJyPgo8YnI+Ck9uIDA1LzA1LzIwMDYsIGF0IDk6MTEgQU0s IFJvYmVydCBTYXlyZSB3cm90ZTo8YnI+Cjxicj4KJmd0Ozxicj4KJmd0OyBJJ3ZlIGJlZW4gd29y a2luZyB0byBhZGQgQXRvbSBzdXBwb3J0IHRvIEZpcmVmb3ggMi4gU29tZSBvdGhlciBGaXJlZm94 IDxicj4KJmd0OyBkZXZzIGFyZSB0b3lpbmcgd2l0aCBleHBvc2luZyBpbnRlcm5hbCBkYXRhIGxp a2UgaGlzdG9yeSBhbmQgYm9va21hcmtzIDxicj4KJmd0OyBhcyBBdG9tIGZlZWRzLjxicj4KJmd0 Ozxicj4KJmd0OyBXaGF0IHNvZnR3YXJlIGFyZSB5b3Ugd3JpdGluZz88YnI+CiZndDs8YnI+CiZn dDsgLS08YnI+CiZndDs8YnI+CiZndDsgUm9iZXJ0IFNheXJlPGJyPgomZ3Q7PGJyPgomZ3Q7ICZx dW90O0kgd291bGQgaGF2ZSB3cml0dGVuIGEgc2hvcnRlciBsZXR0ZXIsIGJ1dCBJIGRpZCBub3Qg aGF2ZSB0aGUKdGltZS4mcXVvdDsgPGJyPgomZ3Q7IDwvcD4KCjwvZGl2PgoKPHA+PGJyPgo8YnIg Y2xlYXI9ImFsbCI+Cjxicj4KLS0gPGJyPgombHQ7TTpELyZndDs8YnI+Cjxicj4KTS4gRGF2aWQg UGV0ZXJzb248YnI+CjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyIgdGFyZ2V0PSJf YmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRo aXMpIj5odHRwOi8vd3d3LnhzbHRibG9nLmNvbS8gPC9hPjwvcD4KCjwvc3Bhbj48L2Rpdj48ZGl2 IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjwvZGl2PgoKCgoKCjwvZGl2PjwvYmxvY2txdW90ZT48 L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5N LiBEYXZpZCBQZXRlcnNvbjxicj48YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iPmh0 dHA6Ly93d3cueHNsdGJsb2cuY29tLzwvYT4K ------=_Part_51819_29412588.1147100113665-- From owner-atom-syntax@mail.imc.org Tue May 09 12:24:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdV0U-0002Tg-7G for atompub-archive@lists.ietf.org; Tue, 09 May 2006 12:24:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdV0S-000176-RU for atompub-archive@lists.ietf.org; Tue, 09 May 2006 12:24:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49G9BZK011230; Tue, 9 May 2006 09:09:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k49G9BY4011229; Tue, 9 May 2006 09:09:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k49G9A3S011222 for ; Tue, 9 May 2006 09:09:10 -0700 (MST) (envelope-from hgranqvist@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k49G998T018386; Tue, 9 May 2006 09:09:09 -0700 Received: from MOU1WNEXMB02.vcorp.ad.vrsn.com ([10.25.12.244]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 09:09:03 -0700 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: What Atom software are you working on? Date: Tue, 9 May 2006 09:09:03 -0700 Message-ID: <45D459DDA07DC442A499A4D46F4939BA01B887D2@MOU1WNEXMB02.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What Atom software are you working on? Thread-Index: AcZwSD8Tt9YGKByRSJi/gnSAwB88EgDOiqCA From: "Granqvist, Hans" To: "Robert Sayre" , "Atom Syntax" X-OriginalArrivalTime: 09 May 2006 16:09:03.0839 (UTC) FILETIME=[E436FEF0:01C67382] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k49G9A3S011223 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Rob, Been working a while on profile drafts how to apply security to Atom feeds/entries, and how to reference these secured items in other protocols, and reference implementations thereof over at http://signedping.com Thanks, Hans > -----Original Message----- > From: owner-atom-syntax@mail.imc.org > [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Robert Sayre > Sent: Friday, May 05, 2006 6:11 AM > To: Atom Syntax > Subject: What Atom software are you working on? > > > I've been working to add Atom support to Firefox 2. Some > other Firefox devs are toying with exposing internal data > like history and bookmarks as Atom feeds. > > What software are you writing? > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > > > From owner-atom-syntax@mail.imc.org Wed May 10 23:30:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1sN-0008VI-6Y for atompub-archive@lists.ietf.org; Wed, 10 May 2006 23:30:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe1sK-0008Ry-QN for atompub-archive@lists.ietf.org; Wed, 10 May 2006 23:30:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B3IHaP097024; Wed, 10 May 2006 20:18:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4B3IH2W097023; Wed, 10 May 2006 20:18:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.192]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B3IHVs097016 for ; Wed, 10 May 2006 20:18:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id t15so74289wxc for ; Wed, 10 May 2006 20:18:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=dVlfEWzs3F78DJ3n1kVLobdXcxA9pSvbF1bLND+R9PfmmQANllX5YEqBI4xJtyf9lzyrKvOfIdZYk73de0ihCALE5tDl2scy0mndU9NpsuiWA2JUDLUJ+H6HBsfthsSS2luak6EOkUPJBb7boyOafA5rMv3Wnd6jQYoAmPASnVU= Received: by 10.70.99.2 with SMTP id w2mr471548wxb; Wed, 10 May 2006 20:18:16 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 34sm166583wra.2006.05.10.20.18.15; Wed, 10 May 2006 20:18:16 -0700 (PDT) Message-ID: <4462ACF3.3000203@gmail.com> Date: Wed, 10 May 2006 20:18:11 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Content and Summary Test 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: X-Spam-Score: 1.9 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 http://www.snellspace.com/wp/?p=316 When some feed readers see an entry that has a atom:content with base64 content AND an atom:summary with text, for some reason they choose to show the raw base64. Test feed here: http://www.snellspace.com/public/contentsummary.xml - James From owner-atom-syntax@mail.imc.org Wed May 10 23:32:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe1uI-0000Vg-Cy for atompub-archive@lists.ietf.org; Wed, 10 May 2006 23:32:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe1uH-00005i-1j for atompub-archive@lists.ietf.org; Wed, 10 May 2006 23:32:06 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B3MUXh097174; Wed, 10 May 2006 20:22:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4B3MUoE097173; Wed, 10 May 2006 20:22:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B3MTv6097165 for ; Wed, 10 May 2006 20:22:30 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id w49so107606pyg for ; Wed, 10 May 2006 20:22:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ptaOVAJSSC1QEaqPWxEmEXq3FMwObekhCOYu6SFugEIj5W5kmhYUOd8nnglvWS85IwEpjqo7M/T4l4lGupOVpfxnL7GR/kFO18PzRYxCYqqX8oQ3sUrTMeJEVvDoSiO38tqErpPH4+Stw7yiUvTHzgb9qEt6/6K+mqIj9k4uWaY= Received: by 10.35.123.2 with SMTP id a2mr472683pyn; Wed, 10 May 2006 20:22:26 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Wed, 10 May 2006 20:22:26 -0700 (PDT) Message-ID: <68fba5c50605102022v7a6d6e8fxaafeb27289f168a8@mail.gmail.com> Date: Wed, 10 May 2006 23:22:26 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: Weekly Posting Summary MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4B3MUv6097168 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.44% | 7 | 41.09% | 100373 | xmlhacker@gmail.com 11.11% | 4 | 12.86% | 31414 | sewe@rbg.informatik.tu-darmstadt.de 11.11% | 4 | 9.60% | 23444 | jasnell@gmail.com 13.89% | 5 | 6.06% | 14807 | pagaltzis@gmx.de 11.11% | 4 | 4.91% | 12001 | tim.bray@sun.com 8.33% | 3 | 4.44% | 10857 | sayrer@gmail.com 2.78% | 1 | 7.25% | 17717 | seanlynd@exchange.microsoft.com 5.56% | 2 | 4.21% | 10293 | djpowell@djpowell.net 5.56% | 2 | 3.97% | 9707 | t.broyer@gmail.com 2.78% | 1 | 1.59% | 3895 | kmarvin@google.com 2.78% | 1 | 1.59% | 3876 | nick@socklabs.com 2.78% | 1 | 1.24% | 3041 | hgranqvist@verisign.com 2.78% | 1 | 1.17% | 2869 | jtauber@jtauber.com --------+------+--------+----------+------------------------ 100.00% | 36 |100.00% | 244294 | Total -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Thu May 11 01:01:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3J7-0002ya-Jw for atompub-archive@lists.ietf.org; Thu, 11 May 2006 01:01:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe3J6-0004EC-68 for atompub-archive@lists.ietf.org; Thu, 11 May 2006 01:01:49 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B4iVv1000894; Wed, 10 May 2006 21:44:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4B4iVN0000893; Wed, 10 May 2006 21:44:31 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav14.bay109.hotmail.com [64.4.19.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B4iUVw000887 for ; Wed, 10 May 2006 21:44:31 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 May 2006 21:44:30 -0700 Message-ID: Received: from 81.179.109.21 by BAY109-DAV14.phx.gbl with DAV; Thu, 11 May 2006 04:44:27 +0000 X-Originating-IP: [81.179.109.21] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <4462ACF3.3000203@gmail.com> Subject: Re: Content and Summary Test Date: Thu, 11 May 2006 04:46:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 11 May 2006 04:44:30.0433 (UTC) FILETIME=[97621D10:01C674B5] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 James M Snell wrote: > When some feed readers see an entry that has a atom:content with base64 > content AND an atom:summary with text, for some reason they choose to > show the raw base64. Yeah, I noticed that when I was testing our image content support. Most feed readers (I tested about a dozen or so) either showed the raw base64 or nothing at all. One couldn't parse my test feed at all when it contained base64-encoded content. Why am I not surprised? Btw, were your tests meant to be using a media type of "applcation/xml" (note the missing 'i')? Regards James From owner-atom-syntax@mail.imc.org Thu May 11 01:22:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe3dX-00046X-G7 for atompub-archive@lists.ietf.org; Thu, 11 May 2006 01:22:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe3dW-0004pG-4w for atompub-archive@lists.ietf.org; Thu, 11 May 2006 01:22:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B55WxM001739; Wed, 10 May 2006 22:05:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4B55WBO001738; Wed, 10 May 2006 22:05:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B55Vjh001730 for ; Wed, 10 May 2006 22:05:32 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so59262wra for ; Wed, 10 May 2006 22:05:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ocxMh77sxY/lOxg3WMIf5FBrIrvdpxx/GOnYL5Uo7jW67CtJfstvlWFnRTAwXlmcPQr9JZLSrtV/Ku7hUh9YH1dCtX8ygcKKWZSKysWjv9yZUQNeuW+mtcLEQ0zaWw/SgPkjLV3Z5hHkZtfX8sXJzXjEnxIwWo39HyeUKEQIsdw= Received: by 10.54.149.10 with SMTP id w10mr542911wrd; Wed, 10 May 2006 22:05:29 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 27sm387709wrl.2006.05.10.22.05.27; Wed, 10 May 2006 22:05:28 -0700 (PDT) Message-ID: <4462C614.6060405@gmail.com> Date: Wed, 10 May 2006 22:05:24 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Content and Summary Test References: <4462ACF3.3000203@gmail.com> In-Reply-To: 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 James Holderness wrote: >[snip] > Yeah, I noticed that when I was testing our image content support. Most > feed readers (I tested about a dozen or so) either showed the raw base64 > or nothing at all. One couldn't parse my test feed at all when it > contained base64-encoded content. Why am I not surprised? > I don't have access to a Windows box right now... how does snarfer do on these tests? > Btw, were your tests meant to be using a media type of "applcation/xml" > (note the missing 'i')? > Oops. Fixed. - James From owner-atom-syntax@mail.imc.org Thu May 11 02:12:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe4Pg-0006ZX-Ju for atompub-archive@lists.ietf.org; Thu, 11 May 2006 02:12:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe4Pf-0006tO-8Y for atompub-archive@lists.ietf.org; Thu, 11 May 2006 02:12:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B626Pn003769; Wed, 10 May 2006 23:02:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4B6260W003768; Wed, 10 May 2006 23:02:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav4.bay109.hotmail.com [64.4.19.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4B626df003761 for ; Wed, 10 May 2006 23:02:06 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 May 2006 23:02:05 -0700 Message-ID: Received: from 81.179.109.21 by BAY109-DAV4.phx.gbl with DAV; Thu, 11 May 2006 06:02:00 +0000 X-Originating-IP: [81.179.109.21] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "atom-syntax" References: <4462ACF3.3000203@gmail.com> <4462C614.6060405@gmail.com> Subject: Re: Content and Summary Test Date: Thu, 11 May 2006 06:04:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 11 May 2006 06:02:05.0646 (UTC) FILETIME=[6E1B3EE0:01C674C0] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 4.9 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 James M Snell wrote: > I don't have access to a Windows box right now... how does snarfer do on > these tests? Displays the summary for the two application/xml tests and the calendar test. Displays the content for the two plaintext tests (although the summary is still optionally viewable in the list view). Displays the image for the base64 test (as with plaintext, the summary can still be seen in the list view). Regards James From owner-atom-syntax@mail.imc.org Mon May 15 18:29:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FflYy-0008HB-KD for atompub-archive@lists.ietf.org; Mon, 15 May 2006 18:29:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FflYx-0000Fs-7c for atompub-archive@lists.ietf.org; Mon, 15 May 2006 18:29:16 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4FMFNb2053778; Mon, 15 May 2006 15:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4FMFNTc053777; Mon, 15 May 2006 15:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4FMFNus053769 for ; Mon, 15 May 2006 15:15:23 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so888909wra for ; Mon, 15 May 2006 15:15:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=IZ4HMOWNSN+2m+Lv60LMB3vzHJ0sL2og5ZPvHaY09MWg9PP778jDMn46PvTMQVKrhXRWXW39OG0uzBU+QuItMC3GDv0I2yeZYz4t5JqCCkEUC1a8hc68YYC/VnFHdVWbHnvvadop/QlYCKULfC6xBaGu7FczKqebJlDfw4Yb5Ag= Received: by 10.54.129.12 with SMTP id b12mr171149wrd; Mon, 15 May 2006 15:15:22 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 15sm241297wrl.2006.05.15.15.15.20; Mon, 15 May 2006 15:15:22 -0700 (PDT) Message-ID: <4468FD76.6050805@gmail.com> Date: Mon, 15 May 2006 15:15:18 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Feed Thread in Last Call 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hey all, I'm happy to announce that the Feed Thread extension (draft -10) [1] has entered Last Call. [2] The thr:count and thr:when extension attributes are back in Draft -10 following the recent on-list discussion and post by Tim Bray affirming that the atom:link element is indeed extensible. I fully recognize that not everyone on list agrees with this approach, but after trying to propertly implement alternatives, re-reading RFC4287 and surveying folks who I know have already done the work necessary to implement Feed Thread, I believe the decision to keep thr:when and thr:count as attributes is the right decision. At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I have also added Feed Thread support to my Wordpress and Roller blog templates. IBM has plans to ship at least one product with Feed Thread support in the not too distant future (our Atom Publishing Protocol interop/test endpoint currently contains support for Feed Thread). If you do or do not want to see Feed Thread move forward as a Proposed Standard, now is the time to step up and make your case. :-) - James [1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt [2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13577&rfc_flag=0 From owner-atom-syntax@mail.imc.org Mon May 15 22:50:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffpdl-0006gN-Df for atompub-archive@lists.ietf.org; Mon, 15 May 2006 22:50:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffpdh-00034w-0n for atompub-archive@lists.ietf.org; Mon, 15 May 2006 22:50:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G2Xik2007683; Mon, 15 May 2006 19:33:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G2Xiwi007682; Mon, 15 May 2006 19:33:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G2Xg1g007676 for ; Mon, 15 May 2006 19:33:43 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1247189pya for ; Mon, 15 May 2006 19:33:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OlLy7keg2uSEwR3zLwn053e8dVcWdNJ8BFjw2osNfgvLP5iATuKyY+xj1fIsi+iu6ge4nqKU3ehRbsu3Qy8/Dtxlo231d4xudVAErJKsn/FftHw3n03fcsZqnunGQtnWvTYCF976AOcjhF0rGgj/h64WoIyohY6djgXkJf4Juhc= Received: by 10.35.107.20 with SMTP id j20mr611641pym; Mon, 15 May 2006 19:33:42 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Mon, 15 May 2006 19:33:42 -0700 (PDT) Message-ID: <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> Date: Tue, 16 May 2006 04:33:42 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: atom-syntax , "Lisa Dusseault" In-Reply-To: <4468FD76.6050805@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4G2Xh1g007677 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On 5/16/06, James M Snell wrote: > > At this point, Feed Thread support has been deployed in Friendster, > Typepad, and MovableType. I thought the working group was fairly clear about the dubious value and placement of these attributes, and you yourself posted that no one was implementing them, they were "strictly informational", and free to be ignored. So you don't think they're important or needed, and then WG doesn't have consensus on them. Even Tim's comments were in the abstract, and not related to feed thread at all. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. From a technical perspective, the interactions between multiple links with the extension attributes remain unspecified. As a client implementor, I suppose I'll find out what exactly they're for whenever I see the already-completed implementations deployed. In my opinion, the document should do more to inform the community on the role of these attributes. > now is the time to step up and make your case. You've merely stated you "believe" that moving these attributes back to the original location is the right decision. That is not a technical rationale. I would expect to see a more compelling reason, given the clear, technical rationales of those against your decision. On an unrelated note, this document contains sections copied verbatim from RFC 4287, and it would be polite and honest to acknowledge that. -- Robert Sayre From owner-atom-syntax@mail.imc.org Mon May 15 23:55:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfqeP-00064J-Rd for atompub-archive@lists.ietf.org; Mon, 15 May 2006 23:55:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfqeM-00058Q-CR for atompub-archive@lists.ietf.org; Mon, 15 May 2006 23:55:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G3iuUS025077; Mon, 15 May 2006 20:44:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G3iuTu025076; Mon, 15 May 2006 20:44:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4G3itSV025049 for ; Mon, 15 May 2006 20:44:55 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 May 2006 03:44:48 -0000 Received: from xdsl-84-44-229-98.netcologne.de (EHLO klangraum) [84.44.229.98] by mail.gmx.net (mp040) with SMTP; 16 May 2006 05:44:48 +0200 X-Authenticated: #163624 Date: Tue, 16 May 2006 05:45:10 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060516034510.GH10609@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4G3iuUS025077 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de * Robert Sayre [2006-05-16 04:45]: > [=E2=80=A6] +1 Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon May 15 23:58:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffqho-0006XN-0r for atompub-archive@lists.ietf.org; Mon, 15 May 2006 23:58:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffqhn-0005Ax-Kn for atompub-archive@lists.ietf.org; Mon, 15 May 2006 23:58:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G3o9vd026249; Mon, 15 May 2006 20:50:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G3o9tL026248; Mon, 15 May 2006 20:50:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G3o8vE026242 for ; Mon, 15 May 2006 20:50:08 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so936502wra for ; Mon, 15 May 2006 20:50: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:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=k0+Hk+gdbz4NLLAR1wLOl38STyWM2O6bPwsPRFrzJZG19/kKNBIzont5JSPrPSJY63gsi9YmI3EEjJ1/OLSuObMEinV430SLbMVjGGhPSkil1yumIuTt69JHx9mIkbEcmxmoeE1ndeYSW/N5GDgJPOtRuCfFtIAntPqiESA/yJ8= Received: by 10.54.80.18 with SMTP id d18mr520905wrb; Mon, 15 May 2006 20:50:08 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g2sm390481wra.2006.05.15.20.50.06; Mon, 15 May 2006 20:50:07 -0700 (PDT) Message-ID: <44694BEB.6090203@gmail.com> Date: Mon, 15 May 2006 20:50:03 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax CC: Lisa Dusseault Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> In-Reply-To: <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Robert Sayre wrote: > On 5/16/06, James M Snell wrote: >> >> At this point, Feed Thread support has been deployed in Friendster, >> Typepad, and MovableType. > > I thought the working group was fairly clear about the dubious value A few of the individuals on the WG had a problem with the placement of the attributes due to various limitations of a few existing Atom 1.0 implementations. None of the folks I know of that have actually implemented support for the extension has had any problems with them. > and placement of these attributes, and you yourself posted that no one > was implementing them, they were "strictly informational", and free to > be ignored. So you don't think they're important or needed, and then > WG doesn't have consensus on them. Even Tim's comments were in the > abstract, and not related to feed thread at all. > I never posted that no one was implementing the attributes. Quite on the contrary, you can pull up quite a few TypePad and Friendster feeds that are using them. You can also look at Sam Ruby's personal blog... or look at my wordpress and roller blog feeds. The attributes are being used. What I did say was that I wasn't aware of anyone using multiple replies links in a single entry and that I personally did not intend on publishing any feeds that used multiple replies links in a single entry. >> From a technical perspective, the interactions between multiple links > with the extension attributes remain unspecified. As a client > implementor, I suppose I'll find out what exactly they're for whenever > I see the already-completed implementations deployed. In my opinion, > the document should do more to inform the community on the role of > these attributes. > The interaction is unspecified because there is no interaction. As I've said before, the thr:count and thr:when attributes apply only to the atom:link element to which they belong. The slash:comments extension element can be used to provide a global comment count that operates independently of the replies link. The roles of the attributes are clearly specified in the spec. There are existing feeds in deployment that demonstrate their use. . > On an unrelated note, this document contains sections copied verbatim > from RFC 4287, and it would be polite and honest to acknowledge that. > My apologies, I thought I had already done so. It will be fixed in the next revision. - James From owner-atom-syntax@mail.imc.org Tue May 16 01:32:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfsAU-0005Hy-4f for atompub-archive@lists.ietf.org; Tue, 16 May 2006 01:32:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfsAR-0008PO-PR for atompub-archive@lists.ietf.org; Tue, 16 May 2006 01:32:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5MPev045986; Mon, 15 May 2006 22:22:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G5MPrH045985; Mon, 15 May 2006 22:22:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5MONZ045971 for ; Mon, 15 May 2006 22:22:24 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1276392pya for ; Mon, 15 May 2006 22:22:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FPKUddibfmSMAB9C0HE23C7xg5Uy92AW7D7eNjmyPwkfLyMic98oZUJMdvP/F/xnSvs7Bi88Xz9rXnuUgDpq2p1AEvWfOToA6nNM6bOF2Xft7xbry4kav5lZa8ZAboh9y7FpHgx3x7odjKqDget/TusKqLMrRFz6UjZaz1B2Qrc= Received: by 10.35.12.13 with SMTP id p13mr740309pyi; Mon, 15 May 2006 22:22:23 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Mon, 15 May 2006 22:22:23 -0700 (PDT) Message-ID: <68fba5c50605152222m39486e29i5d783e6c3d421fff@mail.gmail.com> Date: Tue, 16 May 2006 07:22:23 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: atom-syntax , "Lisa Dusseault" In-Reply-To: <44694BEB.6090203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4G5MONZ045980 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On 5/16/06, James M Snell wrote: > > A few of the individuals on the WG had a problem with the placement of > the attributes due to various limitations of a few existing Atom 1.0 > implementations. Right, and you're breaking them because...? You haven't coherently explained your reason for moving them back. After all, you agreed with the WG and updated the document, but now you've moved them back for unexplained reasons and pointed at deployments. > None of the folks I know of that have actually > implemented support for the extension has had any problems with them. I find your answers most unsatisfying and full of circular reasoning that serves mostly to dance around the fact that you and a few others have already deployed. That's been your argument for months now, and the IETF process has a way to deal with that situation: Informational. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 16 01:59:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfsaE-00042Q-KB for atompub-archive@lists.ietf.org; Tue, 16 May 2006 01:59:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfsaD-0000sX-8P for atompub-archive@lists.ietf.org; Tue, 16 May 2006 01:59:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5nuCa052450; Mon, 15 May 2006 22:49:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G5nu6R052449; Mon, 15 May 2006 22:49:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G5ntfm052442 for ; Mon, 15 May 2006 22:49:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so992553wri for ; Mon, 15 May 2006 22:49:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RRADH7oNpiJP/qNaYrBOU9PYJvmfPFTMa0bA4jnrepvdGbJkUnU2ClR83Kj2ZS0751LnoykI/Z0e+5z26uX6z5Aph3/DsGwVM+Npv68Kb/5YY48j2EYS5dq3zUaBeHJ032th80So9HVhx4ffCiPOdNFIDFQioHbkt8+34NOyWhM= Received: by 10.54.121.19 with SMTP id t19mr7079925wrc; Mon, 15 May 2006 22:49:55 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm745592wrl.2006.05.15.22.49.54; Mon, 15 May 2006 22:49:55 -0700 (PDT) Message-ID: <446967FE.60808@gmail.com> Date: Mon, 15 May 2006 22:49:50 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 CC: atom-syntax , Lisa Dusseault Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <68fba5c50605152222m39486e29i5d783e6c3d421fff@mail.gmail.com> In-Reply-To: <68fba5c50605152222m39486e29i5d783e6c3d421fff@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Robert Sayre wrote: > On 5/16/06, James M Snell wrote: >> >> A few of the individuals on the WG had a problem with the placement of >> the attributes due to various limitations of a few existing Atom 1.0 >> implementations. > > Right, and you're breaking them because...? You haven't coherently > explained your reason for moving them back. After all, you agreed with > the WG and updated the document, but now you've moved them back for > unexplained reasons and pointed at deployments. > Very simple reasons: the attributes are easier to implement, are allowed by RFC4287 and are being used in real deployments. That's more than enough justification for me. I agreed in principle with the arguments presented by David and Aristotle; Accordingly, I drafted up an alternative; Implemented the alternative; Compared the two implementations and the pros/cons of each; Discussed those on the mailing list; and decided in the end that the risk/benefit weighed in favor of the attributes. After testing a number of Atom implementations, I have yet to find one that is "broken" as a result of using the attributes. - James From owner-atom-syntax@mail.imc.org Tue May 16 02:09:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfskX-0007Yq-DK for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:09:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfskS-0001L2-Tj for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:09:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G60fZX054797; Mon, 15 May 2006 23:00:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G60flC054796; Mon, 15 May 2006 23:00:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4G60eZ0054761 for ; Mon, 15 May 2006 23:00:40 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 May 2006 06:00:34 -0000 Received: from xdsl-213-196-246-167.netcologne.de (EHLO klangraum) [213.196.246.167] by mail.gmx.net (mp015) with SMTP; 16 May 2006 08:00:34 +0200 X-Authenticated: #163624 Date: Tue, 16 May 2006 08:00:56 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060516060056.GI10609@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <44694BEB.6090203@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4G60fZX054797 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 * James M Snell [2006-05-16 06:00]: > The slash:comments extension element can be used to provide a > global comment count that operates independently of the replies > link. Supply per-link information as namespaced attributes on link elements, if you must. I don=E2=80=99t like the idea, but it seems there is unfortunately no way to associate link-specific RFC 4287 Simple or Structured Extension Elements with a link. (But why `thr:when` rather than `thr:updated`?) However, don=E2=80=99t neglect to provide a way to supply a global reply count. That would break the argument that the FTE covers nearly every threading use cases without having to resort to a gaggle of other extensions and hence weaken FTE=E2=80=99s position, IMO. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 16 02:20:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfsvN-0001io-G3 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:20:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfsvM-0001jD-5C for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:20:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G6BmdA057428; Mon, 15 May 2006 23:11:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G6BmRU057427; Mon, 15 May 2006 23:11:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G6BlHU057421 for ; Mon, 15 May 2006 23:11:47 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so1283907pya for ; Mon, 15 May 2006 23:11:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B8BZnIyC6QF7RtPX5XtZLxEiOaVM44ybKz1Et4hk66nt7MvD5nUSo46K7l1qa45PdovkuEpRz7fww0XO+WKcM+PiPJ6W6exsix8qkR136Mi6/LHYEnZ48neNugALq0wZrrguGaDaKXoWBOMlC0dmcuvu1Gwxj9toqSImI2YJBZY= Received: by 10.35.60.15 with SMTP id n15mr811910pyk; Mon, 15 May 2006 23:11:46 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Mon, 15 May 2006 23:11:46 -0700 (PDT) Message-ID: <68fba5c50605152311m3f12cc6bsbcb60c7a20d6cfb8@mail.gmail.com> Date: Tue, 16 May 2006 08:11:46 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: atom-syntax , "Lisa Dusseault" In-Reply-To: <446967FE.60808@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <68fba5c50605152222m39486e29i5d783e6c3d421fff@mail.gmail.com> <446967FE.60808@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4G6BlHU057422 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On 5/16/06, James M Snell wrote: > > Very simple reasons: the attributes are easier to implement, Speaking as an actual, rather than alleged, client implementer, I find this assertion ridiculous and dishonest. > are allowed by RFC4287 and are being used in real deployments. So, the argument is that it's already deployed, then? It looks like you agree with me. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 16 02:28:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fft32-0003zf-Rt for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:28:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fft31-00023G-GC for atompub-archive@lists.ietf.org; Tue, 16 May 2006 02:28:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G6IDFp058830; Mon, 15 May 2006 23:18:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4G6IDkl058829; Mon, 15 May 2006 23:18:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4G6ICvX058821 for ; Mon, 15 May 2006 23:18:12 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so953705wra for ; Mon, 15 May 2006 23:18:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=H41qDvXQ6X/sxDcgsHve5LRwk1Imbmn8P523sxGEv+wvQlagC1cQxcWiK/jipmQkAvR0IZZ8waIiXru498WwvW6Bhj0r+x6BLetPDHWC1SbJJcRIep5ypHtBncrmNmSL+nTe3DxDRvzlsQPzXTW7foxrHq4DjSHmMzqkIEPgk04= Received: by 10.54.126.1 with SMTP id y1mr4522602wrc; Mon, 15 May 2006 23:18:12 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g9sm783190wra.2006.05.15.23.18.11; Mon, 15 May 2006 23:18:11 -0700 (PDT) Message-ID: <44696E9F.7040209@gmail.com> Date: Mon, 15 May 2006 23:18:07 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <20060516060056.GI10609@klangraum> In-Reply-To: <20060516060056.GI10609@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4G6IDFp058830 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a A. Pagaltzis wrote: > * James M Snell [2006-05-16 06:00]: >> The slash:comments extension element can be used to provide a >> global comment count that operates independently of the replies >> link. >=20 > Supply per-link information as namespaced attributes on link > elements, if you must. I don=E2=80=99t like the idea, but it seems ther= e > is unfortunately no way to associate link-specific RFC 4287 > Simple or Structured Extension Elements with a link. (But why > `thr:when` rather than `thr:updated`?) >=20 RFC4287 does not forbid simple or structured extension elements on link. > However, don=E2=80=99t neglect to provide a way to supply a global repl= y > count. That would break the argument that the FTE covers nearly > every threading use cases without having to resort to a gaggle of > other extensions and hence weaken FTE=E2=80=99s position, IMO. I will consider adding a thr:count element to the spec to cover the global count case. - James From owner-atom-syntax@mail.imc.org Tue May 16 07:26:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxgv-0005xO-AV for atompub-archive@lists.ietf.org; Tue, 16 May 2006 07:26:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffxgs-0008MS-JO for atompub-archive@lists.ietf.org; Tue, 16 May 2006 07:26:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GB9cPQ027242; Tue, 16 May 2006 04:09:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GB9clD027241; Tue, 16 May 2006 04:09:38 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GB9awS027209 for ; Tue, 16 May 2006 04:09:37 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060516110930.JEXF29343.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 16 May 2006 12:09:30 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060516110930.XKHY24467.aamtaout02-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Tue, 16 May 2006 12:09:30 +0100 Date: Tue, 16 May 2006 12:09:31 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1228709845.20060516120931@djpowell.net> To: "Sylvain Hellegouarch" CC: atom-syntax@imc.org Subject: Re: Feed update mechanism In-Reply-To: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.com> References: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Tuesday, May 16, 2006, 11:18:04 AM, Sylvain Hellegouarch wrote: > Hi everyone, > These days It seems that when UAs request a server to check if a feed has > changed the server responds with either an HTTP 304 Not Modified status > code or by returning the updated feed. > It looks to me as a problem if only one or a couple of entries have been > updated within the feed as it wastes so much bandwith specially when the > said feed contains all entries being produced on the server. Check out "A-IM: feed" [1]. It is already implemented by lots of aggregators, and it is trivial for client implementors to support. [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html -- Dave From owner-atom-syntax@mail.imc.org Tue May 16 08:08:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyLN-0000A6-SI for atompub-archive@lists.ietf.org; Tue, 16 May 2006 08:08:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyLM-0002vq-HE for atompub-archive@lists.ietf.org; Tue, 16 May 2006 08:08:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GBtnfQ038030; Tue, 16 May 2006 04:55:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GBtnZp038029; Tue, 16 May 2006 04:55:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+zJWAWQ9KzEK+hnI0lgqsVN45IvrnR6ew@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GBtmTG038022 for ; Tue, 16 May 2006 04:55:48 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19IiIOp02EVxlnhXg1Y1YiywDzcXKL1OO0@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4GBtlZK019876 for ; Tue, 16 May 2006 06:55:47 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4GBtlnG019874; Tue, 16 May 2006 12:55:47 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 16 May 2006 12:55:47 +0100 (BST) Message-ID: <35618.194.221.74.7.1147780547.squirrel@mail1.python-hosting.com> In-Reply-To: <1228709845.20060516120931@djpowell.net> References: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.com> <1228709845.20060516120931@djpowell.net> Date: Tue, 16 May 2006 12:55:47 +0100 (BST) Subject: Re: Feed update mechanism From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi Dave, > Check out "A-IM: feed" [1]. It is already implemented by lots of > aggregators, and it is trivial for client implementors to support. > > [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html Very nice article indeed and it shows I'm not the only wondering about this. The A-IM idea is pretty neat and efficient apparently. I'll give it a look. Thanks, - Sylvain From owner-atom-syntax@mail.imc.org Tue May 16 10:20:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0Pb-0003KH-PG for atompub-archive@lists.ietf.org; Tue, 16 May 2006 10:20:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffy0E-0001Nt-SV for atompub-archive@lists.ietf.org; Tue, 16 May 2006 07:46:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffxl3-0004Q6-GT for atompub-archive@lists.ietf.org; Tue, 16 May 2006 07:30:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GAI6ox015726; Tue, 16 May 2006 03:18:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GAI6KK015725; Tue, 16 May 2006 03:18:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+WxPon4TYZx0zQELbK7NMIuUq75WCOtkY@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GAI5FR015718 for ; Tue, 16 May 2006 03:18:05 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19RCVQfTP7QdmUC3PFibI4tLsLaX1+2CVs@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4GAI4gu016964 for ; Tue, 16 May 2006 05:18:05 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4GAI4IK016962; Tue, 16 May 2006 11:18:04 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 16 May 2006 11:18:04 +0100 (BST) Message-ID: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.com> Date: Tue, 16 May 2006 11:18:04 +0100 (BST) Subject: Feed update mechanism From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.1 (-) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Hi everyone, These days It seems that when UAs request a server to check if a feed has changed the server responds with either an HTTP 304 Not Modified status code or by returning the updated feed. It looks to me as a problem if only one or a couple of entries have been updated within the feed as it wastes so much bandwith specially when the said feed contains all entries being produced on the server. Below are ideas I had about that issue. Nothing formal. PROPOSAL 1 ========== 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again and provide the If-Modified-Since header a. No changes done, the server returns a 304 Not Modified b. The server checks which entries have been updated or published since that date and returns a feed containing only those. The UA updates its copy of the feed with the incoming data. The big issue with this algorithm is that it adds semantic to the HTTP caching system by expecting the UA to update its copy of the feed instead of simply replacing it. Although specific aggregators could do it, it is more than likely that some clients would just replace their copy of the feed and confuse the end user. PROPOSAL 2 ========== 1. An UA requests the feed for the first time, the server returns the full current feed. The UA stores it in its cache 2. The UA requests the feed again but provides a time range like this: http://host/feed?after=2003-12-13T18:30:02Z&before=2003-12-13T19:30:02Z a. No changes done, the server returns a 304 Not Modified b. If entries have been published or updated in the time range, then return a feed with those only. Of course, one might only pass either 'after' or 'before'. The problem with this proposal is to add parameters to the URI which might not be handled by the server. There are a few ways to handle that: * The UA could also use the OPTIONS method from HTTP to check if the server supports the said URI. * The client sends the requests and the server could return 400 Bad Request if it cannot handle it. In order to deal with those proposals we could add a simple extension to a feed such as When receiving the feed for the first time the client would know if it can either request for: * full => default to fetch the complete feed each time when it has been modified. The default behavior as it exists today. * incremental => the server says it can serve entries published or updated after a given date (equivalent to using only the 'after' parameter in PROPOSAL 2 or PROPOSAL 1) * chunk => the server says it can serve feed of entries published or updated between two dates (as explained in PROPOSAL 2) These are just some thoughts and there might already be ways of dealing with this. If not I'd be happy to hearing your feedback. - Sylvain http://www.defuze.org From owner-atom-syntax@mail.imc.org Tue May 16 16:06:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5oQ-000315-MW for atompub-archive@lists.ietf.org; Tue, 16 May 2006 16:06:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5oP-00045G-B1 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 16:06:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJsHuN045613; Tue, 16 May 2006 12:54:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GJsHUm045612; Tue, 16 May 2006 12:54:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GJsFsu045606 for ; Tue, 16 May 2006 12:54:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 16 May 2006 12:53:22 -0700 To: Atom WG From: The IESG Subject: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from an individual submitter to consider the following document: - 'Atom Threading Extensions ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt From owner-atom-syntax@mail.imc.org Tue May 16 17:56:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7XC-0007OS-5z for atompub-archive@lists.ietf.org; Tue, 16 May 2006 17:56:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7XA-0001bx-R6 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 17:56:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GLeBo2066323; Tue, 16 May 2006 14:40:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GLeBNd066322; Tue, 16 May 2006 14:40:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GLe7t7066300; Tue, 16 May 2006 14:40:08 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> Date: Tue, 16 May 2006 14:39:58 -0700 To: "Robert Sayre" , "James M Snell" From: Paul Hoffman Subject: Re: Feed Thread in Last Call Cc: atom-syntax , "Lisa Dusseault" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 At 4:33 AM +0200 5/16/06, Robert Sayre wrote: >I thought the working group was fairly clear about the dubious value >and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. >So you don't think they're important or needed, and then >WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. In the IETF, individuals can submit documents to become RFCs without those documents being Working Group items. This document (and all of the other format extension documents out there) fall into that category. If the author asks an Area Director to have the document published as a standards-track RFC, the AD will most likely ask for input on any relevant mailing list, including any existing WG mailing lists. >You don't have to listen to the WG, but if one or two WG members are >going to deploy and then standardize whatever they've done, that's an >informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 16 18:15:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7pB-000177-6V for atompub-archive@lists.ietf.org; Tue, 16 May 2006 18:15:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7p8-0002g5-QX for atompub-archive@lists.ietf.org; Tue, 16 May 2006 18:15:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GM3pwW070808; Tue, 16 May 2006 15:03:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GM3pHo070807; Tue, 16 May 2006 15:03:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GM3oCB070784 for ; Tue, 16 May 2006 15:03:50 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so93821pyf for ; Tue, 16 May 2006 15:03:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HyeoDUR4PsYKJcgtL/T9cNU5J66L27mwzC0ZYiCdtg9Gt9Z+xeiI0x9IiPk0yJwpg8i70ie8GUmTkbDPGjlbz3IoLj0jVZdFbYyBVYCtFSwLzg+1R10gyyhu/F3GXT19np6uuvPIcUOPNYwf5oirowsaHaFS6wS4qWnyitsOQMk= Received: by 10.35.43.10 with SMTP id v10mr262517pyj; Tue, 16 May 2006 15:03:47 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 16 May 2006 15:03:47 -0700 (PDT) Message-ID: <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> Date: Wed, 17 May 2006 00:03:47 +0200 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Feed Thread in Last Call Cc: "James M Snell" , atom-syntax , "Lisa Dusseault" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GM3oCB070801 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On 5/16/06, Paul Hoffman wrote: > At 4:33 AM +0200 5/16/06, Robert Sayre wrote: > >I thought the working group was fairly clear about the dubious value > >and placement of these attributes, > > For the benefit of Lisa, who is the sponsoring AD for this document, > please list links to those messages. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. > >So you don't think they're important or needed, and then > >WG doesn't have consensus on them. > > Quite true, but it is true because there has never been a call for > consensus on the document, and there won't be in the future. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a "proposed standard" explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its "individual" contributors. >>You don't have to listen to the WG, but if one or two WG members are >>going to deploy and then standardize whatever they've done, that's an >>informational document. > > That is not true. If it is a protocol or a format, standards track is > also appropriate. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 16 19:07:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg8dc-0001Zm-8V for atompub-archive@lists.ietf.org; Tue, 16 May 2006 19:07:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg8da-0005G2-Ow for atompub-archive@lists.ietf.org; Tue, 16 May 2006 19:07:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GMuGDH081637; Tue, 16 May 2006 15:56:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GMuGVG081634; Tue, 16 May 2006 15:56:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GMuBXw081611 for ; Tue, 16 May 2006 15:56:15 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so86981wra for ; Tue, 16 May 2006 15:56: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:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DakamotY14AwBPBrFTYyIlbWcszquYYQZjvWSmP3NhPe9XLUkkRrX6/ECMXOs89jO6nTyd0DMq4kkj4U5LmkccDB/46BUl83gUOcma0zj1BWZK+tY0xbMOnyrGZ/iLMZpYCiDym4/Jvo8ML5NHyTMvYKaICRRGXTGclUuuBNSRs= Received: by 10.54.127.16 with SMTP id z16mr278294wrc; Tue, 16 May 2006 15:56:06 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 35sm1210408wra.2006.05.16.15.56.05; Tue, 16 May 2006 15:56:06 -0700 (PDT) Message-ID: <446A587D.8030107@gmail.com> Date: Tue, 16 May 2006 15:55:57 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Robert Sayre CC: Paul Hoffman , atom-syntax , Lisa Dusseault Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> In-Reply-To: <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Robert Sayre wrote: >[snip] > Looks like the IETF wants to publish a "proposed standard" explicitly > designed to break a very popular implementation, with no technical > reason. I think that speaks volumes about the IETF, its management, > and the quality of its "individual" contributors. > "...explicitly designed to break a very popular implementation"!? Give me a break. I've been purposefully judicious lately not to respond to crap like this but given the Last Call status on the spec, I think several very clear points need to be made: 1. My decision to use the attributes has absolutely nothing to do with Microsoft's implementation. In fact, the attributes were introduced to the spec *before* I knew any details about the Microsoft implementation. Any claims to the contrary are false. Any claims that I *explicitly designed* the extension to break a particular vendor implementation borders on the downright absurd. 2. Microsoft's implementation is no more "broken" by the use of the attributes than any other feed reader implementation that has not been specifically modified to support the extensions. I use Liferea, it can't do anything with the thr:count or thr:when attributes either. I guess that means I "exlicitly designed" the spec to break Liferea as well? Microsoft's implementation doesn't support multiple enclosures, so I guess RFC4287 was "explicitly designed" to break their implementation? Please, enough. I asked Byrne Reese if he could load up Sam Ruby's personal blog feed in IE7 and capture a screenshot. Sam's feed uses the thr:count and thr:when attributes. IE7 worked as expected, properly ignoring the extensions it does not understand. http://www.snellspace.com/public/ie7screen.png What's broken? - James From owner-atom-syntax@mail.imc.org Tue May 16 19:50:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg9JX-0000ff-8x for atompub-archive@lists.ietf.org; Tue, 16 May 2006 19:50:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg9JV-0008EA-U6 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 19:50:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GNc8qG090471; Tue, 16 May 2006 16:38:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4GNc8io090470; Tue, 16 May 2006 16:38:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4GNc7xA090454 for ; Tue, 16 May 2006 16:38:07 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so108918pyf for ; Tue, 16 May 2006 16:38:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aXP2oPiYkSoeW33aYqhatc62AQLvRdbFokXyIYyE5Iy06pUaQVcPkT/UPhwQcfsX/i3oavMOerkDcg48L8yJXjQ9z3uXNtkX53Oa4bjhibKbg/HJQvHYYDsgWLw7fBqgeV/NNQxaKWIVkR9OM3LDEJUiT+r494nbHeDkFYIqMY0= Received: by 10.35.101.9 with SMTP id d9mr354429pym; Tue, 16 May 2006 16:38:07 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 16 May 2006 16:38:07 -0700 (PDT) Message-ID: <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> Date: Wed, 17 May 2006 01:38:07 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: "Paul Hoffman" , atom-syntax , "Lisa Dusseault" In-Reply-To: <446A587D.8030107@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4GNc8xA090457 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 5/17/06, James M Snell wrote: > > What's broken? Do you think the AD and this WG are dumb? Why are you setting up such an obvious strawman? Congratulations, your extension didn't break Atom. The point is that your extension is broken. You're including attributes in that document that you know won't be visible to a large number of implementations. You have no technical reason that makes that location compelling, and several WG members have questioned whether this document adequately covers the area in question. In fact, you appear unable to explain the rationale behind any technical decision without resorting to circular reasoning, logical fallacies, and claims that are outright false. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 16 20:25:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg9qi-0004q2-Pe for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:25:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg9qh-0002Qn-9v for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:25:12 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0EMeG097780; Tue, 16 May 2006 17:14:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H0EMaS097779; Tue, 16 May 2006 17:14:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4H0EKGZ097749 for ; Tue, 16 May 2006 17:14:21 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 May 2006 00:14:15 -0000 Received: from xdsl-81-173-169-206.netcologne.de (EHLO klangraum) [81.173.169.206] by mail.gmx.net (mp043) with SMTP; 17 May 2006 02:14:15 +0200 X-Authenticated: #163624 Date: Wed, 17 May 2006 02:14:38 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060517001438.GB1714@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4H0EMeG097780 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 * Robert Sayre [2006-05-17 01:50]: > You have no technical reason that makes that location > compelling, and several WG members have questioned whether this > document adequately covers the area in question. I have to disagree that there is no technical reason. There is no way to sanely associate additional information with a link element. I suggested an approach based on cross-referencing with the `href` value, but interactions with xml:base invalidate that approach. Other than `href`, there is no other hook on `atom:link` which could be used for cross-referencing without resorting to microparsing hacks. The root of the problem is a miniscule omission in RFC 4287: Sec 6.4. does not list `atom:link` as a location for Metadata elements. It should have. The effect is that links in Atom can only be extended at the XML level, not at the model level. There is no other reasonable choice for the FTE than to supply this information as namespaced attributes on the link element. This is now clear. I hate the idea as much as you do, but RFC 4287 is what it is. > In fact, you appear unable to explain the rationale behind any > technical decision without resorting to circular reasoning, > logical fallacies, and claims that are outright false. That doesn=E2=80=99t mean there is *no* reason for any of these technical decisions. But I agree that James has advocated the position he chose on this particular issue extremely poorly, just as you=E2=80=99d have done your own argument a favour by omitting your interpretation of the matter as vendor politics. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 16 20:32:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg9xP-0007Ei-0P for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:32:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg9xN-00032W-Gh for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:32:06 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0KJUI098986; Tue, 16 May 2006 17:20:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H0KJ7b098985; Tue, 16 May 2006 17:20:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0KId3098959 for ; Tue, 16 May 2006 17:20:19 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (unknown [83.70.255.53]) by chilco.textdrive.com (Postfix) with ESMTP id C1E4EDBCCB; Wed, 17 May 2006 00:20:12 +0000 (UTC) Message-ID: <446A6C39.1090706@dehora.net> Date: Wed, 17 May 2006 01:20:09 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Atom WG CC: The IESG Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the > following document: > > - 'Atom Threading Extensions ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt I'm -0 this becoming a Proposed Standard. I think this is really cool, has room for interop problems, probably has security issues, and thus is arguably premature/innovative and could be considered informational. One reason I think it's cool is not for commenting support but for cheap full duplex/reliable messaging - traditionally a SOAP use case. FTR, I have no implementation experience with Feed Thread, haven't studiously followed the discussion on atom-syntax and that basis feel my opinion doesn't count for that much. == Multiple references In particular the RNC: in-reply-to = element thr:in-reply-to { atomCommonAttributes, ( ref, source? | href, type? | ref, source?, href, type? ) } varies in co-occurrence constraints. No one attribute seems to be required in all cases, which is a problem imo (if I'm wrong I'll argue I still have a point that it's unclear what an implementor should look for). I think this will be an interop headache and that either ref or href should always be required. Naturally ref to atom:id is to spec the right choice, but in practice it seems the first thing anyone will want to do unless they are the authority for the comment *and* the entry is pull down what's being replied to via href. Otoh, mandating ref implies as yet undeployed/unstandardised lookup/query services for atom:id - we have enough experience now with identity lookup services (CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service won't ever be deployed uniformly, or will be deployed in a way that isn't some kind of SPOF or business model or outright failure. That, or the feature will end being limited to local cases where ref is preferred over href (point to point integrations come to mind, hence the mention of SOAP). This of course is fallout from the way identity in Atom is specced, which is also a hedge. Feed Thread imvho should consider getting off the fence on id v link and providing guidance for follow on extensions. == @rel optionality [[[ allow Atom clients that are not familiar with the in-reply-to extension to know that a relationship exists between the entry and the resource being responded to, publishers are advised to consider including a "related" link referencing a representation of the resource identified by the in-reply-to element. ]]] I think to do anything useful with this relation you would have had enough code written to switch on thr:in-reply-to to begin with. It could be struck. == Interop There are multiple publishing options in terms of how to associate comments with entries/comments. That this hasn't bitten anyone yet seems to me to be a combination/result of lack of implementations targeting the feature, Atom's mU policy for extensions, and (possibly) a lack of experience with comment aggregation across publishing and aggregating authorities. Do the WG believe this will work out with multiple authorities using multiple stacks? == Security [[[ As this specification defines an extension to the Atom Syndication Format, it is subject to the same security considerations as defined in [RFC4287]. ]]] I have a serious enough quibble with this statement (the ddos attack note notwithstanding). As an atom foreign markup extension, it's true on the face of things, but the thr:reply-to semantics introduce attribution/repudiation issues as well as providing aggregator/planet spamming options. IOW thr:in-reply-to seems to standardise the same attack/spam vectors we see in mail for feeds and this needs to be acknowledged given spam mail is a multi-billion dollar sinkhole (or industry depending on the pov). That's a dramatic way to state things sure, but not without some truth. So - where's the digest/sig hook? James, you know this stuff... :) cheers Bill From owner-atom-syntax@mail.imc.org Tue May 16 20:57:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgALu-0007Xi-7T for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:57:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgALs-0004HC-Sv for atompub-archive@lists.ietf.org; Tue, 16 May 2006 20:57:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0k6jj004413; Tue, 16 May 2006 17:46:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H0k6Ut004412; Tue, 16 May 2006 17:46:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H0k5pF004398 for ; Tue, 16 May 2006 17:46:06 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so118728pyf for ; Tue, 16 May 2006 17:46:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aGbEuFoBxcWvBJz9ijh2NvwG5+Jfhj1yySk5XyoPdS6Ytd9BIptdWZsE9bn4l290LmWM3ay2EwO3LGkEk02atJJx9hDsaaqjNdWWMvlr+MGSUOc0Cd/upyYx9TbRGf3fw3p5M+KqAvTZBsxk0GaUROlITpEcK4mrGMjLSdwefLY= Received: by 10.35.101.9 with SMTP id d9mr407433pym; Tue, 16 May 2006 17:46:05 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 16 May 2006 17:46:05 -0700 (PDT) Message-ID: <68fba5c50605161746v45442db4ma5dcbd1ed37b15f1@mail.gmail.com> Date: Wed, 17 May 2006 02:46:05 +0200 From: "Robert Sayre" To: atom-syntax Subject: Re: Feed Thread in Last Call In-Reply-To: <20060517001438.GB1714@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <20060517001438.GB1714@klangraum> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4H0k6pF004402 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On 5/17/06, A. Pagaltzis wrote: > > > I have to disagree that there is no technical reason. > > There is no way to sanely associate additional information with a > link element. Sure there is, and it's the way James did it. Is the information valuable? Does the spec cover cardinality issues? Is the link element useful here? Was the spec less effective in its previous incarnation? The answer to all of these questions is no. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 16 21:20:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgAi2-0007Hh-Pl for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:20:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgAi1-0005Lq-6a for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:20:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H15DBO008302; Tue, 16 May 2006 18:05:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H15DZc008301; Tue, 16 May 2006 18:05:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H15CJr008286 for ; Tue, 16 May 2006 18:05:13 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id t5so85321wxc for ; Tue, 16 May 2006 18:05:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oHBgjLcAO4i0AUhJwgOUDdP6NHBOV4x0YsVvQnaUj0rkFr4wnU5pz+lAI0cO49t7IiG0YWDhMHLNlqIUgs23OAJcXEzj25QLL+SwnVMbtqvNrASikqCmQNfJtrrrvgUaozWB6wrBd1iirOVYz83T7GdgYiv1M8b4bqMbWjPHeH0= Received: by 10.70.54.20 with SMTP id c20mr472756wxa; Tue, 16 May 2006 18:05:12 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id h11sm1536500wxd.2006.05.16.18.05.10; Tue, 16 May 2006 18:05:11 -0700 (PDT) Message-ID: <446A76C4.2060808@gmail.com> Date: Tue, 16 May 2006 18:05:08 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom WG , The IESG Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) References: <446A6C39.1090706@dehora.net> In-Reply-To: <446A6C39.1090706@dehora.net> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4H15DBO008302 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Bill, Thank you very much for the detailed feedback. Comments inline. Bill de h=D3ra wrote: >[snip] > I'm -0 this becoming a Proposed Standard. I think this is really cool, > has room for interop problems, probably has security issues, and thus i= s > arguably premature/innovative and could be considered informational. >=20 I am not opposed to informational status for the extension. I would prefer Standards Track, of course, but in general, In general, I have a number of deep concerns over whether or not there is enough of a consensus in the Atom community about the right ways of extending the format. It may very well make more sense to hold off on standardizing any extensions to the format until the community has had more time to figure out the "right" approach. Perhaps it would also make sense to consider a formal WG focusing on Atom extensions. >[snip] > =3D=3D Multiple references >=20 > ref=3D"tag:entries.com,2005:1" > type=3D"application/xhtml+xml" > href=3D"http://www.example.org/entries/1"/> >=20 > In particular the RNC: >=20 > in-reply-to =3D > element thr:in-reply-to { > atomCommonAttributes, > ( ref, source? > | href, type? > | ref, source?, href, type? ) > } >=20 > varies in co-occurrence constraints. No one attribute seems to be > required in all cases, which is a problem imo (if I'm wrong I'll argue = I > still have a point that it's unclear what an implementor should look > for). I think this will be an interop headache and that either ref or > href should always be required. Naturally ref to atom:id is to spec the > right choice, but in practice it seems the first thing anyone will want > to do unless they are the authority for the comment *and* the entry is > pull down what's being replied to via href. Otoh, mandating ref implies > as yet undeployed/unstandardised lookup/query services for atom:id - we > have enough experience now with identity lookup services > (CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service > won't ever be deployed uniformly, or will be deployed in a way that > isn't some kind of SPOF or business model or outright failure. That, or > the feature will end being limited to local cases where ref is preferre= d > over href (point to point integrations come to mind, hence the mention > of SOAP). >=20 > This of course is fallout from the way identity in Atom is specced, > which is also a hedge. Feed Thread imvho should consider getting off th= e > fence on id v link and providing guidance for follow on extensions. >=20 This design stems from a design decision to support responses to resources that do not have an Atom representation (and therefore no atom:id to reference). Alternatively, the resource being responded to may only exist as an entry within an Atom feed and therefore only be referenceable via it's atom:id. Or, the resource being responded to may only exist as an item within an RSS feed that has no guid NOR a stable URI that may be used to reference it. We could require ref at a minimum. Doing so would require that implementations using the element to reference non-Atom resources would be required to come up with some way of uniquely identifying those resources. I think this is acceptable as I believe it safely covers the majority of the use cases. I do not believe that mandating ref would require any kind of atom:id lookup mechanism. >=20 > =3D=3D @rel optionality >=20 > [[[ > allow Atom clients that are not familiar with the in-reply-to > extension to know that a relationship exists between the entry and > the resource being responded to, publishers are advised to consider > including a "related" link referencing a representation of the > resource identified by the in-reply-to element. > ]]] >=20 > I think to do anything useful with this relation you would have had > enough code written to switch on thr:in-reply-to to begin with. It coul= d > be struck. >=20 Agree. > =3D=3D Interop >=20 > There are multiple publishing options in terms of how to associate > comments with entries/comments. That this hasn't bitten anyone yet seem= s > to me to be a combination/result of lack of implementations targeting > the feature, Atom's mU policy for extensions, and (possibly) a lack of > experience with comment aggregation across publishing and aggregating > authorities. >=20 > Do the WG believe this will work out with multiple authorities using > multiple stacks? >=20 What kinds of issues are you anticipating would be a problem? Specifically, I'm not sure what you mean by "There are multiple publishing options in terms of how to associate comments with entries/comments." Can you expand a bit on this? >=20 > =3D=3D Security >=20 > [[[ > As this specification defines an extension to the Atom Syndication > Format, it is subject to the same security considerations as defined > in [RFC4287]. > ]]] >=20 > I have a serious enough quibble with this statement (the ddos attack > note notwithstanding). As an atom foreign markup extension, it's true o= n > the face of things, but the thr:reply-to semantics introduce > attribution/repudiation issues as well as providing aggregator/planet > spamming options. IOW thr:in-reply-to seems to standardise the same > attack/spam vectors we see in mail for feeds and this needs to be > acknowledged given spam mail is a multi-billion dollar sinkhole (or > industry depending on the pov). That's a dramatic way to state things > sure, but not without some truth. So - where's the digest/sig hook? > James, you know this stuff... :) >=20 A statement could be added to the Security Considerations recommending the use of XML digital signatures per RFC4287. Also, a statement describing the possibility for abuse, particularly in aggregator/planet scenarios is a good idea. I will work on beefing this up. - James > cheers > Bill >=20 >=20 From owner-atom-syntax@mail.imc.org Tue May 16 21:42:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgB3K-0006MH-Lf for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:42:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgB3J-0006Pz-A4 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:42:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H1Ne6w012236; Tue, 16 May 2006 18:23:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H1Nepj012235; Tue, 16 May 2006 18:23:40 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H1Ndsc012211 for ; Tue, 16 May 2006 18:23:39 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so123665pyf for ; Tue, 16 May 2006 18:23:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I8+CYkjbZ9LO/Ew+CMuWwP6E//zPH81GuBiHk+HITw5NATFXXYkWEsmigwS0eczGoup0nUZeG4NhhbqKoVrCknBavOVLnXWmUESsY5DFWPRsoxEpDwvDQ+SQQNniB1K27ifgR01B8XDTh99E+JCG0xacfUi24FQCZ/8rq/cHQ7M= Received: by 10.35.37.18 with SMTP id p18mr439660pyj; Tue, 16 May 2006 18:23:36 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 16 May 2006 18:23:36 -0700 (PDT) Message-ID: <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> Date: Wed, 17 May 2006 03:23:36 +0200 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Feed Thread in Last Call Cc: "James M Snell" , "Paul Hoffman" , atom-syntax In-Reply-To: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4H1Ndsc012230 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On 5/17/06, Lisa Dusseault wrote: > > - We're talking about visibility to implementations of the base > spec only, not implementations of the extension, naturally. Any new > information can be visible to implementations of that extension. There's a misunderstanding here. Many applications rely on a feed parsing service provided by the OS or a language-level library. Some of those platforms (MS is not the only one) don't provide access to extension attributes on the link element. For example, ... here the extension attribute stands a chance of getting lost. The reason this occurs is because it's much easier to design an API that doesn't deal with these things in the general case. This situation could change in the future, as Atom consumer APIs develop. My implementation will parse and preserve the attribute, but I'm not sure what I'm supposed to do with it at an application level, especially if I encounter more than one such link element. As a result, I see no reason to introduce gratuitous compatibility problems when the cardinality of the link element doesn't seem to suit the problem very well. > - We're talking about adding machine-parsable data that would be > invisible to readers of the post content I don't know. The specification says nothing about that. Presumably, the implementers that have already deployed know what they are for. -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 16 21:47:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgB8Z-0008I1-Ox for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:47:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgB8Y-0006dx-Dd for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:47:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H113Sf007492; Tue, 16 May 2006 18:01:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H113gr007491; Tue, 16 May 2006 18:01:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H1126G007470; Tue, 16 May 2006 18:01:02 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B92FC14227E; Tue, 16 May 2006 18:01:01 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28580-06; Tue, 16 May 2006 18:01:01 -0700 (PDT) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 412CE142278; Tue, 16 May 2006 18:01:01 -0700 (PDT) In-Reply-To: <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> Cc: "James M Snell" , "Paul Hoffman" , atom-syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Feed Thread in Last Call Date: Tue, 16 May 2006 18:00:55 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On May 16, 2006, at 4:38 PM, Robert Sayre wrote: > You're including attributes in that document > that you know won't be visible to a large number of implementations. Is there some way that one could write an Atom extension that would have new feed/post information that *would* be visible to a large number of implementations? Some assumptions I'm making in reading this, so you can correct me if my assumptions are wrong: - We're talking about visibility to implementations of the base spec only, not implementations of the extension, naturally. Any new information can be visible to implementations of that extension. - We're talking about adding machine-parsable data that would be invisible to readers of the post content Lisa From owner-atom-syntax@mail.imc.org Tue May 16 21:53:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgBES-0001Z2-Kg for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:53:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgBER-0006vo-97 for atompub-archive@lists.ietf.org; Tue, 16 May 2006 21:53:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H1cPwx015441; Tue, 16 May 2006 18:38:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H1cPf8015440; Tue, 16 May 2006 18:38:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H1cOiQ015415 for ; Tue, 16 May 2006 18:38:25 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id t5so89061wxc for ; Tue, 16 May 2006 18:38:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=O+o4/DyJrduQQxM+D8rG2bwWA+mkwY0UtmeA+Giq9KIL1AiGu++grhG6lL9/VYdWIXz4zOTYRAoxTxzI1SDC+bzRdlYU8pUmUqomzDTtsXv8CIqdQHmrpwlXP1Zl2bQWe9vwiR9ac15FU22wZKAQ7oEgC36rj96b9fhH4XAlPRg= Received: by 10.70.71.6 with SMTP id t6mr519053wxa; Tue, 16 May 2006 18:38:22 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id i36sm1639187wxd.2006.05.16.18.38.20; Tue, 16 May 2006 18:38:21 -0700 (PDT) Message-ID: <446A7E89.6090809@gmail.com> Date: Tue, 16 May 2006 18:38:17 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Robert Sayre CC: Lisa Dusseault , Paul Hoffman , atom-syntax Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> In-Reply-To: <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Robert Sayre wrote: >[snip] > My implementation will parse and preserve the attribute, but I'm not > sure what I'm supposed to do with it at an application level, > especially if I encounter more than one such link element. > This will be fixed in the next revision of the draft. The short answer is: every "replies" link MUST be processed independently of any others. That is, the feed consumer MUST NOT assume that multiple replies links are all just pointing at different representations of the same set of responses. >[snip] >> - We're talking about adding machine-parsable data that would be >> invisible to readers of the post content > > I don't know. The specification says nothing about that. Presumably, > the implementers that have already deployed know what they are for. > Machine-parseable data that may or may not be presented to users. The spec is silent on how the metadata should be used because there is no reason to dictate how it should be used. Implementations should use it in whatever way they feel is most appropriate. - James From owner-atom-syntax@mail.imc.org Tue May 16 22:35:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgBsX-0006qT-Eo for atompub-archive@lists.ietf.org; Tue, 16 May 2006 22:35:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgBsW-0000om-3a for atompub-archive@lists.ietf.org; Tue, 16 May 2006 22:35:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H2PE1R025941; Tue, 16 May 2006 19:25:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H2PEFB025940; Tue, 16 May 2006 19:25:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H2P6dd025904; Tue, 16 May 2006 19:25:06 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <446A6C39.1090706@dehora.net> References: <446A6C39.1090706@dehora.net> Date: Tue, 16 May 2006 19:25:03 -0700 To: Bill de =?iso-8859-1?Q?h=D3ra?= , Atom WG From: Paul Hoffman Subject: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: The IESG Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4H2PE1R025941 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At 1:20 AM +0100 5/17/06, Bill de h=D3ra wrote: >I'm -0 this becoming a Proposed Standard. I think this is really=20 >cool, has room for interop problems, probably has security issues,=20 >and thus is arguably premature/innovative and could be considered=20 >informational. These are not reasons to make something an Informational RFC. In the=20 minds of developers, there is no difference between Informational and=20 standards-track RFCs. The IETF's differentiation between types of=20 RFCs has always been confusing, but that is not a reason for us to=20 niggle on a particular document. This document describes an extension to an existing standards-track=20 document: it should either be on standards track or it should not be=20 an RFC. If the document has "room for interop problems", and/or security=20 issues, they should be stated so that the sponsoring AD, and the IESG=20 as a whole, can decide whether or not the document is ready to be an=20 RFC, regardless of the type of RFC it will become. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 16 22:43:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgC10-0001Qr-Jg for atompub-archive@lists.ietf.org; Tue, 16 May 2006 22:43:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgC0z-0001DS-2J for atompub-archive@lists.ietf.org; Tue, 16 May 2006 22:43:58 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H2WwbX027472; Tue, 16 May 2006 19:32:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H2WwYw027471; Tue, 16 May 2006 19:32:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H2Wuco027456 for ; Tue, 16 May 2006 19:32:57 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id v1so65973nzb for ; Tue, 16 May 2006 19:32:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=F6Zup9VHPWpTkzhf3a5I+NbdOQK1YzoRhpuonSAF2JrNvsaETR+c6ApQsWK3tGY9+YR5IBAPatwU+fxF2G4n8aF5ggpfF758XELhz7+uV4jNKyO2WW4VARx9E3MRoBCGtKbO/cOv3NqTknoB1lciKpuoDLTfDjn5MXxsR72wLq0= Received: by 10.65.95.18 with SMTP id x18mr658761qbl; Tue, 16 May 2006 19:32:56 -0700 (PDT) Received: by 10.65.233.15 with HTTP; Tue, 16 May 2006 19:32:56 -0700 (PDT) Message-ID: Date: Tue, 16 May 2006 20:32:56 -0600 From: "M. David Peterson" To: sh@defuze.org Subject: Re: Feed update mechanism Cc: atom-syntax@imc.org In-Reply-To: <35618.194.221.74.7.1147780547.squirrel@mail1.python-hosting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_98012_14723333.1147833176202" References: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.com> <1228709845.20060516120931@djpowell.net> <35618.194.221.74.7.1147780547.squirrel@mail1.python-hosting.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_Part_98012_14723333.1147833176202 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline V29ydGggbm90aW5nOgoKdmlhCmh0dHA6Ly93d3cub3JlaWxseW5ldC5jb20vd2luZG93cy9ibG9n LzIwMDYvMDQva2VlcF90aGVfZ29vZF90aGluZ3Nfcm9sbGluZ19tLmh0bWx3aGljaApsaW5rcyB0 bwpodHRwOi8vYmxvZ3MubXNkbi5jb20vcnNzdGVhbS9hcmNoaXZlLzIwMDYvMDQvMDgvNTcxNTA5 LmFzcHggeW91J2xsIGZpbmQ6CgpEZWx0YSBFbmNvZGluZwoKSW4gYWRkaXRpb24gdG8gc3RhbmRh cmQgY29uZGl0aW9uYWwgR0VUcyB0aGUgUlNTIFBsYXRmb3JtIGRvd25sb2FkIGVuZ2luZQpzdXBw b3J0cyBEZWx0YSBFbmNvZGluZyAoZm9yIGRldGFpbHMsIHNlZSBCb2IgV3ltYW4ncyBwb3N0ICJV c2luZyBSRkMgMzIyOQp3aXRoIEZlZWRzIikgd2hpY2ggYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gcmVz cG9uZCB3aXRoIG9ubHkgdGhlIGZlZWQgaXRlbXMKdGhhdCBhcmUgbmV3IG9yIGhhdmUgYmVlbiB1 cGRhdGVkLCB0aGVyZWJ5IHBvc3NpYmx5IHJlZHVjaW5nIHRoZSByZXNwb25zZQpzaWduaWZpY2Fu dGx5LgoKU28gUkZDMzIyOSBpcyBzdXBwb3J0ZWQgYnkgZGVmYXVsdCBpbiBJRTcuLi4gR29vZCBz dHVmZiBmb3Igc3VyZSA6KQoKCk9uIDUvMTYvMDYsIFN5bHZhaW4gSGVsbGVnb3VhcmNoIDxzaEBk ZWZ1emUub3JnPiB3cm90ZToKPgo+Cj4KPiBIaSBEYXZlLAo+Cj4gPiBDaGVjayBvdXQgIkEtSU06 IGZlZWQiIFsxXS4gSXQgaXMgYWxyZWFkeSBpbXBsZW1lbnRlZCBieSBsb3RzIG9mCj4gPiBhZ2dy ZWdhdG9ycywgYW5kIGl0IGlzIHRyaXZpYWwgZm9yIGNsaWVudCBpbXBsZW1lbnRvcnMgdG8gc3Vw cG9ydC4KPiA+Cj4gPiBbMV0gaHR0cDovL2JvYnd5bWFuLnB1YnN1Yi5jb20vbWFpbi8yMDA0LzA5 L3VzaW5nX3JmYzMyMjlfdy5odG1sCj4KPiBWZXJ5IG5pY2UgYXJ0aWNsZSBpbmRlZWQgYW5kIGl0 IHNob3dzIEknbSBub3QgdGhlIG9ubHkgd29uZGVyaW5nIGFib3V0Cj4gdGhpcy4gVGhlIEEtSU0g aWRlYSBpcyBwcmV0dHkgbmVhdCBhbmQgZWZmaWNpZW50IGFwcGFyZW50bHkuIEknbGwgZ2l2ZSBp dAo+IGEgbG9vay4KPgo+IFRoYW5rcywKPiAtIFN5bHZhaW4KPgo+Cj4KPgo+Cj4KPgoKCi0tIAo8 TTpELz4KCk0uIERhdmlkIFBldGVyc29uCmh0dHA6Ly93d3cueHNsdGJsb2cuY29tLwo= ------=_Part_98012_14723333.1147833176202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V29ydGggbm90aW5nOjxicj48YnI+dmlhIDxhIGhyZWY9Imh0dHA6Ly93d3cub3JlaWxseW5ldC5j b20vd2luZG93cy9ibG9nLzIwMDYvMDQva2VlcF90aGVfZ29vZF90aGluZ3Nfcm9sbGluZ19tLmh0 bWwiPmh0dHA6Ly93d3cub3JlaWxseW5ldC5jb20vd2luZG93cy9ibG9nLzIwMDYvMDQva2VlcF90 aGVfZ29vZF90aGluZ3Nfcm9sbGluZ19tLmh0bWw8L2E+IHdoaWNoIGxpbmtzIHRvIDxhIGhyZWY9 Imh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9yc3N0ZWFtL2FyY2hpdmUvMjAwNi8wNC8wOC81NzE1MDku YXNweCI+Cmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9yc3N0ZWFtL2FyY2hpdmUvMjAwNi8wNC8wOC81 NzE1MDkuYXNweDwvYT4geW91J2xsIGZpbmQ6PGJyPjxicj48YmxvY2txdW90ZT48cD5EZWx0YSBF bmNvZGluZzwvcD4KPHA+SW4gYWRkaXRpb24gdG8gc3RhbmRhcmQgY29uZGl0aW9uYWwgR0VUcyB0 aGUgUlNTIFBsYXRmb3JtIGRvd25sb2FkCmVuZ2luZSBzdXBwb3J0cyBEZWx0YSBFbmNvZGluZyAo Zm9yIGRldGFpbHMsIHNlZSBCb2IgV3ltYW4ncyBwb3N0CiJVc2luZyBSRkMgMzIyOSB3aXRoIEZl ZWRzIikgd2hpY2ggYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gcmVzcG9uZCB3aXRoCm9ubHkgdGhlIGZl ZWQgaXRlbXMgdGhhdCBhcmUgbmV3IG9yIGhhdmUgYmVlbiB1cGRhdGVkLCB0aGVyZWJ5IHBvc3Np Ymx5CnJlZHVjaW5nIHRoZSByZXNwb25zZSBzaWduaWZpY2FudGx5LjwvcD48L2Jsb2NrcXVvdGU+ PHA+U28gUkZDMzIyOSBpcyBzdXBwb3J0ZWQgYnkgZGVmYXVsdCBpbiBJRTcuLi4gR29vZCBzdHVm ZiBmb3Igc3VyZSA6KTxicj48L3A+PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gNS8xNi8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlN5bHZhaW4gSGVsbGVn b3VhcmNoCjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpzaEBkZWZ1emUub3JnIj5zaEBkZWZ1emUu b3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46 IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPjxicj48YnI+SGkgRGF2ZSw8 YnI+Cjxicj4mZ3Q7IENoZWNrIG91dCAmcXVvdDtBLUlNOiBmZWVkJnF1b3Q7IFsxXS4gSXQgaXMg YWxyZWFkeSBpbXBsZW1lbnRlZCBieSBsb3RzIG9mPGJyPiZndDsgYWdncmVnYXRvcnMsIGFuZCBp dCBpcyB0cml2aWFsIGZvciBjbGllbnQgaW1wbGVtZW50b3JzIHRvIHN1cHBvcnQuPGJyPiZndDs8 YnI+Jmd0OyBbMV0gPGEgaHJlZj0iaHR0cDovL2JvYnd5bWFuLnB1YnN1Yi5jb20vbWFpbi8yMDA0 LzA5L3VzaW5nX3JmYzMyMjlfdy5odG1sIj4KaHR0cDovL2JvYnd5bWFuLnB1YnN1Yi5jb20vbWFp bi8yMDA0LzA5L3VzaW5nX3JmYzMyMjlfdy5odG1sPC9hPjxicj48YnI+VmVyeSBuaWNlIGFydGlj bGUgaW5kZWVkIGFuZCBpdCBzaG93cyBJJ20gbm90IHRoZSBvbmx5IHdvbmRlcmluZyBhYm91dDxi cj50aGlzLiBUaGUgQS1JTSBpZGVhIGlzIHByZXR0eSBuZWF0IGFuZCBlZmZpY2llbnQgYXBwYXJl bnRseS4gSSdsbCBnaXZlIGl0PGJyPgphIGxvb2suPGJyPjxicj5UaGFua3MsPGJyPi0gU3lsdmFp bjxicj48YnI+PGJyPjxicj48YnI+PGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBj bGVhcj0iYWxsIj48YnI+LS0gPGJyPiZsdDtNOkQvJmd0Ozxicj48YnI+TS4gRGF2aWQgUGV0ZXJz b248YnI+PGEgaHJlZj0iaHR0cDovL3d3dy54c2x0YmxvZy5jb20vIj5odHRwOi8vd3d3LnhzbHRi bG9nLmNvbS88L2E+Cg== ------=_Part_98012_14723333.1147833176202-- From owner-atom-syntax@mail.imc.org Wed May 17 01:39:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEjy-00087U-Af for atompub-archive@lists.ietf.org; Wed, 17 May 2006 01:38:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgEZk-0000SJ-9n for atompub-archive@lists.ietf.org; Wed, 17 May 2006 01:28:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H5C1o4062066; Tue, 16 May 2006 22:12:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H5C18M062065; Tue, 16 May 2006 22:12:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H5C0np062048 for ; Tue, 16 May 2006 22:12:00 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so158925pyf for ; Tue, 16 May 2006 22:12:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V6gSbwJE8NWqEAPDqH7k6gt+KX/t4zRGnU+Qdv7qXnoZUjD1C4isSKXoFZp6X4EPqLvYYHsPPwbFnu9NkzDMXWngy3CiA2NfmkjdgiIWQhpQdZKaSg5YDQ2H0X2dl4iP3leR7OHm8cM+Uf5DCwJV9tDfDmUcLwwueDjzv1AcZy0= Received: by 10.35.101.9 with SMTP id d9mr572153pym; Tue, 16 May 2006 22:11:59 -0700 (PDT) Received: by 10.35.26.15 with HTTP; Tue, 16 May 2006 22:11:59 -0700 (PDT) Message-ID: <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> Date: Wed, 17 May 2006 07:11:59 +0200 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: "=?ISO-8859-1?Q?Bill_de_h=D3ra?=" , "Atom WG" , "The IESG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <446A6C39.1090706@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4H5C0np062054 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On 5/17/06, Paul Hoffman wrote: > > This document describes an extension to an existing standards-track > document: it should either be on standards track or it should not be > an RFC. Where is that written down? Didn't Julian just get some WebDAV extensions approved as Experimental? You seem to be saying IETF participants don't get to have anything other than a black/white opinion on the readiness of this document. I disagree, and I also think it's kind of inappropriate for you to be managing discussion in this way. After all, it's not a WG document, is it? I would have said this should go Experimental, but it's not clear that the author is willing to change the document in any meaningful way, so there's no experiment to conduct. Informational and Experimental RFCs The role of Informational RFCs is often debated in the IETF. Many people like having them, particularly for specifications that were created outside the IETF but are referenced by IETF documents. They are also useful for specifications that are the precursors for work being done by IETF Working Groups. On the other hand, some people refer to Informational RFCs as "standards" even though the RFCs are not standards, usually to fool the gullible public about something that the person is selling or supporting. When this happens, the debate about Informational RFCs is renewed. Experimental RFCs are for specifications that may be interesting, but for which it is unclear if there will be much interest in implementing them, or whether they will work once deployed. That is, a specification might solve a problem, but if it is not clear that many people think that the problem is important, or think that they will bother fixing the problem with the specification, the specification might be labeled an Experimental RFC. If, later, the specification becomes popular (or proves that it works well), it can be re-issued as a standards-track RFC. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards track material, but for which there are still unanswered questions. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed May 17 02:20:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFOl-0004pR-Jw for atompub-archive@lists.ietf.org; Wed, 17 May 2006 02:20:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFLw-0002o9-BI for atompub-archive@lists.ietf.org; Wed, 17 May 2006 02:17:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H65Mw8074443; Tue, 16 May 2006 23:05:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H65Mcw074442; Tue, 16 May 2006 23:05:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H65KUE074411; Tue, 16 May 2006 23:05:21 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4H65CoJ028648; Wed, 17 May 2006 15:05:12 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1486_141bfefe_e56b_11da_9338_0014221f2a2d; Wed, 17 May 2006 15:05:12 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4H63KD8026436; Wed, 17 May 2006 15:04:09 +0900 Message-Id: <6.0.0.20.2.20060517105001.0551f210@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 17 May 2006 13:14:59 +0900 To: "Robert Sayre" From: Martin Duerst Subject: Re: Feed Thread in Last Call Cc: "James M Snell" , atom-syntax , "Lisa Dusseault" , "Paul Hoffman" In-Reply-To: <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.co m> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hello Robert, It's not the IETF which wants to move this on on Standards Track, it's (currently) James as an individual submitter. The IESG just did what it does for all such requests from individuals: Put the document out for IETF Last Call and tell the relevant mailing lists about it. Now it's your (and everybody else's) turn to tell the IESG what you think about this draft. A short, but clearly argued and nicely worded mail, with some easy-to-follow pointers to further material, is all that is needed. This may say "okay with Standards Track iff these things get fixed" or "should be experimental because ..." or even "too controversial for an individual submission, needs a WG". The time you invest in this email will be a lot better spent than writing yet another mail to James and this list. Lisa (the "sponsoring" AD) and the rest of the IESG will then look at all the input they get, and will make a decision. Regards, Martin. At 07:03 06/05/17, Robert Sayre wrote: > >On 5/16/06, Paul Hoffman wrote: >> At 4:33 AM +0200 5/16/06, Robert Sayre wrote: >> >I thought the working group was fairly clear about the dubious value >> >and placement of these attributes, >> >> For the benefit of Lisa, who is the sponsoring AD for this document, >> please list links to those messages. > >James changed the document in response to those messages. That should >be enough. Maybe she could ask James about them. It's not my >obligation to spelunk for them, and it's certainly not your place to >start making demands like that. > >> >So you don't think they're important or needed, and then >> >WG doesn't have consensus on them. >> >> Quite true, but it is true because there has never been a call for >> consensus on the document, and there won't be in the future. > >Well, I'm not going to quibble with you about procedural details. But >I have to wonder why they're in the document at all. > >Looks like the IETF wants to publish a "proposed standard" explicitly >designed to break a very popular implementation, with no technical >reason. I think that speaks volumes about the IETF, its management, >and the quality of its "individual" contributors. > >>>You don't have to listen to the WG, but if one or two WG members are >>>going to deploy and then standardize whatever they've done, that's an >>>informational document. >> >> That is not true. If it is a protocol or a format, standards track is >> also appropriate. > >Well, I don't want to standardize some of what James has deployed. It >won't work in Sean's implementation. I'm not sure I can interoperably >implement the parts in question. Your two biggest client implementers >aren't real happy about this. It might be appropriate if you really >stretch, but it's sure not smart. > >-- > >Robert Sayre > From owner-atom-syntax@mail.imc.org Wed May 17 04:52:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHlU-0007tX-6h for atompub-archive@lists.ietf.org; Wed, 17 May 2006 04:52:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHlS-0002I8-QD for atompub-archive@lists.ietf.org; Wed, 17 May 2006 04:52:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H8dK7E008765; Wed, 17 May 2006 01:39:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H8dKvM008764; Wed, 17 May 2006 01:39:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H8dKZg008730; Wed, 17 May 2006 01:39:20 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (83-70-255-53.b-ras1.prp.dublin.eircom.net [83.70.255.53]) by chilco.textdrive.com (Postfix) with ESMTP id 6E4E8DBED8; Wed, 17 May 2006 08:39:13 +0000 (UTC) Message-ID: <446AE12E.70600@dehora.net> Date: Wed, 17 May 2006 09:39:10 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG , The IESG Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) References: <446A6C39.1090706@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Paul Hoffman wrote: > These are not reasons to make something an Informational RFC. In the > minds of developers, there is no difference between Informational and > standards-track RFCs. The IETF's differentiation between types of RFCs > has always been confusing, but that is not a reason for us to niggle on > a particular document. Understood - thanks for educating me. > If the document has "room for interop problems", and/or security issues, > they should be stated so that the sponsoring AD, and the IESG as a > whole, can decide whether or not the document is ready to be an RFC, > regardless of the type of RFC it will become. Ok. I'll try to be more specific rsn. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 17 05:07:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgI0d-0004d2-LV for atompub-archive@lists.ietf.org; Wed, 17 May 2006 05:07:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgI0c-00047f-7r for atompub-archive@lists.ietf.org; Wed, 17 May 2006 05:07:59 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H8oSTm011284; Wed, 17 May 2006 01:50:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H8oS5V011283; Wed, 17 May 2006 01:50:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18/w5uXVL8MoUP/SbhjXlJop4oqPrTQS/I@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H8oRex011266 for ; Wed, 17 May 2006 01:50:27 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/BORzf8rK95gQqsezF7NKlfzPFdcTUfus@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4H8oOYg023604 for ; Wed, 17 May 2006 03:50:24 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4H8oOMw023602; Wed, 17 May 2006 09:50:24 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 09:50:24 +0100 (BST) Message-ID: <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> In-Reply-To: <446A7E89.6090809@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> Date: Wed, 17 May 2006 09:50:24 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 >>[snip] >>> - We're talking about adding machine-parsable data that would be >>> invisible to readers of the post content >> >> I don't know. The specification says nothing about that. Presumably, >> the implementers that have already deployed know what they are for. >> > > Machine-parseable data that may or may not be presented to users. The > spec is silent on how the metadata should be used because there is no > reason to dictate how it should be used. Implementations should use it > in whatever way they feel is most appropriate. > I'm sorry to stir this up again but I've read once more the last FT draft and I still cannot understand the use of the thr:count and thr:when attributes. Well in regards to the context they sit I see their meaning but I cannot see their value. If a feed containg FTE information is meant to be handled by machines only, then those values are not precise enough to be use (but I'd be happy to gearing about them though). If those values are to be presented to users, they are also not precise to have any interest. Besides, say a comment is added to the comments feed. I, as an application developer, will want to update thr:count and thr:when of the entry itself. Meaning that I will have to disregard any If-Modified-Since header sent by an aggregator to check out if my entry has changed when it has actually not changed per se. Anyway, I do not see the value brought by thr:count and thr:when alltogether. Since it is a MAY as well, I hardly see the point of keeping them. Another point is that neither your draft nor RFC 4287 seem to say what a processor, which cannot process a value of the rel attribute, should do. Should the link be ignored? Should an error be raised? I assume the former but sadly the spec is not helping in this case. Finally, if I set a into a feed element, should the ref attribute of the in-reply-to should use the id of the feed or the entry it concerns? If it is the former, aggregators won't be able to correlate threads and entries. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 05:18:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIAL-0007EM-Uf for atompub-archive@lists.ietf.org; Wed, 17 May 2006 05:18:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIAK-0004ZS-J7 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 05:18:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H90dNi013651; Wed, 17 May 2006 02:00:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4H90dRC013649; Wed, 17 May 2006 02:00:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/sbrC0mQDzzL1Tzbn0R3L++zlqgtN2LnU@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4H90chP013643 for ; Wed, 17 May 2006 02:00:38 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18vtw2xvBJkzlMgKke1z/Q1fo0D3+m/zdc@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4H90bFV023900; Wed, 17 May 2006 04:00:37 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4H90a4w023897; Wed, 17 May 2006 10:00:36 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 10:00:36 +0100 (BST) Message-ID: <18671.194.221.74.7.1147856436.squirrel@mail1.python-hosting.com> In-Reply-To: References: <62489.194.221.74.7.1147774684.squirrel@mail1.python-hosting.com> <1228709845.20060516120931@djpowell.net> <35618.194.221.74.7.1147780547.squirrel@mail1.python-hosting.com> Date: Wed, 17 May 2006 10:00:36 +0100 (BST) Subject: Re: Feed update mechanism From: "Sylvain Hellegouarch" To: "M. David Peterson" Cc: sh@defuze.org, atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > http://blogs.msdn.com/rssteam/archive/2006/04/08/571509.aspx you'll find: Very nice article David, I really like the safe approach taken by Microsoft on this one. Thanks, - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 08:34:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLEi-0008PY-Ad for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:34:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLEb-0006dR-UO for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:34:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HCDJBR058751; Wed, 17 May 2006 05:13:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HCDJIA058750; Wed, 17 May 2006 05:13:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HCDHWY058634 for ; Wed, 17 May 2006 05:13:18 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 17 May 2006 21:33:35 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 17 May 2006 21:33:12 +1000 Subject: Re: Feed Thread in Last Call From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <446A7E89.6090809@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 17/5/06 11:38 AM, "James M Snell" wrote: > This will be fixed in the next revision of the draft. The short answer > is: every "replies" link MUST be processed independently of any others. > That is, the feed consumer MUST NOT assume that multiple replies links > are all just pointing at different representations of the same set of > responses. would this mean this is possible: ... e. From owner-atom-syntax@mail.imc.org Wed May 17 08:52:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLWH-0006NA-7N for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:52:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLWF-0007VW-Rz for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:52:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HCfMme065452; Wed, 17 May 2006 05:41:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HCfMsW065451; Wed, 17 May 2006 05:41:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4HCfKXf065424 for ; Wed, 17 May 2006 05:41:21 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 17 May 2006 12:41:14 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 17 May 2006 14:41:14 +0200 X-Authenticated: #1915285 Message-ID: <446B19E7.4000103@gmx.de> Date: Wed, 17 May 2006 14:41:11 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Robert Sayre CC: Paul Hoffman , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom WG , The IESG Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> In-Reply-To: <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 I'm with Robert here. To clarify what happened with the WebDAV specs he mentioned...: - WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda, and currently is implemented only by two vendors. Thus, "experimental" seems to be absolutely the right category. - WebDAV Redirect References (RFC4437) was on the working group's agenda, but in the end too few implementors seemed to be interested (again: two). Thus "experimental" wasn't what I would have hoped to achieve, but at least this kind of publication preserves the effort that was invested, and it also documents running code in some implementations. Best regards, Julian From owner-atom-syntax@mail.imc.org Wed May 17 08:56:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLa6-0007Ub-Sz for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:56:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLa5-0007n1-Cv for atompub-archive@lists.ietf.org; Wed, 17 May 2006 08:56:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HClYTT066939; Wed, 17 May 2006 05:47:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HClY83066938; Wed, 17 May 2006 05:47:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4HClWwI066908 for ; Wed, 17 May 2006 05:47:33 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 May 2006 12:47:27 -0000 Received: from xdsl-213-196-250-78.netcologne.de (EHLO klangraum) [213.196.250.78] by mail.gmx.net (mp042) with SMTP; 17 May 2006 14:47:27 +0200 X-Authenticated: #163624 Date: Wed, 17 May 2006 14:47:50 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060517124750.GK1714@klangraum> Mail-Followup-To: Atom Syntax References: <446A7E89.6090809@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HClYTT066939 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 * Eric Scheid [2006-05-17 14:25]: > would this mean this is possible: >=20 > > > > ... > You mean `hreflang`, not `xml:lang`, right? I have to say at first blush I don=E2=80=99t see why it should not work, so I find your thought experiment quite amusing. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 17 09:28:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgM50-0001Br-D1 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 09:28:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgM4z-0000fm-0I for atompub-archive@lists.ietf.org; Wed, 17 May 2006 09:28:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HDGd7d073662; Wed, 17 May 2006 06:16:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HDGdmF073661; Wed, 17 May 2006 06:16:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4HDGbaw073635 for ; Wed, 17 May 2006 06:16:38 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 May 2006 13:16:32 -0000 Received: from xdsl-213-196-250-78.netcologne.de (EHLO klangraum) [213.196.250.78] by mail.gmx.net (mp038) with SMTP; 17 May 2006 15:16:32 +0200 X-Authenticated: #163624 Date: Wed, 17 May 2006 15:16:55 +0200 From: "A. Pagaltzis" To: Atom WG Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Message-ID: <20060517131655.GL1714@klangraum> Mail-Followup-To: Atom WG References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HDGd7d073662 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Robert Sayre [2006-05-17 07:25]: > I would have said this should go Experimental, +1 We can wait and see what problems crop up in practice with the contested attributes, and whether extensibility according to Sec 6.4. ff (or lack thereof) turns out to be paramount or, to borrow Tim=E2=80=99s turn of phrase, a molehill. If it works out, just reissue it; if not, there=E2=80=99s room to go back and fix it. Sounds reasonable enough to me. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 17 10:15:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMo5-00044J-0v for atompub-archive@lists.ietf.org; Wed, 17 May 2006 10:15:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMo1-0002tg-KS for atompub-archive@lists.ietf.org; Wed, 17 May 2006 10:15:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HE1Ws4084262; Wed, 17 May 2006 07:01:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HE1Wcq084261; Wed, 17 May 2006 07:01:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HE1VuV084246 for ; Wed, 17 May 2006 07:01:31 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 17 May 2006 23:52:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 17 May 2006 23:52:16 +1000 Subject: Re: Feed Thread in Last Call From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20060517124750.GK1714@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HE1WuV084254 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HE1Ws4084262 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 17/5/06 10:47 PM, "A. Pagaltzis" wrote: > You mean `hreflang`, not `xml:lang`, right? oops, yes. > I have to say at first blush I don=B9t see why it should not work, > so I find your thought experiment quite amusing. :-) From owner-atom-syntax@mail.imc.org Wed May 17 10:45:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNHB-0006u2-8P for atompub-archive@lists.ietf.org; Wed, 17 May 2006 10:45:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNHA-0004jj-Sm for atompub-archive@lists.ietf.org; Wed, 17 May 2006 10:45:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HERuS8090566; Wed, 17 May 2006 07:27:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HERuDK090565; Wed, 17 May 2006 07:27:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HEReAx090420; Wed, 17 May 2006 07:27:46 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> Date: Wed, 17 May 2006 07:27:36 -0700 To: "Robert Sayre" From: Paul Hoffman Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: =?iso-8859-1?Q?=22Bill_de_h=D3ra=22?= , "Atom WG" , "The IESG" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 7:11 AM +0200 5/17/06, Robert Sayre wrote: >On 5/17/06, Paul Hoffman wrote: >> >>This document describes an extension to an existing standards-track >>document: it should either be on standards track or it should not be >>an RFC. > >Where is that written down? RFC 2026. > Didn't Julian just get some WebDAV >extensions approved as Experimental? Maybe, but that's irrelevant. The fact that some WGs don't follow the IETF process doesn't mean we should do the same. If our AD (who is also the AD for WebDAV) wanted this document to not be on standards track, she would not have put out the IETF last call for the document to be on standards track. > You seem to be saying IETF >participants don't get to have anything other than a black/white >opinion on the readiness of this document. Correct. > I disagree, and I also >think it's kind of inappropriate for you to be managing discussion in >this way. After all, it's not a WG document, is it? Nope, and that's why I said it as an IETF process weenie, not as WG co-chair. > I would have said >this should go Experimental, but it's not clear that the author is >willing to change the document in any meaningful way, so there's no >experiment to conduct. If you want to change RFC 2026, that's fine, but this is not the right forum to do so. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 17 11:28:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNxL-0001bl-DM for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:28:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNxK-0007Mx-0W for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:28:59 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFFqx4001975; Wed, 17 May 2006 08:15:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HFFqcA001972; Wed, 17 May 2006 08:15:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFFpaJ001959 for ; Wed, 17 May 2006 08:15:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so235124wra for ; Wed, 17 May 2006 08:15:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KJwG+n8cGDgmuvd4q8DlmmMpINSVlrZj6elH4ev5xQ+0ryMR+Mz7mrBkEWXU9Gt5syXFeOpoLlBCwgBGFXzkce+F4nYUdM9LFIi254rKAlpLQCig0z6g25SrABNtJuAI02D2oaRAxcHS/I058jOU8RKwbmVZHt6U49xni8/zuog= Received: by 10.54.127.16 with SMTP id z16mr1240273wrc; Wed, 17 May 2006 08:15:51 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 7sm1910011wrl.2006.05.17.08.15.49; Wed, 17 May 2006 08:15:50 -0700 (PDT) Message-ID: <446B3E23.7090004@gmail.com> Date: Wed, 17 May 2006 08:15:47 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> In-Reply-To: <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Sylvain Hellegouarch wrote: >[snip] > If a feed containg FTE information is meant to be handled by machines > only, then those values are not precise enough to be use (but I'd be happy > to gearing about them though). If those values are to be presented to > users, they are also not precise to have any interest. > I have no idea what you mean by "not precise enough to be used". What makes them imprecise? Look at just about piece of blogging software that accepts comments and on the front page you'll typically see a link that specifies the number of comment received for that entry. It may, or may not be an accurate count, but it serves a useful purpose. Why is the same metadata not useful in an entry/feed? >[snip] > Another point is that neither your draft nor RFC 4287 seem to say what a > processor, which cannot process a value of the rel attribute, should do. > Should the link be ignored? Should an error be raised? I assume the former > but sadly the spec is not helping in this case. > The spec is silent on this, handle it however you want to handle it in your implementation. IMHO, Good implementations will silently ignore links they don't understand. > Finally, if I set a into a feed element, should > the ref attribute of the in-reply-to should use the id of the feed or the > entry it concerns? If it is the former, aggregators won't be able to > correlate threads and entries. > The ref attribute is the unique identifier of the resource being responded to. It doesn't make make sense to respond to a Feed. - James From owner-atom-syntax@mail.imc.org Wed May 17 11:52:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOJp-0004gG-Oe for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:52:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOJo-00009a-C8 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:52:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFaBb0006486; Wed, 17 May 2006 08:36:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HFaBhn006485; Wed, 17 May 2006 08:36:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18bl4ON7rKH9A2Jop74ISUSKckzmwW3Ssk@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFaAdg006478 for ; Wed, 17 May 2006 08:36:10 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX197vGeb4bCdkjh0lqo7EoB8HgRbSwyCAFQ@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HFa95a004095 for ; Wed, 17 May 2006 10:36:09 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HFa9GQ004093; Wed, 17 May 2006 16:36:09 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 16:36:09 +0100 (BST) Message-ID: <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> In-Reply-To: <446B3E23.7090004@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> Date: Wed, 17 May 2006 16:36:09 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 > I have no idea what you mean by "not precise enough to be used". What > makes them imprecise? The very fact they don't represent a state that can be trusted. As the spec says they are not the true value but the true value at one given time. > Look at just about piece of blogging software that accepts comments and > on the front page you'll typically see a link that specifies the number > of comment received for that entry. It may, or may not be an accurate > count, but it serves a useful purpose. Why is the same metadata not > useful in an entry/feed? Well to take your example a bit further. Say I'm following comments posted to an entry, since there is no way for me to decide if the number provided by the extension is the most up-to-date, I will have to manually go to the source itself and check if someone replied since my last visit. How is that useful to me as an user? Besides you do not answer the question of HTTP caching I mentionned. Basically it would break most planets out there which rely heavily on the '304 Not Modified' status code to check if a feed has been modified. In this case a server such as Apache would respond: "well yes the file has changed on the disk so here it is" when in fact the content of the feed has only changed for the number of comments of an entry. Clients could of course work around such issue but this is a rather big problem to me. > The ref attribute is the unique identifier of the resource being > responded to. It doesn't make make sense to respond to a Feed. Common sense is one thing, being clearly specified is another one. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 11:52:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOK7-0004xG-MB for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:52:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOK7-00009l-B7 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 11:52:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFeJux007461; Wed, 17 May 2006 08:40:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HFeJtm007460; Wed, 17 May 2006 08:40:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+L4Y7i4/CC/9UQy1jbx5lD9X+ZRn+jJe8@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HFeI2o007450 for ; Wed, 17 May 2006 08:40:18 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/x84QkQyOXJAIWcK/EVjt4DdEnTZ21Zoc@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HFeHFe004262 for ; Wed, 17 May 2006 10:40:17 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HFeFYt004259; Wed, 17 May 2006 16:40:15 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 16:40:15 +0100 (BST) Message-ID: <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> In-Reply-To: <446B3E23.7090004@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> Date: Wed, 17 May 2006 16:40:15 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 > > The ref attribute is the unique identifier of the resource being > responded to. It doesn't make make sense to respond to a Feed. By the way, don't get me wrong. I am really looking forward to the FTE replies element but not its attributes which are just useless and counter productive to my liking. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 12:30:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOul-0005uV-Ve for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:30:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOuj-0001Qz-HT for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:30:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HG8Hbq013654; Wed, 17 May 2006 09:08:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HG8HoV013653; Wed, 17 May 2006 09:08:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HG8Gbp013631 for ; Wed, 17 May 2006 09:08:16 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so224874wra for ; Wed, 17 May 2006 09:08:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NEL133qU4WBCniIh+wgk8+3jjnm5xx2Rr098EeVJ/ieHO5CeKaQSN0eL6Gl02BJR/3kD98uHlK1a0F5MZ6Kvznt6jvKYAsjpbK2FVbu0yKyCjw4+brOsAgy2aF11eGAfuNfz+4ARR2LpZ0JVnSReFaFr7jjxj178HnoV5gTvIcg= Received: by 10.54.80.18 with SMTP id d18mr2648705wrb; Wed, 17 May 2006 09:08:15 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 29sm3095976wrl.2006.05.17.09.08.14; Wed, 17 May 2006 09:08:14 -0700 (PDT) Message-ID: <446B4A60.6070300@gmail.com> Date: Wed, 17 May 2006 09:08:00 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> In-Reply-To: <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Sylvain Hellegouarch wrote: > >> I have no idea what you mean by "not precise enough to be used". What >> makes them imprecise? > > The very fact they don't represent a state that can be trusted. As the > spec says they are not the true value but the true value at one given > time. > The values are no more or less trustworthy than the link's own type, length, and hreflang attributes. I refer you to http://www.w3.org/2001/tag/doc/mime-respect-20060412 >> Look at just about piece of blogging software that accepts comments and >> on the front page you'll typically see a link that specifies the number >> of comment received for that entry. It may, or may not be an accurate >> count, but it serves a useful purpose. Why is the same metadata not >> useful in an entry/feed? > > Well to take your example a bit further. Say I'm following comments posted > to an entry, since there is no way for me to decide if the number provided > by the extension is the most up-to-date, I will have to manually go to the > source itself and check if someone replied since my last visit. How is > that useful to me as an user? > If you need an exact count, go to the linked resource. Feed publishers should take steps to ensure that the count is accurate. Again, read the W3C Tag finding referenced above. > Besides you do not answer the question of HTTP caching I mentionned. > Basically it would break most planets out there which rely heavily on the > '304 Not Modified' status code to check if a feed has been modified. In > this case a server such as Apache would respond: "well yes the file has > changed on the disk so here it is" when in fact the content of the feed > has only changed for the number of comments of an entry. > HTTP provides a possible solution to this in the form of a weak entity tag. Also, Feed delta encoding could be leveraged to further mitigate the potential issues. > Clients could of course work around such issue but this is a rather big > problem to me. > I would suspect that you currently have the same problems with folks that use the highly popular slash:comments RSS extension. FTE is not introducing any new problems, nor is it seeking to fix existing problems in the feed syndication model. - James From owner-atom-syntax@mail.imc.org Wed May 17 12:33:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOxM-0007cW-1I for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:33:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOxK-0001XN-Kl for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:33:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HG84xk013574; Wed, 17 May 2006 09:08:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HG84RS013573; Wed, 17 May 2006 09:08:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HG833R013565 for ; Wed, 17 May 2006 09:08:03 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so304132pyf for ; Wed, 17 May 2006 09:08:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hTzadvbK8/HVWykFVfOolGzxzsPi6o6mt0gTM7WyRETWb7xlHjWFWzI9YktFYCIt6VWxtYKIydzLt5wOY0Klpr97VFLh39wIBochT+ljSyQie9I/Oixu4W57VMnfbSLiKpqF7xcX9nWewqXRDYm8kfMiUlIKBaTcdHvBU0CNsaY= Received: by 10.35.119.11 with SMTP id w11mr816920pym; Wed, 17 May 2006 09:08:02 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 17 May 2006 09:08:02 -0700 (PDT) Message-ID: <68fba5c50605170908o72cfabc2v1e692437eadbe2e0@mail.gmail.com> Date: Wed, 17 May 2006 18:08:02 +0200 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: "=?ISO-8859-1?Q?\"Bill_de_h=D3ra\"?=" , "Atom WG" , "The IESG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HG833R013566 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On 5/17/06, Paul Hoffman wrote: > At 7:11 AM +0200 5/17/06, Robert Sayre wrote: > >On 5/17/06, Paul Hoffman wrote: > >> > >>This document describes an extension to an existing standards-track > >>document: it should either be on standards track or it should not be > >>an RFC. > > > >Where is that written down? > > RFC 2026. That's a long document that's been updated by other process RFCs. Care to point me at the relevant section? I didn't see one. > > Didn't Julian just get some WebDAV > >extensions approved as Experimental? > > Maybe, but that's irrelevant. I don't know much about the IETF, but I do know the process consists mostly of the unwritten rules, rather than the written ones. So, it seems to me that it is very much relevant. In fact, I can quote you on this, from the initial Atom meeting at Sun Microsystems. "If you're big on process, the IETF probably isn't for you", or something to that effect. Why the change of heart? > The fact that some WGs don't follow the > IETF process doesn't mean we should do the same. If our AD (who is > also the AD for WebDAV) That's true in the sense that our AD is in the Apps area. However, Ted Hardie is the AD advisor for WebDAV, and those documents were approved before Lisa was an AD, IIRC. But, I suspect you knew all of that. > wanted this document to not be on standards > track, she would not have put out the IETF last call for the document > to be on standards track. OK, phrase it that way. Why does our AD want this document on the standards track? It was clearly designed without much research, no input from client implementers, and contains lots of extra cruft. We also -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed May 17 12:39:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgP3a-0000kE-FQ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:39:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgP3Z-0001qZ-3l for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:39:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGOIvA017311; Wed, 17 May 2006 09:24:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGOIIJ017310; Wed, 17 May 2006 09:24:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGO9WO017268 for ; Wed, 17 May 2006 09:24:16 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50605170908o72cfabc2v1e692437eadbe2e0@mail.gmail.com> References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <68fba5c50605170908o72cfabc2v1e692437eadbe2e0@mail.gmail.com> Date: Wed, 17 May 2006 09:24:04 -0700 To: "Atom WG" From: Paul Hoffman Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At 6:08 PM +0200 5/17/06, Robert Sayre wrote: >On 5/17/06, Paul Hoffman wrote: >> >Where is that written down? >> >>RFC 2026. > >That's a long document that's been updated by other process RFCs. Care >to point me at the relevant section? I didn't see one. Sections 4.1 describes what is appropriate for standards track; section 4.2 describes what is appropriate for Informational and Experimental RFCs. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed May 17 12:44:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgP8G-00014h-GK for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:44:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgP8E-00028Q-Vr for atompub-archive@lists.ietf.org; Wed, 17 May 2006 12:44:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGRMm1017964; Wed, 17 May 2006 09:27:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGRMfP017963; Wed, 17 May 2006 09:27:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGRL1e017957 for ; Wed, 17 May 2006 09:27:22 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so234069wra for ; Wed, 17 May 2006 09:27:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=truq0iue7xPcy1nBNPl2Iu39UsiURvtH2YYcvEfQ7vnboCCZAjVnc+ZzPmOyYLwiE468/Ra38D/hwPYfM94+0WvzKD9BteVBMx61+gJARxo5Gp7853WDkqmzjEmfTUbBObr5WpHx8DjgQtDwKPn8y6t16V5tXBEJ6eaBDSK2TVI= Received: by 10.54.141.6 with SMTP id o6mr1322463wrd; Wed, 17 May 2006 09:27:21 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 10sm1954640wrl.2006.05.17.09.27.11; Wed, 17 May 2006 09:27:12 -0700 (PDT) Message-ID: <446B4EDD.7060602@gmail.com> Date: Wed, 17 May 2006 09:27:09 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom WG , Lisa Dusseault Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> In-Reply-To: <20060517131655.GL1714@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HGRMm1017964 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b I find it utterly amazing that there is so much contention over two optional attributes that serve a purely informational purpose. If a feed publishers includes them, and a particular feed consumer currently doesn't see a use for them, that feed consumer can ignore them and continue processing the feed with ZERO loss of function. "I've started thinking about my schema not as the definition of what this system needs right now but as the definition of what the data should look like if it's present instead." - Tim Ewald, "Making everything optional" [1] There are some folks for whom the attributes will be useful. I know, for instance, that SixApart has found a use for them in some stuff they are doing with Friendster. I have also used the attributes in a browser-based feed aggregator I've been toying around with. Others may not find a use for the attributes at all. That's ok. If you don't have a use for them right now, **ignore them**. If someone implements support for the attributes and finds that they cause some sort of significant interop issue, that's ok, that's why the IETF process is iterative. "Proposed Standards" are not set in stone. They can be changed if implementation experience demonstrates that change is necessar= y. Regarding whether this should be Experimental or a Proposed Standard, I will defer to the judgement of the IESG, however, RFC2026 has the following to say about "Proposed Standards": A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. ... Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Seems appropriate to me. Regarding how The Evil Attributes could be used? Given two replies links= , ... You can display two buttons in a GUI. "Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)" "Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)" - James [1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx A. Pagaltzis wrote: > * Robert Sayre [2006-05-17 07:25]: >> I would have said this should go Experimental, >=20 > +1 >=20 > We can wait and see what problems crop up in practice with the > contested attributes, and whether extensibility according to Sec > 6.4. ff (or lack thereof) turns out to be paramount or, to borrow > Tim=E2=80=99s turn of phrase, a molehill. >=20 > If it works out, just reissue it; if not, there=E2=80=99s room to go ba= ck > and fix it. >=20 > Sounds reasonable enough to me. >=20 > Regards, From owner-atom-syntax@mail.imc.org Wed May 17 13:00:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPOL-0002LI-Jk for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:00:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPOJ-0002rc-3l for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:00:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGfnbt021328; Wed, 17 May 2006 09:41:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGfnNp021327; Wed, 17 May 2006 09:41:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGflPa021302 for ; Wed, 17 May 2006 09:41:48 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.55] (sera-10-169-186-55.nscp.aoltw.net [10.169.186.55]) by mcom.com (8.10.0/8.10.0) with ESMTP id k4HGfZg29627; Wed, 17 May 2006 09:41:36 -0700 (PDT) Message-ID: <446B5241.20301@aol.net> Date: Wed, 17 May 2006 09:41:37 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James M Snell CC: Atom WG , Lisa Dusseault Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> In-Reply-To: <446B4EDD.7060602@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HGfnbt021328 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Experience report: Our implementation of comments for AOL blogs =20 includes the count information in a proprietary extension=20 (aj:commentCount), precisely because we need the information for UI=20 purposes. We've found it useful and we'd like to use a more standard=20 extension to help enable interoperability.=20 The one issue we've had with it was with a partner who used a checksum=20 on the retrieved file to determine if something has 'changed' in the=20 feed. We explained how they can use the update timestamps for that=20 purpose and everything was solved. I don't see any issue with these attributes. -John James M Snell wrote: >I find it utterly amazing that there is so much contention over two >optional attributes that serve a purely informational purpose. If a >feed publishers includes them, and a particular feed consumer currently >doesn't see a use for them, that feed consumer can ignore them and >continue processing the feed with ZERO loss of function. > > "I've started thinking about my schema not as the definition of what > this system needs right now but as the definition of what the data > should look like if it's present instead." > - Tim Ewald, "Making everything optional" [1] > >There are some folks for whom the attributes will be useful. I know, >for instance, that SixApart has found a use for them in some stuff they >are doing with Friendster. I have also used the attributes in a >browser-based feed aggregator I've been toying around with. Others may >not find a use for the attributes at all. That's ok. If you don't have >a use for them right now, **ignore them**. If someone implements >support for the attributes and finds that they cause some sort of >significant interop issue, that's ok, that's why the IETF process is >iterative. "Proposed Standards" are not set in stone. They can be >changed if implementation experience demonstrates that change is necessa= ry. > >Regarding whether this should be Experimental or a Proposed Standard, I >will defer to the judgement of the IESG, however, RFC2026 has the >following to say about "Proposed Standards": > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. > >Seems appropriate to me. > > >Regarding how The Evil Attributes could be used? Given two replies link= s, > > > ... > thr:count=3D"10" thr:when=3D"2006-12-12T12:12:12Z" /> > thr:count=3D"5" thr:when=3D"2006-11-11T11:11:121Z" /> > > >You can display two buttons in a GUI. > > "Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)" > "Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)" > > >- James > >[1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx > >A. Pagaltzis wrote: > =20 > >>* Robert Sayre [2006-05-17 07:25]: >> =20 >> >>>I would have said this should go Experimental, >>> =20 >>> >>+1 >> >>We can wait and see what problems crop up in practice with the >>contested attributes, and whether extensibility according to Sec >>6.4. ff (or lack thereof) turns out to be paramount or, to borrow >>Tim=E2=80=99s turn of phrase, a molehill. >> >>If it works out, just reissue it; if not, there=E2=80=99s room to go ba= ck >>and fix it. >> >>Sounds reasonable enough to me. >> >>Regards, >> =20 >> From owner-atom-syntax@mail.imc.org Wed May 17 13:01:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPP5-0002Y4-Sz for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:01:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPP4-0002td-GP for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:01:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGl6Xu022540; Wed, 17 May 2006 09:47:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGl6Sh022539; Wed, 17 May 2006 09:47:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGl5rT022533 for ; Wed, 17 May 2006 09:47:05 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so238435wra for ; Wed, 17 May 2006 09:47:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=t3vo1M3NXKzSrMJcJVv5ZrwjGR9BZBN13USS6Ozsswqif7XgCkCpOT677ipL1HSD2CxKnMmkSVqkj7sLnh+SR2XDimlcJthI1fmBUIP58vMP0QoEbF82sZW/cm0nhZeJXG1bzL5k1RaqUj8HhsCzEFsPQs5rOvcwzYmCm26hQDo= Received: by 10.54.141.6 with SMTP id o6mr1341692wrd; Wed, 17 May 2006 09:47:04 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 7sm1989398wrh.2006.05.17.09.47.03; Wed, 17 May 2006 09:47:04 -0700 (PDT) Message-ID: <446B5385.9090300@gmail.com> Date: Wed, 17 May 2006 09:47:01 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: John Panzer CC: Atom WG , Lisa Dusseault Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> In-Reply-To: <446B5241.20301@aol.net> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Excellent, thank you. John Panzer wrote: > Experience report: Our implementation of comments for AOL blogs > includes the count information in a proprietary extension > (aj:commentCount), precisely because we need the information for UI > purposes. We've found it useful and we'd like to use a more standard > extension to help enable interoperability. > The one issue we've had with it was with a partner who used a checksum > on the retrieved file to determine if something has 'changed' in the > feed. We explained how they can use the update timestamps for that > purpose and everything was solved. > > I don't see any issue with these attributes. > > -John > From owner-atom-syntax@mail.imc.org Wed May 17 13:04:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPRa-00031o-N0 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:04:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPRZ-00030G-Ag for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:04:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGer9l021126; Wed, 17 May 2006 09:40:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGerXo021125; Wed, 17 May 2006 09:40:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGenuW021094 for ; Wed, 17 May 2006 09:40:52 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so313106pyf for ; Wed, 17 May 2006 09:40:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DIXkpfvfC4mWpoV2OpEkjPuR9mPuyuFFBzK2RnGmvmXRWq8vZDtkLaFIVsc+Us/TqD1ws0Bc/aeOxVwDVCIcJHWSIQVRUv8prp3V9dwHQ6vC2+wiBV6p4rwzE3x/MnS7LdXJdPYGLRnidRaQS6V5EDU16sx+JMd0ko49WrYo77E= Received: by 10.35.49.4 with SMTP id b4mr874172pyk; Wed, 17 May 2006 09:40:47 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 17 May 2006 09:40:47 -0700 (PDT) Message-ID: <68fba5c50605170940s21f945a8u4c02a16d18110925@mail.gmail.com> Date: Wed, 17 May 2006 18:40:47 +0200 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: "Atom WG" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <68fba5c50605170908o72cfabc2v1e692437eadbe2e0@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HGequW021114 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 5/17/06, Paul Hoffman wrote: > > Sections 4.1 describes what is appropriate for standards track; > section 4.2 describes what is appropriate for Informational and > Experimental RFCs. That's true, but the you asserted the following: >>This document describes an extension to an existing standards-track >>document: it should either be on standards track or it should not be >>an RFC. > >Where is that written down? Don't see it in RFC2026. In fact, I don't see any of the process we're encountering documented there. I'm disappointed you didn't answer the more interesting and relevant questions in my previous message. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 17 13:09:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPWB-0003b4-Lc for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:09:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPW7-0003Dd-98 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:09:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGvsfP024986; Wed, 17 May 2006 09:57:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HGvsba024985; Wed, 17 May 2006 09:57:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HGvq6W024868 for ; Wed, 17 May 2006 09:57:53 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 18 May 2006 02:57:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 18 May 2006 02:56:08 +1000 Subject: Re: Feed Thread in Last Call From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20060517124750.GK1714@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 17/5/06 10:47 PM, "A. Pagaltzis" wrote: >> >> >> >> ... >> > > You mean `hreflang`, not `xml:lang`, right? I also meant there to be different hrefs too :-( ... e. From owner-atom-syntax@mail.imc.org Wed May 17 13:14:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPbh-0005b1-SX for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:14:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPbh-0003Pf-GY for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:14:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH3YM3026253; Wed, 17 May 2006 10:03:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HH3YRt026252; Wed, 17 May 2006 10:03:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH3XeQ026246 for ; Wed, 17 May 2006 10:03:33 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 18 May 2006 03:03:52 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 18 May 2006 03:02:08 +1000 Subject: Re: Feed Thread in Last Call From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 18/5/06 1:36 AM, "Sylvain Hellegouarch" wrote: > Apache would respond: "well yes the file has > changed on the disk so here it is" when in fact the content of the feed > has only changed for the number of comments of an entry. so? we have atom:updated to help aggregators detect if there has been a significant change ... everything else is just meta data. e. From owner-atom-syntax@mail.imc.org Wed May 17 13:15:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPbz-0005qB-Bx for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:15:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPbx-0003Q5-VW for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:15:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH2Bts025956; Wed, 17 May 2006 10:02:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HH2BHN025955; Wed, 17 May 2006 10:02:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH29Vp025948 for ; Wed, 17 May 2006 10:02:10 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so318266pyf for ; Wed, 17 May 2006 10:02:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oTO2pOUbQJ8Lr9tnNqM0Pjip+sMhgcEZe9r/2kL8pptCAztB95JyOkQeR3+AKHxuRWShaA8/KIBKsnYaehVwiXvNHSurZKNUPyzhw0KNiedEeB1R7vpx7FN/UZs6uI6d/Ya44ZBoCuSUtq7LW9buuNYD5/Yc6fwL0PSGiWFBTOs= Received: by 10.35.97.17 with SMTP id z17mr1303899pyl; Wed, 17 May 2006 10:02:09 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 17 May 2006 10:02:09 -0700 (PDT) Message-ID: <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> Date: Wed, 17 May 2006 19:02:09 +0200 From: "Robert Sayre" To: "John Panzer" Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) Cc: "James M Snell" , "Atom WG" , "Lisa Dusseault" In-Reply-To: <446B5241.20301@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HH2AVp025949 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On 5/17/06, John Panzer wrote: > > I don't see any issue with these attributes. Do you see Windows Feed Platform apps using these attributes? Probably not, huh? Do you consider that lack of interoperation a feature? > > James M Snell wrote: > > >I find it utterly amazing that there is so much contention over two > >optional attributes that serve a purely informational purpose. Are we supposed to take this seriously? Since you can't coherently defend a single design decision in the draft, it's safe to conclude this document is not ready to be an RFC. > > If a > >feed publishers includes them, and a particular feed consumer currently > >doesn't see a use for them, that feed consumer can ignore them and > >continue processing the feed with ZERO loss of function. Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed May 17 13:28:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPp5-0005YI-Uc for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:28:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPp4-00048C-Ia for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:28:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH9xbr027702; Wed, 17 May 2006 10:09:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HH9xBi027701; Wed, 17 May 2006 10:09:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HH9vme027688 for ; Wed, 17 May 2006 10:09:58 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.118] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 18 May 2006 02:58:18 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 18 May 2006 02:57:49 +1000 Subject: Re: Feed Thread in Last Call From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20060517124750.GK1714@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HH9wme027690 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HH9xbr027702 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 17/5/06 10:47 PM, "A. Pagaltzis" wrote: > I have to say at first blush I don=B9t see why it should not work, > so I find your thought experiment quite amusing. this should be amusing too: ... e. From owner-atom-syntax@mail.imc.org Wed May 17 13:41:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQ1y-0006zm-Vq for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:41:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQ1x-000537-J4 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:41:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHRxkh031693; Wed, 17 May 2006 10:27:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HHRx0O031692; Wed, 17 May 2006 10:27:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHRwIY031686 for ; Wed, 17 May 2006 10:27:59 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so256398wri for ; Wed, 17 May 2006 10:27:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KbJFa6si8hIL5euSmcm/C7hRurzNEjX+mKcOfs31A4WeShshsv8wrErfz5uLqq8d7xh0wXtB9E3Nh/66T5vx7E9Rtg6/EUUhmlO2AruX5kWLmvmgs1o7Y4kL2iTX3wZKU7p3ksq2ri0hS+QuTfa5Y9eAsjL1bLJ3egxK3MnvR+4= Received: by 10.54.103.11 with SMTP id a11mr2738250wrc; Wed, 17 May 2006 10:27:57 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 13sm3179586wrl.2006.05.17.10.27.56; Wed, 17 May 2006 10:27:56 -0700 (PDT) Message-ID: <446B5D16.8000303@gmail.com> Date: Wed, 17 May 2006 10:27:50 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Feed Thread in Last Call References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HHRxkh031693 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Yes. This is possible. What I'm not sure about is whether "amusing" is "good" or "bad". What point are you trying to make exactly? - James Eric Scheid wrote: > On 17/5/06 10:47 PM, "A. Pagaltzis" wrote: >=20 >> I have to say at first blush I don=B9t see why it should not work, >> so I find your thought experiment quite amusing. >=20 > this should be amusing too: >=20 > > > > ... > >=20 > e. >=20 >=20 >=20 From owner-atom-syntax@mail.imc.org Wed May 17 13:54:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQEC-0006j0-07 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:54:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQEA-00066C-JS for atompub-archive@lists.ietf.org; Wed, 17 May 2006 13:54:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHg4EW034884; Wed, 17 May 2006 10:42:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HHg4vO034883; Wed, 17 May 2006 10:42:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHg3LP034868 for ; Wed, 17 May 2006 10:42:03 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 37so459130wra for ; Wed, 17 May 2006 10:42:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=H+jySq47Y1InrqnoOh/WFo2l4IP/ZstQPwQtbx1HTbh3P9/55LnzTrHX7rfmo3yJ37vOe7EZOS79iXPPPTuJzTRGSwVgtzXm/S1rUwEYAztXPfduzesdwnDyq95rXeKkSEsb9hOB+isxRYdL2lSu+Y1VJKGs1lthEhyMHKXdzcs= Received: by 10.54.118.13 with SMTP id q13mr2728831wrc; Wed, 17 May 2006 10:42:02 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 65sm2009550wra.2006.05.17.10.42.01; Wed, 17 May 2006 10:42:02 -0700 (PDT) Message-ID: <446B6067.2010106@gmail.com> Date: Wed, 17 May 2006 10:41:59 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> In-Reply-To: <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Sylvain Hellegouarch wrote: >> The ref attribute is the unique identifier of the resource being >> responded to. It doesn't make make sense to respond to a Feed. > > By the way, don't get me wrong. I am really looking forward to the FTE > replies element but not its attributes which are just useless and counter > productive to my liking. > Can't you just ignore them then? The feed update / last-modified issue is not isolated to the use of thr:when and thr:count. As I mentioned in another note, you end up with the exact same problem when folks use the slash:comments element but no one seems to mind that. This problem is not unique to FTE, nor does FTE make the problem any worse. What else, in your opinion makes them useless and counter productive? I'm seriously asking because I really don't see it. - James > - Sylvain > > From owner-atom-syntax@mail.imc.org Wed May 17 14:10:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQTh-0003dr-Vo for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:10:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQTf-0007Yy-IZ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:10:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHvqvn038660; Wed, 17 May 2006 10:57:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HHvqu1038659; Wed, 17 May 2006 10:57:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+ynpCmOUqtWGszqfXLY+OB7gTgH1dz54I@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHvoBw038651 for ; Wed, 17 May 2006 10:57:51 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19rnrcwcyr8IPJ5QRcnrEYb7Q0PlZWNOX4@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HHvn8o008374; Wed, 17 May 2006 12:57:49 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HHvn75008371; Wed, 17 May 2006 18:57:49 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 84.9.36.47 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 18:57:49 +0100 (BST) Message-ID: <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> In-Reply-To: <446B6067.2010106@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> Date: Wed, 17 May 2006 18:57:49 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "James M Snell" Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > Can't you just ignore them then? The feed update / last-modified issue > is not isolated to the use of thr:when and thr:count. As I mentioned in > another note, you end up with the exact same problem when folks use the > slash:comments element but no one seems to mind that. This problem is > not unique to FTE, nor does FTE make the problem any worse. > > What else, in your opinion makes them useless and counter productive? > I'm seriously asking because I really don't see it. > Well to me there is no need to include, or specify, information that cannot be found otherwise already. Specifying the way to find how to retrieve the replies resource is a great idea and I'm looking forward to it. However, if I'm an aggregator I don't need the thr:count and thr:when because I will find those information anyway with the following process: 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has been posted, I won't fetch the feed containing the entry but the feed containing the comment a. No comment added => 304 Not Modified B. A comment added => I fetch the feed again and know both the number of comments and the date of the latest one This process will happen anyway from the aggregator point of view so I see little value in the 'thr' attributes overall. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 14:11:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQUw-0004gU-MQ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:11:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQUw-0007hs-Ad for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:11:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHxxnP039106; Wed, 17 May 2006 10:59:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HHxxGI039105; Wed, 17 May 2006 10:59:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19s8JQw3q6Q+v63+apGHnx9G1fcP419pW8@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HHxwlZ039099 for ; Wed, 17 May 2006 10:59:58 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19Nd7fZj5HWt8dBycDq+Ngg1V8yV44WZ5I@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HHxvHP008447; Wed, 17 May 2006 12:59:57 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HHxvhh008445; Wed, 17 May 2006 18:59:57 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 84.9.36.47 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 18:59:57 +0100 (BST) Message-ID: <61632.84.9.36.47.1147888797.squirrel@mail1.python-hosting.com> In-Reply-To: References: <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> Date: Wed, 17 May 2006 18:59:57 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "Eric Scheid" Cc: "Atom Syntax" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > > On 18/5/06 1:36 AM, "Sylvain Hellegouarch" wrote: > >> Apache would respond: "well yes the file has >> changed on the disk so here it is" when in fact the content of the feed >> has only changed for the number of comments of an entry. > > so? > > we have atom:updated to help aggregators detect if there has been a > significant change ... everything else is just meta data. > > e. > I'm not sure you have understood me. I'm not talking about the application level but from the HTTP level. If we update the feed each time we update the thr attributes then we screw the HTTP cache big time and waste bandwith. If we don't update them to avoid that issue then those attributes are just useless. Personally I have no interest in doing either way. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 14:14:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQXr-00064R-DG for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:14:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQXq-0007vM-16 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:14:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HI2bgP039736; Wed, 17 May 2006 11:02:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HI2bJx039735; Wed, 17 May 2006 11:02:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18mkCT7HjJXatQGBnle6fxiv3sxciT9CGI@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HI2Zhi039719 for ; Wed, 17 May 2006 11:02:36 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1//otUN01fNX3EQiNFmKo1duTen6P1b9vM@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HI2YLi008530; Wed, 17 May 2006 13:02:34 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HI2YUK008528; Wed, 17 May 2006 19:02:34 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 84.9.36.47 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 19:02:34 +0100 (BST) Message-ID: <61683.84.9.36.47.1147888954.squirrel@mail1.python-hosting.com> In-Reply-To: <446B4A60.6070300@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> <446B4A60.6070300@gmail.com> Date: Wed, 17 May 2006 19:02:34 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "James M Snell" Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > > HTTP provides a possible solution to this in the form of a weak entity > tag. Also, Feed delta encoding could be leveraged to further mitigate > the potential issues. ETag are not reliable without If-Modified-Since header and they are not as wide spreaded. > > I would suspect that you currently have the same problems with folks > that use the highly popular slash:comments RSS extension. FTE is not > introducing any new problems, nor is it seeking to fix existing problems > in the feed syndication model. This is rather sad. So because others are broken we should not do better. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 14:20:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQdK-0007vS-Sy for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:20:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQdJ-00087U-GF for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:20:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HI8nkU041106; Wed, 17 May 2006 11:08:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HI8n1h041104; Wed, 17 May 2006 11:08:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4HI8lXg041054 for ; Wed, 17 May 2006 11:08:47 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 May 2006 18:08:41 -0000 Received: from xdsl-213-196-250-78.netcologne.de (EHLO klangraum) [213.196.250.78] by mail.gmx.net (mp004) with SMTP; 17 May 2006 20:08:41 +0200 X-Authenticated: #163624 Date: Wed, 17 May 2006 20:09:05 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060517180905.GR1714@klangraum> Mail-Followup-To: Atom Syntax References: <446B5D16.8000303@gmail.com> <20060517124750.GK1714@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <446B5D16.8000303@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HI8nkU041106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 * Eric Scheid [2006-05-17 19:10]: > I also meant there to be different hrefs too :-( Oh! I thought that was the point =E2=80=93 the idea being that you can express (roughly =E2=80=93 not precisely) that there are X entries in SomeLanguage at $some-uri and Y entries in OtherLanguage at the same $some-uri. Which I think is in fact expressible. But I=E2=80=99d have to go back and check RFC 4287 in detail to know for sure. * James M Snell [2006-05-17 19:40]: > What I'm not sure about is whether "amusing" is "good" or > "bad". If what you=E2=80=99re asking is what I meant by =E2=80=9Camusing,=E2=80=9D= then the answer is =E2=80=9Cgood.=E2=80=9D Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 17 14:25:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQiN-0001cv-Dr for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:25:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQiK-0008HD-0C for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:25:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HI8ksa041087; Wed, 17 May 2006 11:08:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HI8kF7041086; Wed, 17 May 2006 11:08:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HI8jQ4041080 for ; Wed, 17 May 2006 11:08:45 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so254956wra for ; Wed, 17 May 2006 11:08: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:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kRRKW681XdiFJ5JdKXVITyxnb/aR1lzxyTe+sUDhm6q/l9Ve/aYHIfojB19MVSTOzwh1t1EZf2zLiGFd3UFhisEm+UvFUIkTzj37I6USkkdEedMADhQtHmjmujfvaEfqjarAU1ccng+7P80xbt6S1IPUoVyZUgjQU1XBaA19ex0= Received: by 10.54.89.1 with SMTP id m1mr393962wrb; Wed, 17 May 2006 11:08:44 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 24sm1814245wrl.2006.05.17.11.08.43; Wed, 17 May 2006 11:08:44 -0700 (PDT) Message-ID: <446B66A9.7080007@gmail.com> Date: Wed, 17 May 2006 11:08:41 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> <446B4A60.6070300@gmail.com> <61683.84.9.36.47.1147888954.squirrel@mail1.python-hosting.com> In-Reply-To: <61683.84.9.36.47.1147888954.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Sylvain Hellegouarch wrote: >[snip] >> I would suspect that you currently have the same problems with folks >> that use the highly popular slash:comments RSS extension. FTE is not >> introducing any new problems, nor is it seeking to fix existing problems >> in the feed syndication model. > > This is rather sad. So because others are broken we should not do better. > No. I'm only just trying to solve one problem at a time. - James From owner-atom-syntax@mail.imc.org Wed May 17 14:32:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQom-0002Ov-Sg for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:32:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQom-0008U7-GF for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:32:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIKAdp043737; Wed, 17 May 2006 11:20:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HIKArd043736; Wed, 17 May 2006 11:20:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4HIK8dY043707 for ; Wed, 17 May 2006 11:20:08 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 17 May 2006 18:20:02 -0000 Received: from xdsl-213-196-250-78.netcologne.de (EHLO klangraum) [213.196.250.78] by mail.gmx.net (mp035) with SMTP; 17 May 2006 20:20:02 +0200 X-Authenticated: #163624 Date: Wed, 17 May 2006 20:20:26 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call Message-ID: <20060517182026.GS1714@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4HIKAdp043737 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f * Sylvain Hellegouarch [2006-05-17 20:10]: > However, if I'm an aggregator I don't need the thr:count and > thr:when because I will find those information anyway with the > following process: Consider the situation where a weblog only has a single global comments feed =E2=80=93 which I strongly favour because having one of them for each entry just does not scale. Then it=E2=80=99s easily possible for some comments to have fallen of the bottom of the comments feed by the time you fetch it to check. In that case, the information in the attributes will be more accurate than the process you describe. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 17 14:42:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQz2-0007oU-UW for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:42:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQz1-0000rd-G6 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 14:42:56 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIKivI043883; Wed, 17 May 2006 11:20:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HIKisf043882; Wed, 17 May 2006 11:20:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIKgUn043868 for ; Wed, 17 May 2006 11:20:43 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so257267wra for ; Wed, 17 May 2006 11:20:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I4dyBrfgNpn8cUIQhoGPMqLCmGnq2UsQ9hGr06aVfLJ2zRzAdMXtANF1p0xdHJCP9e5U4g4Hhand3s8lNu5R5YvBDzMTmUdbqe2fWoyWrMqs7E18kPxJsP96xK2tQtw5aINRtcXpU3DYWr9+1FFddQ/hv7f5N5LjQwxIsNA1pLU= Received: by 10.54.89.1 with SMTP id m1mr404478wrb; Wed, 17 May 2006 11:20:42 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 27sm1824789wrl.2006.05.17.11.20.40; Wed, 17 May 2006 11:20:41 -0700 (PDT) Message-ID: <446B6975.2060209@gmail.com> Date: Wed, 17 May 2006 11:20:37 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> In-Reply-To: <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Sylvain Hellegouarch wrote: >[snip] >> What else, in your opinion makes them useless and counter productive? >> I'm seriously asking because I really don't see it. >> > > Well to me there is no need to include, or specify, information that > cannot be found otherwise already. > Do you feel the same way about the link element's existing type, title, hreflang, and length attributes? > Specifying the way to find how to retrieve the replies resource is a great > idea and I'm looking forward to it. > > However, if I'm an aggregator I don't need the thr:count and thr:when > because I will find those information anyway with the following process: > > 1. I fetch the comment feed and put it my cache > 2. I want to know if a new comment has been posted, I won't fetch the feed > containing the entry but the feed containing the comment > a. No comment added => 304 Not Modified > B. A comment added => I fetch the feed again and know both the number > of comments and the date of the latest one > > This process will happen anyway from the aggregator point of view so I see > little value in the 'thr' attributes overall. > This boils down to an implementation choice. The thr attributes provide a way for UI's to display something before fetching the feed, which is often useful for an individual to decide whether or not it is even worthwhile to fetch to the comments feed in the first place. Also, consider that comment feeds may span multiple pages (using the paging link rels). With your algorithm (which, yes, is the only authoritative way of determining *exactly* how many comments have been received), you would have to retrieve every page and count up the comments. Considering also that feeds do not necessarily have to be ordered chronologically (tho most are) and that the feed may contain comments to multiple entries, getting a precise count of the total number of comments can be a time and resource consuming process that involves examining every individual entry in the feed for the presence of a matching in-reply-to link. Alternatively, you could decide to trust that the feed publisher may have already done all this work and has provided a reasonably accurate count in the form of the thr:count attribute. It's your choice. - James From owner-atom-syntax@mail.imc.org Wed May 17 15:59:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgSAi-0001bM-DC for atompub-archive@lists.ietf.org; Wed, 17 May 2006 15:59:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgSAg-0005pQ-VS for atompub-archive@lists.ietf.org; Wed, 17 May 2006 15:59:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HJkZRk063507; Wed, 17 May 2006 12:46:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HJkZ6C063506; Wed, 17 May 2006 12:46:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.myOutlookonlinE.com (mx1.MyOutlookOnline.com [69.25.74.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HJkY01063480 for ; Wed, 17 May 2006 12:46:35 -0700 (MST) (envelope-from byrne@sixapart.com) Received: from be022.mail.lan ([10.109.209.122]) by mx1.myOutlookonlinE.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:46:29 -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: Feed Thread in Last Call Date: Wed, 17 May 2006 15:46:09 -0400 Message-ID: In-Reply-To: <4468FD76.6050805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feed Thread in Last Call Thread-Index: AcZ4b6/kodgeziIcTX6YvrHFo5QL5gBep2fw References: <4468FD76.6050805@gmail.com> From: "Byrne Reese" To: "James M Snell" , "atom-syntax" X-OriginalArrivalTime: 17 May 2006 19:46:29.0011 (UTC) FILETIME=[970C4630:01C679EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HJkZ01063495 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Speaking up: http://www.majordojo.com/atom/standardizing_the_atom_thread_extension.ph p No surprise I guess, but I am a huge +1. Lock this spec down and ship it. -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of James M Snell Sent: Monday, May 15, 2006 3:15 PM To: atom-syntax Subject: Feed Thread in Last Call Hey all, I'm happy to announce that the Feed Thread extension (draft -10) [1] has entered Last Call. [2] The thr:count and thr:when extension attributes are back in Draft -10 following the recent on-list discussion and post by Tim Bray affirming that the atom:link element is indeed extensible. I fully recognize that not everyone on list agrees with this approach, but after trying to propertly implement alternatives, re-reading RFC4287 and surveying folks who I know have already done the work necessary to implement Feed Thread, I believe the decision to keep thr:when and thr:count as attributes is the right decision. At this point, Feed Thread support has been deployed in Friendster, Typepad, and MovableType. I have also added Feed Thread support to my Wordpress and Roller blog templates. IBM has plans to ship at least one product with Feed Thread support in the not too distant future (our Atom Publishing Protocol interop/test endpoint currently contains support for Feed Thread). If you do or do not want to see Feed Thread move forward as a Proposed Standard, now is the time to step up and make your case. :-) - James [1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1 0.txt [2]https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT ag=13577&rfc_flag=0 From owner-atom-syntax@mail.imc.org Wed May 17 16:14:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgSPY-0007Ul-UZ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 16:14:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgSPW-0007CE-Au for atompub-archive@lists.ietf.org; Wed, 17 May 2006 16:14:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIpxLL051836; Wed, 17 May 2006 11:51:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HIpxIr051835; Wed, 17 May 2006 11:51:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIpt4a051801 for ; Wed, 17 May 2006 11:51:56 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.241.143] (sera-10-169-186-18.nscp.aoltw.net [10.169.186.18]) by mcom.com (8.10.0/8.10.0) with ESMTP id k4HIpWg10998; Wed, 17 May 2006 11:51:37 -0700 (PDT) Message-ID: <446B70B6.7010109@aol.net> Date: Wed, 17 May 2006 11:51:34 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sh@defuze.org CC: James M Snell , atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> In-Reply-To: <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Content-Type: multipart/alternative; boundary="------------070908090803080704010800" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.6 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multi-part message in MIME format. --------------070908090803080704010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sylvain Hellegouarch wrote: > > >>Can't you just ignore them then? The feed update / last-modified issue >>is not isolated to the use of thr:when and thr:count. As I mentioned in >>another note, you end up with the exact same problem when folks use the >>slash:comments element but no one seems to mind that. This problem is >>not unique to FTE, nor does FTE make the problem any worse. >> >>What else, in your opinion makes them useless and counter productive? >>I'm seriously asking because I really don't see it. >> >> >> > >Well to me there is no need to include, or specify, information that >cannot be found otherwise already. > > The use case we've identified here is to be able to quickly display the comment count attribute on a web page where you have 10 entries. We really don't want to have to make 10 extra remote calls to retrieve 10 integers when they are so easily included in the top level entry feed; in fact, should a standard require this, we'd have to shrug and embed the data inside proprietary extensions for performance reasons. >Specifying the way to find how to retrieve the replies resource is a great >idea and I'm looking forward to it. > >However, if I'm an aggregator I don't need the thr:count and thr:when >because I will find those information anyway with the following process: > >1. I fetch the comment feed and put it my cache >2. I want to know if a new comment has been posted, I won't fetch the feed >containing the entry but the feed containing the comment > a. No comment added => 304 Not Modified > B. A comment added => I fetch the feed again and know both the number >of comments and the date of the latest one > >This process will happen anyway from the aggregator point of view so I see >little value in the 'thr' attributes overall. > >- Sylvain > > > -- John Panzer System Architect, AOL http://abstractioneer.org --------------070908090803080704010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sylvain Hellegouarch wrote: 
  
Can't you just ignore them then?  The feed update / last-modified issue
is not isolated to the use of thr:when and thr:count.  As I mentioned in
another note, you end up with the exact same problem when folks use the
slash:comments element but no one seems to mind that.  This problem is
not unique to FTE, nor does FTE make the problem any worse.

What else, in your opinion makes them useless and counter productive?
I'm seriously asking because I really don't see it.

    

Well to me there is no need to include, or specify, information that
cannot be found otherwise already.
The use case we've identified here is to be able to quickly display the comment count attribute on a web page where you have 10 entries.  We really don't want to have to make 10 extra remote calls to retrieve 10 integers when they are so easily included in the top level entry feed; in fact, should a standard require this, we'd have to shrug and embed the data inside proprietary extensions for performance reasons.

Specifying the way to find how to retrieve the replies resource is a great
idea and I'm looking forward to it.

However, if I'm an aggregator I don't need the thr:count and thr:when
because I will find those information anyway with the following process:

1. I fetch the comment feed and put it my cache
2. I want to know if a new comment has been posted, I won't fetch the feed
containing the entry but the feed containing the comment
   a. No comment added => 304 Not Modified
   B. A comment added => I fetch the feed again and know both the number
of comments and the date of the latest one

This process will happen anyway from the aggregator point of view so I see
little value in the 'thr' attributes overall.

- Sylvain

  


-- 
John Panzer
System Architect, AOL
http://abstractioneer.org
--------------070908090803080704010800-- From owner-atom-syntax@mail.imc.org Wed May 17 16:25:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgSaT-0000Pf-4L for atompub-archive@lists.ietf.org; Wed, 17 May 2006 16:25:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgSK6-0006hy-Bq for atompub-archive@lists.ietf.org; Wed, 17 May 2006 16:08:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgSBe-0000iL-L9 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 16:00:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIg686049504; Wed, 17 May 2006 11:42:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HIg6Jd049503; Wed, 17 May 2006 11:42:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav14.bay109.hotmail.com [64.4.19.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HIg6xd049496 for ; Wed, 17 May 2006 11:42:06 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 May 2006 11:42:05 -0700 Message-ID: Received: from 85.210.26.209 by BAY109-DAV14.phx.gbl with DAV; Wed, 17 May 2006 18:42:01 +0000 X-Originating-IP: [85.210.26.209] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Subject: Re: Feed Thread in Last Call Date: Wed, 17 May 2006 18:41:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 17 May 2006 18:42:05.0771 (UTC) FILETIME=[9860A1B0:01C679E1] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Sylvain Hellegouarch wrote: > However, if I'm an aggregator I don't need the thr:count and thr:when > because I will find those information anyway with the following process: That's certainly one way of doing things, but not the only way. I'm fairly sure there are existing clients that rely on the thread count (using slash:comments) to determine whether a replies feed has changed. This makes sense when there is a separate feed for each reply - instead of connecting to dozens of feeds looking for updates (and hoping they support 304), you just download the main feed looking for a change in the thread count. If you don't like these attributes, that's fine - nobody is forcing you to use them. But don't assume that everyone wants to do things the same way as you. Don't try and prevent people from doing something different to you just because you personally don't like their choice. Regards James From owner-atom-syntax@mail.imc.org Wed May 17 17:03:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTAs-0006e1-4Q for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:03:18 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTAq-00021P-OZ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:03:18 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HKkolW076327; Wed, 17 May 2006 13:46:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HKkosC076326; Wed, 17 May 2006 13:46:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HKknd4076302 for ; Wed, 17 May 2006 13:46:49 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from [192.168.0.3] (c-67-177-6-93.hsd1.ut.comcast.net[67.177.6.93]) by comcast.net (sccrmhc11) with SMTP id <2006051720464301100k5294e>; Wed, 17 May 2006 20:46:43 +0000 In-Reply-To: <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <10102.194.221.74.7.1147880169.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5360C7B6-F575-457E-A8B8-A64F94CB3676@geckotribe.com> Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: Feed Thread in Last Call Date: Wed, 17 May 2006 14:46:41 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.750) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On May 17, 2006, at 9:36 AM, Sylvain Hellegouarch wrote: > Besides you do not answer the question of HTTP caching I mentionned. > Basically it would break most planets out there which rely heavily > on the > '304 Not Modified' status code to check if a feed has been > modified. In > this case a server such as Apache would respond: "well yes the file > has > changed on the disk so here it is" when in fact the content of the > feed > has only changed for the number of comments of an entry. I do think the document could use a note pointing out that using thr:when and thr:count may increase bandwidth usage by reducing the number of instances where you can send '304 Not Modified' responses. Publishers should weigh the value of those attributes against the cost of providing them when deciding whether to include them in their feeds. From owner-atom-syntax@mail.imc.org Wed May 17 17:53:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTxH-0004en-9B for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:53:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTxF-0005Qh-TW for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:53:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLdrZ0086281; Wed, 17 May 2006 14:39:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HLdrjL086280; Wed, 17 May 2006 14:39:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19ONJpqcr9zktnDoG7b9AT0i4ef8V2h+pk@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLdpCm086255 for ; Wed, 17 May 2006 14:39:52 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19Mg7CEdWkLAAdmv/OGajqeMNIqzlh8DEA@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HLdmto014927 for ; Wed, 17 May 2006 16:39:49 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HLdl5Y014924; Wed, 17 May 2006 22:39:47 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 87.74.84.184 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 22:39:47 +0100 (BST) Message-ID: <61522.87.74.84.184.1147901987.squirrel@mail1.python-hosting.com> In-Reply-To: References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Date: Wed, 17 May 2006 22:39:47 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > If you don't like these attributes, that's fine - nobody is forcing you to > use them. But don't assume that everyone wants to do things the same way > as > you. Don't try and prevent people from doing something different to you > just > because you personally don't like their choice. The problem I've raised is not about my taste in the end but about making sure we have taken every aspects into consideration. As you said, maybe there are other ways of doing than the basic algorithm I suggested but they do not play on the same level. Anyway, sorry if I came harsh on this question. I didn't mean it but saying that I don't have to use it if I don't like it is not really relevant. We re not discussing what each of us would do but what we want the community to be able to do. James > Would you consider adding informative documentation on this matter in the spec or is that out of its boundaries? - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 17:58:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU2M-00075K-T6 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:58:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgU2L-0005jQ-Gu for atompub-archive@lists.ietf.org; Wed, 17 May 2006 17:58:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLgsrs086851; Wed, 17 May 2006 14:42:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HLgsp5086850; Wed, 17 May 2006 14:42:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19+QlkalW3/jIvOKfYrK3R77kZbmtV4W20@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLgrJF086844 for ; Wed, 17 May 2006 14:42:53 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18FaWQfLpddx/8H28P27jolY+4933eWBlA@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HLgrMt015055 for ; Wed, 17 May 2006 16:42:53 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HLgqif015053; Wed, 17 May 2006 22:42:52 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 87.74.84.184 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 22:42:52 +0100 (BST) Message-ID: <61844.87.74.84.184.1147902172.squirrel@mail1.python-hosting.com> In-Reply-To: <446B6975.2060209@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <446B6975.2060209@gmail.com> Date: Wed, 17 May 2006 22:42:52 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > This boils down to an implementation choice. The thr attributes provide > a way for UI's to display something before fetching the feed, which is > often useful for an individual to decide whether or not it is even > worthwhile to fetch to the comments feed in the first place. > > Also, consider that comment feeds may span multiple pages (using the > paging link rels). With your algorithm (which, yes, is the only > authoritative way of determining *exactly* how many comments have been > received), you would have to retrieve every page and count up the > comments. Considering also that feeds do not necessarily have to be > ordered chronologically (tho most are) and that the feed may contain > comments to multiple entries, getting a precise count of the total > number of comments can be a time and resource consuming process that > involves examining every individual entry in the feed for the presence > of a matching in-reply-to link. Alternatively, you could decide to trust > that the feed publisher may have already done all this work and has > provided a reasonably accurate count in the form of the thr:count > attribute. It's your choice. Fair enough. It sounds reasonable but I'm still not fully convinced. I'm happy we discussed it anyway. Thanks, - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 18:09:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUCT-0002Nw-51 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:09:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUCP-0006Ih-Jp for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:09:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLtqnJ089289; Wed, 17 May 2006 14:55:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HLtqWe089288; Wed, 17 May 2006 14:55:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from netc-relay-2m.netcourrier.com (netc-relay-2m.netcourrier.com [194.158.104.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLtpnt089273 for ; Wed, 17 May 2006 14:55:51 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id 428D2B156 for ; Wed, 17 May 2006 23:55:47 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) Date: Wed, 17 May 2006 23:55:47 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HLtqnt089283 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > Subject: Last Call: 'Atom Threading Extensions' to Proposed Standard > (draft-snell-atompub-feed-thread) > From: The IESG > Date: Tue, 16 May 2006 12:53:22 -0700 > The IESG has received a request from an individual submitter to consider the > following document: > > - 'Atom Threading Extensions ' > as a Proposed Standard > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt In section 3, this draft give an xml element corresponding to In-reply-to: (rfc 2822 section 3.6.4). Therefore, the draft do not give an equivalent to References: 822' header field (rfc 2822 section 3.6.4) (wich could be usefull to build a mail --> atom gateway). The section 7.2. do not mention rfc 2822. From owner-atom-syntax@mail.imc.org Wed May 17 18:14:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUHu-0003OR-7s for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:14:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUHs-0006bF-RA for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:14:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLvxe3089695; Wed, 17 May 2006 14:57:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HLvxCR089694; Wed, 17 May 2006 14:57:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX192kOA81ldnQoxnpcr2fowXB4dHBCdVIqs@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HLvwue089680 for ; Wed, 17 May 2006 14:57:58 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+HqAYy2DTQYiSOxE4mW7NJG0X6IEZUaSI@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4HLvnis015507; Wed, 17 May 2006 16:57:49 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4HLvmaq015505; Wed, 17 May 2006 22:57:48 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 87.74.84.184 (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Wed, 17 May 2006 22:57:48 +0100 (BST) Message-ID: <63006.87.74.84.184.1147903068.squirrel@mail1.python-hosting.com> In-Reply-To: <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> Date: Wed, 17 May 2006 22:57:48 +0100 (BST) Subject: Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)) From: "Sylvain Hellegouarch" To: "Robert Sayre" Cc: "John Panzer" , "James M Snell" , "Atom WG" , "Lisa Dusseault" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c My major issue here is not really whether or not those attributes exist but the fact that there is no real review of their implications. We mainly hear of how useful they can be for some existing implementations but it'd be a shame to realize in a couple of years that they were in fact bringing more issues than solving problems. Call me paranoid or picky but I think a few questions that have been raised here were valid ones. Besides this is the all point of this list isn't it? ;) Of course I wouldn't want the community to split. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 17 18:17:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUKb-0004CA-L5 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:17:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUKZ-0006iB-7w for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:17:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HM0Ed7090169; Wed, 17 May 2006 15:00:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HM0EhA090168; Wed, 17 May 2006 15:00:14 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HM0DHn090162 for ; Wed, 17 May 2006 15:00:13 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so306553wri for ; Wed, 17 May 2006 15:00:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S9ctp7PV8yY1+gljjnTpVOXaAusfgrtn05/5/ZGGjn+RcQruaXwd9J4PM2NY7TNYemFx39fTi+5zqOaBwqNevr+7bHmH0MPAii2sHhfUx+6cm71Js1F2s9SxdH/C9f7cU7CD7KHlUifQXq8DMQ426WUmZAuvZNKK+KUXx4Xy2Ow= Received: by 10.54.146.17 with SMTP id t17mr3004124wrd; Wed, 17 May 2006 15:00:13 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 39sm156288wrl.2006.05.17.15.00.11; Wed, 17 May 2006 15:00:12 -0700 (PDT) Message-ID: <446B9CE9.1030200@gmail.com> Date: Wed, 17 May 2006 15:00:09 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <61522.87.74.84.184.1147901987.squirrel@mail1.python-hosting.com> In-Reply-To: <61522.87.74.84.184.1147901987.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Sylvain Hellegouarch wrote: > James > Would you consider adding informative documentation on this > matter in the spec or is that out of its boundaries? What I intend to do is provide a fairly short section discussing the use of the thr attributes, a few comments regarding the precision and authority of their values, and the potential impact that changes to metadata of any kind in a Feed may have on the cacheability of the feed document. The latter is, of course, not specific to FTE, but apparently is enough of a problem to at least warrant a mention. - James From owner-atom-syntax@mail.imc.org Wed May 17 18:26:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUTo-0002Fa-QN for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:26:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUTn-00071u-Dn for atompub-archive@lists.ietf.org; Wed, 17 May 2006 18:26:56 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HMFfaw093204; Wed, 17 May 2006 15:15:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HMFfus093203; Wed, 17 May 2006 15:15:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HMFeJw093195 for ; Wed, 17 May 2006 15:15:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 55so308083wri for ; Wed, 17 May 2006 15:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sURx+Kac54G+Fa2HJFhbzNB/Lr4co51ITo643yMaxVzZlDtrOUmPh8VRDuw1xCGi56U5dl7DyaoI4hBowMNsn4lQzJ/bpNx6ZWE71w4KWNv7SFShjOUZV+2nJvWvK6pavpuvHhy+bFn2n9xNqgQqay+dvtF3TzvgH7WuocU9Viw= Received: by 10.54.103.11 with SMTP id a11mr3030579wrc; Wed, 17 May 2006 15:15:40 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 64sm105328wra.2006.05.17.15.15.39; Wed, 17 May 2006 15:15:40 -0700 (PDT) Message-ID: <446BA089.7000709@gmail.com> Date: Wed, 17 May 2006 15:15:37 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Nicolas Krebs CC: atom-syntax@imc.org Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hello Nicolas, thanks for the comments. Nicolas Krebs wrote: >[snip] > In section 3, this draft give an xml element corresponding to In-reply-to: > (rfc 2822 section 3.6.4). Therefore, the draft do not give an equivalent to > References: 822' header field (rfc 2822 section 3.6.4) (wich could be usefull > to build a mail --> atom gateway). > A feed thread element in the form of Would serve as the equivalent to the RFC2822 in-reply-to header. And yes, it would likely be good to mention that the in-reply-to element draws some of its inspiration from the smtp in-reply-to header. - James From owner-atom-syntax@mail.imc.org Wed May 17 19:58:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVu1-0007dm-WA for atompub-archive@lists.ietf.org; Wed, 17 May 2006 19:58:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVu0-0003uv-HT for atompub-archive@lists.ietf.org; Wed, 17 May 2006 19:58:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNjpmA010910; Wed, 17 May 2006 16:45:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HNjpL7010908; Wed, 17 May 2006 16:45:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.myOutlookonlinE.com (mx1.MyOutlookOnline.com [69.25.74.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNjoZb010881 for ; Wed, 17 May 2006 16:45:50 -0700 (MST) (envelope-from byrne@sixapart.com) Received: from be022.mail.lan ([10.109.209.122]) by mx1.myOutlookonlinE.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 19:45:43 -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: Feed Thread in Last Call Date: Wed, 17 May 2006 19:45:23 -0400 Message-ID: In-Reply-To: <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feed Thread in Last Call Thread-Index: AcZ53bBFsEh3nQu9RRqxqzEzLbc/kAAK8lbw References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> From: "Byrne Reese" To: , "James M Snell" Cc: X-OriginalArrivalTime: 17 May 2006 23:45:43.0093 (UTC) FILETIME=[02BF5E50:01C67A0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HNjpZb010901 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac > However, if I'm an aggregator I don't need the thr:count and thr:when because I will find > those information anyway with the following process: > > 1. I fetch the comment feed and put it my cache 2. I want to know if a new comment has > been posted, I won't fetch the feed containing the entry but the feed containing the > comment > a. No comment added => 304 Not Modified > b. A comment added => I fetch the feed again and know both the number of comments and > the date of the latest one When Friendster approached Six Apart and asked for a way to keep abreast as to the comment activity within the Friendster Blogging network (powered by TypePad), I turned immediately to FTE. In this implementation, there was actually no desire for Friendster to gain access to the comments themselves - all they wanted was to know: has there been a new comment posted to any of this users blog entries? And in actually, TypePad didn't want to add another page to be rebuilt. We wanted to keep things as simple as possible, in order to satisfy the customer's requirements within incurring any more development overhead than absolutely necessary. FTE was a perfect fit because it allowed Friendster to monitor comment activity quite reliably. The count attribute wasn't enough for them because the count attribute by itself doesn't reflect accurately if a new comment was posted (e.g. comment count is 0, new comment received, comment count is 1, comment deleted, comment count is 0, comment received, etc). Depending upon the poll interval of the client, it may miss the fact that a comment was posted. However, the count attribute and then when attribute gave Friendster just what they needed: enough information to know that a) a new comment was received, and b) sufficiently (not necessary 100% accurate, but they didn't care) accurate comment count. They used this information to send emails to the blog owner saying, since we last emailed you, there has been this activity on your blog. The Friendster link relation looks like this: Notice, in this case we are pointing to the HTML page where comments can be found - and not to another Atom feed because we don't produce a comments feed. We simply produce some meta data about comment activity. Furthermore, Six Apart likes this spec as-is because it helps to reduce the number of documents that need to be parsed in order to determine simple details about an entry. The burden of having to fetch an Atom document for each entry and then counting the number of entries within that feed to derive a count, is totally absurd. If you CAN make it easier for a developer, why won't you? Not to mention that in Friendster's case, this process would not have worked for them because we didn't produce a feed for them to extract this information from, because their requirements forbade it. I have gone on long enough. I am hoping this gave some good background around a real implementation and use case currently in use today. Caveat: Six Apart didn't implement this extension with ANY assumption that it would remain as-is. James warned me that it could change - and in fact it did. We implemented it knowing full well it wasn't final. But despite the risk of it not being final - it was still the best solution on the market. Byrne Reese Manager, Platform Technology Six Apart, Ltd. From owner-atom-syntax@mail.imc.org Wed May 17 20:09:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW4n-0003kG-4X for atompub-archive@lists.ietf.org; Wed, 17 May 2006 20:09:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgW4m-0004YC-PJ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 20:09:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNuKi2012735; Wed, 17 May 2006 16:56:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HNuKsr012733; Wed, 17 May 2006 16:56:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.myOutlookonlinE.com (mx1.MyOutlookOnline.com [69.25.74.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNuJdU012714 for ; Wed, 17 May 2006 16:56:19 -0700 (MST) (envelope-from byrne@sixapart.com) Received: from be022.mail.lan ([10.109.209.122]) by mx1.myOutlookonlinE.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 19:56:14 -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: Feed Thread in Last Call Date: Wed, 17 May 2006 19:55:54 -0400 Message-ID: In-Reply-To: <446B6975.2060209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feed Thread in Last Call Thread-Index: AcZ54oFeeqQ5Q9mhQiuO0+CRRLRcygAKfrIQ References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <446B6975.2060209@gmail.com> From: "Byrne Reese" To: "James M Snell" , X-OriginalArrivalTime: 17 May 2006 23:56:14.0057 (UTC) FILETIME=[7AD4D590:01C67A0D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4HNuJdU012725 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 > Alternatively, you could decide to > trust that the feed publisher may have already done all this work and > has provided a reasonably accurate count in the form of the thr:count > attribute. It's your choice. This to me is what its all about. I hear a lot of people saying that you can't be sure that the comment count is accurate. That the ONLY way to be sure is to get the whole feed with all the comments. To those people I would say you have "trust issues." I am being snide, I admit, but truthfully, why would Six Apart (or any other implementer) not want to keep the two values in sync when it is so clear that we SHOULD. Certainly my implementations do. And if they were ever out of sync (i.e. the count attribute saying 5, and the feed containing 6) then that is a bug and I frick'n need to fix that. Byrne From owner-atom-syntax@mail.imc.org Wed May 17 20:11:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgW79-0004pW-Ej for atompub-archive@lists.ietf.org; Wed, 17 May 2006 20:11:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgW79-0004d4-1i for atompub-archive@lists.ietf.org; Wed, 17 May 2006 20:11:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNwlE9013144; Wed, 17 May 2006 16:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4HNwlBi013143; Wed, 17 May 2006 16:58:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4HNwkEr013136 for ; Wed, 17 May 2006 16:58:46 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 12A7B142270; Wed, 17 May 2006 16:58:46 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27961-03; Wed, 17 May 2006 16:58:45 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 94BB114226C; Wed, 17 May 2006 16:58:45 -0700 (PDT) In-Reply-To: <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09EE30D9-0446-4D1D-AC56-9018AD9F80B9@osafoundation.org> Cc: Atom WG , IESG Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Informational vs. standards-track for Atom Threading Extensions Date: Wed, 17 May 2006 16:58:36 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On May 17, 2006, at 10:02 AM, Robert Sayre wrote: > > Well, you clearly don't think they're important. But then you felt > compelled to change them back and got an instant stamp of approval > from our AD. What happened there? I read this as implying causality between two events. Those two events happened to be near each other in time but weren't causally related. The changes just before the last revision had no impact on my decision to post an IETF Last Call for moving this proposal onto the standards track. It could not have had an impact because I wasn't so closely tuned into the revisions of this draft that I noticed any particular change -- I just reviewed the version presented to me with the shepherding request. My decision to shepherd this document was because I was asked, read the proposal, and felt it was not obviously too harmful and could be useful. It's customary to ask the advising AD for a WG, to shepherd a document closely related to that WG. My decision to recommend Standards Track was because I saw evidence of multiple independent implementations and even some interoperability testing. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I would be less likely to recommend Informational status for a document like this which has been implemented and has normative statements intended for implementors (e.g. it's not a requirements document or a design overview). Confusingly, Informational is also used sometimes for documents which do not undergo significant community review (e.g. RFC-Editor submissions) but the 4-week IETF last call, previous postings to this list, and comments of implementors, combine to make this document one that is getting significant community review. I hope that makes the situation clearer! Lisa From owner-atom-syntax@mail.imc.org Wed May 17 21:51:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgXg1-0001Hu-V4 for atompub-archive@lists.ietf.org; Wed, 17 May 2006 21:51:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgXg1-0007va-QJ for atompub-archive@lists.ietf.org; Wed, 17 May 2006 21:51:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgXRs-0004Yp-MM for atompub-archive@lists.ietf.org; Wed, 17 May 2006 21:37:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I1J3e0028853; Wed, 17 May 2006 18:19:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4I1J3Qn028852; Wed, 17 May 2006 18:19:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I1J2Eo028844 for ; Wed, 17 May 2006 18:19:02 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1286D142270; Wed, 17 May 2006 18:19:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07976-07; Wed, 17 May 2006 18:19:00 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C79414226C; Wed, 17 May 2006 18:19:00 -0700 (PDT) In-Reply-To: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) Date: Wed, 17 May 2006 18:18:57 -0700 To: Andreas Sewe X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.5 (--) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 For related work, you could look at the email spam filtering stuff from SIEVE: The similar problem is that many spam libraries already produce some kind of linear or similar scale of severity/likelihood rating for emails, much like existing services already provide their own scale of post rankings. The approach SIEVE took, very roughly, was simply to tell implementors to find some way to map their implementation's ranking scheme to a canonical range of numerical values. A SIEVE implementation might have one algorithm for converting SpamAssassin rankings to the canonical scale, and a different algorithm for some different library. Since spam rankings are intended more for automated filters than for user display (though clearly the user is sometimes involved in evaluating the rankings, as when the user creates/edits a mail filter rule like "file all email with a spam rating > 5 to spam folder"), the considerations of course could be different from the case of Atom post rankings. Lisa On May 5, 2006, at 7:48 AM, Andreas Sewe wrote: > > Having ended up as co-author of the Atom Rank Extensions draft > index-09.txt> > I would like to encourage some more discussion on the extension's > features. I would especially like to know whether they are flexible > enough to cope with all the major use cases while being at the same > time > reasonably simple to implement. > > The extension should, e.g., be able to cope with most grading > schemes in > use; it needs to be able to describe the set of permissible rank > values > (grades). So we are talking (totally) ordered sets here. > > Now the order part is easy; that is what @significance > (="ascending"/"descending") is for. The hard part is to describe the > underlying set of numbers. > > Now the current draft defines two elements, r:value and r:range, for > this purpose. Those two elements can be, however, be collapsed into a > single one, and, with cleverly chosen defaults, defining sets using > this > new r:values element is IMHO as simple, if not simpler, as with the > old > approach. Others might have different opinions, though, which I would > really like to hear about. > > At any rate, the proposed change looks basically as follows (Note, > however, that the issue of rounding rank values has intentionally been > left out, since this would only distract from the design issue at > hand.) > > > The r:scheme Element > > Ranking Schemes are defined using the r:scheme element. Each scheme > defines the set of rank values permissible for all r:rank elements > with > the associated scheme. > > [...] > > The set of rank values defined by an r:scheme element is the union of > the sets of rank values defined by each of its r:values elements. > Note > that those sets may overlap. > > The r:values Element > > The r:values elements defines a set of rank values, each of which > has to > conform to the XML Schema decimal data type [W3C.REC- > xmlschema-2-20041028]. > > values = element r:values { > atomCommonAttributes, > attribute minimum { xsd:decimal | "unbounded" }?, > attribute maximum { xsd:decimal | "unbounded" }?, > attribute steps { xsd:decimal | "continuous" }?, > attribute origin { xsd:decimal }?, > undefinedContent > } > > The "minimum" attribute specifies an inclusive lower bound on the > set of > rank values defined by the r:values element. Here, the special > value of > "unbounded" denotes negative infinity. If not specified, the value of > the "minimum" attribute is considered to be "unbounded". > > The "maximum" attribute specifies an inclusive upper bound on the > set of > rank values defined by the r:values element. Here, the special > value of > "unbounded" denotes positive infinity. If not specified, the value of > the "minimum" attribute is considered to be "unbounded". > > The "steps" attribute specifies either an increment or has the special > value "continuous". If not specified, the value of the "steps" > attribute is considered to be 0. > > The "origin" element specifies the base from which steps are to be > calculated. If not specified, the value of the "origin" attribute is > considered to be 0. > > If the value of the "steps" attribute is "continuous" the set of rank > values defined by the r:values element is > > { x | minimum <= x <= maximum }. > > Otherwise the set of rank values defined by the r:values element is > > { x | minimum <= x <= maximum, > x = (origin + i * steps) for some integer i }. > > The following examples illustrate how different sets of rank values > can > be defined by means of a single r:value element: > > > > > > > > > > > > > > > > > > > > > That's all. Also note that this approach allows overlapping r:values > sets. For example, one is now able to define, in a reasonable concise > way, the following grading scheme common in Germany: > > > > > > > > > > Of course one could alternatively list all 11 values explicitly, > but the > above is rather more concise. (In fact, the definition of 5.0 could > even be moved into the first r:values element.) > > But as I said above, others might see this differently... > > Also, I would like to know whether a definition in terms of set > notation > is fine with you, or whether we should expand on the natural language > explanations. Describing precisely what "origin" and "steps" do, in > plain English, is unfortunately surprisingly difficult. :-( > > Looking forwards to your feedback, > > Andreas Sewe > From owner-atom-syntax@mail.imc.org Wed May 17 23:05:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgYpR-000416-Bu for atompub-archive@lists.ietf.org; Wed, 17 May 2006 23:05:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgYpR-00064y-AK for atompub-archive@lists.ietf.org; Wed, 17 May 2006 23:05:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgYcw-0005FX-0S for atompub-archive@lists.ietf.org; Wed, 17 May 2006 22:52:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I2fMJR047654; Wed, 17 May 2006 19:41:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4I2fM16047653; Wed, 17 May 2006 19:41:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I2fLag047645 for ; Wed, 17 May 2006 19:41:21 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id c31so430175pyd for ; Wed, 17 May 2006 19:41:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hYtttIoXNLhbh2uv0zIBv4Yz4ZfLsqMZxm4vuVAkq4To49n/1iXMfUOvqUPNUYD2xIKjwOOJl65pGJzRAjcuNEPLk3XjIbhb+nArwrWsK7zYr/+hHCIhMGLwpXq4Qf1U50K/Cz3BEbUBeaUprHrHRsrHXD9kXTpPw7Zhns0KVJY= Received: by 10.35.66.12 with SMTP id t12mr32160pyk; Wed, 17 May 2006 19:41:20 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 17 May 2006 19:41:15 -0700 (PDT) Message-ID: <68fba5c50605171941o3a071b2ah84954034f120a8a9@mail.gmail.com> Date: Thu, 18 May 2006 04:41:15 +0200 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Informational vs. standards-track for Atom Threading Extensions Cc: "Atom WG" , IESG In-Reply-To: <09EE30D9-0446-4D1D-AC56-9018AD9F80B9@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> <09EE30D9-0446-4D1D-AC56-9018AD9F80B9@osafoundation.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4I2fMag047648 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.7 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 5/18/06, Lisa Dusseault wrote: > > On May 17, 2006, at 10:02 AM, Robert Sayre wrote: > > > > Well, you clearly don't think they're important. But then you felt > > compelled to change them back and got an instant stamp of approval > > from our AD. What happened there? My question has yet to be answered. > > I could still recommend Experimental instead of Standards Track if I > learned of some possible harm to security/privacy or Internet health, > or some deep barrier to interoperability, but I have not yet learned > of a high enough risk+severity of such concerns to change my mind there. I think this is an excellent standard. If another individual, such as myself, were to submit an individually authored document, it would have to meet the same standard, right? > > I hope that makes the situation clearer! Sure does! -- Robert Sayre From owner-atom-syntax@mail.imc.org Thu May 18 04:39:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fge2Z-0005km-7I for atompub-archive@lists.ietf.org; Thu, 18 May 2006 04:39:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fge2X-0000f4-P4 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 04:39:27 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I8Rdes023436; Thu, 18 May 2006 01:27:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4I8RdkF023435; Thu, 18 May 2006 01:27:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18ka13OKLv0k3RK8+1JIu/e98SpBZGj+uM@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I8Rc8Q023428 for ; Thu, 18 May 2006 01:27:38 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/k77aZeK+w2ogVq5x0LnPKGCRS6dv0sP0@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4I8RbkM029679; Thu, 18 May 2006 03:27:37 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4I8Rbtb029677; Thu, 18 May 2006 09:27:37 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 09:27:37 +0100 (BST) Message-ID: <12774.194.221.74.7.1147940857.squirrel@mail1.python-hosting.com> In-Reply-To: <446B9CE9.1030200@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <61522.87.74.84.184.1147901987.squirrel@mail1.python-hosting.com> <446B9CE9.1030200@gmail.com> Date: Thu, 18 May 2006 09:27:37 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "James M Snell" Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > The latter is, of course, not specific to FTE, but apparently is enough > of a problem to at least warrant a mention. > Thank you. This is fully appreciated. - Sylvain From owner-atom-syntax@mail.imc.org Thu May 18 04:41:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fge4l-0006ZD-NJ for atompub-archive@lists.ietf.org; Thu, 18 May 2006 04:41:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fge4l-0000lH-4g for atompub-archive@lists.ietf.org; Thu, 18 May 2006 04:41:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I8QMob023178; Thu, 18 May 2006 01:26:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4I8QMMY023177; Thu, 18 May 2006 01:26:22 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+VmjwURjpwaOExw28skyMi4cVqWF3fEL8@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4I8QKpF023169 for ; Thu, 18 May 2006 01:26:21 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/GBJIdQUhNPITAiDSnJlQXPvedcXMHuNc@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4I8QJOd029634; Thu, 18 May 2006 03:26:19 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4I8QIK3029632; Thu, 18 May 2006 09:26:18 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 09:26:18 +0100 (BST) Message-ID: <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> In-Reply-To: References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <68fba5c50605161503i78873ac6o1a9524edbea4a409@mail.gmail.com> <446A587D.8030107@gmail.com> <68fba5c50605161638v28df5f1bpa6d412ea59c04b49@mail.gmail.com> <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> Date: Thu, 18 May 2006 09:26:18 +0100 (BST) Subject: RE: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "Byrne Reese" Cc: sh@defuze.org, "James M Snell" , atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a > > When Friendster approached Six Apart and asked for a way to keep abreast > as to the comment activity within the Friendster Blogging network > (powered by TypePad), I turned immediately to FTE. > > In this implementation, there was actually no desire for Friendster to > gain access to the comments themselves - all they wanted was to know: > has there been a new comment posted to any of this users blog entries? > > And in actually, TypePad didn't want to add another page to be rebuilt. > We wanted to keep things as simple as possible, in order to satisfy the > customer's requirements within incurring any more development overhead > than absolutely necessary. > > FTE was a perfect fit because it allowed Friendster to monitor comment > activity quite reliably. The count attribute wasn't enough for them > because the count attribute by itself doesn't reflect accurately if a > new comment was posted (e.g. comment count is 0, new comment received, > comment count is 1, comment deleted, comment count is 0, comment > received, etc). Depending upon the poll interval of the client, it may > miss the fact that a comment was posted. > > However, the count attribute and then when attribute gave Friendster > just what they needed: enough information to know that a) a new comment > was received, and b) sufficiently (not necessary 100% accurate, but they > didn't care) accurate comment count. They used this information to send > emails to the blog owner saying, since we last emailed you, there has > been this activity on your blog. > > The Friendster link relation looks like this: > > href="http://..../foo.html#comments" > thr:when="" thr:count="" /> > > Notice, in this case we are pointing to the HTML page where comments can > be found - and not to another Atom feed because we don't produce a > comments feed. We simply produce some meta data about comment activity. > > Furthermore, Six Apart likes this spec as-is because it helps to reduce > the number of documents that need to be parsed in order to determine > simple details about an entry. The burden of having to fetch an Atom > document for each entry and then counting the number of entries within > that feed to derive a count, is totally absurd. If you CAN make it > easier for a developer, why won't you? Well you simply move the burden to a different level where it is not your problem anymore, ie on the HTTP level and far from the application level. It is fine but the load will be paid by someone at any given time. > > Not to mention that in Friendster's case, this process would not have > worked for them because we didn't produce a feed for them to extract > this information from, because their requirements forbade it. > > I have gone on long enough. I am hoping this gave some good background > around a real implementation and use case currently in use today. You did and I thank you for sharing this information. That being said, I raised two points in me original mail: 1. The fact I thought the thr attributes were useless. You made a good case and I will not fight against their use on the application level anymore. We are therefore fine on *that* level. 2. The burden added to the HTTP layer. I'll try to make myself clear. In your implementation above you have to update the Atom feed to modify the thr attributes. The problem is that you have then to update the last modified date of the resource (as in the REST definition of resource) itself (whether you generate ir on the fly or save it on disk). For aggregators which are aware of the FTE, it won't be so much of a problem as you showed me because they will know how to deal with that on the application level and make the best of it. However, there will be clients which won't care about the semantic of the resource, their point is simply to fetch a resource and cache it as long as it is not modified. By acting as you do, we may end up in a huge amount of feeds being sent on the wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they will not handle anyway). This is my grief. Your use case is great at the application level but could really mess bandwith usage as well. That's why I also say you have moved the burden down to one level so that it doesn't make your life more complicated and so that others pay the price of it. I'd be interested to hearing from Friendster about their feed bandwith usage since you have setup the FTE. However I'm not blind enough either to realise my algorithm would not be much better in some circumstances. I guess my problem is that the semantic conveyed by those attributes should belong to a push protocol and not to a pulled one like HTTP. I aslo understand that Atom and its extensions are not protocol aware. They should not have to care about HTTP. It does not mean though that we cannot think about their implications in those areas. Thanks for your feedback. - Sylvain From owner-atom-syntax@mail.imc.org Thu May 18 09:31:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgibZ-0005sl-3Q for atompub-archive@lists.ietf.org; Thu, 18 May 2006 09:31:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgibY-0001Ov-A7 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 09:31:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDFvDT090479; Thu, 18 May 2006 06:15:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IDFvtf090478; Thu, 18 May 2006 06:15:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDFreQ090435 for ; Thu, 18 May 2006 06:15:56 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060518131546.HMT29040.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Thu, 18 May 2006 14:15:46 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20060518131546.VYLE16286.aamtaout03-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Thu, 18 May 2006 14:15:46 +0100 Date: Thu, 18 May 2006 14:15:43 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <97566250.20060518141543@djpowell.net> To: James M Snell CC: atom-syntax , Lisa Dusseault Subject: Re: Feed Thread in Last Call In-Reply-To: <44694BEB.6090203@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote: > A few of the individuals on the WG had a problem with the placement of > the attributes due to various limitations of a few existing Atom 1.0 > implementations. That doesn't accurately state my problem with FTE. My concern is more general than the compatibility with a specific Atom implementations. The fact that the MS feed platform exhibits the issue is just a confirmation that the issue is more than a theoretical concern. An implementor that wants to /consume/ Atom (such as a feed API, or store), ought to be able to create an accurate implementation just by reading RFC4287. That document describes what properties entries, feeds, links, and extension elements have, and how they are represented in an Atom document. Using this it is possible to create a database schema or OO API that can represent feed data. My problem with FTE is that rather than using Atom's extension-point: the "Extension Element" (which an implementor of RFC4287 is likely to be capable of preserving), it uses the fact that Atom doesn't prohibit extra attributes to be included anywhere in the document. Is an API, feed store, or Atom Protocol implementation expected to preserve every attribute on every element, in addition to the core elements, and extension points? This might be practical on a few green-field Atom implementations, but it wouldn't be practical on systems than need to be retrofitted to support Atom. What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. Atom implementations with generic support for links and extensions, will find that this draft moves the goalposts of what a reasonable implementation is expected to handle, and I firmly believe that it should be possible for implementations to provide generic support for extensions in order to assist their adoption. Part of the problem might be caused by flaws in Atom's extensibility model, but that is all the more reason for extensions to be conservative in its use. > None of the folks I know of that have actually > implemented support for the extension has had any problems with them. Does that include any stateful feed APIs, or APP servers that aren't based on native XML back-ends? I notice that you said "implemented support" - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to "implement support" for each new bit of content that publishers put into their feeds. -- Dave From owner-atom-syntax@mail.imc.org Thu May 18 09:35:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgifS-0007ZU-Al for atompub-archive@lists.ietf.org; Thu, 18 May 2006 09:35:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgifQ-0001ca-UK for atompub-archive@lists.ietf.org; Thu, 18 May 2006 09:35:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDO5JF092380; Thu, 18 May 2006 06:24:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IDO5ol092379; Thu, 18 May 2006 06:24:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDO4Cq092362 for ; Thu, 18 May 2006 06:24:05 -0700 (MST) (envelope-from hwinkler@gmail.com) Received: by nz-out-0102.google.com with SMTP id x7so102696nzc for ; Thu, 18 May 2006 06:24:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=OmAaE6lAgrR3XfOAhTgtwkJM2Za3UrvZ5Ckj3cu3AhxYi87EhhTg/mssLD2nEZ8bZQSJEozing9MUMh0PS+QXBZpG/SVKJVRz4MpBd6nU6GFu3oCZXPX170u2lCA3so38nI2tMSBZUPJ/uoCLERMh//FezFwcV/wpiRJz5KgVgg= Received: by 10.65.254.14 with SMTP id g14mr300420qbs; Thu, 18 May 2006 06:24:03 -0700 (PDT) Received: by 10.65.215.17 with HTTP; Thu, 18 May 2006 06:24:03 -0700 (PDT) Message-ID: <927441b30605180624v67e9db08lb114d1bb816dc0be@mail.gmail.com> Date: Thu, 18 May 2006 08:24:03 -0500 From: "Hugh Winkler" To: sh@defuze.org Subject: Re: Feed Thread in Last Call Cc: "Byrne Reese" , "James M Snell" , atom-syntax@imc.org In-Reply-To: <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_85210_18911829.1147958643490" References: <4468FD76.6050805@gmail.com> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> X-Google-Sender-Auth: 70f1913fb46d395e Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b ------=_Part_85210_18911829.1147958643490 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > By acting as you do, we may end up in a huge amount of feeds being sent o= n > the wire to clients which believe the feed has actually changed in its > content when it has changed only in one meta-data value (that they will > not handle anyway). Servers don't *have* to change the feed's Last-Modified and ETag values whe= n a comment count changes. They are free to respond 304 to a conditional GET, even if the count has changed. Hugh ------=_Part_85210_18911829.1147958643490 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

By a= cting as you do, we may end up in a huge amount of feeds being sent on
t= he wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they will=
not handle anyway).


Servers don't *have* to change the feed's Last-Modified and ETag values when a comment count changes. They are free to respond 304 to a conditional GET, even if the count has changed.

Hugh

------=_Part_85210_18911829.1147958643490-- From owner-atom-syntax@mail.imc.org Thu May 18 10:10:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjCi-0002se-7d for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:10:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjCf-0003bZ-RW for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:10:16 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDx0gZ000977; Thu, 18 May 2006 06:59:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IDx0Xl000976; Thu, 18 May 2006 06:59:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18bTW4Fn9yuBu0bgUEpu5vfmRK3DV2oSSk@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IDwxYd000970 for ; Thu, 18 May 2006 06:58:59 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/AvW5YUEouTNI5SuXQ5ARWW8+NRf66a0s@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4IDww65006890; Thu, 18 May 2006 08:58:58 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4IDwvrb006888; Thu, 18 May 2006 14:58:57 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 14:58:57 +0100 (BST) Message-ID: <32482.194.221.74.7.1147960737.squirrel@mail1.python-hosting.com> In-Reply-To: <927441b30605180624v67e9db08lb114d1bb816dc0be@mail.gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <927441b30605180624v67e9db08lb114d1bb816dc0be@mail.gmail.com> Date: Thu, 18 May 2006 14:58:57 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: "Hugh Winkler" Cc: sh@defuze.org, "Byrne Reese" , "James M Snell" , atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >> >> By acting as you do, we may end up in a huge amount of feeds being sent >> on >> the wire to clients which believe the feed has actually changed in its >> content when it has changed only in one meta-data value (that they will >> not handle anyway). > > > > Servers don't *have* to change the feed's Last-Modified and ETag values > when > a comment count changes. They are free to respond 304 to a conditional > GET, > even if the count has changed. > Well this is debatable because you effectively change the resource itself and ought to update its meta-data as well (ie Last-Modified and Etag values). Besides, by not doing so can be even worse because an aggregator would requests the feed, the server would respond with a 304 and the aggregator would not even know the count ahs changed in the end. It feels even worse. - Sylvain From owner-atom-syntax@mail.imc.org Thu May 18 10:28:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgjUL-0008Il-Pe for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:28:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjUK-0005Bp-E2 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:28:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IECX9I004159; Thu, 18 May 2006 07:12:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IECXaf004158; Thu, 18 May 2006 07:12:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18p/m/3M8IDplmpZzB7k/84xBawyemW4To@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IECUkC004132 for ; Thu, 18 May 2006 07:12:32 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/OyMstVYFdA/kIBDKmg7SP6iAmCV4dZn4@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4IECQ3p007326; Thu, 18 May 2006 09:12:26 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4IECQIK007324; Thu, 18 May 2006 15:12:26 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 15:12:26 +0100 (BST) Message-ID: <61983.194.221.74.7.1147961546.squirrel@mail1.python-hosting.com> In-Reply-To: <32482.194.221.74.7.1147960737.squirrel@mail1.python-hosting.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <927441b30605180624v67e9db08lb114d1bb816dc0be@mail.gmail.com> <32482.194.221.74.7.1147960737.squirrel@mail1.python-hosting.com> Date: Thu, 18 May 2006 15:12:26 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: sh@defuze.org Cc: "Hugh Winkler" , sh@defuze.org, "Byrne Reese" , "James M Snell" , atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > Well this is debatable because you effectively change the resource itself > and ought to update its meta-data as well (ie Last-Modified and Etag > values). > > Besides, by not doing so can be even worse because an aggregator would > requests the feed, the server would respond with a 304 and the aggregator > would not even know the count ahs changed in the end. It feels even worse. > Actually the aggregator could NOT send the If-Modified-Since header of course in that specific case and be safe. But this seems like a bit of an abuse of HTTP to me. - Sylvain From owner-atom-syntax@mail.imc.org Thu May 18 10:36:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjby-000435-Gd for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:36:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgjbv-0005ig-WE for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:36:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IEEffs004642; Thu, 18 May 2006 07:14:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IEEfoF004635; Thu, 18 May 2006 07:14:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IEEe06004627 for ; Thu, 18 May 2006 07:14:40 -0700 (MST) (envelope-from whateley@gmail.com) Received: by nz-out-0102.google.com with SMTP id x7so114116nzc for ; Thu, 18 May 2006 07:14:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Zo2uMruz9DN0ZtOOpbGjiI0iz7i+WRVwt11mRG0v+M++hMsfJPiCxoUtzp2vbgOBHd7zLS9eqVQFtUem3IAddfOLxLLcVlALo3Fj3SaRoXL00bVI+Dv2E2T/edAKPGH6w3fSqjMlHNKiEjDfbNqqs7zze6Hch/o5tnHy9ax2qGE= Received: by 10.65.132.1 with SMTP id j1mr371746qbn; Thu, 18 May 2006 07:14:39 -0700 (PDT) Received: from nyarlathotep ( [64.247.134.14]) by mx.gmail.com with ESMTP id z21sm246624qbc.2006.05.18.07.14.38; Thu, 18 May 2006 07:14:39 -0700 (PDT) Date: Thu, 18 May 2006 08:10:38 -0600 From: Brendan Taylor To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call Message-ID: <20060518141037.GA11601@nyarlathotep.ssimicro.com> Mail-Followup-To: atom-syntax@imc.org References: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> User-Agent: Mutt/1.5.11 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 18, 2006 at 09:26:18AM +0100, Sylvain Hellegouarch wrote: > By acting as you do, we may end up in a huge amount of feeds being sent on > the wire to clients which believe the feed has actually changed in its > content when it has changed only in one meta-data value (that they will > not handle anyway). It's a valid concern, but as James has been saying the "problem" is with the syndication model. This isn't something that Atom (or any extension)=20 can solve. Do you have any suggestions about how this metadata could be included without changing the content of the feed? AFAICT the only solution is to not use the attributes (which aren't required, of course). --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEbIBdc7m7RB/1A2URAsC2AKCBl9Zdo4uZw37w87aquNhwGKEO/ACfWCMZ FO3zLoCCIr997P8ZwjjZDSg= =mqvy -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-atom-syntax@mail.imc.org Thu May 18 10:40:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjfy-000569-0v for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:40:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgjfx-0005wS-HZ for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:40:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IES7Fi007616; Thu, 18 May 2006 07:28:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IES7J6007615; Thu, 18 May 2006 07:28:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+MxdlL5oH00oosWtKGRlKUTZArgOkuAFM@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IES6rh007606 for ; Thu, 18 May 2006 07:28:06 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/6FaIZmFrD8oiwTiMFbft+4F6bm8Od3dM@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4IES5Ym007787 for ; Thu, 18 May 2006 09:28:05 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4IES5XU007785; Thu, 18 May 2006 15:28:05 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 15:28:05 +0100 (BST) Message-ID: <33510.194.221.74.7.1147962485.squirrel@mail1.python-hosting.com> In-Reply-To: <20060518141037.GA11601@nyarlathotep.ssimicro.com> References: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> Date: Thu, 18 May 2006 15:28:05 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > > It's a valid concern, but as James has been saying the "problem" is with > the syndication model. This isn't something that Atom (or any extension) > can solve. I agree with you and James. This is much larger issue and this spec is not the right place to try solving it. > Do you have any suggestions about how this metadata could be included > without changing the content of the feed? AFAICT the only solution is to > not use the attributes (which aren't required, of course). I'll make a fool of myself after being so virulent but apart from a fairly big change in the Internet architecture. There is little that could be done to solve the problem of polling Vs pushing. That being said, I would not be surprised that ISPs push really hard for such a discussion to happen as they will soon be overloaded by the huge amount of data passing on the wires they pay for (thinks much larger than just feeds like HDTV ;). Anyway, no I don't have a better solution. I am nevertheless happy that the point will be notified by James in its draft. - Sylvain From owner-atom-syntax@mail.imc.org Thu May 18 10:46:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjld-0007aG-7x for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:46:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgjlb-0006Ru-Rb for atompub-archive@lists.ietf.org; Thu, 18 May 2006 10:46:21 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IEZjcf009355; Thu, 18 May 2006 07:35:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IEZjvh009353; Thu, 18 May 2006 07:35:45 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18NreFmRQTLxBOVNel7tZDN0+2pdeRGGSU@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IEZiIv009347 for ; Thu, 18 May 2006 07:35:44 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19SE2EMDTjq55Qg/bBfen+IaNpBJhwwfzI@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4IEZhDi007996; Thu, 18 May 2006 09:35:43 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4IEZhEj007993; Thu, 18 May 2006 15:35:43 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Thu, 18 May 2006 15:35:43 +0100 (BST) Message-ID: <49215.194.221.74.7.1147962943.squirrel@mail1.python-hosting.com> In-Reply-To: <33510.194.221.74.7.1147962485.squirrel@mail1.python-hosting.com> References: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> <33510.194.221.74.7.1147962485.squirrel@mail1.python-hosting.com> Date: Thu, 18 May 2006 15:35:43 +0100 (BST) Subject: Re: Feed Thread in Last Call From: "Sylvain Hellegouarch" To: sh@defuze.org Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 And I am sorry for the numerous mistakes I make in my written English. *sigh* From owner-atom-syntax@mail.imc.org Thu May 18 11:39:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkaw-0001sp-OX for atompub-archive@lists.ietf.org; Thu, 18 May 2006 11:39:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgkaw-00012c-4a for atompub-archive@lists.ietf.org; Thu, 18 May 2006 11:39:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IFRneR021487; Thu, 18 May 2006 08:27:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IFRn3i021486; Thu, 18 May 2006 08:27:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IFRmWl021472 for ; Thu, 18 May 2006 08:27:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so442438wra for ; Thu, 18 May 2006 08:27: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:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bdV44PsewMR9qqi3//AUS+hsdDPDAPyJvetKkgxG38TYFYNKXb9zyrit/LUFGDzb9eN6Fwh3KXHdCoZUpVY4j5/wOKKEpq4kSCU9vfV+6AFUCaCpu1M4FURffv7L8U5hatTbdsaIDEkemCSGSrPmihCmURYHeBso+1rUS6YYj/E= Received: by 10.54.89.1 with SMTP id m1mr716489wrb; Thu, 18 May 2006 08:27:46 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 7sm593409wrl.2006.05.18.08.27.44; Thu, 18 May 2006 08:27:45 -0700 (PDT) Message-ID: <446C926E.6080605@gmail.com> Date: Thu, 18 May 2006 08:27:42 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: David Powell CC: atom-syntax , Lisa Dusseault Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> In-Reply-To: <97566250.20060518141543@djpowell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac David, David Powell wrote: > Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote: > >> A few of the individuals on the WG had a problem with the placement of >> the attributes due to various limitations of a few existing Atom 1.0 >> implementations. > > That doesn't accurately state my problem with FTE. My concern is more > general than the compatibility with a specific Atom implementations. > The fact that the MS feed platform exhibits the issue is just a > confirmation that the issue is more than a theoretical concern. > My apologies for the misrepresentation. It was unintentional. > An implementor that wants to /consume/ Atom (such as a feed API, or > store), ought to be able to create an accurate implementation just by > reading RFC4287. That document describes what properties entries, > feeds, links, and extension elements have, and how they are > represented in an Atom document. Using this it is possible to create a > database schema or OO API that can represent feed data. > When I look at RFC4287 I see the following statements: 1.3 : "Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance." 4.2.7 : "The "atom:link" element defines a reference from an entry or feed to a Web resource. This specification assigns no meaning to the content (if any) of this element." 6.1 : "Markup from other vocabularies ("foreign markup") can be used in an Atom Document." 6.3: "Atom Processors that encounter foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error." 6.4: "Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden." Further, the RELAX NG definition for atom:link is, atomLink = element atom:link { atomCommonAttributes, attribute href { atomUri }, attribute rel { atomNCName | atomUri }?, attribute type { atomMediaType }?, attribute hreflang { atomLanguageTag }?, attribute title { text }?, attribute length { text }?, undefinedContent } atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }?, undefinedAttribute* undefinedAttribute = attribute * - (xml:base | xml:lang | local:*) { text } undefinedContent = (text|anyForeignElement)* My interpretation of the text and the RELAX NG definition is that while the specification does not assign any meaning to extensions of the link element, it is nonetheless explicitly allowed. It may have been a mistake, but the discussion of section 6.4 is explicitly scoped *only* to child elements of atom:entry, atom:feed, atom:source and Person constructs. Note that this section does NOT state that ONLY those elements may be extended; rather, the section defines the characteristics of two types of extensions that could occur on those subsets of elements. The characteristics of extensions on other elements in the Atom vocabulary are left undefined. The definitions of the atomCommonAttributes (which allows any number of "undefinedAttributes" and the definition of undefinedContent is very clear on the point that extensions ARE allowed on Link. Such extensions may not be semantically meaningful to RFC4287, but they are nonetheless legal and a valid component of the Atom data model. >[snip] > What I see as a problem is that reasonable implementations will not > preserve Atom documents bit-for-bit, so they will need to explicitly > support this draft if they don't want to corrupt data by dropping the > thr:count attributes. By the letter of RFC4287 there is no problem > with the draft, but practically there is something like a layering > concern if an extension requires existing conformant implementations > to be changed. > Atom does not define any notion of "conformance". That is, there are no requirements anywhere that define what aspects of the Atom data model an implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to expect that different implementations will offer varying levels of support for a variety of the core features offered by the protocol. For instance, Atom's data model allows for multiple enclosure links. In my Atom implementation, this is easily handled and exposed by the API; in Microsoft's implementation, however, only a single enclosure is exposed. Some implementations do not expose any link other than the first "alternate" link that they happen to find in the entry. I'm sure there are countless such examples. Some implementations don't use/preserve the scheme attribute on the category element; some implementations don't fully support the atom content model (e.g. base64 encoded content); some implementations don't support XML digital signatures; etc. Because there is no definition of conformance, even for the core Atom format, it is perfectly reasonable to expect that existing implementations may have to change a bit in order to support the introduction of new extensions, depending on the level of support they have for the full atom data model as defined by RFC4287. > Atom implementations with generic support for links and extensions, > will find that this draft moves the goalposts of what a reasonable > implementation is expected to handle, and I firmly believe that it > should be possible for implementations to provide generic support for > extensions in order to assist their adoption. > RFC4287 sets the goal posts. Extension attributes and elements ARE allowed on Link. Whether or not an implementation chooses to support such extensions is an implementation choice. >[snip] >> None of the folks I know of that have actually >> implemented support for the extension has had any problems with them. > > Does that include any stateful feed APIs, or APP servers that aren't > based on native XML back-ends? > I am not certain what you mean by "stateful feed APIs", but the answer is yes to the question about non-native XML back-ends. >[snip] - James From owner-atom-syntax@mail.imc.org Thu May 18 12:05:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkzk-0003Zt-EF for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:05:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgkzh-00038A-To for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:05:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IFsww6027400; Thu, 18 May 2006 08:54:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IFswKs027399; Thu, 18 May 2006 08:54:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4IFstJS027357 for ; Thu, 18 May 2006 08:54:56 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2006 15:54:49 -0000 Received: from xdsl-84-44-230-75.netcologne.de (EHLO klangraum) [84.44.230.75] by mail.gmx.net (mp038) with SMTP; 18 May 2006 17:54:49 +0200 X-Authenticated: #163624 Date: Thu, 18 May 2006 17:54:48 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060518155448.GC5530@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <446C926E.6080605@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 * James M Snell [2006-05-18 17:40]: > My interpretation of the text and the RELAX NG definition is > that while the specification does not assign any meaning to > extensions of the link element, it is nonetheless explicitly > allowed. Noone ever debated that. > It may have been a mistake, but the discussion of section 6.4 > is explicitly scoped *only* to child elements of atom:entry, > atom:feed, atom:source and Person constructs. That was a mistake, yes. Unfortunately, hindsight is 20/20. > Note that this section does NOT state that ONLY those elements > may be extended; rather, the section defines the > characteristics of two types of extensions that could occur on > those subsets of elements. The characteristics of extensions on > other elements in the Atom vocabulary are left undefined. Yes. That means extending other elements is a free-for-all just as it is in RSS 2.0, and we know the problems that this poses in practice. Extending Atom in ways other than those defined in Sec 6.4. has the same problems as extending RSS 2.0 with namespaced elements. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 18 12:27:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglLe-0004k7-31 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:27:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglLc-0004AU-IM for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:27:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IGDPSJ031724; Thu, 18 May 2006 09:13:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IGDPqF031723; Thu, 18 May 2006 09:13:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IGDOKn031688 for ; Thu, 18 May 2006 09:13:24 -0700 (MST) (envelope-from stpeter@jabber.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 195874DF2A5 for ; Thu, 18 May 2006 10:13:41 -0600 (MDT) Message-ID: <446C9D34.5010406@jabber.org> Date: Thu, 18 May 2006 10:13:40 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: "Atom Over XMPP" I-D X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040904080202060407020407" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This is a cryptographically signed message in MIME format. --------------ms040904080202060407020407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As you may have noticed, the "Atom Over XMPP" I-D expired on February 20 of this year: http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-04.html However, by no means is this I-D abandoned. Since January, the underlying publish-subscribe specification (JEP-0060) used by draft-saintandre-atompub-notify has been under revision within the Jabber Software Foundation's standards process, mainly in order to incorporate feedback based on implementation experience (also to make the specification easier to understand). The revision process is close to completion and the Jabber Council is currently requesting feedback on the revisions: http://mail.jabber.org/pipermail/standards-jig/2006-May/011101.html http://www.jabber.org/jeps/tmp/jep-0060-1.8.html If all goes well, the revised pubsub specification will be approved by the Jabber Council during the week of June 12. At that time (and before the IETF 66 cutoff date of June 26), I will submit a revised version of draft-saintandre-atompub-notify to the Secretariat. Thanks for your interest. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbJ00NF1RSzyt3NURAh/GAJ9Y3bOdSRu8sjL7fQJRyPK2gT8lawCghrPZ oR6vRLed4adw0a6ssgJvO2M= =Bb/z -----END PGP SIGNATURE----- --------------ms040904080202060407020407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTE4MTYxMzQwWjAjBgkqhkiG9w0BCQQxFgQUTceYVfWiQwZgW52u eEiuyRLWF1gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBALme+6zeoZlmrI/Ik/o/R2A4aiQ+vYbo KomLe3GOJ1QKOl7KxT8ZkMcZi2fpHvFg5ayucd37COIlZv8rBB8OC+q2uhJ6Vx60cwveXC2x W3ZcyrsB2Lk11EvK/JOV0Nwy3Dw2b4ObElZ2V++tGdhkXsahItB1OmP8V0gVWV3c2zmTw0kD hggtMz9WQeHGrUjnQVr+Ybc0csALJ6/ZNJBzfesrjeQta5CbuB0g/vK3byoO0tUvtOzk8bkQ Rfr7eOaM5m5FXPfuhH9tkBNvdb6c8ouXa4zJLhIK10+pcKUp/NWOkKlPDpZsG02krLqIWwBQ 6jysC7gH7Wf5wcHbhmvdm5AAAAAAAAA= --------------ms040904080202060407020407-- From owner-atom-syntax@mail.imc.org Thu May 18 12:50:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fglhu-0005kY-7i for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:50:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fglhs-0005Ot-Rh for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:50:38 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IGZK0B036713; Thu, 18 May 2006 09:35:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IGZKYe036712; Thu, 18 May 2006 09:35:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4IGZIGs036670 for ; Thu, 18 May 2006 09:35:19 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2006 16:35:12 -0000 Received: from xdsl-84-44-230-75.netcologne.de (EHLO klangraum) [84.44.230.75] by mail.gmx.net (mp003) with SMTP; 18 May 2006 18:35:12 +0200 X-Authenticated: #163624 Date: Thu, 18 May 2006 18:35:12 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed Thread in Last Call Message-ID: <20060518163512.GH5530@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4IGZK0B036713 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad * Robert Sayre [2006-05-18 18:05]: > There's no technical reason for the placement of the > attributes, Do you have better ideas on how to provide this information on a per-link basis? It would help if you actually tried to suggest an approach instead of bashing what=E2=80=99s there. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 18 14:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmsO-0007SS-5L for atompub-archive@lists.ietf.org; Thu, 18 May 2006 14:05:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgmsN-00015C-Oc for atompub-archive@lists.ietf.org; Thu, 18 May 2006 14:05:32 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IHn9kA052872; Thu, 18 May 2006 10:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IHn9VR052871; Thu, 18 May 2006 10:49:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IHn7gD052825 for ; Thu, 18 May 2006 10:49:08 -0700 (MST) (envelope-from x-antone@geckotribe.com) Received: from [192.168.0.3] (c-67-177-6-93.hsd1.ut.comcast.net[67.177.6.93]) by comcast.net (sccrmhc11) with SMTP id <2006051817490001100k4dude>; Thu, 18 May 2006 17:49:01 +0000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060518141037.GA11601@nyarlathotep.ssimicro.com> References: <3F141A03-8781-4498-930A-B5CDFB6AE450@osafoundation.org> <68fba5c50605161823x4afa089fp38465ee8a22a1baa@mail.gmail.com> <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: Feed Thread in Last Call Date: Thu, 18 May 2006 11:48:58 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.750) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da On May 18, 2006, at 8:10 AM, Brendan Taylor wrote: > Do you have any suggestions about how this metadata could be included > without changing the content of the feed? AFAICT the only solution > is to > not use the attributes (which aren't required, of course). If it's in the feed document and it gets updated other than when the entry itself is updated (...and it wouldn't be of much use if it were only updated when the entry was updated), it's going to result in data getting re-fetched when nothing but the comment count and timestamp change. I don't see any way around that. So if you really want a way to publish comment counts and timestamps without causing lots of unchanged data from getting refetched, you're going to have to separate that data out of the feed. Here's pseudo-XML for a possible approach: ... ... foo ... bar ... ... and in another document: ... Of course the comment tracking document wouldn't only be authoritative for feeds that pointed to it with a comment-tracking link. This would require an extra subscription to track the comments, as well as understanding an additional format (as opposed to just an additional extension--either approach requires SOME additional work), but it would prevent unnecessary downloads by clients that aren't aware of it, and would reduce the bandwidth used by those that are. This approach could be generalized to enable offloading of other metadata that's more volatile than the entries themselves. Antone From owner-atom-syntax@mail.imc.org Thu May 18 14:14:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgn0f-0003OD-Su for atompub-archive@lists.ietf.org; Thu, 18 May 2006 14:14:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglGb-0003yT-KR for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:22:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgl5Z-0004mU-GH for atompub-archive@lists.ietf.org; Thu, 18 May 2006 12:11:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IFuf76027846; Thu, 18 May 2006 08:56:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IFufvc027845; Thu, 18 May 2006 08:56:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IFueDH027838 for ; Thu, 18 May 2006 08:56:40 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so610861pyf for ; Thu, 18 May 2006 08:56:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qd/4nUs6WKKB71RrGTtBxtMjFfMF7zGh8hcCmL00LoDv+9kC0fdtnIqC5XOspcHvTw3byZbnj2h12rpg/F0AMM+tVucpNvqB780S8Xq527ptzTVhghpUkp1yIh3xbuYqicnhvuKV5MI10b2eo2cndY2GQ/SG6cPIDUYueSmEW4g= Received: by 10.35.131.4 with SMTP id i4mr708351pyn; Thu, 18 May 2006 08:56:39 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Thu, 18 May 2006 08:56:39 -0700 (PDT) Message-ID: <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> Date: Thu, 18 May 2006 17:56:39 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: "David Powell" , atom-syntax , "Lisa Dusseault" In-Reply-To: <446C926E.6080605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4IFueDH027839 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.9 (-) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Look at that giant email. Seems to me that it's a debate taking place for no discernable reason. There's no technical reason for the placement of the attributes, and management has made it clear that any objections are "irrelevant." Hope that helps! On 5/18/06, James M Snell wrote: > > David, > > David Powell wrote: > > Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote: > > > >> A few of the individuals on the WG had a problem with the placement of > >> the attributes due to various limitations of a few existing Atom 1.0 > >> implementations. > > > > That doesn't accurately state my problem with FTE. My concern is more > > general than the compatibility with a specific Atom implementations. > > The fact that the MS feed platform exhibits the issue is just a > > confirmation that the issue is more than a theoretical concern. > > > > My apologies for the misrepresentation. It was unintentional. > > > An implementor that wants to /consume/ Atom (such as a feed API, or > > store), ought to be able to create an accurate implementation just by > > reading RFC4287. That document describes what properties entries, > > feeds, links, and extension elements have, and how they are > > represented in an Atom document. Using this it is possible to create a > > database schema or OO API that can represent feed data. > > > > When I look at RFC4287 I see the following statements: > > 1.3 : "Some sections of this specification are illustrated with > fragments of a non-normative RELAX NG Compact schema > [RELAX-NG]. However, the text of this specification provides > the definition of conformance." > 4.2.7 : "The "atom:link" element defines a reference from an entry or > feed to a Web resource. This specification assigns no meaning > to the content (if any) of this element." > 6.1 : "Markup from other vocabularies ("foreign markup") can be used > in an Atom Document." > 6.3: "Atom Processors that encounter foreign markup in a location > that is legal according to this specification MUST NOT stop > processing or signal an error." > 6.4: "Atom allows foreign markup anywhere in an Atom document, except > > where it is explicitly forbidden." > > Further, the RELAX NG definition for atom:link is, > > atomLink = > element atom:link { > atomCommonAttributes, > attribute href { atomUri }, > attribute rel { atomNCName | atomUri }?, > attribute type { atomMediaType }?, > attribute hreflang { atomLanguageTag }?, > attribute title { text }?, > attribute length { text }?, > undefinedContent > } > > > atomCommonAttributes = > attribute xml:base { atomUri }?, > attribute xml:lang { atomLanguageTag }?, > undefinedAttribute* > > undefinedAttribute = > attribute * - (xml:base | xml:lang | local:*) { text } > > undefinedContent = (text|anyForeignElement)* > > My interpretation of the text and the RELAX NG definition is that while > the specification does not assign any meaning to extensions of the link > element, it is nonetheless explicitly allowed. > > It may have been a mistake, but the discussion of section 6.4 is > explicitly scoped *only* to child elements of atom:entry, atom:feed, > atom:source and Person constructs. Note that this section does NOT state > that ONLY those elements may be extended; rather, the section defines > the characteristics of two types of extensions that could occur on those > subsets of elements. The characteristics of extensions on other > elements in the Atom vocabulary are left undefined. > > The definitions of the atomCommonAttributes (which allows any number of > "undefinedAttributes" and the definition of undefinedContent is very > clear on the point that extensions ARE allowed on Link. Such extensions > may not be semantically meaningful to RFC4287, but they are nonetheless > legal and a valid component of the Atom data model. > > >[snip] > > What I see as a problem is that reasonable implementations will not > > preserve Atom documents bit-for-bit, so they will need to explicitly > > support this draft if they don't want to corrupt data by dropping the > > thr:count attributes. By the letter of RFC4287 there is no problem > > with the draft, but practically there is something like a layering > > concern if an extension requires existing conformant implementations > > to be changed. > > > > Atom does not define any notion of "conformance". That is, there are no > requirements anywhere that define what aspects of the Atom data model an > implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to > expect that different implementations will offer varying levels of > support for a variety of the core features offered by the protocol. For > instance, Atom's data model allows for multiple enclosure links. In my > Atom implementation, this is easily handled and exposed by the API; in > Microsoft's implementation, however, only a single enclosure is exposed. > Some implementations do not expose any link other than the first > "alternate" link that they happen to find in the entry. > > I'm sure there are countless such examples. Some implementations don't > use/preserve the scheme attribute on the category element; some > implementations don't fully support the atom content model (e.g. base64 > encoded content); some implementations don't support XML digital > signatures; etc. > > Because there is no definition of conformance, even for the core Atom > format, it is perfectly reasonable to expect that existing > implementations may have to change a bit in order to support the > introduction of new extensions, depending on the level of support they > have for the full atom data model as defined by RFC4287. > > > Atom implementations with generic support for links and extensions, > > will find that this draft moves the goalposts of what a reasonable > > implementation is expected to handle, and I firmly believe that it > > should be possible for implementations to provide generic support for > > extensions in order to assist their adoption. > > > > RFC4287 sets the goal posts. Extension attributes and elements ARE > allowed on Link. Whether or not an implementation chooses to support > such extensions is an implementation choice. > > >[snip] > >> None of the folks I know of that have actually > >> implemented support for the extension has had any problems with them. > > > > Does that include any stateful feed APIs, or APP servers that aren't > > based on native XML back-ends? > > > > I am not certain what you mean by "stateful feed APIs", but the answer > is yes to the question about non-native XML back-ends. > > >[snip] > > - James > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Thu May 18 14:45:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnVS-0006zo-6Z for atompub-archive@lists.ietf.org; Thu, 18 May 2006 14:45:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnVP-0003hW-AE for atompub-archive@lists.ietf.org; Thu, 18 May 2006 14:45:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IIVmW2062499; Thu, 18 May 2006 11:31:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IIVmg9062498; Thu, 18 May 2006 11:31:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4IIVkXt062474 for ; Thu, 18 May 2006 11:31:47 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2006 18:31:40 -0000 Received: from xdsl-84-44-230-75.netcologne.de (EHLO klangraum) [84.44.230.75] by mail.gmx.net (mp043) with SMTP; 18 May 2006 20:31:40 +0200 X-Authenticated: #163624 Date: Thu, 18 May 2006 20:31:39 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call Message-ID: <20060518183139.GI5530@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4IIVmW2062499 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c * Antone Roundy [2006-05-18 20:05]: > and in another document: >=20 > > > > hreflang=3D"..." ct:count=3D"5" ct:when=3D"..." /> > hreflang=3D"..." ct:count=3D"3" ct:when=3D"..." /> > > > hreflang=3D"..." ct:count=3D"0" ct:when=3D"..." /> > hreflang=3D"..." ct:count=3D"1" ct:when=3D"..." /> > > ... > >=20 > Of course the comment tracking document wouldn't only be > authoritative for feeds that pointed to it with a > comment-tracking link. >=20 > This would require an extra subscription to track the comments, > as well as understanding an additional format (as opposed to > just an additional extension--either approach requires SOME > additional work), but it would prevent unnecessary downloads by > clients that aren't aware of it, and would reduce the bandwidth > used by those that are. >=20 > This approach could be generalized to enable offloading of > other metadata that's more volatile than the entries > themselves. Actually, you don=E2=80=99t really need another format. There=E2=80=99s n= o reason why you couldn=E2=80=99t use atom:feed in place of your hypothetical ct:comment-tracking. :-) Your ct:entry elements could almost be atom:entry ones instead, too, except that assigning them titles and IDs feels like overkill. The real cost is not the cost of an extra format, but that implementations then need to understand the FTE in order to know to poll an extra document to retrieve the out-of-band metadata. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 18 15:59:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeQ-0000To-Q7 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 15:59:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgoPV-0008SG-2q for atompub-archive@lists.ietf.org; Thu, 18 May 2006 15:43:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IJPTkr074918; Thu, 18 May 2006 12:25:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IJPTW8074917; Thu, 18 May 2006 12:25:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IJPSCU074891 for ; Thu, 18 May 2006 12:25:28 -0700 (MST) (envelope-from geckotribe@comcast.net) Received: from [192.168.0.3] (c-67-177-6-93.hsd1.ut.comcast.net[67.177.6.93]) by comcast.net (sccrmhc11) with SMTP id <2006051819252201100kb80se>; Thu, 18 May 2006 19:25:22 +0000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060518183139.GI5530@klangraum> References: <446A7E89.6090809@gmail.com> <58851.194.221.74.7.1147855824.squirrel@mail1.python-hosting.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> <20060518183139.GI5530@klangraum> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: From: Antone Roundy Subject: Re: Feed Thread in Last Call Date: Thu, 18 May 2006 13:25:21 -0600 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.750) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4IJPSCU074911 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4IJPTkr074918 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d On May 18, 2006, at 12:31 PM, A. Pagaltzis wrote: > Actually, you don=92t really need another format. There=92s no reason > why you couldn=92t use atom:feed in place of your hypothetical > ct:comment-tracking. :-) Your ct:entry elements could almost be > atom:entry ones instead, too, except that assigning them titles > and IDs feels like overkill. The point of the whole exercise is to create a lightweight document =20 for volatile metadata. If it's an atom:feed, you have to include a =20 lot of stuff that's not needed here--atom:title, atom:updated, =20 atom:author, and atom:summary or atom:content. Also, you'd need to =20 have an atom:id for each entry in addition to the @ref pointing to =20 the entry that it talks about. > The real cost is not the cost of an extra format, but that > implementations then need to understand the FTE in order to know > to poll an extra document to retrieve the out-of-band metadata. Sure, but if they don't understand FTE, they wouldn't know what to do =20 with the extra metadata anyway even if it were in the main feed. =20 They MIGHT be able to do some generic processing of the comments =20 link, but the reliability of any generic processing algorithm for =20 unknown link types is questionable since we left atom:link open to =20 all sorts of uses. And you COULD keep the comments links in the main =20 feed but just leave off @count and @when for the benefit of apps that =20 don't process the sibling document. On May 18, 2006, at 11:48 AM, Antone Roundy wrote: > This approach could be generalized to enable offloading of other =20 > metadata that's more volatile than the entries themselves. I don't know yet what other metadata might be handled this way, but =20 here's slightly revised pseudo-XML that makes it more general and =20 adds a few useful things: foobar ... ... foo ... bar ... ... ... ... ... ... From owner-atom-syntax@mail.imc.org Thu May 18 16:15:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgouB-0004rN-VO for atompub-archive@lists.ietf.org; Thu, 18 May 2006 16:15:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgou9-0002dj-Tn for atompub-archive@lists.ietf.org; Thu, 18 May 2006 16:15:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IK2kqE082982; Thu, 18 May 2006 13:02:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IK2khi082981; Thu, 18 May 2006 13:02:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IK2iXk082963 for ; Thu, 18 May 2006 13:02:45 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x7so193745nzc for ; Thu, 18 May 2006 13:02:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=JQZEtj9TZn20PUXowQmr+PHQb5vC9uaSOrBxvTV2QgfDNg5WC9+XilETJbosp9whGfk+VkAMPZ9CGygE0xLGj8lPPzHWbbRnTMcMnb3RzPVkrE8cyoBJoVEes17qxSY38hiqm/NL+2tuPwo/EqXfNWZFWHRPVXI5pmHSYT8uYuk= Received: by 10.65.156.19 with SMTP id i19mr860457qbo; Thu, 18 May 2006 13:02:44 -0700 (PDT) Received: by 10.65.233.15 with HTTP; Thu, 18 May 2006 13:02:44 -0700 (PDT) Message-ID: Date: Thu, 18 May 2006 14:02:44 -0600 From: "M. David Peterson" To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call In-Reply-To: <20060518183139.GI5530@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_134812_29272630.1147982564056" References: <446A7E89.6090809@gmail.com> <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> <20060518183139.GI5530@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 ------=_Part_134812_29272630.1147982564056 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline PGE6ZiBpZD0iaWRvZmZlZWQiIGE6ZHM9IjEiPgo8YTplIGlkPSJpZG9mZW50cnkiIGE6cj0iMiI+ CjxhOmMgaWQ9Imlkb2Zjb21tZW50IiBhOnI9IjEiPgo8YTpjIGlkPSJpZG9mY29tbWVudCIgYTpy PSIyIi8+CjwvYTpjPgo8L2E6ZT4KPGE6ZSBpZD0iaWRvZmVudHJ5OiBhOnI9IjMiLz4KPC9hOmY+ CgpUaGUgcmVxdWVzdG9yIHNlbmRzIGEgcmVxdWVzdCBmb3IgYWxsIGVudHJpZXMgYW5kIGNvbW1l bnRzIG9uIHRob3NlIGVudGlyaWVzCnNpbmNlIGEgY2VydGFpbiBkYXRlLiAgSWYgdGhlIGRhdGUg cmVxdWVzdCBpcyBjb25zaWRlcmVkIHJlYXNvbmFibGUsIGEKY29tcGFjdCBhdG9tIHN5bnRheCB0 aGF0IGNvbnRhaW5zLAoKYSkgYSBkZXRlcm1pbmF0aW9uIGFzIHRvIHdoZXRoZXIgdGhleSBzdXBw b3J0IHByb3ZpZGluZyBkaWZmcyBhOmRzPSIwIgpmYWxzZSwgYTpkcz0iMSIsIHRydWUKCmIpIHRo ZSByZWxhdmVudCBwaWVjZXMgbmVjZXNzYXJ5IHRvIGRldGVybWluZSBpZiwKCmI6MSkgeW91IGhh dmUgYSBsb2NhbCBpbnN0YW5jZSBvZiB0aGF0IGlkLgpiOjE6MSkgSWYgeWVzLCBjb21wYXJlIHRo ZSByZXZpc2lvbiAoYTpyKSB2YWx1ZS4KYjoxOjE6MSkgSWYgdGhlIHNhbWUsIGlnbm9yZSwKYjox OjE6MikgaWYgZGlmZmVyZW50LCB0aGUgZGlmZmVyZW5jZSBpcyBkZXRlcm1pbmVkLCBhbmQgc3Rv cmVkIHVudGlsIHRoZQpjb21wYWN0IHN5bnRheCBhYm92ZSBoYXMgZmluaXNoZWQgYmVpbmcgcHJv Y2Vzc2VkLgpiOjE6MikgSWYgdGhlcmUgaXMgbm8gbG9jYWwgaW5zdGFuY2Ugb2YgdGhhdCBpZCwg c3RvcmUgdGhlIHRoaXMgdW50aWwgdGhlCnByb2Nlc3MgaGFzIGZpbmlzaGVkLgoKcmVjdXJzZSB1 bnRpbCBjb21wbGV0ZS4KCnJlY3Vyc2UgdGhlIHJlc3VsdDoKYTogSWYgeW91IGNhbiBwcm9jZXNz IHRoZSBkaWZmLCBhbmQgdGhleSBzdXBwb3J0IHJldHVybmluZyBqdXN0IHRoZSBkaWZmLApzZXQg YSByZXF1ZXN0IGhlYWRlciBkZXRlcm1pbmVkIHRvIHNwZWNpZnkgdGhpcyB0byB0aGUgc2VydmVy LgpiOiBzZXQgYSBoZWFkZXIgdG8gc3BlY2lmeSB0byB0aGUgc2VydmVyIGlmIHlvdSB3YW50IHRo ZSBleGFjdCBzcGVjaWZpZWQKcmV2aXNpb24sIG9yIGFkZGl0aW9uYWwgcmV2aXNpb25zIGlmIHRo ZXkgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoZSBvcmlnaW5hbApxdWVyeS4KYzogcmV0dXJuIGEgcmVx dWVzdCBmb3IgZWFjaCB1cGRhdGVkIG9yIG5ldyByZXNvdXJjZSwgd2l0aCB0aGUgZGlmZmVyZW5j ZQpiZXR3ZWVuIHRoZSBsb2NhbCByZXZpc2lvbiBudW1iZXIgYW5kIHRoZSByZXZpc2lvbiBudW1i ZXIgb24gdGhlIHNlcnZlciBpZgphcHByb3ByaWF0ZS4KCmVhY2ggcmVxdWVzdCBpcyBpbml0aWFs bHkgYXRvbWljLCB3aXRoIHRoZSBhYmlsaXR5IHRvIGJlIGdyb3VwZWQgaWYgdGhlCnNlcnZlciBk ZXRlcm1pbmVzIHRoYXQgaXQgd291bGQgYmUgbW9yZSBlZmZpY2llbnQgYXQgcHJlc2VudCB0aW1l IHRvIGhhbmRsZQpvbmUgcmVxdWVzdCBhdCBhIHRpbWUsIG9yIGdyb3VwZWQgdG9nZXRoZXIgdXNp bmcgYSBjb25hbmljYWwgY29tcHJlc3Npb24gb2YKdGhlIHJlcXVlc3RlZCBpdGVtcy4gIFRoaXMg d291bGQgYmUgcmV0dXJuZWQgaW4gdGhlIHJlc3BvbnNlIGhlYWRlciBzdWNoIGFzCnRvIG1haW50 YWluIGEgY29uc2lzdGVudCBhYmlsaXR5IHRvIGFkYXB0IGF0IGFueSBtb21lbnQgdG8gY3VycmVu dCBvYWQgb24KdGhlIHNlcnZlci4KCm5vdGhpbmcgaXMgYXBwcm94aW1hdGUsIGVhY2ggc2lkZSBv ZiB0aGUgdHJhbnNhY3Rpb24gaGFzIHRoZSBhYmlsaXR5IHRvCmFkYXB0IHRvIGNoYW5nZSwgYW5k IHRvIGRlY2lkZSBpZiBpdCB3YW50cyB0byBoYW5kbGUgcG90ZW50aWFsIGRpZmZlcmVuY2VzCnRo YXQgdGFrZSBwbGFjZSBkdXJpbmcgdGhlIHNwYW4gYmV0d2VlbiByZXF1ZXN0cyBub3csIG9yIGF0 IGEgbGF0ZXIgZGF0ZS4KV2l0aCBlYWNoIHRyYW5zYWN0aW9uLCBlbm91Z2ggaW5mb3JtYXRpb24g aXMgcHJvdmlkZWQgdG8gcXVpY2tseSBjYWxjdWxhdGUKYW5kIGRldGVybWluZSwgb3Igc3BlY2lm eSBhIGRlZmF1bHQgaWYgdGhlIGN1cnJlbnQgbG9hZCBpcyBwYXN0IGEgY2VydGFpbgp0aHJlc2hv bGQsIHdoaWxlIHN0aWxsIG1haW50YWluaW5nIHRoZSBrbm93bGVkZ2UgdGhhdCB1cGRhdGVzIGV4 aXN0cywgYW5kCndoZW4gdGhlIGxvYWQgYWxsb3dzLCBtYWtlIGEgbmV3IHJlcXVlc3QgYmFzZWQg b24gdGhlIGRpZmZlcmVuY2UgaW4gc3RvcmVkCnZhbHVlcyB0aGF0IHBlcnRhaW4gdG8gZWFjaCBp ZCAgaXQgaGFzIGtub3dsZWRnZSB0byBoYXZlIGRpZmZlcmVuY2VzLgoKSWYgZHVyaW5nIHRoaXMg c3BhbiwgdGhlIHNlcnZlciBpbiB3aGljaCByZWNlaXZlcyB0aGUgcmVxdWVzdCByZWFsaXplcyB0 aGF0CnNpbmNlIHRoZSBsYXN0IHJlcXVlc3QsIGEgcmVzb3VyY2UgaGFzIGJlZW4gcmVtb3ZlZC9k ZWxldGVkLCBhIGhlYWRlciBjYW4gYmUKc2V0IHRvIHNwZWNpZnkgdGhhdCBmdXR1cmUgY2FsY3Vs YXRpb25zIHNob3VsZCBiZSBiYXNlZCBvbiB0aGUgbmV3CmRpZmZlcmVuY2UgaW5zdGVhZCBvZiB0 aGUgb2xkLgoKLS0tLQpJbiB0aGUgYWJvdmUgc2NlbmFyaW8gdGhlIGFtb3VudCBvZiBkYXRhIGV4 Y2hhbmdlIGlzIGF0IGEgYmFyZSBtaW5pbXVtLCB0aGUKcHJvY2Vzc2luZyByZXF1aXJlZCB0byBj YWxjdWxhdGUgdGhlIGRpZmZlcmVuY2VzIGlzIGF0IGEgYmFyZSBtaW5pbnVtLCBpdAptYWludGFp bnMgYSBsZXZlbCBvZiBkYXRhIGludGVncml0eSB0aGF0IGlzIGdyYW51bGFyIGVub3VnaCB0byBh ZGFwdCB0byBlYWNoCmNoYW5nZSBpbiB0aGUgc3lzdGVtLCB3aXRob3V0IHJlcXVpcmVtZW50IG9m IGV4dGVuc2l2ZSBwcm9jZXNzaW5nIHRvCmRldGVybWluZSB0aGlzIGRpZmZlcmVuY2UsIHdoaWxl IG1haW50YWluaW5nIGFuIGFnaWxlL2FkYXB0aWJsZSBmb3VuZGF0aW9uCnRoYXQgY2FuIGFkanVz dCBhcyBuZWVkZWQgd2l0aG91dCBsb3NzIG9mIGRhdGEgaW50ZWdyaXR5IG9uIGVpdGhlciBzaWRl IG9mCnRoZSB0cmFuc2FjdGlvbi4KCkdpdmVuIHRoZSBhbW91bnQgb2YgZGF0YSBzZW50IHdpdGgg aW5pdGlhbCByZXF1ZXN0IGlzIGF0IGEgYmFyZSBtaW5pbXVtLAp0aGlzIGNhbiBiZSBzZXQgaW4g bWVtb3J5IGFzIHRoZSBkZWZhdWx0IHJlc3BvbnNlIGJhc2VkIG9uIHRoZSB0aW1lCmRpZmZlcmVu Y2UgdG8gZGV0ZXJtaW5lIHRoZSBhZGRyZXNzIG9mIHdoZXJlIHRvIGJlZ2luIHN0cmVhbWluZyB0 aGUgcmVxdWVzdCwKdXNpbmcgdGhlIGRlZmF1bHQgYTpmIGlkPSJmZWVkaWQiIHRvIG9wZW4vY2xv c2UgdGhlIHJlc3BvbnNlIHN0cmVhbSBhdCB0aGUKYXBwcm9wcmlhdGUgc3RhcnQgYW5kIHN0b3Ag cG9pbnQgb2YgdGhlIHJldHVybmVkIHN0cmVhbS4KClBsZWFzZSBkaXNyZWdhcmQgdGhlIGFib3Zl IGlmIEkgaGF2ZSBsZWZ0IG91dCBvYnZpb3VzIGFyZWFzIGluIHdoaWNoIG1ha2VzCnRoaXMgaXJy ZWxldmFudC4gIE5vdCB0cnlpbmcgdG8gdGFrZSBhICJ0aGlzIGlzIHRoZSBhYnNvbHV0ZSByaWdo dCB3YXkgdG8gZG8KdGhpcyIgYW5kIGluc3RlYWQgaW5qZWN0IHRoZSBzbWFsbGVzdCwgc2ltcGxl c3QgcGF0aCB0aGF0IHNlZW1zIHRvIGxvZ2ljYWxseQpwcm92aWRlIHRoZSBuZWNlc3NhcnkgcGll Y2VzIHRvIG1ha2UgdGhlIHRyYW5zYWN0aW9uIHByb2Nlc3Npbmcgb2YKZGlmZmVyZW5jZXMgYXMg c2ltcGxlIGFuZCBlZmZpY2llbnQgYXMgcG9zc2libGUsIHdoaWxlIGRvaW5nIHNvIGluIGEgd2F5 CnRoYXRzIGp1c3Qgb3V0c2lkZSB0aGUgYm94LCBidXQgY2xvc2UgZW5vdWdoIGFzIHRvIG5vdCBy ZXF1aXJlIGFueSBjaGFuZ2VzCnRvIGFueSBhY3R1YWwgZHJhZnQgc3BlY2lmaWNhdGlvbnMsIGFu ZCBpbnN0ZWFkIGEgd2F5IHRvIGlsbGltaW5hdGUgc29tZSBvZgp0aGUgY29uY2VybnMgcHJlc2Vu dGVkIHRoYXQgc3VnZ2VzdGVkIHBvdGVudGlhbHMgYXJlYXMgb2YgaW5lZmZpY2llbnQgb3IKaW5u YWN1cmF0ZSBiZWhhdmlvcnMgdGhhdCBob2xkIHBvdGVudGlhbCBmb3IgcHJvYmxlbXMgZG93biB0 aGUgcm9hZC4KClBlYWNlIDopCgoKT24gNS8xOC8wNiwgQS4gUGFnYWx0emlzIDxwYWdhbHR6aXNA Z214LmRlPiB3cm90ZToKPgo+Cj4gKiBBbnRvbmUgUm91bmR5IDx4LWFudG9uZUBnZWNrb3RyaWJl LmNvbT4gWzIwMDYtMDUtMTggMjA6MDVdOgo+ID4gYW5kIGluIGFub3RoZXIgZG9jdW1lbnQ6Cj4g Pgo+ID4gPGN0OmNvbW1lbnQtdHJhY2tpbmcgeG1sbnM6Y3Q9Ii4uLiIgeG1sbnM6YXRvbT0iLi4u IiAuLi4+Cj4gPiAgICAgICA8YXRvbTpsaW5rIHJlbD0icmVsYXRlZCIgaHJlZj0iVVJMIG9mIHRo ZSBmZWVkIiAuLi4gLz4KPiA+ICAgICAgIDxjdDplbnRyeSByZWY9ImZvbyI+Cj4gPiAgICAgICAg ICAgICAgIDxhdG9tOmxpbmsgcmVsPSJjb21tZW50cyIgaHJlZj0iLi4uIiB0eXBlPSIuLi4iCj4g PiAgICAgICAgICAgICAgIGhyZWZsYW5nPSIuLi4iICBjdDpjb3VudD0iNSIgY3Q6d2hlbj0iLi4u IiAvPgo+ID4gICAgICAgICAgICAgICA8YXRvbTpsaW5rIHJlbD0iY29tbWVudHMiIGhyZWY9Ii4u LiIgdHlwZT0iLi4uIgo+ID4gICAgICAgICAgICAgICBocmVmbGFuZz0iLi4uIiAgY3Q6Y291bnQ9 IjMiIGN0OndoZW49Ii4uLiIgLz4KPiA+ICAgICAgIDwvY3Q6ZW50cnk+Cj4gPiAgICAgICA8Y3Q6 ZW50cnkgcmVmPSJiYXIiPgo+ID4gICAgICAgICAgICAgICA8YXRvbTpsaW5rIHJlbD0iY29tbWVu dHMiIGhyZWY9Ii4uLiIgdHlwZT0iLi4uIgo+ID4gICAgICAgICAgICAgICBocmVmbGFuZz0iLi4u IiAgY3Q6Y291bnQ9IjAiIGN0OndoZW49Ii4uLiIgLz4KPiA+ICAgICAgICAgICAgICAgPGF0b206 bGluayByZWw9ImNvbW1lbnRzIiBocmVmPSIuLi4iIHR5cGU9Ii4uLiIKPiA+ICAgICAgICAgICAg ICAgaHJlZmxhbmc9Ii4uLiIgIGN0OmNvdW50PSIxIiBjdDp3aGVuPSIuLi4iIC8+Cj4gPiAgICAg ICA8L2N0OmVudHJ5Pgo+ID4gICAgICAgLi4uCj4gPiA8L2N0OmNvbW1lbnQtdHJhY2tpbmc+Cj4g Pgo+ID4gT2YgY291cnNlIHRoZSBjb21tZW50IHRyYWNraW5nIGRvY3VtZW50IHdvdWxkbid0IG9u bHkgYmUKPiA+IGF1dGhvcml0YXRpdmUgZm9yIGZlZWRzIHRoYXQgcG9pbnRlZCB0byBpdCB3aXRo IGEKPiA+IGNvbW1lbnQtdHJhY2tpbmcgbGluay4KPiA+Cj4gPiBUaGlzIHdvdWxkIHJlcXVpcmUg YW4gZXh0cmEgc3Vic2NyaXB0aW9uIHRvIHRyYWNrIHRoZSBjb21tZW50cywKPiA+IGFzIHdlbGwg YXMgdW5kZXJzdGFuZGluZyBhbiBhZGRpdGlvbmFsIGZvcm1hdCAoYXMgb3Bwb3NlZCB0bwo+ID4g anVzdCBhbiBhZGRpdGlvbmFsIGV4dGVuc2lvbi0tZWl0aGVyIGFwcHJvYWNoIHJlcXVpcmVzIFNP TUUKPiA+IGFkZGl0aW9uYWwgd29yayksIGJ1dCBpdCB3b3VsZCBwcmV2ZW50IHVubmVjZXNzYXJ5 IGRvd25sb2FkcyBieQo+ID4gY2xpZW50cyB0aGF0IGFyZW4ndCBhd2FyZSBvZiBpdCwgYW5kIHdv dWxkIHJlZHVjZSB0aGUgYmFuZHdpZHRoCj4gPiB1c2VkIGJ5IHRob3NlIHRoYXQgYXJlLgo+ID4K PiA+IFRoaXMgYXBwcm9hY2ggY291bGQgYmUgZ2VuZXJhbGl6ZWQgdG8gZW5hYmxlIG9mZmxvYWRp bmcgb2YKPiA+IG90aGVyIG1ldGFkYXRhIHRoYXQncyBtb3JlIHZvbGF0aWxlIHRoYW4gdGhlIGVu dHJpZXMKPiA+IHRoZW1zZWx2ZXMuCj4KPiBBY3R1YWxseSwgeW91IGRvbid0IHJlYWxseSBuZWVk IGFub3RoZXIgZm9ybWF0LiBUaGVyZSdzIG5vIHJlYXNvbgo+IHdoeSB5b3UgY291bGRuJ3QgdXNl IGF0b206ZmVlZCBpbiBwbGFjZSBvZiB5b3VyIGh5cG90aGV0aWNhbAo+IGN0OmNvbW1lbnQtdHJh Y2tpbmcuIDotKSBZb3VyIGN0OmVudHJ5IGVsZW1lbnRzIGNvdWxkIGFsbW9zdCBiZQo+IGF0b206 ZW50cnkgb25lcyBpbnN0ZWFkLCB0b28sIGV4Y2VwdCB0aGF0IGFzc2lnbmluZyB0aGVtIHRpdGxl cwo+IGFuZCBJRHMgZmVlbHMgbGlrZSBvdmVya2lsbC4KPgo+IFRoZSByZWFsIGNvc3QgaXMgbm90 IHRoZSBjb3N0IG9mIGFuIGV4dHJhIGZvcm1hdCwgYnV0IHRoYXQKPiBpbXBsZW1lbnRhdGlvbnMg dGhlbiBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIEZURSBpbiBvcmRlciB0byBrbm93Cj4gdG8gcG9s bCBhbiBleHRyYSBkb2N1bWVudCB0byByZXRyaWV2ZSB0aGUgb3V0LW9mLWJhbmQgbWV0YWRhdGEu Cj4KPiBSZWdhcmRzLAo+IC0tCj4gQXJpc3RvdGxlIFBhZ2FsdHppcyAvLyA8aHR0cDovL3BsYXNt YXN0dXJtLm9yZy8+Cj4KPgoKCi0tIAo8TTpELz4KCk0uIERhdmlkIFBldGVyc29uCmh0dHA6Ly93 d3cueHNsdGJsb2cuY29tLwo= ------=_Part_134812_29272630.1147982564056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Jmx0O2E6ZiBpZD0mcXVvdDtpZG9mZmVlZCZxdW90OyBhOmRzPSZxdW90OzEmcXVvdDsmZ3Q7PGJy PiZsdDthOmUgaWQ9JnF1b3Q7aWRvZmVudHJ5JnF1b3Q7IGE6cj0mcXVvdDsyJnF1b3Q7Jmd0Ozxi cj4mbHQ7YTpjIGlkPSZxdW90O2lkb2Zjb21tZW50JnF1b3Q7IGE6cj0mcXVvdDsxJnF1b3Q7Jmd0 Ozxicj4mbHQ7YTpjIGlkPSZxdW90O2lkb2Zjb21tZW50JnF1b3Q7IGE6cj0mcXVvdDsyJnF1b3Q7 LyZndDsKPGJyPiZsdDsvYTpjJmd0Ozxicj4mbHQ7L2E6ZSZndDs8YnI+Jmx0O2E6ZSBpZD0mcXVv dDtpZG9mZW50cnk6IGE6cj0mcXVvdDszJnF1b3Q7LyZndDs8YnI+Jmx0Oy9hOmYmZ3Q7PGJyPjxi cj5UaGUgcmVxdWVzdG9yIHNlbmRzIGEgcmVxdWVzdCBmb3IgYWxsIGVudHJpZXMgYW5kIGNvbW1l bnRzIG9uIHRob3NlIGVudGlyaWVzIHNpbmNlIGEgY2VydGFpbiBkYXRlLiZuYnNwOyBJZiB0aGUg ZGF0ZSByZXF1ZXN0IGlzIGNvbnNpZGVyZWQgcmVhc29uYWJsZSwgYSBjb21wYWN0IGF0b20gc3lu dGF4IHRoYXQgY29udGFpbnMsCjxicj48YnI+YSkgYSBkZXRlcm1pbmF0aW9uIGFzIHRvIHdoZXRo ZXIgdGhleSBzdXBwb3J0IHByb3ZpZGluZyBkaWZmcyBhOmRzPSZxdW90OzAmcXVvdDsgZmFsc2Us IGE6ZHM9JnF1b3Q7MSZxdW90OywgdHJ1ZTxicj48YnI+YikgdGhlIHJlbGF2ZW50IHBpZWNlcyBu ZWNlc3NhcnkgdG8gZGV0ZXJtaW5lIGlmLDxicj48YnI+YjoxKSB5b3UgaGF2ZSBhIGxvY2FsIGlu c3RhbmNlIG9mIHRoYXQgaWQuIAo8YnI+YjoxOjEpIElmIHllcywgY29tcGFyZSB0aGUgcmV2aXNp b24gKGE6cikgdmFsdWUuIDxicj5iOjE6MToxKSBJZiB0aGUgc2FtZSwgaWdub3JlLCA8YnI+Yjox OjE6MikgaWYKZGlmZmVyZW50LCB0aGUgZGlmZmVyZW5jZSBpcyBkZXRlcm1pbmVkLCBhbmQgc3Rv cmVkIHVudGlsIHRoZSBjb21wYWN0CnN5bnRheCBhYm92ZSBoYXMgZmluaXNoZWQgYmVpbmcgcHJv Y2Vzc2VkLjxicj5iOjE6MikgSWYgdGhlcmUgaXMgbm8gbG9jYWwgaW5zdGFuY2Ugb2YgdGhhdCBp ZCwgc3RvcmUgdGhlIHRoaXMgdW50aWwgdGhlIHByb2Nlc3MgaGFzIGZpbmlzaGVkLjxicj48YnI+ cmVjdXJzZSB1bnRpbCBjb21wbGV0ZS48YnI+PGJyPnJlY3Vyc2UgdGhlIHJlc3VsdDo8YnI+YTog SWYgeW91IGNhbiBwcm9jZXNzIHRoZSBkaWZmLCBhbmQgdGhleSBzdXBwb3J0IHJldHVybmluZyBq dXN0IHRoZSBkaWZmLCBzZXQgYSByZXF1ZXN0IGhlYWRlciBkZXRlcm1pbmVkIHRvIHNwZWNpZnkg dGhpcyB0byB0aGUgc2VydmVyLgo8YnI+Yjogc2V0IGEgaGVhZGVyIHRvIHNwZWNpZnkgdG8gdGhl IHNlcnZlciBpZiB5b3Ugd2FudCB0aGUgZXhhY3Qgc3BlY2lmaWVkIHJldmlzaW9uLCBvciBhZGRp dGlvbmFsIHJldmlzaW9ucyBpZiB0aGV5IGhhdmUgY2hhbmdlZCBzaW5jZSB0aGUgb3JpZ2luYWwg cXVlcnkuPGJyPmM6IHJldHVybiBhIHJlcXVlc3QgZm9yIGVhY2ggdXBkYXRlZCBvciBuZXcgcmVz b3VyY2UsIHdpdGggdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbG9jYWwgcmV2aXNpb24gbnVt YmVyIGFuZCB0aGUgcmV2aXNpb24gbnVtYmVyIG9uIHRoZSBzZXJ2ZXIgaWYgYXBwcm9wcmlhdGUu Cjxicj48YnI+ZWFjaCByZXF1ZXN0IGlzIGluaXRpYWxseSBhdG9taWMsIHdpdGggdGhlIGFiaWxp dHkgdG8gYmUgZ3JvdXBlZCBpZiB0aGUgc2VydmVyIGRldGVybWluZXMgdGhhdCBpdCB3b3VsZCBi ZSBtb3JlIGVmZmljaWVudCBhdCBwcmVzZW50IHRpbWUgdG8gaGFuZGxlIG9uZSByZXF1ZXN0IGF0 IGEgdGltZSwgb3IgZ3JvdXBlZCB0b2dldGhlciB1c2luZyBhIGNvbmFuaWNhbCBjb21wcmVzc2lv biBvZiB0aGUgcmVxdWVzdGVkIGl0ZW1zLiZuYnNwOyBUaGlzIHdvdWxkIGJlIHJldHVybmVkIGlu IHRoZSByZXNwb25zZSBoZWFkZXIgc3VjaCBhcyB0byBtYWludGFpbiBhIGNvbnNpc3RlbnQgYWJp bGl0eSB0byBhZGFwdCBhdCBhbnkgbW9tZW50IHRvIGN1cnJlbnQgb2FkIG9uIHRoZSBzZXJ2ZXIu Cjxicj48YnI+bm90aGluZyBpcyBhcHByb3hpbWF0ZSwgZWFjaCBzaWRlIG9mIHRoZSB0cmFuc2Fj dGlvbiBoYXMgdGhlIGFiaWxpdHkgdG8gYWRhcHQgdG8gY2hhbmdlLCBhbmQgdG8gZGVjaWRlIGlm IGl0IHdhbnRzIHRvIGhhbmRsZSBwb3RlbnRpYWwgZGlmZmVyZW5jZXMgdGhhdCB0YWtlIHBsYWNl IGR1cmluZyB0aGUgc3BhbiBiZXR3ZWVuIHJlcXVlc3RzIG5vdywgb3IgYXQgYSBsYXRlciBkYXRl LiZuYnNwOyBXaXRoIGVhY2ggdHJhbnNhY3Rpb24sIGVub3VnaCBpbmZvcm1hdGlvbiBpcyBwcm92 aWRlZCB0byBxdWlja2x5IGNhbGN1bGF0ZSBhbmQgZGV0ZXJtaW5lLCBvciBzcGVjaWZ5IGEgZGVm YXVsdCBpZiB0aGUgY3VycmVudCBsb2FkIGlzIHBhc3QgYSBjZXJ0YWluIHRocmVzaG9sZCwgd2hp bGUgc3RpbGwgbWFpbnRhaW5pbmcgdGhlIGtub3dsZWRnZSB0aGF0IHVwZGF0ZXMgZXhpc3RzLCBh bmQgd2hlbiB0aGUgbG9hZCBhbGxvd3MsIG1ha2UgYSBuZXcgcmVxdWVzdCBiYXNlZCBvbiB0aGUg ZGlmZmVyZW5jZSBpbiBzdG9yZWQgdmFsdWVzIHRoYXQgcGVydGFpbiB0byBlYWNoIGlkJm5ic3A7 IGl0IGhhcyBrbm93bGVkZ2UgdG8gaGF2ZSBkaWZmZXJlbmNlcy4KPGJyPjxicj5JZiBkdXJpbmcg dGhpcyBzcGFuLCB0aGUgc2VydmVyIGluIHdoaWNoIHJlY2VpdmVzIHRoZSByZXF1ZXN0IHJlYWxp emVzIHRoYXQgc2luY2UgdGhlIGxhc3QgcmVxdWVzdCwgYSByZXNvdXJjZSBoYXMgYmVlbiByZW1v dmVkL2RlbGV0ZWQsIGEgaGVhZGVyIGNhbiBiZSBzZXQgdG8gc3BlY2lmeSB0aGF0IGZ1dHVyZSBj YWxjdWxhdGlvbnMgc2hvdWxkIGJlIGJhc2VkIG9uIHRoZSBuZXcgZGlmZmVyZW5jZSBpbnN0ZWFk IG9mIHRoZSBvbGQuCjxicj48YnI+LS0tLTxicj5JbiB0aGUgYWJvdmUgc2NlbmFyaW8gdGhlIGFt b3VudCBvZiBkYXRhIGV4Y2hhbmdlIGlzIGF0IGEgYmFyZSBtaW5pbXVtLCB0aGUgcHJvY2Vzc2lu ZyByZXF1aXJlZCB0byBjYWxjdWxhdGUgdGhlIGRpZmZlcmVuY2VzIGlzIGF0IGEgYmFyZSBtaW5p bnVtLCBpdCBtYWludGFpbnMgYSBsZXZlbCBvZiBkYXRhIGludGVncml0eSB0aGF0IGlzIGdyYW51 bGFyIGVub3VnaCB0byBhZGFwdCB0byBlYWNoIGNoYW5nZSBpbiB0aGUgc3lzdGVtLCB3aXRob3V0 IHJlcXVpcmVtZW50IG9mIGV4dGVuc2l2ZSBwcm9jZXNzaW5nIHRvIGRldGVybWluZSB0aGlzIGRp ZmZlcmVuY2UsIHdoaWxlIG1haW50YWluaW5nIGFuIGFnaWxlL2FkYXB0aWJsZSBmb3VuZGF0aW9u IHRoYXQgY2FuIGFkanVzdCBhcyBuZWVkZWQgd2l0aG91dCBsb3NzIG9mIGRhdGEgaW50ZWdyaXR5 IG9uIGVpdGhlciBzaWRlIG9mIHRoZSB0cmFuc2FjdGlvbi4KPGJyPjxicj5HaXZlbiB0aGUgYW1v dW50IG9mIGRhdGEgc2VudCB3aXRoIGluaXRpYWwgcmVxdWVzdCBpcyBhdCBhIGJhcmUgbWluaW11 bSwgdGhpcyBjYW4gYmUgc2V0IGluIG1lbW9yeSBhcyB0aGUgZGVmYXVsdCByZXNwb25zZSBiYXNl ZCBvbiB0aGUgdGltZSBkaWZmZXJlbmNlIHRvIGRldGVybWluZSB0aGUgYWRkcmVzcyBvZiB3aGVy ZSB0byBiZWdpbiBzdHJlYW1pbmcgdGhlIHJlcXVlc3QsIHVzaW5nIHRoZSBkZWZhdWx0IGE6ZiBp ZD0mcXVvdDtmZWVkaWQmcXVvdDsgdG8gb3Blbi9jbG9zZSB0aGUgcmVzcG9uc2Ugc3RyZWFtIGF0 IHRoZSBhcHByb3ByaWF0ZSBzdGFydCBhbmQgc3RvcCBwb2ludCBvZiB0aGUgcmV0dXJuZWQgc3Ry ZWFtLgo8YnI+PGJyPlBsZWFzZSBkaXNyZWdhcmQgdGhlIGFib3ZlIGlmIEkgaGF2ZSBsZWZ0IG91 dCBvYnZpb3VzIGFyZWFzIGluIHdoaWNoIG1ha2VzIHRoaXMgaXJyZWxldmFudC4mbmJzcDsgTm90 IHRyeWluZyB0byB0YWtlIGEgJnF1b3Q7dGhpcyBpcyB0aGUgYWJzb2x1dGUgcmlnaHQgd2F5IHRv IGRvIHRoaXMmcXVvdDsgYW5kIGluc3RlYWQgaW5qZWN0IHRoZSBzbWFsbGVzdCwgc2ltcGxlc3Qg cGF0aCB0aGF0IHNlZW1zIHRvIGxvZ2ljYWxseSBwcm92aWRlIHRoZSBuZWNlc3NhcnkgcGllY2Vz IHRvIG1ha2UgdGhlIHRyYW5zYWN0aW9uIHByb2Nlc3Npbmcgb2YgZGlmZmVyZW5jZXMgYXMgc2lt cGxlIGFuZCBlZmZpY2llbnQgYXMgcG9zc2libGUsIHdoaWxlIGRvaW5nIHNvIGluIGEgd2F5IHRo YXRzIGp1c3Qgb3V0c2lkZSB0aGUgYm94LCBidXQgY2xvc2UgZW5vdWdoIGFzIHRvIG5vdCByZXF1 aXJlIGFueSBjaGFuZ2VzIHRvIGFueSBhY3R1YWwgZHJhZnQgc3BlY2lmaWNhdGlvbnMsIGFuZCBp bnN0ZWFkIGEgd2F5IHRvIGlsbGltaW5hdGUgc29tZSBvZiB0aGUgY29uY2VybnMgcHJlc2VudGVk IHRoYXQgc3VnZ2VzdGVkIHBvdGVudGlhbHMgYXJlYXMgb2YgaW5lZmZpY2llbnQgb3IgaW5uYWN1 cmF0ZSBiZWhhdmlvcnMgdGhhdCBob2xkIHBvdGVudGlhbCBmb3IgcHJvYmxlbXMgZG93biB0aGUg cm9hZC4KPGJyPjxicj5QZWFjZSA6KTxicj48YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA1LzE4LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+QS4gUGFnYWx0 emlzPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhZ2FsdHppc0BnbXguZGUiPnBhZ2FsdHppc0Bn bXguZGU8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdp bjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Cjxicj4qIEFudG9uZSBS b3VuZHkgJmx0OzxhIGhyZWY9Im1haWx0bzp4LWFudG9uZUBnZWNrb3RyaWJlLmNvbSI+eC1hbnRv bmVAZ2Vja290cmliZS5jb208L2E+Jmd0OyBbMjAwNi0wNS0xOCAyMDowNV06PGJyPiZndDsgYW5k IGluIGFub3RoZXIgZG9jdW1lbnQ6PGJyPiZndDs8YnI+Jmd0OyAmbHQ7Y3Q6Y29tbWVudC10cmFj a2luZyB4bWxuczpjdD0mcXVvdDsuLi4mcXVvdDsgeG1sbnM6YXRvbT0mcXVvdDsuLi4mcXVvdDsg Li4uJmd0Owo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 YXRvbTpsaW5rIHJlbD0mcXVvdDtyZWxhdGVkJnF1b3Q7IGhyZWY9JnF1b3Q7VVJMIG9mIHRoZSBm ZWVkJnF1b3Q7IC4uLiAvJmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDtjdDplbnRyeSByZWY9JnF1b3Q7Zm9vJnF1b3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDthdG9tOmxpbmsgcmVsPSZxdW90O2NvbW1lbnRzJnF1 b3Q7IGhyZWY9JnF1b3Q7Li4uJnF1b3Q7IHR5cGU9JnF1b3Q7Li4uJnF1b3Q7Cjxicj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhyZWZsYW5nPSZxdW90Oy4uLiZxdW90OyZuYnNwOyZu YnNwO2N0OmNvdW50PSZxdW90OzUmcXVvdDsgY3Q6d2hlbj0mcXVvdDsuLi4mcXVvdDsgLyZndDs8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7YXRvbTpsaW5rIHJlbD0mcXVv dDtjb21tZW50cyZxdW90OyBocmVmPSZxdW90Oy4uLiZxdW90OyB0eXBlPSZxdW90Oy4uLiZxdW90 Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhyZWZsYW5nPSZxdW90Oy4uLiZx dW90OyZuYnNwOyZuYnNwO2N0OmNvdW50PSZxdW90OzMmcXVvdDsgY3Q6d2hlbj0mcXVvdDsuLi4m cXVvdDsgLyZndDsKPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0Oy9jdDplbnRyeSZndDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7Y3Q6ZW50cnkgcmVmPSZxdW90O2JhciZxdW90OyZndDs8YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7YXRvbTpsaW5rIHJlbD0mcXVvdDtjb21tZW50cyZxdW90 OyBocmVmPSZxdW90Oy4uLiZxdW90OyB0eXBlPSZxdW90Oy4uLiZxdW90Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhyZWZsYW5nPSZxdW90Oy4uLiZxdW90OyZuYnNwOyZuYnNw O2N0OmNvdW50PSZxdW90OzAmcXVvdDsgY3Q6d2hlbj0mcXVvdDsuLi4mcXVvdDsgLyZndDsKPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2F0b206bGluayByZWw9JnF1b3Q7 Y29tbWVudHMmcXVvdDsgaHJlZj0mcXVvdDsuLi4mcXVvdDsgdHlwZT0mcXVvdDsuLi4mcXVvdDs8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBocmVmbGFuZz0mcXVvdDsuLi4mcXVv dDsmbmJzcDsmbmJzcDtjdDpjb3VudD0mcXVvdDsxJnF1b3Q7IGN0OndoZW49JnF1b3Q7Li4uJnF1 b3Q7IC8mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 Oy9jdDplbnRyeSZndDsKPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLi4uPGJyPiZndDsgJmx0Oy9jdDpjb21tZW50LXRyYWNraW5nJmd0Ozxicj4mZ3Q7PGJyPiZn dDsgT2YgY291cnNlIHRoZSBjb21tZW50IHRyYWNraW5nIGRvY3VtZW50IHdvdWxkbid0IG9ubHkg YmU8YnI+Jmd0OyBhdXRob3JpdGF0aXZlIGZvciBmZWVkcyB0aGF0IHBvaW50ZWQgdG8gaXQgd2l0 aCBhPGJyPiZndDsgY29tbWVudC10cmFja2luZyBsaW5rLjxicj4KJmd0Ozxicj4mZ3Q7IFRoaXMg d291bGQgcmVxdWlyZSBhbiBleHRyYSBzdWJzY3JpcHRpb24gdG8gdHJhY2sgdGhlIGNvbW1lbnRz LDxicj4mZ3Q7IGFzIHdlbGwgYXMgdW5kZXJzdGFuZGluZyBhbiBhZGRpdGlvbmFsIGZvcm1hdCAo YXMgb3Bwb3NlZCB0bzxicj4mZ3Q7IGp1c3QgYW4gYWRkaXRpb25hbCBleHRlbnNpb24tLWVpdGhl ciBhcHByb2FjaCByZXF1aXJlcyBTT01FPGJyPiZndDsgYWRkaXRpb25hbCB3b3JrKSwgYnV0IGl0 IHdvdWxkIHByZXZlbnQgdW5uZWNlc3NhcnkgZG93bmxvYWRzIGJ5Cjxicj4mZ3Q7IGNsaWVudHMg dGhhdCBhcmVuJ3QgYXdhcmUgb2YgaXQsIGFuZCB3b3VsZCByZWR1Y2UgdGhlIGJhbmR3aWR0aDxi cj4mZ3Q7IHVzZWQgYnkgdGhvc2UgdGhhdCBhcmUuPGJyPiZndDs8YnI+Jmd0OyBUaGlzIGFwcHJv YWNoIGNvdWxkIGJlIGdlbmVyYWxpemVkIHRvIGVuYWJsZSBvZmZsb2FkaW5nIG9mPGJyPiZndDsg b3RoZXIgbWV0YWRhdGEgdGhhdCdzIG1vcmUgdm9sYXRpbGUgdGhhbiB0aGUgZW50cmllcwo8YnI+ Jmd0OyB0aGVtc2VsdmVzLjxicj48YnI+QWN0dWFsbHksIHlvdSBkb24ndCByZWFsbHkgbmVlZCBh bm90aGVyIGZvcm1hdC4gVGhlcmUncyBubyByZWFzb248YnI+d2h5IHlvdSBjb3VsZG4ndCB1c2Ug YXRvbTpmZWVkIGluIHBsYWNlIG9mIHlvdXIgaHlwb3RoZXRpY2FsPGJyPmN0OmNvbW1lbnQtdHJh Y2tpbmcuIDotKSBZb3VyIGN0OmVudHJ5IGVsZW1lbnRzIGNvdWxkIGFsbW9zdCBiZQo8YnI+YXRv bTplbnRyeSBvbmVzIGluc3RlYWQsIHRvbywgZXhjZXB0IHRoYXQgYXNzaWduaW5nIHRoZW0gdGl0 bGVzPGJyPmFuZCBJRHMgZmVlbHMgbGlrZSBvdmVya2lsbC48YnI+PGJyPlRoZSByZWFsIGNvc3Qg aXMgbm90IHRoZSBjb3N0IG9mIGFuIGV4dHJhIGZvcm1hdCwgYnV0IHRoYXQ8YnI+aW1wbGVtZW50 YXRpb25zIHRoZW4gbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBGVEUgaW4gb3JkZXIgdG8ga25vdwo8 YnI+dG8gcG9sbCBhbiBleHRyYSBkb2N1bWVudCB0byByZXRyaWV2ZSB0aGUgb3V0LW9mLWJhbmQg bWV0YWRhdGEuPGJyPjxicj5SZWdhcmRzLDxicj4tLTxicj5BcmlzdG90bGUgUGFnYWx0emlzIC8v ICZsdDs8YSBocmVmPSJodHRwOi8vcGxhc21hc3R1cm0ub3JnLyI+aHR0cDovL3BsYXNtYXN0dXJt Lm9yZy88L2E+Jmd0Ozxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFs bCI+Cjxicj4tLSA8YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5NLiBEYXZpZCBQZXRlcnNvbjxicj48 YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iPmh0dHA6Ly93d3cueHNsdGJsb2cuY29t LzwvYT4K ------=_Part_134812_29272630.1147982564056-- From owner-atom-syntax@mail.imc.org Thu May 18 17:39:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqCz-0000lX-SW for atompub-archive@lists.ietf.org; Thu, 18 May 2006 17:39:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgpG1-0004Mu-MG for atompub-archive@lists.ietf.org; Thu, 18 May 2006 16:38:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgp35-0007f1-99 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 16:24:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4IJpWbu080503; Thu, 18 May 2006 12:51:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4IJpW5v080502; Thu, 18 May 2006 12:51:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4IJpUPa080476 for ; Thu, 18 May 2006 12:51:31 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 18 May 2006 19:51:25 -0000 Received: from xdsl-84-44-230-75.netcologne.de (EHLO klangraum) [84.44.230.75] by mail.gmx.net (mp001) with SMTP; 18 May 2006 21:51:25 +0200 X-Authenticated: #163624 Date: Thu, 18 May 2006 21:51:24 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Feed Thread in Last Call Message-ID: <20060518195124.GL5530@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <446B3E23.7090004@gmail.com> <21719.194.221.74.7.1147880415.squirrel@mail1.python-hosting.com> <446B6067.2010106@gmail.com> <61611.84.9.36.47.1147888669.squirrel@mail1.python-hosting.com> <10208.194.221.74.7.1147940778.squirrel@mail1.python-hosting.com> <20060518141037.GA11601@nyarlathotep.ssimicro.com> <20060518183139.GI5530@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4IJpWbu080503 X-Spam-Score: -2.6 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 * Antone Roundy [2006-05-18 21:40]: > The point of the whole exercise is to create a lightweight > document for volatile metadata. If it's an atom:feed, you have > to include a lot of stuff that's not needed here--atom:title, > atom:updated, atom:author, and atom:summary or atom:content. > Also, you'd need to have an atom:id for each entry in addition > to the @ref pointing to the entry that it talks about. I did say that atom:entry is overkill. You could still use a feed document, though. If you have no atom:entry in it you can elide the feed-level atom:author, and the other required elements for a feed (atom:id and atom:updated) seem like a good idea to have in this sort of document. Only atom:title is unnecessary, but that does not feel like a big burden. > Sure, but if they don't understand FTE, they wouldn't know what > to do with the extra metadata anyway even if it were in the > main feed. That is only half correct. The point of Sec 6.4 is to allow intermediaries at the infrastructure level (which includes things like the RSS Platform) to store and pass on extension metadata generically, without having to understand what a particular extension means. If you put this metadata out of band, then the application layer has to take on infrastructure layer responsibilities. Note that I=E2=80=99m not arguing against the approach. It seems like an interesting idea. I=E2=80=99m just pointing out that it does have costs. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu May 18 17:45:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqJD-0004le-N4 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 17:45:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqJC-0000cw-A4 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 17:45:27 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ILY97n001485; Thu, 18 May 2006 14:34:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4ILY9En001484; Thu, 18 May 2006 14:34:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from netc-relay-3m.netcourrier.com (netc-relay-3m.netcourrier.com [194.158.104.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ILY4Te001467 for ; Thu, 18 May 2006 14:34:09 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id 9C938B07E for ; Thu, 18 May 2006 23:34:03 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell Date: Thu, 18 May 2006 23:34:03 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4ILY9Te001479 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >From: Nicolas Krebs >To: atom-syntax@imc.org >Subject: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread) >Date: Wed, 17 May 2006 23:55:47 +0200 >> - 'Atom Threading Extensions ' >> as a Proposed Standard >In section 3, this draft give an xml element corresponding to In-reply-to: >(rfc 2822 section 3.6.4). Therefore, the draft do not give an equivalent to >References: 822' header field (rfc 2822 section 3.6.4) (wich could be usefull >to build a mail --> atom gateway). > >The section 7.2. do not mention rfc 2822. Sorry, my mistake. This draft give in section 3 an xml element corresponding to In-reply-to of rfc 2822 section 3.6.4. However the draft do not give an equivalent to the header field References of rfc 2822 section 3.6.4, which could be usefull to build mail --> atom gateway and usenet --> atom gateway, and to find all previous message in a thread. The section 7.2. do not mention rfc 2822. From owner-atom-syntax@mail.imc.org Thu May 18 19:32:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgryO-0000y4-Kp for atompub-archive@lists.ietf.org; Thu, 18 May 2006 19:32:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgryN-0006ke-T7 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 19:32:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4INFO6o022614; Thu, 18 May 2006 16:15:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4INFOlO022613; Thu, 18 May 2006 16:15:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4INFHnS022582 for ; Thu, 18 May 2006 16:15:17 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BDE20142297; Thu, 18 May 2006 16:15:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11601-05; Thu, 18 May 2006 16:15:14 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 98F0214228A; Thu, 18 May 2006 16:15:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v749.3) References: Content-Type: multipart/alternative; boundary=Apple-Mail-20-35697861 Message-Id: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> Cc: James M Snell , doug_otis@trendmicro.com, clive@demon.net, simon@josefsson.org From: Lisa Dusseault Subject: Fwd: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Date: Thu, 18 May 2006 16:15:05 -0700 To: discuss@apps.ietf.org, XMPP WG List , Atom , ietf-nntp@lists.eyrie.org X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 --Apple-Mail-20-35697861 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This announcement is for a document that will obsolete RFC3548, which is referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax (RFC4287). There are also a few drafts that reference RFC3548 that caught my eye: - draft-ietf-nntpext-base, which is in RFC ED queue - draft-josefsson-sasl-gs2-00 - draft-otis-dkim-options-00 - draft-snell-atompub-author-extensions-00 thanks, Lisa Begin forwarded message: > From: The IESG > Date: May 18, 2006 7:51:48 AM PDT > To: IETF-Announce > Cc: Internet Architecture Board , RFC Editor editor@rfc-editor.org> > Subject: Protocol Action: 'The Base16, Base32, and Base64 Data > Encodings' to Proposed Standard > > The IESG has approved the following document: > > - 'The Base16, Base32, and Base64 Data Encodings ' > as a Proposed Standard > > This document has been reviewed in the IETF but is not the product > of an > IETF Working Group. > > The IESG contact person is Ted Hardie. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-04.txt > > Technical Summary > > This document describes the commonly used base 64, base 32, and base > 16 encoding schemes. It also discusses the use of line-feeds in > encoded data, use of padding in encoded data, use of non-alphabet > characters in encoded data, and use of different encoding > alphabets. > It obsoletes the descriptions in RFC 3548. > > Working Group Summary > > This work is the product of an individual submitter. There were > significant > IETF Last Call comments, and the draft was updated to respond to > them. > > Protocol Quality > > This document was reviewed for the IESG by Ted Hardie. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-20-35697861 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 This announcement is for a = document that will obsolete RFC3548, which is referenced by a couple = APPS area RFCs:=A0 XMPP (RFC3920) and Atom Syntax (RFC4287).

There are also a few drafts = that reference RFC3548 that caught my eye:

=A0- draft-ietf-nntpext-base, which is in RFC ED = queue
=A0- = =A0draft-josefsson-sasl-gs2-00
=A0- = draft-otis-dkim-options-00

thanks,
From: = The IESG <iesg-secretary@ietf.org>
Date: May 18, 2006 7:51:48 AM = PDT
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>= ;
Subject: Protocol Action: 'The Base16, = Base32, and Base64 Data=A0 = Encodings' to Proposed Standard=A0

The = IESG has approved the following document:

- 'The = Base16, Base32, and Base64 Data Encodings '
=A0=A0 = <draft-josefsson-rfc3548bis-04.txt> as a Proposed = Standard

This document has been reviewed in the IETF but is = not the product of an
IETF Working Group.=A0

The IESG = contact person is Ted Hardie.

A URL of this Internet-Draft = is:

Technical Summary

=A0 This document describes the = commonly used base 64, base 32, and base
=A0=A0 16 encoding schemes.=A0 It also discusses the use of = line-feeds in
=A0=A0 encoded data, use of = padding in encoded data, use of non-alphabet
=A0=A0 = characters in encoded data, and use of different encoding = alphabets.
=A0=A0 It obsoletes the = descriptions in RFC 3548.

Working Group Summary

=A0This work is the product of an = individual submitter.=A0 = There were significant
=A0IETF Last Call comments, and = the draft was updated to respond to them.

Protocol = Quality

=A0This = document was reviewed for the IESG by Ted Hardie.


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-20-35697861-- From owner-atom-syntax@mail.imc.org Thu May 18 20:09:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgsYF-0000nb-I3 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 20:09:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgsYD-0000yi-60 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 20:09:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4INwdxt031710; Thu, 18 May 2006 16:58:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4INwd0D031709; Thu, 18 May 2006 16:58:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4INwbkn031695 for ; Thu, 18 May 2006 16:58:38 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so709588pyf for ; Thu, 18 May 2006 16:58:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UzQFGZJ9GGsSaysdBRopO/o58+AJqlVLzIuDRKmqnCHHTJTZAYDktYsAqiCufY1jSnInu1roljBnS38aamaWG7FQOqOYk1lVze0SsJ//3wH+4R9Y8Cg3ELfkXajlO780GGFGZUY+j0bafZTO+Xq+tOnOYbSR2S9plep8rWSatAU= Received: by 10.35.36.13 with SMTP id o13mr1180846pyj; Thu, 18 May 2006 16:58:33 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Thu, 18 May 2006 16:58:33 -0700 (PDT) Message-ID: <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> Date: Fri, 19 May 2006 01:58:33 +0200 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Cc: Atom , "James M Snell" In-Reply-To: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4INwckn031704 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 5/19/06, Lisa Dusseault wrote: > > This announcement is for a document that will obsolete RFC3548, which is > referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax > (RFC4287). Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for a revision. > - draft-snell-atompub-author-extensions-00 Oh, this excellent document is affected too. Seems like we have a real problem here. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Thu May 18 20:52:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgtEH-0008MH-Bl for atompub-archive@lists.ietf.org; Thu, 18 May 2006 20:52:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgtEF-0003KE-Vg for atompub-archive@lists.ietf.org; Thu, 18 May 2006 20:52:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J0epFJ040399; Thu, 18 May 2006 17:40:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J0epVW040398; Thu, 18 May 2006 17:40:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J0eoPY040381 for ; Thu, 18 May 2006 17:40:51 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B199142289; Thu, 18 May 2006 17:40:48 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24515-08; Thu, 18 May 2006 17:40:47 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B80E414228A; Thu, 18 May 2006 17:40:47 -0700 (PDT) In-Reply-To: <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "James M Snell" , "David Powell" , atom-syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Feed Thread in Last Call Date: Thu, 18 May 2006 17:40:43 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On May 18, 2006, at 8:56 AM, Robert Sayre wrote: > Look at that giant email. Seems to me that it's a debate taking place > for no discernable reason. There's no technical reason for the > placement of the attributes, and management has made it clear that any > objections are "irrelevant." I realize that the placement of the attributes is one choice among many. Sometimes you just have to make a choice and there's no reason beyond "it needs to go somewhere". I've been trying to understand if there's a technical problem with the draft's chosen placement of the attributes and the best case I've seen is that "that location is technically disallowed by RFC4287", an assertion which is disputed (alas, natural language meanings are often disputed). Am I missing something in the case against the choice of location for the metadata? Thanks, Lisa From owner-atom-syntax@mail.imc.org Thu May 18 21:02:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgtNu-0005TG-Pe for atompub-archive@lists.ietf.org; Thu, 18 May 2006 21:02:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgtNu-00042B-D1 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 21:02:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J0pbvH042688; Thu, 18 May 2006 17:51:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J0pbXc042687; Thu, 18 May 2006 17:51:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J0pbkC042673 for ; Thu, 18 May 2006 17:51:37 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DB3CD142297; Thu, 18 May 2006 17:51:36 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05201-05; Thu, 18 May 2006 17:51:36 -0700 (PDT) Received: from [192.168.1.101] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F543142289; Thu, 18 May 2006 17:51:36 -0700 (PDT) In-Reply-To: <68fba5c50605171941o3a071b2ah84954034f120a8a9@mail.gmail.com> References: <446A6C39.1090706@dehora.net> <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> <09EE30D9-0446-4D1D-AC56-9018AD9F80B9@osafoundation.org> <68fba5c50605171941o3a071b2ah84954034f120a8a9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Atom WG" , IESG Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Informational vs. standards-track for Atom Threading Extensions Date: Thu, 18 May 2006 17:51:32 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On May 17, 2006, at 7:41 PM, Robert Sayre wrote: > On 5/18/06, Lisa Dusseault wrote: >> >> On May 17, 2006, at 10:02 AM, Robert Sayre wrote: >> > >> > Well, you clearly don't think they're important. But then you felt >> > compelled to change them back and got an instant stamp of approval >> > from our AD. What happened there? > > My question has yet to be answered. I answered your question as fully as I could from the information I know, as I reviewed one revision of the draft before agreeing to shepherd the document. I can't tell you why James made any particular change from one draft to another but I don't find that question very relevant to the quality of the final document. > >> >> I could still recommend Experimental instead of Standards Track if I >> learned of some possible harm to security/privacy or Internet health, >> or some deep barrier to interoperability, but I have not yet learned >> of a high enough risk+severity of such concerns to change my mind >> there. > > I think this is an excellent standard. If another individual, such as > myself, were to submit an individually authored document, it would > have to meet the same standard, right? Yes, along with the other considerations I mentioned earlier in that email, about usefulness, adoption and review. > >> >> I hope that makes the situation clearer! > > Sure does! Good :) Lisa From owner-atom-syntax@mail.imc.org Thu May 18 21:12:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgtXe-0000Cx-Hb for atompub-archive@lists.ietf.org; Thu, 18 May 2006 21:12:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgtXd-0004QN-67 for atompub-archive@lists.ietf.org; Thu, 18 May 2006 21:12:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J12X1f045017; Thu, 18 May 2006 18:02:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J12XHd045016; Thu, 18 May 2006 18:02:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [192.168.0.47] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J12UJd044999; Thu, 18 May 2006 18:02:30 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> References: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> Date: Thu, 18 May 2006 18:02:31 -0700 To: "Robert Sayre" , "Lisa Dusseault" From: Paul Hoffman Subject: Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Cc: Atom , "James M Snell" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At 1:58 AM +0200 5/19/06, Robert Sayre wrote: >On 5/19/06, Lisa Dusseault wrote: >> >>This announcement is for a document that will obsolete RFC3548, which is >>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax >>(RFC4287). > >Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for >a revision. I'm confused. What breaks? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu May 18 23:28:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgvfL-0001S6-6v for atompub-archive@lists.ietf.org; Thu, 18 May 2006 23:28:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgvfG-00021B-QU for atompub-archive@lists.ietf.org; Thu, 18 May 2006 23:28:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J3D7mN073634; Thu, 18 May 2006 20:13:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J3D7qv073633; Thu, 18 May 2006 20:13:07 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J3D492073606 for ; Thu, 18 May 2006 20:13:06 -0700 (MST) (envelope-from joe.gregorio@gmail.com) Received: by nz-out-0102.google.com with SMTP id x7so259378nzc for ; Thu, 18 May 2006 20:13:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HGakiuFn6xjyAMZGIEaXMaA6C/7TEn+wPZhmBUBa2Ax69SxmkkU/l+gHr/YzwgD7TzPlYIyd8yl6nLWiFzHfrtwRdXxz2fPDkN5IpzobwySrC2S0YkitBRsyM/0KFLlyLXiLNWJNO1qTIQWaFvGAqKEVJu1A6W+aSjvlqMf8gD0= Received: by 10.65.159.9 with SMTP id l9mr1114869qbo; Thu, 18 May 2006 20:13:03 -0700 (PDT) Received: by 10.65.81.16 with HTTP; Thu, 18 May 2006 20:13:03 -0700 (PDT) Message-ID: <3f1451f50605182013m7468a0d8mafaad0a23495bdfa@mail.gmail.com> Date: Thu, 18 May 2006 23:13:03 -0400 From: "Joe Gregorio" To: "Paul Hoffman" Subject: Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Cc: "Robert Sayre" , "Lisa Dusseault" , Atom , "James M Snell" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4J3D692073628 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I think Robert is referring to this: http://tinyurl.com/l2uop -joe On 5/18/06, Paul Hoffman wrote: > > At 1:58 AM +0200 5/19/06, Robert Sayre wrote: > >On 5/19/06, Lisa Dusseault wrote: > >> > >>This announcement is for a document that will obsolete RFC3548, which is > >>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax > >>(RFC4287). > > > >Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for > >a revision. > > I'm confused. What breaks? > > --Paul Hoffman, Director > --Internet Mail Consortium > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Thu May 18 23:52:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgw2K-0003F0-Sw for atompub-archive@lists.ietf.org; Thu, 18 May 2006 23:52:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgw2J-0005CP-Df for atompub-archive@lists.ietf.org; Thu, 18 May 2006 23:52:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J3cuSC079387; Thu, 18 May 2006 20:38:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J3cu5U079386; Thu, 18 May 2006 20:38:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav10.bay109.hotmail.com [64.4.19.82]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J3cujk079371 for ; Thu, 18 May 2006 20:38:56 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 May 2006 20:38:55 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV10.phx.gbl with DAV; Fri, 19 May 2006 03:38:50 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom" References: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> <3f1451f50605182013m7468a0d8mafaad0a23495bdfa@mail.gmail.com> Subject: Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard Date: Fri, 19 May 2006 04:38:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 19 May 2006 03:38:55.0671 (UTC) FILETIME=[C1631470:01C67AF5] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad In which you predict somebody will *complain* that Atom is broken - you never claim that Atom will actually break. I think Robert's complaint is merely a kind attempt to help you fulfil your prophecy. Joe Gregorio wrote: > I think Robert is referring to this: > > http://tinyurl.com/l2uop > > On 5/18/06, Paul Hoffman wrote: >> I'm confused. What breaks? From owner-atom-syntax@mail.imc.org Fri May 19 03:05:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgz32-0001JD-U8 for atompub-archive@lists.ietf.org; Fri, 19 May 2006 03:05:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgz30-0000sU-Gz for atompub-archive@lists.ietf.org; Fri, 19 May 2006 03:05:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J6pUWE022143; Thu, 18 May 2006 23:51:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J6pUWw022142; Thu, 18 May 2006 23:51:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J6pREK022127 for ; Thu, 18 May 2006 23:51:29 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id 14so238364nzn for ; Thu, 18 May 2006 23:51:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qVaDg/mWkTGgBKvwBy/amlJWaQUY7siQfc8nTKKwkE5MAeoCetAgx0P8uuQ1UNf+ByaF5tdDLQC3xtqXmSmsXLe8CcVCNclKxCttVF7TCW+FkIN8boaxyc65VYl1V2RiAnt5Pkin/pZBaWGZqtoKvrVpBozODUzzl1omz7/ZXEE= Received: by 10.36.80.7 with SMTP id d7mr1495975nzb; Thu, 18 May 2006 23:51:26 -0700 (PDT) Received: by 10.36.178.15 with HTTP; Thu, 18 May 2006 23:51:26 -0700 (PDT) Message-ID: Date: Fri, 19 May 2006 08:51:26 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <334E15AA-7049-4A6E-AFD7-916667E67E6D@osafoundation.org> <68fba5c50605181658k7f18d6cg61f40aa1abe803a9@mail.gmail.com> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k4J6pUEK022137 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4J6pUWE022143 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 2006/5/19, Paul Hoffman : > At 1:58 AM +0200 5/19/06, Robert Sayre wrote: > >On 5/19/06, Lisa Dusseault wrote: > >> > >>This announcement is for a document that will obsolete RFC3548, which= is > >>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Synta= x > >>(RFC4287). > > > >Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for > >a revision. > > I'm confused. What breaks? +1 base32 and base32hex are for use in case insensitive contexts, but XML is case sensitive and Atom is XML. I can't find a real need for base16 and it doubles the size of the input, I'd say that Atom doesn't need it. Atom doesn't need base64url either, as + and / are not reserved characters in XML PCDATA (the only part of Atom where base64 is used). base64url might be useful on "data" URL though, but that's not the use of base64 encoding made by Atom. There's no reason for Atom not to support those encodings (other than because it introduces new encodings for processors to know about, and it would introduce a new attribute to tell processors which encoding has been used), but there's no reason for Atom to support any baseNN encoding other than the "plain old" base64. Having a single encoding is better for interop: implementors of processors/producers know exactly what to support; supporting multiple encodings would require an additional attribute telling which encoding has been used, which would lead to complains that this attribute's value set isn't extensible=E2=80=A6 So no, Atom shouldn't have to support other baseNN encodings than base64, and doing so wouldn't prove good for interop, so this revised RFC doesn't break Atom. --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Fri May 19 04:19:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0Cy-0007s2-FZ for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:19:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0Cx-0004Nz-2A for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:19:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J83lp4039127; Fri, 19 May 2006 01:03:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J83lGi039126; Fri, 19 May 2006 01:03:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+yQ+ucTNF4iedquVjAyqXMp+7wf8IuKB4@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J83j9M039116 for ; Fri, 19 May 2006 01:03:46 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19KWvwsYCOwzfAw0P0Ilf66vOBcNrJhs1Q@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4J83j9i003296; Fri, 19 May 2006 03:03:45 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4J83iKL003294; Fri, 19 May 2006 09:03:44 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Fri, 19 May 2006 09:03:44 +0100 (BST) Message-ID: <9671.194.221.74.7.1148025824.squirrel@mail1.python-hosting.com> In-Reply-To: <446C9D34.5010406@jabber.org> References: <446C9D34.5010406@jabber.org> Date: Fri, 19 May 2006 09:03:44 +0100 (BST) Subject: Re: "Atom Over XMPP" I-D From: "Sylvain Hellegouarch" To: "Peter Saint-Andre" Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi Peter, Just noticed your message (we've flooded the list with the FTE draft ;)). I can tell you this is a work that I'm really interested in and I'm looking forward to your new draft. - Sylvain > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > As you may have noticed, the "Atom Over XMPP" I-D expired on February 20 > of this year: > > http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-04.html > > However, by no means is this I-D abandoned. > > Since January, the underlying publish-subscribe specification (JEP-0060) > used by draft-saintandre-atompub-notify has been under revision within > the Jabber Software Foundation's standards process, mainly in order to > incorporate feedback based on implementation experience (also to make > the specification easier to understand). The revision process is close > to completion and the Jabber Council is currently requesting feedback on > the revisions: > > http://mail.jabber.org/pipermail/standards-jig/2006-May/011101.html > > http://www.jabber.org/jeps/tmp/jep-0060-1.8.html > > If all goes well, the revised pubsub specification will be approved by > the Jabber Council during the week of June 12. At that time (and before > the IETF 66 cutoff date of June 26), I will submit a revised version of > draft-saintandre-atompub-notify to the Secretariat. > > Thanks for your interest. > > Peter > > - -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.shtml > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEbJ00NF1RSzyt3NURAh/GAJ9Y3bOdSRu8sjL7fQJRyPK2gT8lawCghrPZ > oR6vRLed4adw0a6ssgJvO2M= > =Bb/z > -----END PGP SIGNATURE----- > From owner-atom-syntax@mail.imc.org Fri May 19 04:22:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0G8-0000bW-RF for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:22:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0G7-0004WH-Fr for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:22:56 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J8D4Rr041147; Fri, 19 May 2006 01:13:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J8D4Be041146; Fri, 19 May 2006 01:13:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J8D3wx041131 for ; Fri, 19 May 2006 01:13:03 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so788337pyf for ; Fri, 19 May 2006 01:13:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fgnEV1COX5aaYk5OLnRuOkd/s/SfXHVh+99DgEXbunyWIm033Asdv/DhIAQ+VpEWCKb217AekUr+5RB/m8oaiX2b4Rk5lzKG02JpVpOT9Gkd4H7dxZFHIiwMACMinUjMTFgEYzLELp4PJUveNoo8UkgiEXMChldj2fxWrg7SaKo= Received: by 10.35.22.17 with SMTP id z17mr1626838pyi; Fri, 19 May 2006 01:13:03 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Fri, 19 May 2006 01:13:03 -0700 (PDT) Message-ID: <68fba5c50605190113w29520184sf87b28ec75b7c47e@mail.gmail.com> Date: Fri, 19 May 2006 10:13:03 +0200 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Informational vs. standards-track for Atom Threading Extensions Cc: "Atom WG" , IESG In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <68fba5c50605162211l2919cb79ka80d4a97bb3e5ec@mail.gmail.com> <20060517131655.GL1714@klangraum> <446B4EDD.7060602@gmail.com> <446B5241.20301@aol.net> <68fba5c50605171002l1a7436d1g88ba60dc604925c9@mail.gmail.com> <09EE30D9-0446-4D1D-AC56-9018AD9F80B9@osafoundation.org> <68fba5c50605171941o3a071b2ah84954034f120a8a9@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4J8D4wx041133 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 5/19/06, Lisa Dusseault wrote: > > I answered your question as fully as I could > Quite true, but I asked James. -- Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 19 04:30:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh0NU-0003xr-Le for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:30:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0NS-0004qn-V0 for atompub-archive@lists.ietf.org; Fri, 19 May 2006 04:30:32 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J8Go4S042077; Fri, 19 May 2006 01:16:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J8Go67042076; Fri, 19 May 2006 01:16:50 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J8GmAl042052 for ; Fri, 19 May 2006 01:16:49 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x7so295718nzc for ; Fri, 19 May 2006 01:16:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=msGIffHa9Drj1hsLr/AoKj5djF4OwCzpAMYzREGGnf8VAA2MHxnVQMewoEjvDzOrVJOucUQ91scp0rnJOZHS8gxbx7fv+PaeXtzF+gPlyC1oDZvKyxHvUlAd5u2NyLDmeN2uMMTdv9wJAKLnG0pF7HYP/wVBLqVH8ckSSUUZs6E= Received: by 10.64.142.19 with SMTP id p19mr1231046qbd; Fri, 19 May 2006 01:16:48 -0700 (PDT) Received: by 10.65.233.15 with HTTP; Fri, 19 May 2006 01:16:48 -0700 (PDT) Message-ID: Date: Fri, 19 May 2006 02:16:48 -0600 From: "M. David Peterson" To: sh@defuze.org Subject: Re: "Atom Over XMPP" I-D Cc: "Peter Saint-Andre" , atom-syntax@imc.org, LLUP-Design In-Reply-To: <9671.194.221.74.7.1148025824.squirrel@mail1.python-hosting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_142162_9189245.1148026608339" References: <446C9D34.5010406@jabber.org> <9671.194.221.74.7.1148025824.squirrel@mail1.python-hosting.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 ------=_Part_142162_9189245.1148026608339 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SW4gZmFjdCwgbWFueSBvZiB1cyBhcmUsIGFzIGl0IGhhcyBiZWVuIHRoZSBmb3VuZGF0aW9uIG9m IHRoZSB3b3JrIHdlIGhhdmUKYmVlbiBkb2luZyBvbiBhbm90aGVyIHByb2plY3QgdGhhdCBpcyBz b21ld2hhdCByZWxhdGVkLCBidXQgZm9jdXNlZCBvbiBhcmVhCnRoYXQgaXMgcXVpdGUgYSBiaXQg ZGlmZmVyZW50IGluIHJlZ2FyZHMgdG8gdGhlIHByaW1hcnkgZm9jdXMgb2YgQXRvbSBvdmVyClhN UFAsIHdoaWNoIEkgdGhpbmsgaXMgR1JFQVQgYXMgaXQgc2hvd2Nhc2VzIHF1aXRlIG5pY2VseSBo b3cgYSB3ZWxsCmRlc2lnbmVkIGZvcm1hdCBjYW4gYmUgZXh0ZW5kZWQgdG8gcHJvdmlkZSBhZGRp dGlvbmFsIHZhbHVlLWFkZCB3aXRob3V0CmJyZWFraW5nIHRoZSB1bmRlcmx5aW5nIHNwZWNpZmlj YXRpb24gdGhhdCBpdCBleHRlbmRzIGZyb20uCgpEb24ndCBtZWFuIHRvIHNvdW5kIGxpa2UgSSBh bSB0YWxraW5nIGluIGNvZGUgd29yZHMuLi4gQnV0IHdpbGwgbGVhdmUKYWRkaXRpb25hbCBjb21t ZW50cyBpbiBTeWx2YWlucyBjYXBhYmxlIGhhbmRzIGFzIG9uZSBvZiB0aGUgZWRpdG9ycyBvZiB0 aGUKc3BlYyBJIGFtIHJlZmVyaW5nIHRvLi4uIDopCgpPbiA1LzE5LzA2LCBTeWx2YWluIEhlbGxl Z291YXJjaCA8c2hAZGVmdXplLm9yZz4gd3JvdGU6Cj4KPgo+IEhpIFBldGVyLAo+Cj4gSnVzdCBu b3RpY2VkIHlvdXIgbWVzc2FnZSAod2UndmUgZmxvb2RlZCB0aGUgbGlzdCB3aXRoIHRoZSBGVEUg ZHJhZnQgOykpLgo+IEkgY2FuIHRlbGwgeW91IHRoaXMgaXMgYSB3b3JrIHRoYXQgSSdtIHJlYWxs eSBpbnRlcmVzdGVkIGluIGFuZCBJJ20KPiBsb29raW5nIGZvcndhcmQgdG8geW91ciBuZXcgZHJh ZnQuCj4KPiAtIFN5bHZhaW4KPgo+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0t LQo+ID4gSGFzaDogU0hBMQo+ID4KPiA+IEFzIHlvdSBtYXkgaGF2ZSBub3RpY2VkLCB0aGUgIkF0 b20gT3ZlciBYTVBQIiBJLUQgZXhwaXJlZCBvbiBGZWJydWFyeSAyMAo+ID4gb2YgdGhpcyB5ZWFy Ogo+ID4KPiA+IGh0dHA6Ly93d3cueG1wcC5vcmcvZHJhZnRzL2RyYWZ0LXNhaW50YW5kcmUtYXRv bXB1Yi1ub3RpZnktMDQuaHRtbAo+ID4KPiA+IEhvd2V2ZXIsIGJ5IG5vIG1lYW5zIGlzIHRoaXMg SS1EIGFiYW5kb25lZC4KPiA+Cj4gPiBTaW5jZSBKYW51YXJ5LCB0aGUgdW5kZXJseWluZyBwdWJs aXNoLXN1YnNjcmliZSBzcGVjaWZpY2F0aW9uIChKRVAtMDA2MCkKPiA+IHVzZWQgYnkgZHJhZnQt c2FpbnRhbmRyZS1hdG9tcHViLW5vdGlmeSBoYXMgYmVlbiB1bmRlciByZXZpc2lvbiB3aXRoaW4K PiA+IHRoZSBKYWJiZXIgU29mdHdhcmUgRm91bmRhdGlvbidzIHN0YW5kYXJkcyBwcm9jZXNzLCBt YWlubHkgaW4gb3JkZXIgdG8KPiA+IGluY29ycG9yYXRlIGZlZWRiYWNrIGJhc2VkIG9uIGltcGxl bWVudGF0aW9uIGV4cGVyaWVuY2UgKGFsc28gdG8gbWFrZQo+ID4gdGhlIHNwZWNpZmljYXRpb24g ZWFzaWVyIHRvIHVuZGVyc3RhbmQpLiBUaGUgcmV2aXNpb24gcHJvY2VzcyBpcyBjbG9zZQo+ID4g dG8gY29tcGxldGlvbiBhbmQgdGhlIEphYmJlciBDb3VuY2lsIGlzIGN1cnJlbnRseSByZXF1ZXN0 aW5nIGZlZWRiYWNrIG9uCj4gPiB0aGUgcmV2aXNpb25zOgo+ID4KPiA+IGh0dHA6Ly9tYWlsLmph YmJlci5vcmcvcGlwZXJtYWlsL3N0YW5kYXJkcy1qaWcvMjAwNi1NYXkvMDExMTAxLmh0bWwKPiA+ Cj4gPiBodHRwOi8vd3d3LmphYmJlci5vcmcvamVwcy90bXAvamVwLTAwNjAtMS44Lmh0bWwKPiA+ Cj4gPiBJZiBhbGwgZ29lcyB3ZWxsLCB0aGUgcmV2aXNlZCBwdWJzdWIgc3BlY2lmaWNhdGlvbiB3 aWxsIGJlIGFwcHJvdmVkIGJ5Cj4gPiB0aGUgSmFiYmVyIENvdW5jaWwgZHVyaW5nIHRoZSB3ZWVr IG9mIEp1bmUgMTIuIEF0IHRoYXQgdGltZSAoYW5kIGJlZm9yZQo+ID4gdGhlIElFVEYgNjYgY3V0 b2ZmIGRhdGUgb2YgSnVuZSAyNiksIEkgd2lsbCBzdWJtaXQgYSByZXZpc2VkIHZlcnNpb24gb2YK PiA+IGRyYWZ0LXNhaW50YW5kcmUtYXRvbXB1Yi1ub3RpZnkgdG8gdGhlIFNlY3JldGFyaWF0Lgo+ ID4KPiA+IFRoYW5rcyBmb3IgeW91ciBpbnRlcmVzdC4KPiA+Cj4gPiBQZXRlcgo+ID4KPiA+IC0g LS0KPiA+IFBldGVyIFNhaW50LUFuZHJlCj4gPiBKYWJiZXIgU29mdHdhcmUgRm91bmRhdGlvbgo+ ID4gaHR0cDovL3d3dy5qYWJiZXIub3JnL3Blb3BsZS9zdHBldGVyLnNodG1sCj4gPgo+ID4gLS0t LS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KPiA+IFZlcnNpb246IEdudVBHIHYxLjQuMSAoRGFy d2luKQo+ID4gQ29tbWVudDogVXNpbmcgR251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL2VuaWdt YWlsLm1vemRldi5vcmcKPiA+Cj4gPiBpRDhEQlFGRWJKMDBORjFSU3p5dDNOVVJBaC9HQUo5WTNi T2RTUnU4c2pMN2ZRSlJ5UEsyZ1Q4bGF3Q2doclBaCj4gPiBvUjZ2UkxlZDRhZHcwYTZzc2dKdk8y TT0KPiA+ID1CYi96Cj4gPiAtLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KPiA+Cj4KPgoKCi0t IAo8TTpELz4KCk0uIERhdmlkIFBldGVyc29uCmh0dHA6Ly93d3cueHNsdGJsb2cuY29tLwo= ------=_Part_142162_9189245.1148026608339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SW4gZmFjdCwgbWFueSBvZiB1cyBhcmUsIGFzIGl0IGhhcyBiZWVuIHRoZSBmb3VuZGF0aW9uIG9m IHRoZSB3b3JrIHdlIGhhdmUgYmVlbiBkb2luZyBvbiBhbm90aGVyIHByb2plY3QgdGhhdCBpcyBz b21ld2hhdCByZWxhdGVkLCBidXQgZm9jdXNlZCBvbiBhcmVhIHRoYXQgaXMgcXVpdGUgYSBiaXQg ZGlmZmVyZW50IGluIHJlZ2FyZHMgdG8gdGhlIHByaW1hcnkgZm9jdXMgb2YgQXRvbSBvdmVyIFhN UFAsIHdoaWNoIEkgdGhpbmsgaXMgR1JFQVQgYXMgaXQgc2hvd2Nhc2VzIHF1aXRlIG5pY2VseSBo b3cgYSB3ZWxsIGRlc2lnbmVkIGZvcm1hdCBjYW4gYmUgZXh0ZW5kZWQgdG8gcHJvdmlkZSBhZGRp dGlvbmFsIHZhbHVlLWFkZCB3aXRob3V0IGJyZWFraW5nIHRoZSB1bmRlcmx5aW5nIHNwZWNpZmlj YXRpb24gdGhhdCBpdCBleHRlbmRzIGZyb20uCjxicj48YnI+RG9uJ3QgbWVhbiB0byBzb3VuZCBs aWtlIEkgYW0gdGFsa2luZyBpbiBjb2RlIHdvcmRzLi4uIEJ1dCB3aWxsIGxlYXZlIGFkZGl0aW9u YWwgY29tbWVudHMgaW4gU3lsdmFpbnMgY2FwYWJsZSBoYW5kcyBhcyBvbmUgb2YgdGhlIGVkaXRv cnMgb2YgdGhlIHNwZWMgSSBhbSByZWZlcmluZyB0by4uLiA6KTxicj48YnI+PGRpdj48c3BhbiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIDUvMTkvMDYsIAo8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFt ZSI+U3lsdmFpbiBIZWxsZWdvdWFyY2g8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c2hAZGVmdXpl Lm9yZyI+c2hAZGVmdXplLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw NCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4K PGJyPkhpIFBldGVyLDxicj48YnI+SnVzdCBub3RpY2VkIHlvdXIgbWVzc2FnZSAod2UndmUgZmxv b2RlZCB0aGUgbGlzdCB3aXRoIHRoZSBGVEUgZHJhZnQgOykpLjxicj5JIGNhbiB0ZWxsIHlvdSB0 aGlzIGlzIGEgd29yayB0aGF0IEknbSByZWFsbHkgaW50ZXJlc3RlZCBpbiBhbmQgSSdtPGJyPmxv b2tpbmcgZm9yd2FyZCB0byB5b3VyIG5ldyBkcmFmdC48YnI+PGJyPi0gU3lsdmFpbjxicj4KPGJy PiZndDsgLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLTxicj4mZ3Q7IEhhc2g6IFNI QTE8YnI+Jmd0Ozxicj4mZ3Q7IEFzIHlvdSBtYXkgaGF2ZSBub3RpY2VkLCB0aGUgJnF1b3Q7QXRv bSBPdmVyIFhNUFAmcXVvdDsgSS1EIGV4cGlyZWQgb24gRmVicnVhcnkgMjA8YnI+Jmd0OyBvZiB0 aGlzIHllYXI6PGJyPiZndDs8YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LnhtcHAub3JnL2Ry YWZ0cy9kcmFmdC1zYWludGFuZHJlLWF0b21wdWItbm90aWZ5LTA0Lmh0bWwiPgpodHRwOi8vd3d3 LnhtcHAub3JnL2RyYWZ0cy9kcmFmdC1zYWludGFuZHJlLWF0b21wdWItbm90aWZ5LTA0Lmh0bWw8 L2E+PGJyPiZndDs8YnI+Jmd0OyBIb3dldmVyLCBieSBubyBtZWFucyBpcyB0aGlzIEktRCBhYmFu ZG9uZWQuPGJyPiZndDs8YnI+Jmd0OyBTaW5jZSBKYW51YXJ5LCB0aGUgdW5kZXJseWluZyBwdWJs aXNoLXN1YnNjcmliZSBzcGVjaWZpY2F0aW9uIChKRVAtMDA2MCk8YnI+CiZndDsgdXNlZCBieSBk cmFmdC1zYWludGFuZHJlLWF0b21wdWItbm90aWZ5IGhhcyBiZWVuIHVuZGVyIHJldmlzaW9uIHdp dGhpbjxicj4mZ3Q7IHRoZSBKYWJiZXIgU29mdHdhcmUgRm91bmRhdGlvbidzIHN0YW5kYXJkcyBw cm9jZXNzLCBtYWlubHkgaW4gb3JkZXIgdG88YnI+Jmd0OyBpbmNvcnBvcmF0ZSBmZWVkYmFjayBi YXNlZCBvbiBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIChhbHNvIHRvIG1ha2UKPGJyPiZndDsg dGhlIHNwZWNpZmljYXRpb24gZWFzaWVyIHRvIHVuZGVyc3RhbmQpLiBUaGUgcmV2aXNpb24gcHJv Y2VzcyBpcyBjbG9zZTxicj4mZ3Q7IHRvIGNvbXBsZXRpb24gYW5kIHRoZSBKYWJiZXIgQ291bmNp bCBpcyBjdXJyZW50bHkgcmVxdWVzdGluZyBmZWVkYmFjayBvbjxicj4mZ3Q7IHRoZSByZXZpc2lv bnM6PGJyPiZndDs8YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vbWFpbC5qYWJiZXIub3JnL3BpcGVy bWFpbC9zdGFuZGFyZHMtamlnLzIwMDYtTWF5LzAxMTEwMS5odG1sIj4KaHR0cDovL21haWwuamFi YmVyLm9yZy9waXBlcm1haWwvc3RhbmRhcmRzLWppZy8yMDA2LU1heS8wMTExMDEuaHRtbDwvYT48 YnI+Jmd0Ozxicj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuamFiYmVyLm9yZy9qZXBzL3RtcC9q ZXAtMDA2MC0xLjguaHRtbCI+aHR0cDovL3d3dy5qYWJiZXIub3JnL2plcHMvdG1wL2plcC0wMDYw LTEuOC5odG1sPC9hPjxicj4mZ3Q7PGJyPiZndDsgSWYgYWxsIGdvZXMgd2VsbCwgdGhlIHJldmlz ZWQgcHVic3ViIHNwZWNpZmljYXRpb24gd2lsbCBiZSBhcHByb3ZlZCBieQo8YnI+Jmd0OyB0aGUg SmFiYmVyIENvdW5jaWwgZHVyaW5nIHRoZSB3ZWVrIG9mIEp1bmUgMTIuIEF0IHRoYXQgdGltZSAo YW5kIGJlZm9yZTxicj4mZ3Q7IHRoZSBJRVRGIDY2IGN1dG9mZiBkYXRlIG9mIEp1bmUgMjYpLCBJ IHdpbGwgc3VibWl0IGEgcmV2aXNlZCB2ZXJzaW9uIG9mPGJyPiZndDsgZHJhZnQtc2FpbnRhbmRy ZS1hdG9tcHViLW5vdGlmeSB0byB0aGUgU2VjcmV0YXJpYXQuPGJyPgomZ3Q7PGJyPiZndDsgVGhh bmtzIGZvciB5b3VyIGludGVyZXN0Ljxicj4mZ3Q7PGJyPiZndDsgUGV0ZXI8YnI+Jmd0Ozxicj4m Z3Q7IC0gLS08YnI+Jmd0OyBQZXRlciBTYWludC1BbmRyZTxicj4mZ3Q7IEphYmJlciBTb2Z0d2Fy ZSBGb3VuZGF0aW9uPGJyPiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5qYWJiZXIub3JnL3Blb3Bs ZS9zdHBldGVyLnNodG1sIj5odHRwOi8vd3d3LmphYmJlci5vcmcvcGVvcGxlL3N0cGV0ZXIuc2h0 bWwKPC9hPjxicj4mZ3Q7PGJyPiZndDsgLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08YnI+ Jmd0OyBWZXJzaW9uOiBHbnVQRyB2MS40LjEgKERhcndpbik8YnI+Jmd0OyBDb21tZW50OiBVc2lu ZyBHbnVQRyB3aXRoIE1vemlsbGEgLSA8YSBocmVmPSJodHRwOi8vZW5pZ21haWwubW96ZGV2Lm9y ZyI+aHR0cDovL2VuaWdtYWlsLm1vemRldi5vcmc8L2E+PGJyPiZndDs8YnI+Jmd0OyBpRDhEQlFG RWJKMDBORjFSU3p5dDNOVVJBaC9HQUo5WTNiT2RTUnU4c2pMN2ZRSlJ5UEsyZ1Q4bGF3Q2doclBa Cjxicj4mZ3Q7IG9SNnZSTGVkNGFkdzBhNnNzZ0p2TzJNPTxicj4mZ3Q7ID1CYi96PGJyPiZndDsg LS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tPGJyPiZndDs8YnI+PGJyPjwvYmxvY2txdW90ZT48 L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5N LiBEYXZpZCBQZXRlcnNvbjxicj48YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iPgpo dHRwOi8vd3d3LnhzbHRibG9nLmNvbS88L2E+Cg== ------=_Part_142162_9189245.1148026608339-- From owner-atom-syntax@mail.imc.org Fri May 19 05:23:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Co-0001Ks-Pq for atompub-archive@lists.ietf.org; Fri, 19 May 2006 05:23:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh1Cn-000732-Dy for atompub-archive@lists.ietf.org; Fri, 19 May 2006 05:23:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J968Ch053195; Fri, 19 May 2006 02:06:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J968g9053194; Fri, 19 May 2006 02:06:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J9675T053180 for ; Fri, 19 May 2006 02:06:07 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so798557pyf for ; Fri, 19 May 2006 02:06:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e1t69Mue1f9030ykHLhaVrAt5iFuMWddrd0U20kOmJzff82nA7JQwuVUPVFOv6+HWRMsK4glHxxUQsahiGje+g50PctSHLXDeZvSQoeJ9Kmde5zRfJ/ubYGOKLQQXLRyELI2girP59T3ByelKvAdR+QnIkY+k0ob0ULKivAQNhA= Received: by 10.35.112.3 with SMTP id p3mr1677010pym; Fri, 19 May 2006 02:06:06 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Fri, 19 May 2006 02:06:06 -0700 (PDT) Message-ID: <68fba5c50605190206wae820f9n773a35ce69f2560a@mail.gmail.com> Date: Fri, 19 May 2006 11:06:06 +0200 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Feed Thread in Last Call Cc: "James M Snell" , "David Powell" , atom-syntax In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4J9675T053187 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 5/19/06, Lisa Dusseault wrote: > > Am I missing something in the case against the choice of location for > the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in implementations who won't parse them. I think I've made that extremely clear. The previous draft addressed my concerns. My current plan is to implement the threading element, but I'll recommend against accepting bug reports on the other aspects of the document, since I think it's an underspecified mess. Kind of silly considering the clear lessons from earlier efforts, but the threading element is good enough. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Fri May 19 05:55:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1ho-0006CO-Ha for atompub-archive@lists.ietf.org; Fri, 19 May 2006 05:55:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh1hl-0000YB-VB for atompub-archive@lists.ietf.org; Fri, 19 May 2006 05:55:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J9huxN061472; Fri, 19 May 2006 02:43:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4J9huts061471; Fri, 19 May 2006 02:43:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4J9hrDq061455 for ; Fri, 19 May 2006 02:43:55 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1Fh1WS-0006Hv-8S; Fri, 19 May 2006 11:43:52 +0200 Received: from ultra17.rbg.informatik.tu-darmstadt.de ([130.83.160.107]) by mx2.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1Fh1WS-0005hi-4q; Fri, 19 May 2006 11:43:52 +0200 Message-ID: <446D9353.9090005@rbg.informatik.tu-darmstadt.de> Date: Fri, 19 May 2006 11:43:47 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: Atom Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Lisa Dusseault wrote: > For related work, you could look at the email spam filtering stuff from > SIEVE: spamtestbis-02.txt> Thanks for the pointer. I was aware of SIEVE's Filtering Extension but didn't file it mentally as related to the Atom Rank Extension. > The similar problem is that many spam libraries already produce some > kind of linear or similar scale of severity/likelihood rating for > emails, much like existing services already provide their own scale of > post rankings. The approach SIEVE took, very roughly, was simply to > tell implementors to find some way to map their implementation's > ranking scheme to a canonical range of numerical values. A SIEVE > implementation might have one algorithm for converting SpamAssassin > rankings to the canonical scale, and a different algorithm for some > different library. Unfortunately this approach does not suit ranking entries very well; the only "canonical range" I can think of being a superset of every conceivable Ranking Scheme is xsd:decimal. Smaller sets simply won't do. (While loss of information might be acceptable when classifying spam, other ranking use cases, e.g., grades, are less tolerant to it.) Now this would essentially mean dropping the r:scheme element altogether, leaving only r:rank, which was, IIRC, a simplification suggested by Robert Sayre some time ago. But even when dropping r:scheme's capability to define a set of allowed values having an r:scheme-like element around would still be useful: - It provides a single place to specify a scheme's @significance (ascending or descending). Otherwise each and every r:rank element needs to carry its own @significance -- which is especially pointless since @significance has not significance (no pun intended) for a single ranking value; it only ever makes sense for a set of values. - Furthermore, a scheme can also have a @label attached (e.g. "Five Stars"), which might then be used in a UI, complementing r:rank's @label (e.g. "Good"). But this issue is really independent of the question whether r:scheme itself actually has the ability to restrict the rankings to {1, 2, 3, 4, 5} or not. To summarize, droppping r:scheme's datatyping capabilities might be acceptable, but dropping the concepts of Ranking Scheme and Domain is not. I would, however, like to see datatyping being included as well -- iff we can come up with a solution which can describe all the common uses cases out there! Andreas Sewe From owner-atom-syntax@mail.imc.org Fri May 19 12:03:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7RV-0003u9-Fw for atompub-archive@lists.ietf.org; Fri, 19 May 2006 12:03:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7RT-0000tE-Vz for atompub-archive@lists.ietf.org; Fri, 19 May 2006 12:03:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JFjRY7045963; Fri, 19 May 2006 08:45:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JFjRSi045962; Fri, 19 May 2006 08:45:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JFjQeR045943 for ; Fri, 19 May 2006 08:45:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so650020wra for ; Fri, 19 May 2006 08:45:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Y3FIhKC1KKQqTir5MooNc+rBwr1yZ/wj0OlmvVhLKbHfP8zwnJKMf2CQ7Kgz6Qg4TmQWiQvhvpqRUSJ9EQrcwTDcn6luJ4hjlnkt2jq7x6T44QncdR7bpjE3txV083PXSNSih22cfvdF7igOeaxu0C3lObb4uWCGn+47LpAeBF0= Received: by 10.54.116.7 with SMTP id o7mr1917561wrc; Fri, 19 May 2006 08:44:08 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 26sm1579187wra.2006.05.19.08.45.14; Fri, 19 May 2006 08:45:15 -0700 (PDT) Message-ID: <446DE808.4000804@gmail.com> Date: Fri, 19 May 2006 08:45:12 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Andreas Sewe CC: Lisa Dusseault , Atom Syntax Subject: Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long) References: <445B65D3.7060701@rbg.informatik.tu-darmstadt.de> <446D9353.9090005@rbg.informatik.tu-darmstadt.de> In-Reply-To: <446D9353.9090005@rbg.informatik.tu-darmstadt.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Andreas Sewe wrote: > > Lisa Dusseault wrote: >> For related work, you could look at the email spam filtering stuff >> from SIEVE: > spamtestbis-02.txt> > > Thanks for the pointer. I was aware of SIEVE's Filtering Extension but > didn't file it mentally as related to the Atom Rank Extension. > Yes, I had reviewed SIEVE's mechanism a while back. In fact, one of the use cases I had originally considered for feed rank is that the r:rank element could be used by syndication intermediaries to express spam rankings for feed entries... e.g. 0 25 50 100 >> The similar problem is that many spam libraries already produce some >> kind of linear or similar scale of severity/likelihood rating for >> emails, much like existing services already provide their own scale >> of post rankings. The approach SIEVE took, very roughly, was simply >> to tell implementors to find some way to map their implementation's >> ranking scheme to a canonical range of numerical values. A SIEVE >> implementation might have one algorithm for converting SpamAssassin >> rankings to the canonical scale, and a different algorithm for some >> different library. > > Unfortunately this approach does not suit ranking entries very well; the > only "canonical range" I can think of being a superset of every > conceivable Ranking Scheme is xsd:decimal. Smaller sets simply won't do. > (While loss of information might be acceptable when classifying spam, > other ranking use cases, e.g., grades, are less tolerant to it.) > Right. One of the goals for this work is to allow for as broad of a range of ranking scenarios as possible. No single c18n scheme is capable of covering such a range. >[snip] > But even when dropping r:scheme's capability to define a set of allowed > values having an r:scheme-like element around would still be useful: > > - It provides a single place to specify a scheme's @significance > (ascending or descending). Otherwise each and every r:rank element needs > to carry its own @significance -- which is especially pointless since > @significance has not significance (no pun intended) for a single > ranking value; it only ever makes sense for a set of values. > One point that I really do need to make clear in the draft is that ranks can be processed relative to ranking schemes other than what is identified in the rank element's scheme attribute. For instance, going back to the spam example, it is entirely possible that I, as a client, could define a variant of the spamtest ranking scheme that is much more restrictive in range than the generic scheme shown above. The set of entries produced by the processing the spamtest rankings against this scheme would automatically exclude all entries with a spamtest rank greater than 50. >[snip] > To summarize, droppping r:scheme's datatyping capabilities might be > acceptable, but dropping the concepts of Ranking Scheme and Domain is > not. I would, however, like to see datatyping being included as well -- > iff we can come up with a solution which can describe all the common > uses cases out there! > +1 - James From owner-atom-syntax@mail.imc.org Fri May 19 14:02:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9J6-0005hp-0R for atompub-archive@lists.ietf.org; Fri, 19 May 2006 14:02:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9J5-0000xL-C1 for atompub-archive@lists.ietf.org; Fri, 19 May 2006 14:02:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JHlsP3073535; Fri, 19 May 2006 10:47:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JHlsEV073534; Fri, 19 May 2006 10:47:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JHlrID073528 for ; Fri, 19 May 2006 10:47:54 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so674383wra for ; Fri, 19 May 2006 10:47: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:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=ObDLHXGWIpjE1gXKcvQL+9K4N6yjyYq8rzAkMbelK0Hwle2u9UvCli/LF96IAN0luXAe176cq/c6c1wvXG6pKBByMN7X1s1Wqkwvn+FKo1aRODXmsOw1bWRG3yG1cnrOTdt4F3KN9b6E7D0RhkKeZjRAj+VEju/47RQkVojrzlQ= Received: by 10.54.120.17 with SMTP id s17mr1810071wrc; Fri, 19 May 2006 10:47:53 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 12sm139575wrl.2006.05.19.10.47.51; Fri, 19 May 2006 10:47:52 -0700 (PDT) Message-ID: <446E049D.3020504@gmail.com> Date: Fri, 19 May 2006 10:47:09 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax CC: Lisa Dusseault Subject: Feed thread updates 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: X-Spam-Score: 2.3 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f All, I am preparing an update to the Feed Thread draft based on the Last-Call feedback received so far. The intent is to publish an update in time for the May 26 cut-off date that has been set for the next IETF face-to-face being held in Montreal in July. Before sending that draft off, I wanted to run a number of the proposed changes by the WG and request that folks weigh in on whether or not they think the changes appropriately address the issues raised in the recent discussions. If you do not feel the changes appropriately address the issues, if would be very helpful if you would please either list the specific issues not addressed or, better yet, propose some alternative spec text that you think would deal with the issue more appropriately. First, there is the question over the thr: attributes. To handle these concerns, I would like to insert the following: == snip == Considerations for using thr:count and thr:when The thr:count and thr:when attributes provide additional metadata about a resource linked to an Atom feed or entry using the "replies" link relation. The values are intended to make it easier for feed consumers to display basic contextual information about the thread of discussion without requiring those consumers to dereference, parse and analyze the linked resource. That said, there are a number of considerations implementors need to be aware of. First, the thr:count and thr:when attributes MUST NOT be considered to provide completely accurate information about the thread of discussion. That is, the actual total number of responses contained by the linked resource MAY differ than the number specified in the thr:count attribute. Feed publishers SHOULD make an effort to ensure that the meta is accurate. The non-authoritative nature of "external reference metadata", like the replies link attributes, is discussed in detail in section 3.3 of the W3C document "Tag Finding 12: Authoritative Metadata" . Second, the values of the thr:count and thr:when attributes are volatile. Frequent updates to the value of the attributes, or to any part of the Atom document, could have a detrimental impact on the cacheability of Atom documents using the attributes, leading to an increase in overall bandwidth consumption. Feed publishers MUST consider a change to the thr:count and thr:when attributes to be an "insignificant" update, meaning that the value of the containing feed, entry or source element's atom:updated element MUST NOT be affected by a change to the values of either of these attributes. Lastly, implementors need to be aware that while the Atom specification explicitly allows the link element to contain arbitrary extensions, the specification does not require that implementations support such extensions. Specifically, relating to the use of extensions, Atom does not define any level of mandatory conformance on the part of feed consumers beyond a requirement that implementations ignore any extension the implementation does not understand. As a result, some implementations MAY NOT be capable of fully utilizing the extensions defined by this or any specification. == snip == Regarding the thr:in-reply-to element, there was a concern raised over the optionality of the ref and href attributes and a potential for interop issues. There was also a suggestion that the spec include a comparison to the in-reply-to header defined by RFC 2822. To address these concerns, I propose making the following change: == snip == The "in-reply-to" element is used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to. The element is not unlike the references and in-reply-to email message headers defined by , with the exception that, unlike those headers, the "in-reply-to" element is required only to identify the unique identifier of a single parent resource as opposed to the listing all of the unique identifiers for each preceding resource in the thread. If the entry is a response to multiple resources, additional "in-reply-to" elements MAY be used. in-reply-to = element thr:in-reply-to { atomCommonAttributes, ref, href?, source?, type?, ( undefinedContent ) } ref = attribute ref { atomURI } href = attribute href { atomURI } type = attribute type { atomMediaType } source = attribute source { atomURI } The "ref" attribute specifies the persistent, universally unique identifier of the resource being responded to. The value MUST conform to the same construction and comparison rules as the value of the atom:id element. Though the IRI might use a dereferenceable scheme, processors MUST NOT assume it can be dereferenced. If the resource being responded to does not have a persistent, universally unique identifier, the IRI used to retrieve a representation of the resource MAY be used so long as that IRI could also be used as a valid atom:id value and so long as the "href" attribute is also specified. == snip == A concern has been raised over what it means when an feed/entry/source contains multiple replies links (e.g. are they links to alternative representations of the same set of comments, are they links to different sets of comments, etc). To address this concern, I propose adding the following statement: == snip == While Atom feed, entry and source elements MAY each contain any number of atom:link elements using the "replies" link relation, this specification assigns no significance to the presence or order of multiple replies links. Multiple replies links appearing within an atom:entry may reference alternative representations of the same set of responses, or may reference entirely distinct resources containing entirely distinct sets of responses. Processors MUST NOT assume that multiple replies links are referencing different representations of the same resource. == snip == I will also be making additional updates to the Security Considerations portion of the draft. - James From owner-atom-syntax@mail.imc.org Fri May 19 14:29:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9ie-00043P-Nh for atompub-archive@lists.ietf.org; Fri, 19 May 2006 14:29:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9id-0002Bw-BM for atompub-archive@lists.ietf.org; Fri, 19 May 2006 14:29:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JIFNlN079250; Fri, 19 May 2006 11:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JIFNQI079249; Fri, 19 May 2006 11:15:23 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JIFLK8079235 for ; Fri, 19 May 2006 11:15:22 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so679358wra for ; Fri, 19 May 2006 11:15:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nv2bKfLM39vdxjGQS4XTU0fM9wKJXNQO8eZzewYEUMPyw6MiQUV4TvLPqpH5k9OCEj2dfTtNjpFlUirsGoerAXoC7CwaQjT5sz36fojvLAt/VgLUOcRvwxye/3pR64AoqNIbfu5Pt3uN6GYD4GZ/e9imVZBQLNu5AH+gHabS3LQ= Received: by 10.54.76.1 with SMTP id y1mr2092921wra; Fri, 19 May 2006 11:15:16 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 64sm1694277wra.2006.05.19.11.15.14; Fri, 19 May 2006 11:15:15 -0700 (PDT) Message-ID: <446E0B31.2070404@gmail.com> Date: Fri, 19 May 2006 11:15:13 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed thread updates References: <446E049D.3020504@gmail.com> In-Reply-To: <446E049D.3020504@gmail.com> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I stand corrected... the cut off is *June* 26th, not *May* 26. (thanks Peter). Either way, please take a look at the changes and let me know your thoughts. - James James M Snell wrote: > All, > > I am preparing an update to the Feed Thread draft based on the Last-Call > feedback received so far. The intent is to publish an update in time > for the May 26 cut-off date that has been set for the next IETF > face-to-face being held in Montreal in July. > From owner-atom-syntax@mail.imc.org Fri May 19 15:27:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAcz-0001RE-3x for atompub-archive@lists.ietf.org; Fri, 19 May 2006 15:27:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAcx-0005mV-NC for atompub-archive@lists.ietf.org; Fri, 19 May 2006 15:27:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JJE2iA091754; Fri, 19 May 2006 12:14:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JJE22Z091753; Fri, 19 May 2006 12:14:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JJE1vp091741 for ; Fri, 19 May 2006 12:14:01 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so689798wra for ; Fri, 19 May 2006 12:14:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Vhmww0AtOBpNYKmNWgt84Z46G4fanYAzWYxUuWT7Kr/dgrke9DIksOvMg+pL1vRbt03ALjcGRWHY4iva6TCcFJr/XIrLmeq5Aenvmr+9NKiPZXtYY/0cVYwQavTIFjAiqdE/TaVYjd4I1CjltjJvQp4YvP2kLEz5+/a6/MjtpjA= Received: by 10.54.83.9 with SMTP id g9mr2185951wrb; Fri, 19 May 2006 12:14:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 6sm2013707wrl.2006.05.19.12.13.59; Fri, 19 May 2006 12:14:00 -0700 (PDT) Message-ID: <446E18F5.8070006@gmail.com> Date: Fri, 19 May 2006 12:13:57 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <68fba5c50605190206wae820f9n773a35ce69f2560a@mail.gmail.com> In-Reply-To: <68fba5c50605190206wae820f9n773a35ce69f2560a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Robert Sayre wrote: > On 5/19/06, Lisa Dusseault wrote: >> >> Am I missing something in the case against the choice of location for >> the metadata? > > Yes. That location is going to cause interoperability problems in my > implementation, because the draft leaves too much undefined, and in Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. - James From owner-atom-syntax@mail.imc.org Fri May 19 16:52:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBxm-00010O-0G for atompub-archive@lists.ietf.org; Fri, 19 May 2006 16:52:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhBxj-00053Y-Jv for atompub-archive@lists.ietf.org; Fri, 19 May 2006 16:52:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JKcsrf010463; Fri, 19 May 2006 13:38:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4JKcsQv010462; Fri, 19 May 2006 13:38:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4JKcrwr010455 for ; Fri, 19 May 2006 13:38:53 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so957496pyf for ; Fri, 19 May 2006 13:38:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TsIYjZlrZlVMrMo/BQ+g8xmx96hlAfTpeTjr4LlLz+mbjnxHASW/zDAJ3b7LnJcoa9MfUcan31CgP0MphwpQvSjf2+Dxb2/AsDXc11CvzASk68nS1Iw7Uil2xWBKnxGuz8gyHFOCUDiOdzb2aWXlki41EXpUnMfrRimn3E+2B9s= Received: by 10.35.60.15 with SMTP id n15mr2496276pyk; Fri, 19 May 2006 13:38:52 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Fri, 19 May 2006 13:38:52 -0700 (PDT) Message-ID: <68fba5c50605191338j6dcfa4f0q8169b119b2c70f6c@mail.gmail.com> Date: Fri, 19 May 2006 22:38:52 +0200 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: atom-syntax In-Reply-To: <446E18F5.8070006@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <68fba5c50605190206wae820f9n773a35ce69f2560a@mail.gmail.com> <446E18F5.8070006@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4JKcswr010456 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On 5/19/06, James M Snell wrote: > > Other than the issue with the Microsoft implementation, which has > already been thoroughly discussed, what other interop problems are you > anticipating? A clear, non-editorialized, listing of the potential > issues and the rationale for each would be most helpful. You've received several of those from me. I suggest you read your old mail, paying close attention to messages that you replied to in under 15 minutes. I have zero confidence that any technical change or compromise is possible from you, and I find interacting with you to be a giant time sink. My new policy will be to explain my problem *once*, and then I will verify that my concerns (if any) have been addressed at some later date when there is a revised document available. If my concerns aren't addressed, I will make a concerted effort to avoid writing or being responsible for maintaining any relevant functionality. -- Robert Sayre From owner-atom-syntax@mail.imc.org Fri May 19 22:36:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhHKa-0005kd-7l for atompub-archive@lists.ietf.org; Fri, 19 May 2006 22:36:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhHKY-0003BE-KB for atompub-archive@lists.ietf.org; Fri, 19 May 2006 22:36:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4K2L95J084113; Fri, 19 May 2006 19:21:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4K2L9TL084112; Fri, 19 May 2006 19:21:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4K2L7CR084085 for ; Fri, 19 May 2006 19:21:08 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2006 02:21:01 -0000 Received: from xdsl-81-173-224-22.netcologne.de (EHLO klangraum) [81.173.224.22] by mail.gmx.net (mp034) with SMTP; 20 May 2006 04:21:01 +0200 X-Authenticated: #163624 Date: Sat, 20 May 2006 04:21:02 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread updates Message-ID: <20060520022102.GQ5530@klangraum> Mail-Followup-To: atom-syntax References: <446E049D.3020504@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <446E049D.3020504@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4K2L95J084113 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Hi James, * James M Snell [2006-05-19 20:00]: > Considerations for using thr:count and thr:when I=E2=80=99d still like thr:when called thr:updated, as it follows the same semantics as atom:updated and its value is of the same type. > That is, the actual total number of responses contained by the > linked resource MAY differ than the number specified in the > thr:count attribute. Feed publishers SHOULD make an effort to > ensure that the meta is accurate. This SHOULD seems way too prescriptive. If you keep this sentence at all, I suggest changing to an informal =E2=80=9Cmay want to.=E2=80=9D > Feed publishers MUST consider a change to the thr:count and > thr:when attributes to be an "insignificant" update, meaning > that the value of the containing feed, entry or source > element's atom:updated element MUST NOT be affected by a change > to the values of either of these attributes. I would clarify this =E2=80=9Can "insignificant" update in terms of RFC 4287=E2=80=9D. However, I am not sure what this MUST buys, and more importantly, how it could be enforced. Suggesting SHOULD instead. > Lastly, implementors need to be aware that while the Atom > specification explicitly allows the > link element to contain arbitrary extensions, the specification > does not require that implementations support such extensions. This concern could be partially addressed by including an element to specify a global reply count for an entry in an atom:entry Metadata element. The cost of such an inclusion is insignificant, and there are benefits for all consumers, including those which can support the namespaced link attributes. I strongly suggest adding such an element. I am willing to draft spec language for it if you want me to. > The element is not unlike the references and in-reply-to email message > headers defined by , with the exception that= , > unlike those headers, the "in-reply-to" element is required only to > identify the unique identifier of a single parent resource as opposed t= o > the listing all of the unique identifiers for each preceding resource i= n > the thread. If the entry is a response to multiple resources, > additional "in-reply-to" elements MAY be used. This is an inaccurate description of the RFC 2822 headers. Suggest the following: The element is not unlike the references and in-reply-to email message headers defined by . However, unlike the in-reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional "in-reply-to" elements MAY be used. There is no direct equivalent to the references header, which lists the unique identifiers of each preceding message in a thread. > If the resource being responded to does not have a persistent, > universally unique identifier, the IRI used to retrieve a > representation of the resource MAY be used so long as that IRI > could also be used as a valid atom:id value and so long as the > "href" attribute is also specified. It would improve interop if multiple disparate publishers publishing a response to the same resource were led to pick the same identifier, so I suggest changing this MAY to SHOULD. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat May 20 00:40:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJG2-0005s4-9V for atompub-archive@lists.ietf.org; Sat, 20 May 2006 00:40:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJG1-0002Bu-Nx for atompub-archive@lists.ietf.org; Sat, 20 May 2006 00:40:06 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4K4QfDw011296; Fri, 19 May 2006 21:26:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4K4Qf7v011295; Fri, 19 May 2006 21:26:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4K4Qe70011287 for ; Fri, 19 May 2006 21:26:40 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so1023948pyf for ; Fri, 19 May 2006 21:26:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=g2ebtkMLkHfLRSYALyjpEZhHSg22zn+nWTKscPPw/4iPhLgJrDCDC3l0f/ClIvswovSyWcuZIR0WgICjXGJjvp18Gj12nYCNjYW/OV9aTCNS1yk6cIPSjdVHaLJpzDC2iByf+Pd+XM0mQt4fqg+174jjMjTAFoiDIimB/s+P1+A= Received: by 10.35.101.9 with SMTP id d9mr2882023pym; Fri, 19 May 2006 21:26:39 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id q71sm192518pyg.2006.05.19.21.26.38; Fri, 19 May 2006 21:26:39 -0700 (PDT) Message-ID: <446E9A7C.4020308@gmail.com> Date: Fri, 19 May 2006 21:26:36 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed thread updates References: <446E049D.3020504@gmail.com> <20060520022102.GQ5530@klangraum> In-Reply-To: <20060520022102.GQ5530@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4K4QfDw011296 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 A. Pagaltzis wrote: > Hi James, >=20 > * James M Snell [2006-05-19 20:00]: >> Considerations for using thr:count and thr:when >=20 > I=E2=80=99d still like thr:when called thr:updated, as it follows the > same semantics as atom:updated and its value is of the same type. >=20 I'm still stewing over this and haven't quite made up my mind on it yet. The only reason I'm not quite comfortable with it is that it just seems confusing have both an atom:updated and a thr:updated. >> That is, the actual total number of responses contained by the >> linked resource MAY differ than the number specified in the >> thr:count attribute. Feed publishers SHOULD make an effort to >> ensure that the meta is accurate. >=20 > This SHOULD seems way too prescriptive. If you keep this sentence > at all, I suggest changing to an informal =E2=80=9Cmay want to.=E2=80=9D >=20 "may want to" is a little too weak for me, but yes, the SHOULD is too much. Let me think about it. If I can't come up with something better, I'll use the "may want to" suggestion. >> Feed publishers MUST consider a change to the thr:count and >> thr:when attributes to be an "insignificant" update, meaning >> that the value of the containing feed, entry or source >> element's atom:updated element MUST NOT be affected by a change >> to the values of either of these attributes. >=20 > I would clarify this =E2=80=9Can "insignificant" update in terms of RFC > 4287=E2=80=9D. However, I am not sure what this MUST buys, and more > importantly, how it could be enforced. Suggesting SHOULD instead. >=20 Making this a MUST will (hopefully) reduce the likelihood false-updates for clients that don't understand FTE. That is, if I use a client that does not understand FTE and I suddenly see an entry that is marked as updated for no apparent reason, I'm likely to get quite annoyed after a while. (note that I included this after running some tests on a couple of feed readers and discovered that it is indeed quite annoying) >> Lastly, implementors need to be aware that while the Atom >> specification explicitly allows the >> link element to contain arbitrary extensions, the specification >> does not require that implementations support such extensions. >=20 > This concern could be partially addressed by including an element > to specify a global reply count for an entry in an atom:entry > Metadata element. The cost of such an inclusion is insignificant, > and there are benefits for all consumers, including those which > can support the namespaced link attributes. I strongly suggest > adding such an element. >=20 > I am willing to draft spec language for it if you want me to. >=20 Yeah, I'm still stewing over this. I've started and stopped writing a section for this about a dozen times over the last couple of days. On the one hand, it makes a lot of sense for the spec to have this. On the other, I could imagine feed reader implementors being quite pissed off that they have to support an element with identical form/function/semantics as slash:comments just so feed publishers can avoid having to declare one additional xml namespace. Also consider that even if FTE declares a 5 element, most folks are likely going to keep on using slash:comments. (I mean, heck, look at the number of Atom 1.0 feeds that are still using to indicate the category!!) The other elements/attributes in FTE don't suffer from this problem because they introduce useful new functionality/semantics while also reducing the number of xml namespaces that need to be declared. I dunno, I guess I'm not really against having the element; I'm just having a hard time getting myself to define it. >> The element is not unlike the references and in-reply-to email message >> headers defined by , with the exception tha= t, >> unlike those headers, the "in-reply-to" element is required only to >> identify the unique identifier of a single parent resource as opposed = to >> the listing all of the unique identifiers for each preceding resource = in >> the thread. If the entry is a response to multiple resources, >> additional "in-reply-to" elements MAY be used. >=20 > This is an inaccurate description of the RFC 2822 headers. > Suggest the following: >=20 > The element is not unlike the references and in-reply-to > email message headers defined by . > However, unlike the in-reply-to header, the "in-reply-to" > element is required to identify the unique identifier of only > a single parent resource. If the entry is a response to > multiple resources, additional "in-reply-to" elements MAY be > used. There is no direct equivalent to the references header, > which lists the unique identifiers of each preceding message > in a thread. >=20 Yeah, I got to thinking the same thing after I posted the note. Your text is much better. >> If the resource being responded to does not have a persistent, >> universally unique identifier, the IRI used to retrieve a >> representation of the resource MAY be used so long as that IRI >> could also be used as a valid atom:id value and so long as the >> "href" attribute is also specified. >=20 > It would improve interop if multiple disparate publishers > publishing a response to the same resource were led to pick the > same identifier, so I suggest changing this MAY to SHOULD. >=20 Good suggestion. > Regards, Thanks for taking a look - James From owner-atom-syntax@mail.imc.org Sat May 20 01:28:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhK0R-0003bF-7I for atompub-archive@lists.ietf.org; Sat, 20 May 2006 01:28:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhK0O-0005ta-L3 for atompub-archive@lists.ietf.org; Sat, 20 May 2006 01:28:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4K5Ci57021211; Fri, 19 May 2006 22:12:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4K5Cij1021210; Fri, 19 May 2006 22:12:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4K5CgRJ021186 for ; Fri, 19 May 2006 22:12:43 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 20 May 2006 05:12:36 -0000 Received: from xdsl-213-196-255-138.netcologne.de (EHLO klangraum) [213.196.255.138] by mail.gmx.net (mp017) with SMTP; 20 May 2006 07:12:36 +0200 X-Authenticated: #163624 Date: Sat, 20 May 2006 07:12:37 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Feed thread updates Message-ID: <20060520051237.GS5530@klangraum> Mail-Followup-To: atom-syntax References: <446E049D.3020504@gmail.com> <20060520022102.GQ5530@klangraum> <446E9A7C.4020308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <446E9A7C.4020308@gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4K5Ci57021211 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a * James M Snell [2006-05-20 06:40]: > A. Pagaltzis wrote: > > I=E2=80=99d still like thr:when called thr:updated, as it follows the > > same semantics as atom:updated and its value is of the same > > type. >=20 > I'm still stewing over this and haven't quite made up my mind > on it yet. The only reason I'm not quite comfortable with it is > that it just seems confusing have both an atom:updated and a > thr:updated. How so? I honestly can=E2=80=99t follow that. Explain? > >> That is, the actual total number of responses contained by > >> the linked resource MAY differ than the number specified in > >> the thr:count attribute. Feed publishers SHOULD make an > >> effort to ensure that the meta is accurate. > >=20 > > This SHOULD seems way too prescriptive. If you keep this > > sentence at all, I suggest changing to an informal =E2=80=9Cmay want > > to.=E2=80=9D >=20 > "may want to" is a little too weak for me, but yes, the SHOULD > is too much. Let me think about it. If I can't come up with > something better, I'll use the "may want to" suggestion. Oh wait. I was bewildered because I read it as =E2=80=9CFeed aggregators=E2= =80=9D rather than =E2=80=9CFeed publishers.=E2=80=9D Sorry! Comment retracted, = the SHOULD is perfectly appropriate. > >> Feed publishers MUST consider a change to the thr:count and > >> thr:when attributes to be an "insignificant" update, meaning > >> that the value of the containing feed, entry or source > >> element's atom:updated element MUST NOT be affected by a > >> change to the values of either of these attributes. > >=20 > > I would clarify this =E2=80=9Can "insignificant" update in terms of > > RFC 4287=E2=80=9D. However, I am not sure what this MUST buys, and > > more importantly, how it could be enforced. Suggesting SHOULD > > instead. >=20 > Making this a MUST will (hopefully) reduce the likelihood > false-updates for clients that don't understand FTE. That is, > if I use a client that does not understand FTE and I suddenly > see an entry that is marked as updated for no apparent reason, > I'm likely to get quite annoyed after a while. >=20 > (note that I included this after running some tests on a couple > of feed readers and discovered that it is indeed quite > annoying) That means it falls into the =E2=80=9Ccompliance cannot reasonably be tested but non-compliance is likely to cause interop problems=E2=80=9D bucket, which is exactly when a SHOULD is appropriate. > > This concern could be partially addressed by including an > > element to specify a global reply count for an entry in an > > atom:entry Metadata element. >=20 > [=E2=80=A6] I could imagine feed reader implementors being quite pissed > off that they have to support an element with identical > form/function/semantics as slash:comments just so feed > publishers can avoid having to declare one additional xml > namespace. I dunno; it seems like a drop in the bucket compared to the rest of the spec, and if they=E2=80=99ve already implemented slash:comments semantics it seems like the effort to support an equivalent element in another extension is minimal. > Also consider that even if FTE declares a > 5 element, most folks are likely going > to keep on using slash:comments. (I mean, heck, look at the > number of Atom 1.0 feeds that are still using to > indicate the category!!) If they were previously already using it, sure. I=E2=80=99m willing to bet money that next to noone who implemented Atom 1.0 support from scratch is doing that, though. Rather, I=E2=80=99d posit that these are (nearly?) all template-based Atom 0.3 implementations that were upgraded to Atom 1.0 with minimum effort. I believe that those who come to Atom 1.0 with a clean slate benefit from the inclusion of a native atom:category element, and likewise those who come to the FTE with a clean slate will benefit from the inclusion of a native atom:entry Metadata element equivalent to slash:comments. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Sat May 20 12:04:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhTw7-0003Yh-FM for atompub-archive@lists.ietf.org; Sat, 20 May 2006 12:04:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhTw2-0000yo-Gk for atompub-archive@lists.ietf.org; Sat, 20 May 2006 12:04:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4KFnrvV065619; Sat, 20 May 2006 08:49:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4KFnrVm065618; Sat, 20 May 2006 08:49:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4KFnoH2065579 for ; Sat, 20 May 2006 08:49:52 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060520154944.XTCW29343.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Sat, 20 May 2006 16:49:44 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20060520154944.NQHY19763.aamtaout01-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Sat, 20 May 2006 16:49:44 +0100 Date: Sat, 20 May 2006 16:49:42 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1711287765.20060520164942@djpowell.net> To: Lisa Dusseault CC: atom-syntax Subject: Re: Feed Thread in Last Call In-Reply-To: References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Friday, May 19, 2006, 1:40:43 AM, Lisa Dusseault wrote: > I've been trying to understand if there's a technical problem with > the draft's chosen placement of the attributes and the best case > I've seen is that "that location is technically disallowed by > RFC4287" , an assertion which is disputed (alas, natural language > meanings are often disputed). Hmm, that wasn't my argument either... I fully agree that the attributes are technically allowed by both the text and RelaxNG of RFC4287. I don't think anyone is disputing that. Sorry for repeating myself again, but I'll recap my argument in full because it seems like it hasn't been understood. A bit of background: Modelling ========= Software that deals with XML such as an XHTML document, doesn't have much choice but to model the document using generic XML concepts and tools - Infosets, DOM, SAX, strings containing XML tags, etc. For Atom though, it is useful to model feeds and entries in terms of some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF, but that is a dirty word around these parts). Some of the reasons for this are: Most Atom implementations are concerned with the combined state of a feed over time, not the state of an individual feed document, so pure XML access is inadequate. More robust, and efficient implementations, particularly in the case of RDBMS. Implementations may be built upon existing systems, such as existing content management systems, where a mapping between Atom the XML syntax, and the entities in an existing system would need to be established. Even the best XML APIs are horrible to use when compared to domain specific APIs. Extensions ========== Atom standardised a minimal set of elements, with the expectation that any other elements would be created as extensions. It is therefore important that Atom infrastructure shouldn't get in the way of the deployment of extensions. Atom uses mustIgnore semantics for extensions, which allows implementations to copy-through extensions even if they don't understand their purpose. Section 6 of RFC4287 is flawed. It is an ugly mix of my (overly) strict PaceExtensionConstruct proposal[1], and an (overly) liberal philosophy that the existence of foreign markup anywhere won't break implementations, so shouldn't be disallowed. [1] http://www.intertwingly.net/wiki/pie/PaceExtensionConstruct?action=recall&date=1105566248 I complained about it here[2], admittedly a long time after IETF last call, but as we were still making Atom 101 changes about then (eg: let's allow multiple authors), maybe that wasn't so unreasonable. It doesn't make any sense to define two very precise classes of extension element, and then say that any extra markup can go anywhere, without giving any justification or explanation to why we did this, or any guidelines to why extension authors should pick each of these options. [2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html Unfortunately Simple Extension elements are too unconstrained to fulfil their original objective, so the difference between them and Structured Extensions is academic. The intent was that Simple Extensions were a class of extension whose values were context-free strings that would be easy to implement, and easy to provide UIs for, and extension proposers might be encouraged to choose this class of extension where it was appropriate for improved interoperability. I don't think that this worked out. The difference between extension elements, and foreign attributes is significant however. atompub's charter states: > Atom consists of: > * A conceptual model of a resource > * A concrete syntax for this model Extension elements are defined to have both a model and a syntax, but Atom's allowance for foreign attributes to appear anywhere is a case of syntax that has no corresponding model. Atom doesn't really explain what foreign attributes are intended for. It seems like they could be an extension point, but given that many implementations will have an application model that isn't based on the XML Infoset (as described above), it seems very unwise to create an extension proposal which depends on the precise syntax of an element being preserved. The intent of Simple Extensions was to provide a class of extension that was more interoperable; foreign attributes appear to provide a class of extension (if that is what it is) that will be much less interoperable. Some guidance in how to design extensions is definitely missing from the RFC, perhaps an Informational RFC explaining the issues would be appropriate. Relevance of intermediaries =========================== Most of these issues only apply to Atom intermediaries: agents which much accept Atom documents, and represent the documents internally without losing information. It doesn't matter if a desktop aggregator drops extensions if it has no UI for displaying them anyway. But I think that the class of Atom intermediaries will become larger, and more important: All implementations of Atom Publishing Protocol are Atom intermediaries. Value-added feed services, such as FeedBurner. Microsoft's Feed Platform As soon as a desktop aggregator allows plugins for display and processing of extensions, it becomes an intermediary. Behaviour of intermediaries =========================== Atom makes no attempt to standardise the behaviour of intermediaries. A feed store can strip extensions, contributors, or everything but mandatory elements; it can even mutate these core elements - it is just a "quality of implementation" issue. For blogging applications this is acceptable, for web-service-like implementations, perhaps some conformance levels for the preservation of markup might be useful in future. The lack of standardisation is not necessarily a bad thing, implementations are free to implement what is appropriate to their requirements - if implementations were required to preserve everything perfectly it would massively raise the cost of integrating Atom with existing systems. Publishers (and especially the proposers of extensions), need to be mindful of the varying support of implementations: As an extension proposal makes greater requirements on software, the chances of information loss, and interop problems increases. Especially considering as scenario such as using an off-line blog editor, talking to an Atom Protocol Server, providing a feed via FeedBurner, to an application running on top of Microsoft's Feed Engine. It becomes important to be conservative with the use of so many unstandardised components. Anyway the conclusions I take from all of this are: Foreign attributes are bad, and are inherently less interoperable than Extension Elements. Interoperability should take priority of concerns that 'approach X looks better than Y', and other unjustifiable minor concerns. It is a bad precedent for the first IETF approved extension to rely on such a fragile part of RFC4287. Some sort of BCP for extension proposers would be useful to explain the issues. Perhaps foreign attributes could be clarified as being a 3rd class of extension and reincorporated into the Atom model, with the disclaimer that they are less interoperable than Simple & Structured Extensions? -- Dave From owner-atom-syntax@mail.imc.org Sat May 20 13:03:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhUrD-0002ZH-FZ for atompub-archive@lists.ietf.org; Sat, 20 May 2006 13:03:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhUrB-0004VW-1V for atompub-archive@lists.ietf.org; Sat, 20 May 2006 13:03:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4KGoFrq079005; Sat, 20 May 2006 09:50:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4KGoFxF079004; Sat, 20 May 2006 09:50:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4KGoEf3078997 for ; Sat, 20 May 2006 09:50:14 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 69so865657wra for ; Sat, 20 May 2006 09:50:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=a7oWAdZdPItObJZiGFEHTRL+R+FogVjMiPp89QgtHFi29Ad5YqThElpmjXFO9ndN1Cn21HERj7r2rQ9jrH/MNyenC7VESGenwaJu4rmeKNCIUMIXHDSw/nv8TQblqcYmnBSZ7ngMVCMIxTH7lMK/i+sgPLanbg0nBG7Df/lY+cM= Received: by 10.54.139.3 with SMTP id m3mr2197634wrd; Sat, 20 May 2006 09:50:13 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 13sm4090738wrl.2006.05.20.09.50.11; Sat, 20 May 2006 09:50:12 -0700 (PDT) Message-ID: <446F48BA.6080400@gmail.com> Date: Sat, 20 May 2006 09:50:02 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed thread updates References: <446E049D.3020504@gmail.com> <20060520022102.GQ5530@klangraum> <446E9A7C.4020308@gmail.com> <20060520051237.GS5530@klangraum> In-Reply-To: <20060520051237.GS5530@klangraum> Content-Type: text/plain; charset=UTF-8 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4KGoFrq079005 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 A. Pagaltzis wrote: > * James M Snell [2006-05-20 06:40]: >> A. Pagaltzis wrote: >>> I=E2=80=99d still like thr:when called thr:updated, as it follows the >>> same semantics as atom:updated and its value is of the same >>> type. >> I'm still stewing over this and haven't quite made up my mind >> on it yet. The only reason I'm not quite comfortable with it is >> that it just seems confusing have both an atom:updated and a >> thr:updated. >=20 > How so? I honestly can=E2=80=99t follow that. Explain? >=20 Two different things with the same name can lead to confusion... I dunno, I guess it boils down to just a personal preference. >[snip] >> "may want to" is a little too weak for me, but yes, the SHOULD >> is too much. Let me think about it. If I can't come up with >> something better, I'll use the "may want to" suggestion. >=20 > Oh wait. I was bewildered because I read it as =E2=80=9CFeed aggregator= s=E2=80=9D > rather than =E2=80=9CFeed publishers.=E2=80=9D Sorry! Comment retracted= , the > SHOULD is perfectly appropriate. >=20 :-) >[snip] >> Making this a MUST will (hopefully) reduce the likelihood >> false-updates for clients that don't understand FTE. That is, >> if I use a client that does not understand FTE and I suddenly >> see an entry that is marked as updated for no apparent reason, >> I'm likely to get quite annoyed after a while. >> >> (note that I included this after running some tests on a couple >> of feed readers and discovered that it is indeed quite >> annoying) >=20 > That means it falls into the =E2=80=9Ccompliance cannot reasonably be > tested but non-compliance is likely to cause interop problems=E2=80=9D > bucket, which is exactly when a SHOULD is appropriate. >=20 Ok, that's fine. SHOULD gets the point across. >[snip] > I dunno; it seems like a drop in the bucket compared to the rest > of the spec, and if they=E2=80=99ve already implemented slash:comments > semantics it seems like the effort to support an equivalent > element in another extension is minimal. >[snip]=20 >=20 > If they were previously already using it, sure. I=E2=80=99m willing to > bet money that next to noone who implemented Atom 1.0 support > from scratch is doing that, though. Rather, I=E2=80=99d posit that thes= e > are (nearly?) all template-based Atom 0.3 implementations that > were upgraded to Atom 1.0 with minimum effort. >=20 > I believe that those who come to Atom 1.0 with a clean slate > benefit from the inclusion of a native atom:category element, and > likewise those who come to the FTE with a clean slate will > benefit from the inclusion of a native atom:entry Metadata > element equivalent to slash:comments. >=20 I wish I shared your optimism :-) ... if you want to draft up some text, I'll include it. - James From owner-atom-syntax@mail.imc.org Mon May 22 06:20:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7WF-0006v7-Ku for atompub-archive@lists.ietf.org; Mon, 22 May 2006 06:20:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi7WE-0000DF-6r for atompub-archive@lists.ietf.org; Mon, 22 May 2006 06:20:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MA1Geo013436; Mon, 22 May 2006 03:01:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4MA1G6p013435; Mon, 22 May 2006 03:01:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from codanova.cust.azuria.net (codanova.cust.azuria.net [62.233.33.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MA1Ed4013429 for ; Mon, 22 May 2006 03:01:15 -0700 (MST) (envelope-from cedric@over-blog.com) Received: from ip-13.net-81-220-87.toulouse.rev.numericable.fr ([81.220.87.13]:39662) by codanova.cust.azuria.net with esmtpa (Exim 4.44) id 1Fi7Du-0004ue-Do; Mon, 22 May 2006 12:01:14 +0200 From: cedric Reply-To: cedric@over-blog.com Organization: Over Blog To: "A. Pagaltzis" Subject: Re: Feed thread updates Date: Mon, 22 May 2006 12:01:10 +0200 User-Agent: KMail/1.9.1 Cc: atom-syntax References: <446E049D.3020504@gmail.com> <20060520022102.GQ5530@klangraum> In-Reply-To: <20060520022102.GQ5530@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200605221201.10675.cedric@over-blog.com> X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4MA1Fd4013430 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4MA1Geo013436 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Le Samedi 20 Mai 2006 04:21, A. Pagaltzis a =C3=A9crit=C2=A0: >=20 > Hi James, >=20 > * James M Snell [2006-05-19 20:00]: > > Considerations for using thr:count and thr:when >=20 > I=E2=80=99d still like thr:when called thr:updated, as it follows the > same semantics as atom:updated and its value is of the same type. +1 >=20 > > That is, the actual total number of responses contained by the > > linked resource MAY differ than the number specified in the > > thr:count attribute. Feed publishers SHOULD make an effort to > > ensure that the meta is accurate. >=20 > This SHOULD seems way too prescriptive. If you keep this sentence > at all, I suggest changing to an informal =E2=80=9Cmay want to.=E2=80=9D >=20 > > Feed publishers MUST consider a change to the thr:count and > > thr:when attributes to be an "insignificant" update, meaning > > that the value of the containing feed, entry or source > > element's atom:updated element MUST NOT be affected by a change > > to the values of either of these attributes. >=20 > I would clarify this =E2=80=9Can "insignificant" update in terms of RFC > 4287=E2=80=9D. However, I am not sure what this MUST buys, and more > importantly, how it could be enforced. Suggesting SHOULD instead. >=20 > > Lastly, implementors need to be aware that while the Atom > > specification explicitly allows the > > link element to contain arbitrary extensions, the specification > > does not require that implementations support such extensions. >=20 > This concern could be partially addressed by including an element > to specify a global reply count for an entry in an atom:entry > Metadata element. The cost of such an inclusion is insignificant, > and there are benefits for all consumers, including those which > can support the namespaced link attributes. I strongly suggest > adding such an element. >=20 > I am willing to draft spec language for it if you want me to. >=20 > > The element is not unlike the references and in-reply-to email messag= e > > headers defined by , with the exception th= at, > > unlike those headers, the "in-reply-to" element is required only to > > identify the unique identifier of a single parent resource as opposed= to > > the listing all of the unique identifiers for each preceding resource= in > > the thread. If the entry is a response to multiple resources, > > additional "in-reply-to" elements MAY be used. >=20 > This is an inaccurate description of the RFC 2822 headers. > Suggest the following: >=20 > The element is not unlike the references and in-reply-to > email message headers defined by . > However, unlike the in-reply-to header, the "in-reply-to" > element is required to identify the unique identifier of only > a single parent resource. If the entry is a response to > multiple resources, additional "in-reply-to" elements MAY be > used. There is no direct equivalent to the references header, > which lists the unique identifiers of each preceding message > in a thread. >=20 > > If the resource being responded to does not have a persistent, > > universally unique identifier, the IRI used to retrieve a > > representation of the resource MAY be used so long as that IRI > > could also be used as a valid atom:id value and so long as the > > "href" attribute is also specified. >=20 > It would improve interop if multiple disparate publishers > publishing a response to the same resource were led to pick the > same identifier, so I suggest changing this MAY to SHOULD. >=20 > Regards, From owner-atom-syntax@mail.imc.org Mon May 22 18:20:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIlP-00045D-Uo for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:20:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIlK-0001Fp-HN for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:20:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MLxHBn068299; Mon, 22 May 2006 14:59:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4MLxHKW068298; Mon, 22 May 2006 14:59:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MLxHZX068291 for ; Mon, 22 May 2006 14:59:17 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i34so1213902wra for ; Mon, 22 May 2006 14:59:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=B5lbIehQ//G+AJopqqbkpGjMR8ToHhxhk4ySM96Fh2Gt1peHnmnrqwejkxIQs+JPEUZTN29LX7+SNrNQSjX1MHewcOB1RJGSNgKctrA+8f9vbhvO7vyLARpLMOHmubZnyxrL7ry8ISNSzPkFeMX44yiND8wzeEHQHz3PHsbXEi4= Received: by 10.54.76.1 with SMTP id y1mr5219547wra; Mon, 22 May 2006 14:59:16 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 11sm4163524wrl.2006.05.22.14.59.15; Mon, 22 May 2006 14:59:16 -0700 (PDT) Message-ID: <44723430.1050606@gmail.com> Date: Mon, 22 May 2006 14:59:12 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Fyi, Apache project proposal 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Just an FYI, http://wiki.apache.org/incubator/AriProposal http://www.snellspace.com/wp/?p=323 http://www.snellspace.com/public/ari.tar.gz We are proposing the creation of an Atom Reference Implementation project at Apache and have donated source to kick things off. Currently the source fully implements RFC4287 and includes preliminary support for parsing APP introspection documents and the Feed Thread Extensions. Coming soon is APP client and server code. The goal of the project is to provide a feature-complete reference implementation of the syntax and protocol specs along with any standardized extensions. The proposal is currently being reviewed by the Incubator PMC and has not yet been approved. - James From owner-atom-syntax@mail.imc.org Mon May 22 18:27:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIs0-0003Mf-VN for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:27:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIrs-0001qO-HP for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:27:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MM99if069893; Mon, 22 May 2006 15:09:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4MM99tu069892; Mon, 22 May 2006 15:09:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from netc-relay-2m.netcourrier.com (netc-relay-2m.netcourrier.com [194.158.104.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MM8wqX069842 for ; Mon, 22 May 2006 15:09:08 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-4m.netcourrier.com [194.158.104.104]) by netc-relay-2m.netcourrier.com (Postfix) with SMTP id 350D7B1CD for ; Tue, 23 May 2006 00:08:51 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-4m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: [RFC 4287] uri of atom:category element Date: Tue, 23 May 2006 00:08:51 +0200 Mime-Version: 1.0 X-Mailer: Medianet/v2.0 Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4MM99qX069887 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hello, Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287 (avaible in http://www.ietf.org/rfc/rfc4287.txt ) > 4.2.2. The "atom:category" Element > > The "atom:category" element conveys information about a category > associated with an entry or feed. This specification assigns no > meaning to the content (if any) of this element. > > atomCategory = > element atom:category { > atomCommonAttributes, > attribute term { text }, > attribute scheme { atomUri }?, > attribute label { text }?, > undefinedContent > } > The section 4.2.2 does not indicate how to indicate the uri/iri of the atom:category, or an/one uri/iri where i can find info about the atom:category or more detailled than le label attribut, possibly html content with html link to other entry with/of this category, by example "http://www.tbray.org/ongoing/What/Technology/Web/" . Some feed that i have read use the two attributes atom:scheme and atom:term in the way that, if you catenate the two, you obtain the uri/iri of the category (by example "" in http://www.tbray.org/ongoing/ongoing.atom . But the spec (rfc 4287 section 4.2.2) does not give an uri or href attribute wich explicitly contain the uri of the category, neither it (the spec) say that in concatenate the two attributes scheme and term you can go to the uri and that feed generator/editor must ensure that the string scheme + term is a valid uri and is the rui of the uri of the category. Could you explain if there is a standardized way to fin the uri of the category, an give piece of information about mandatory feature of sheme and term ? Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? If it is a forbiden method, will you add an atom:href or atom:uri attribute to the atom:category element ? From owner-atom-syntax@mail.imc.org Mon May 22 18:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJ78-000251-Bq for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:43:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJ75-00033H-Vb for atompub-archive@lists.ietf.org; Mon, 22 May 2006 18:43:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MMQmt1073683; Mon, 22 May 2006 15:26:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4MMQmp6073682; Mon, 22 May 2006 15:26:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MMQlOO073674 for ; Mon, 22 May 2006 15:26:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 69so1218480wra for ; Mon, 22 May 2006 15:26: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:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dV5PdfQhCAwbPgtsNNYDY80sn10uk/YDFvOdcQPmjTneioysx8litgmSvdDIPugc/1xsHA2eYxvZDuriVqY9Df3rIVyJ/0Xj8twtL0U5/ZG89qkR2qzQ46mzYHeaqN8wRQG0ihLR14N4XbJ/eXbEKOTdzRkrC3B52vWN8vIYa00= Received: by 10.54.128.11 with SMTP id a11mr4376606wrd; Mon, 22 May 2006 15:26:47 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 15sm1788134wrl.2006.05.22.15.26.45; Mon, 22 May 2006 15:26:46 -0700 (PDT) Message-ID: <44723AA3.4070107@gmail.com> Date: Mon, 22 May 2006 15:26:43 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: [RFC 4287] uri of atom:category element References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Nicolas Krebs wrote: >[snip] > Could you explain if there is a standardized way to fin the uri of the category, > an give piece of information about mandatory feature of sheme and term ? There is no standardized way of referencing a URI for a category. > Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? This depends on the "scheme". The "scheme" attribute basically specifies how to interpret the term. In the case of Tim Bray's Atom feed, Tim has defined his own scheme, which has the unwritten rule that scheme+term = dereferenceable category URI. Other schemes may use a similar approach, but not all. For example, it would be possible for someone to create a new scheme that dictates that the term MUST be a dereferenceable URI. Some schemes may not have any form of dereferenceable API associated (e.g. Google Data's scheme used to identify the entry type) > If it is a forbiden method, will you add an atom:href or atom:uri attribute > to the atom:category element ? > > I brought up the possibility of an @href attribute on category a while back and didn't get a very positive response. - James From owner-atom-syntax@mail.imc.org Mon May 22 19:12:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJZF-0001EJ-39 for atompub-archive@lists.ietf.org; Mon, 22 May 2006 19:12:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJZC-0003z7-LA for atompub-archive@lists.ietf.org; Mon, 22 May 2006 19:12:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MMsfnY079934; Mon, 22 May 2006 15:54:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4MMsfFD079932; Mon, 22 May 2006 15:54:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4MMse9R079914 for ; Mon, 22 May 2006 15:54:40 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id s1so879520nze for ; Mon, 22 May 2006 15:54:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L3d52gJoXZRfwlN50bg8SLDl6Vl3TXI5zR8K8Qi0ZvYkAxcrwnYu319WetZvTf3fjTb7Q8z8e39+wam2CS6KIbGIRVNZl9QcCmxzRWPESyJuHs8OPEJaLtPp2fXF9KDsgW2ZPnySFOSp7+ElfCJHwTqOZ6OMZJvrA6V5fM5QClE= Received: by 10.36.20.2 with SMTP id 2mr5679173nzt; Mon, 22 May 2006 15:54:40 -0700 (PDT) Received: by 10.36.178.15 with HTTP; Mon, 22 May 2006 15:54:39 -0700 (PDT) Message-ID: Date: Tue, 23 May 2006 00:54:39 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: [RFC 4287] uri of atom:category element In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k4MMsf9R079915 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4MMsfnY079934 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 2006/5/23, Nicolas Krebs : > Could you explain if there is a standardized way to fin the uri of the = category, There isn't. > an give piece of information about mandatory feature of sheme and term = ? There isn't either. > Is concatenation(shme, term) a wrong/good/allowed/mandatory method ? wrong (because not aknowledged by the spec), allowed (because not explicitly forbidden). > If it is a forbiden method, will you add an atom:href or atom:uri attri= bute > to the atom:category element ? I'm not aware of any plan to do so. However, you might want to make up an extension. In this case, try to avoid using foreign attributes on the atom:category element or you'll run into the same problems James in fighting wrt his Fead Thread Extension [1]. The problem is that, as atom:category isn't listed in section 6.4 as containing Metadata Elements, there's no explicit request for processors to surface any extension to atom:category in their model representation, so they might just be discarded. IMO, the Simplest Thing That Could Possibily Work is to define a new link relation, say "category", and use atom:link elements to link to "category-related" resources. The drawback is that those atom:link elements won't be associated in any way to the atom:category elements, so aggregators/readers won't be able, for example, to list categories with links on the one where an "href" is provided, all they could do then is to list categories extracted from the atom:category elements and list "category links" extracted from the atom:link elements with rel=3D"category", as two completely distinct sets. So finally, maybe a attribute or child-element -based extension might be better... On the rationale side, I suspect you want to link to an HTML page listing entries associated with the given category? First, I think this is a too specific case for a "generic" @href. I also don't see the need for it: those "category HTML pages" would generally be available from the HTML representation fo the entry (which I suspect would also exist), so they're only two clicks away. What _could_ be useful eventually would be a link to a *feed* containing entries associated with the given category, and in that case I think an atom:link with a new "category" relation would be enough. But even then I suspect "category feeds" to be not so common or not so commonly used (I'm personnaly not subscribed to any "category feed" and I don't even think sites I'm subscribed to provide "category feeds"; I'd like XML.com to provide an "articles only" feed instead of their "articles and blogs" feed, but that's not a matter of categories =E2=80=93"columns" are a category for articles, and blog posts= have their own categories=E2=80=93). In conclusion: YAGNI. [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1= 0.txt --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Tue May 23 08:43:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWEs-00024s-UO for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:43:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWEr-0005r4-HW for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:43:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCUiWm051598; Tue, 23 May 2006 05:30:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NCUie7051597; Tue, 23 May 2006 05:30:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCUhGT051582 for ; Tue, 23 May 2006 05:30:43 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 2615 invoked from network); 23 May 2006 12:30:42 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 May 2006 12:30:42 -0000 Message-ID: <44730027.8070502@metalab.unc.edu> Date: Tue, 23 May 2006 08:29:27 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: James M Snell CC: atom-syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> In-Reply-To: <44723430.1050606@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NCUiWm051598 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 James M Snell wrote: > We are proposing the creation of an Atom Reference Implementation > project at Apache and have donated source to kick things off. Currentl= y > the source fully implements RFC4287 and includes preliminary support fo= r > parsing APP introspection documents and the Feed Thread Extensions. > Coming soon is APP client and server code. Could you elaborate a little more on what this actually is? For instance=20 does it include a web server? or does it sit on top of one, and if so=20 which? How would you describe this product to a programmer who is not familiar=20 with the relevant RFCs and does not know what Atom is? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ref=3Dnos= im From owner-atom-syntax@mail.imc.org Tue May 23 08:48:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWJ4-0004Vm-SR for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:48:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWJ3-00063T-Gd for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:48:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCXK2V052168; Tue, 23 May 2006 05:33:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NCXKNw052167; Tue, 23 May 2006 05:33:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCXKaK052158 for ; Tue, 23 May 2006 05:33:20 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 7768 invoked from network); 23 May 2006 12:33:19 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 May 2006 12:33:19 -0000 Message-ID: <447300C4.6060805@metalab.unc.edu> Date: Tue, 23 May 2006 08:32:04 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: James M Snell CC: atom-syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> In-Reply-To: <44723430.1050606@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NCXK2V052168 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c James M Snell wrote: > We are proposing the creation of an Atom Reference Implementation > project at Apache and have donated source to kick things off.=20 What minimum Java version are you targetting? 1.2? 1.4? 5? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ref=3Dnos= im From owner-atom-syntax@mail.imc.org Tue May 23 08:49:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWKH-0005Gi-Ns for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:49:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWKG-00066q-Am for atompub-archive@lists.ietf.org; Tue, 23 May 2006 08:49:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCWFvx051934; Tue, 23 May 2006 05:32:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NCWFsI051932; Tue, 23 May 2006 05:32:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCWEJu051921 for ; Tue, 23 May 2006 05:32:15 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 15388 invoked from network); 23 May 2006 12:32:14 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 May 2006 12:32:14 -0000 Message-ID: <44730083.2060909@metalab.unc.edu> Date: Tue, 23 May 2006 08:30:59 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: James M Snell CC: atom-syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> In-Reply-To: <44723430.1050606@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NCWFvx051934 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 James M Snell wrote: > Just an FYI, >=20 > http://wiki.apache.org/incubator/AriProposal > http://www.snellspace.com/wp/?p=3D323 > http://www.snellspace.com/public/ari.tar.gz >=20 > We are proposing the creation of an Atom Reference Implementation > project at Apache and have donated source to kick things off.=20 I'm not sure if this is the right place for comments of this nature or=20 not, but here goes. The one alarm bell that went off when i read this=20 was Woodstox. That project has a history of nonconformance to XML. Is=20 there any chance you could be convinced to throw that way in favor of a=20 more correct STAX implementation such as Sun's? --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ref=3Dnos= im From owner-atom-syntax@mail.imc.org Tue May 23 09:31:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWyh-0002lo-SF for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:31:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWyb-0007lL-6b for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:31:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDIP61062238; Tue, 23 May 2006 06:18:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NDIPWf062237; Tue, 23 May 2006 06:18:25 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDIOa0062222 for ; Tue, 23 May 2006 06:18:25 -0700 (MST) (envelope-from ugo.cei@gmail.com) Received: by wx-out-0102.google.com with SMTP id t5so317200wxc for ; Tue, 23 May 2006 06:18:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=Lb4gNLda7iqUR0s4dlio7jFgNHMZf69BJgECe+Oz+sS1S1r+a5LERiaqEQ1aA1viQWAkjlTRk7Ff8QJA6EUe3XlsZPVWe3S40/GOPhsLuKfNyKwjboxZrHP5gDqSQ5qdMjsEf6bar2m5bMawh079RPrPKrkwL4OwGJCvuMeqljw= Received: by 10.70.15.2 with SMTP id 2mr6361627wxo; Tue, 23 May 2006 06:18:24 -0700 (PDT) Received: from ?10.0.1.3? ( [87.2.152.164]) by mx.gmail.com with ESMTP id h37sm6361282wxd.2006.05.23.06.18.23; Tue, 23 May 2006 06:18:24 -0700 (PDT) In-Reply-To: <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ugo Cei Subject: Re: Fyi, Apache project proposal Date: Tue, 23 May 2006 15:18:18 +0200 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.750) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On May 23, 2006, at 2:59 PM, Sylvain Hellegouarch wrote: > It seems to be good idea to do such promotion. However I wonder why > you > have not considerated using an existing project such as demokritos [1] > which is quite well advanced. Demokritos might be quite well advanced but unfortunately Python code is not very suited for us poor souls who still have to struggle with java environments ;-) Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/ From owner-atom-syntax@mail.imc.org Tue May 23 09:53:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXJr-0001yj-Vg for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:53:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXJo-0000LI-IH for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:53:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDVxWh065907; Tue, 23 May 2006 06:31:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NDVxBs065906; Tue, 23 May 2006 06:31:59 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDVwNv065882 for ; Tue, 23 May 2006 06:31:59 -0700 (MST) (envelope-from jtauber@jtauber.com) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0DA7CD644FF for ; Tue, 23 May 2006 09:31:33 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by frontend3.internal (MEProxy); Tue, 23 May 2006 09:31:33 -0400 X-Sasl-enc: 4NanpwZJebD0hXr1MFx/O19oFVvs3YLFahZTBWfyIxPz 1148391093 Received: from [198.18.100.111] (unknown [65.91.105.130]) by mail.messagingengine.com (Postfix) with ESMTP id 36E891E64 for ; Tue, 23 May 2006 09:31:32 -0400 (EDT) In-Reply-To: <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <794CF96A-029D-48CB-BC45-6409F5DE1FAA@jtauber.com> Content-Transfer-Encoding: 7bit From: James Tauber Subject: Re: Fyi, Apache project proposal Date: Tue, 23 May 2006 09:31:30 -0400 To: atom-syntax X-Mailer: Apple Mail (2.750) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f I could certainly do with more of a critical mass of users / contributors / people-on-the-mailing-list James On 23/05/2006, at 8:59 AM, Sylvain Hellegouarch wrote: > > It seems to be good idea to do such promotion. However I wonder why > you > have not considerated using an existing project such as demokritos [1] > which is quite well advanced. > > - Sylvain > > [1] http://www.jtauber.com/demokritos > From owner-atom-syntax@mail.imc.org Tue May 23 10:31:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXuw-0001Df-6q for atompub-archive@lists.ietf.org; Tue, 23 May 2006 10:31:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXFf-0000AM-Lr for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:48:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiX6l-0007B0-1m for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:39:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDPvsP064389; Tue, 23 May 2006 06:25:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NDPvvg064388; Tue, 23 May 2006 06:25:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/nfJdFH6cMFrOS58IAxfAIL3nxqdfPAIM@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NDPtck064366 for ; Tue, 23 May 2006 06:25:56 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+8ZNXlqks3J8vjNMUdiNUcDOGxhzBiyCI@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NDPqmo004696; Tue, 23 May 2006 08:25:52 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4NDPpST004694; Tue, 23 May 2006 14:25:51 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 23 May 2006 14:25:51 +0100 (BST) Message-ID: <23739.194.221.74.7.1148390751.squirrel@mail1.python-hosting.com> In-Reply-To: References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> Date: Tue, 23 May 2006 14:25:51 +0100 (BST) Subject: Re: Fyi, Apache project proposal From: "Sylvain Hellegouarch" To: "Ugo Cei" Cc: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.1 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > Demokritos might be quite well advanced but unfortunately Python code > is not very suited for us poor souls who still have to struggle with > java environments ;-) > I guess I kind of got that as well. That being said, it will be nice of the project at some point can state exactly how it will either support other environments or at least what bridges it will offer to those, because equally to the fact Python is not suited to your needs, Java is not even on my book ;) I definitely don't want to start a language flame but I merely want to understand if that project will concern me on the long run or not. - Sylvain From owner-atom-syntax@mail.imc.org Tue May 23 10:31:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXuw-0001Dv-Co for atompub-archive@lists.ietf.org; Tue, 23 May 2006 10:31:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWvr-0007Uj-Tx for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:28:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiWg5-0006rP-RG for atompub-archive@lists.ietf.org; Tue, 23 May 2006 09:12:05 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCxOpu058172; Tue, 23 May 2006 05:59:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NCxOm0058171; Tue, 23 May 2006 05:59:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19m+4jVcJaM+irjte05W413LqNpTL7PPSU@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NCxNkU058156 for ; Tue, 23 May 2006 05:59:23 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/2qbeEeHepBC7kTqvOTH2k0eV7TXT6ug4@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NCxMFh003674; Tue, 23 May 2006 07:59:22 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4NCxLrV003671; Tue, 23 May 2006 13:59:21 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 23 May 2006 13:59:21 +0100 (BST) Message-ID: <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> In-Reply-To: <44730083.2060909@metalab.unc.edu> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> Date: Tue, 23 May 2006 13:59:21 +0100 (BST) Subject: Re: Fyi, Apache project proposal From: "Sylvain Hellegouarch" To: "Elliotte Harold" Cc: "James M Snell" , "atom-syntax" Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.5 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > > James M Snell wrote: >> Just an FYI, >> >> http://wiki.apache.org/incubator/AriProposal >> http://www.snellspace.com/wp/?p=323 >> http://www.snellspace.com/public/ari.tar.gz >> >> We are proposing the creation of an Atom Reference Implementation >> project at Apache and have donated source to kick things off. > It seems to be good idea to do such promotion. However I wonder why you have not considerated using an existing project such as demokritos [1] which is quite well advanced. - Sylvain [1] http://www.jtauber.com/demokritos From owner-atom-syntax@mail.imc.org Tue May 23 11:06:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYTA-0003ls-Ji for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:06:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYT9-0003ml-8X for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:06:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NEsAdx084842; Tue, 23 May 2006 07:54:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NEsAOf084841; Tue, 23 May 2006 07:54:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx2.verity.com (mx2.verity.com [192.187.147.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NEs7HW084799 for ; Tue, 23 May 2006 07:54:09 -0700 (MST) (envelope-from wunder@autonomy.com) Received: from VEX1.verity.com (verity-ex1 [192.168.4.151]) by latsop.verity.com (Postfix) with ESMTP id 0BEE1582; Tue, 23 May 2006 07:54:02 -0700 (PDT) Received: from mailhost.verity.com ([192.168.4.43]) by VEX1.verity.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 07:56:39 -0700 Received: from localhost (spike.verity.com [192.168.4.22]) by united.verity.com (Postfix) with ESMTP id 5F1E346D0; Tue, 23 May 2006 07:51:22 -0700 (PDT) Date: Tue, 23 May 2006 07:53:59 -0700 From: Walter Underwood To: Ugo Cei , atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal Message-ID: <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2006 14:56:39.0875 (UTC) FILETIME=[18CB3130:01C67E79] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 --On May 23, 2006 3:18:18 PM +0200 Ugo Cei wrote: > > Demokritos might be quite well advanced but unfortunately Python code is not > very suited for us poor souls who still have to struggle with java environments ;-) The goal is a reference implementation. The goal is to be exactly correct. Being in a particular language, or even being fast enough to be usable, is beside the point. In particular, a reference implementation should always choose code readability over speed. If the goal is to have a standard, free implementation that everyone uses, that is different from a reference implementation and the goals should say that. wunder -- Walter Underwood Principal Software Architect, Autonomy (Ultraseek) From owner-atom-syntax@mail.imc.org Tue May 23 11:21:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYgx-0000hC-C5 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:21:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYgw-0004MR-0l for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:21:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NF9tZa087890; Tue, 23 May 2006 08:09:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NF9tmP087889; Tue, 23 May 2006 08:09:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX19OjDbrT/Z3hP/GYTJCou5fMhbjGUFzNqI@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NF9s1b087875 for ; Tue, 23 May 2006 08:09:54 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18arN569eikFsh/VzL6GWCpQs9L83LCt10@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NF9pMJ008333; Tue, 23 May 2006 10:09:51 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4NF9p1P008329; Tue, 23 May 2006 16:09:51 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 23 May 2006 16:09:51 +0100 (BST) Message-ID: <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> In-Reply-To: <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Date: Tue, 23 May 2006 16:09:51 +0100 (BST) Subject: Re: Fyi, Apache project proposal From: "Sylvain Hellegouarch" To: "Walter Underwood" Cc: "Ugo Cei" , atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > The goal is a reference implementation. The goal is to be exactly correct. > Being in a particular language, or even being fast enough to be usable, > is beside the point. In particular, a reference implementation should > always choose code readability over speed. Fair enough. > > If the goal is to have a standard, free implementation that everyone uses, > that is different from a reference implementation and the goals should > say that. I'm sorry to ask but I'm not sure to understand the meaning of having an implementation which is exactly correct. As we have already seen on this list, RFC4287 lacks of precision in some context, therefore I wonder what being "exactly correct" represents. I believe Jigsaw [1] is a an example of what you mean. Sadly it seems to be hardly referenced anywhere. Besides, that does not really answer the question of whay not improving an existing project over starting a new one from scratch. Again, I don't really care about the fact it is built using Java or else as long as the project ensure bridges to other environment. - Sylvain From owner-atom-syntax@mail.imc.org Tue May 23 11:27:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYms-0003FH-Ry for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:27:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYmr-0004Yf-HM for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:27:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFG9xo089473; Tue, 23 May 2006 08:16:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFG9gZ089472; Tue, 23 May 2006 08:16:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1/1VEs5RKbDCVPnDmRu0QuhWJmEeiyA3M4@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFG85n089458 for ; Tue, 23 May 2006 08:16:08 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX183lz80kvLUZ0DZbMVkP7nj7hB3hM7WheA@localhost.localdomain [127.0.0.1]) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NFG78O008616 for ; Tue, 23 May 2006 10:16:07 -0500 Received: (from apache@localhost) by mail1.python-hosting.com (8.12.11.20060308/8.12.11/Submit) id k4NFG6CK008613; Tue, 23 May 2006 16:16:06 +0100 X-Authentication-Warning: mail1.python-hosting.com: apache set sender to sh@defuze.org using -f Received: from 194.221.74.7 (proxying for unknown) (SquirrelMail authenticated user platom_sylvain) by mail1.python-hosting.com with HTTP; Tue, 23 May 2006 16:16:06 +0100 (BST) Message-ID: <55789.194.221.74.7.1148397366.squirrel@mail1.python-hosting.com> In-Reply-To: <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> Date: Tue, 23 May 2006 16:16:06 +0100 (BST) Subject: Re: Fyi, Apache project proposal From: "Sylvain Hellegouarch" To: atom-syntax@imc.org Reply-To: sh@defuze.org User-Agent: SquirrelMail/1.4.6-5.el3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 > I believe Jigsaw [1] is a an example of what you mean. Jigsaw: http://www.w3.org/Jigsaw/ But you all knew that. ;) - Sylvain From owner-atom-syntax@mail.imc.org Tue May 23 11:41:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ0Z-0003jQ-4C for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:41:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZ0W-0005CM-NH for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:41:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFSCAw092197; Tue, 23 May 2006 08:28:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFSCpT092196; Tue, 23 May 2006 08:28:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFSBI0092182 for ; Tue, 23 May 2006 08:28:12 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 27985 invoked from network); 23 May 2006 15:28:11 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 May 2006 15:28:11 -0000 Message-ID: <447329BF.8080309@metalab.unc.edu> Date: Tue, 23 May 2006 11:26:55 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> In-Reply-To: <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NFSCAw092197 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Sylvain Hellegouarch wrote: > I'm sorry to ask but I'm not sure to understand the meaning of having a= n > implementation which is exactly correct. As we have already seen on thi= s > list, RFC4287 lacks of precision in some context, therefore I wonder wh= at > being "exactly correct" represents. I believe Jigsaw [1] is a an exampl= e > of what you mean. Sadly it seems to be hardly referenced anywhere. >=20 1. It finds bugs in the spec. 2. When the spec isn't clear, the answer is "what the reference=20 implementation does" Of course, this requires the reference implementation to be developed=20 with the same authority that the spec writers have. That's not at all=20 the case here, so I suspect "reference implementation" is a false=20 statement. This will not be the reference implementation, and shouldn't=20 call itself one. --=20 =EF=BB=BFElliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=3D0596527500/ref=3Dnosim/cafeaulai= tA/ From owner-atom-syntax@mail.imc.org Tue May 23 11:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ6m-0006OK-9B for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:47:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZ6j-0005Pr-TI for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:47:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZgpk093986; Tue, 23 May 2006 08:35:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFZgqQ093985; Tue, 23 May 2006 08:35:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZRck093907 for ; Tue, 23 May 2006 08:35:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1314175wra for ; Tue, 23 May 2006 08:35:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GEMpvB77aJFhcX4kbUQVeqPWs/pj0JfN2tobSAI+IRSkHw/OYRXuVvDbop9r681KzAbKZYCNe4BIAF/AQNMk7pq3I4/GvkUcZsuqfD9TIEL5OTHQrkO/pMpoMKe0ALOlvIlVef3GvNdroJe3dt5HFYD9lH3exl9CWKaarNP9o/w= Received: by 10.54.128.11 with SMTP id a11mr5165815wrd; Tue, 23 May 2006 08:35:41 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 38sm5724294wrl.2006.05.23.08.35.38; Tue, 23 May 2006 08:35:41 -0700 (PDT) Message-ID: <44732BC8.10904@gmail.com> Date: Tue, 23 May 2006 08:35:36 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 The goal is to have a reference implementation that is also usable. However, I do have to be careful here, the IETF doesn't really do reference implemenations so the naming of this project is a bit wrong. We really shouldn't be calling it a "reference implementation" although that is the kind of thing we're wanting this to be. - James Walter Underwood wrote: > > --On May 23, 2006 3:18:18 PM +0200 Ugo Cei wrote: >> >> Demokritos might be quite well advanced but unfortunately Python code >> is not >> very suited for us poor souls who still have to struggle with java >> environments ;-) > > The goal is a reference implementation. The goal is to be exactly correct. > Being in a particular language, or even being fast enough to be usable, > is beside the point. In particular, a reference implementation should > always choose code readability over speed. > > If the goal is to have a standard, free implementation that everyone uses, > that is different from a reference implementation and the goals should > say that. > > wunder > -- > Walter Underwood > Principal Software Architect, Autonomy (Ultraseek) > > From owner-atom-syntax@mail.imc.org Tue May 23 11:50:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZ9U-0007cz-Mf for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:50:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZ9T-0005Wy-9V for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:50:32 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZZnL093957; Tue, 23 May 2006 08:35:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFZZJE093956; Tue, 23 May 2006 08:35:35 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZRcj093907 for ; Tue, 23 May 2006 08:35:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1314175wra for ; Tue, 23 May 2006 08:35:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nXu/sHz1w7UYu9eBIO/E0dWJsK1NteVD9o+mCdy/YTTuwu7YA/Vta8Ngkp3ipaksIvZ5Zr+kFeAp+hev3Nqc5bhWYvkR4J1qWTA3F+M/jb9+Jd2quTtYLkJCYYTSlCaCkZJMSCJh4LkfVkWRQC02Opy74Bl9LjfrO2bweJ3laOM= Received: by 10.54.129.12 with SMTP id b12mr5146363wrd; Tue, 23 May 2006 08:35:34 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 29sm8452833wrl.2006.05.23.08.35.32; Tue, 23 May 2006 08:35:33 -0700 (PDT) Message-ID: <44732BC3.2000707@gmail.com> Date: Tue, 23 May 2006 08:35:31 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730027.8070502@metalab.unc.edu> In-Reply-To: <44730027.8070502@metalab.unc.edu> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I don't really want to get into a lot of detail here (it's not the proper forum for it). The project will provide a Java-language Atom parser, APP client, and some APP server side code with the goal of providing as complete an implementation as possible. And regarding the choice of the XML parser... again, that's not something I want to get into here. - James Elliotte Harold wrote: > James M Snell wrote: > >> We are proposing the creation of an Atom Reference Implementation >> project at Apache and have donated source to kick things off. Currently >> the source fully implements RFC4287 and includes preliminary support for >> parsing APP introspection documents and the Feed Thread Extensions. >> Coming soon is APP client and server code. > > Could you elaborate a little more on what this actually is? For instance > does it include a web server? or does it sit on top of one, and if so > which? > > How would you describe this product to a programmer who is not familiar > with the relevant RFCs and does not know what Atom is? > > From owner-atom-syntax@mail.imc.org Tue May 23 11:56:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZFb-0008C8-3K for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:56:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZFb-0005hS-1M for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:56:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiZ7u-00005Y-So for atompub-archive@lists.ietf.org; Tue, 23 May 2006 11:48:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZSdx093922; Tue, 23 May 2006 08:35:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFZS2I093921; Tue, 23 May 2006 08:35:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFZRci093907 for ; Tue, 23 May 2006 08:35:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1314175wra for ; Tue, 23 May 2006 08:35:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Gf+1RtshT4ElHacsfe6n9HkowVa5Na286ESsnTzKy3RUkQrJTquaaIlwOWw/qTKNNstaTGR5BUzKUJ2FcS//j+EcLzFRx/8v7cJ8EQ9P6VXudUdpV6RjfCcVApG0hyQZyTNViNaUGe8kTq2rPCtQ94c4E9e0pS3VCAlolZiXd60= Received: by 10.54.120.7 with SMTP id s7mr1085176wrc; Tue, 23 May 2006 08:34:15 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 40sm2763916wrl.2006.05.23.08.35.24; Tue, 23 May 2006 08:35:24 -0700 (PDT) Message-ID: <44732BBA.9060201@gmail.com> Date: Tue, 23 May 2006 08:35:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> In-Reply-To: <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.2 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 In this particular case, it means providing an implementation that allows, as closely as possible, everything that the spec allows. For instance, if you look at the code, the Link element is marked as being extensible and as allowing string content, both of which are explicitly allowed by RFC4287 via the use of the undefinedContent element. Regarding the choice of language, with any new standard, especially one like Atom, it is important to have as many implementations as possible available in as many languages as possible in order to tease out any interoperability issues and to ensure as broad a reach as possible. - James Sylvain Hellegouarch wrote: > >> The goal is a reference implementation. The goal is to be exactly correct. >> Being in a particular language, or even being fast enough to be usable, >> is beside the point. In particular, a reference implementation should >> always choose code readability over speed. > > Fair enough. > >> If the goal is to have a standard, free implementation that everyone uses, >> that is different from a reference implementation and the goals should >> say that. > > I'm sorry to ask but I'm not sure to understand the meaning of having an > implementation which is exactly correct. As we have already seen on this > list, RFC4287 lacks of precision in some context, therefore I wonder what > being "exactly correct" represents. I believe Jigsaw [1] is a an example > of what you mean. Sadly it seems to be hardly referenced anywhere. > > Besides, that does not really answer the question of whay not improving an > existing project over starting a new one from scratch. > > Again, I don't really care about the fact it is built using Java or else > as long as the project ensure bridges to other environment. > > - Sylvain > > From owner-atom-syntax@mail.imc.org Tue May 23 12:04:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZN4-00057n-GW for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:04:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZN2-0005xf-0S for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:04:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFm089096824; Tue, 23 May 2006 08:48:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFm05e096823; Tue, 23 May 2006 08:48:00 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wrk187.corp.jabber.com (corp-fw-main.jabber.com [207.182.164.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFlwdn096792 for ; Tue, 23 May 2006 08:47:59 -0700 (MST) (envelope-from stpeter@jabber.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 6D4C44E1604 for ; Tue, 23 May 2006 09:48:20 -0600 (MDT) Message-ID: <44732EC3.7050403@jabber.org> Date: Tue, 23 May 2006 09:48:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060308 Thunderbird/1.5.0.2 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Atom Syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> <447329BF.8080309@metalab.unc.edu> In-Reply-To: <447329BF.8080309@metalab.unc.edu> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050800080000040600000306" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 This is a cryptographically signed message in MIME format. --------------ms050800080000040600000306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elliotte Harold wrote: > Of course, this requires the reference implementation to be developed > with the same authority that the spec writers have. That's not at all > the case here, so I suspect "reference implementation" is a false > statement. This will not be the reference implementation, and shouldn't > call itself one. Is it ever the case (at least in the IETF context) that the developers of a reference implementation have the same authority that the spec authors have? As far as I can see, the authority of the spec authors (if there is such authority) is granted by the Internet Standards Process itself. But the Internet Standards Process talks about specifications rather than implementations, so I don't see how any developers could have the same kind of authority (even if they were the spec authors). Ergo we can never have an "authorized" reference implementation for any IETF standard. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEcy7DNF1RSzyt3NURAvV9AKC3jskTpm1t+BOLMMuPeqLA+ESroQCgneHf Ns+UVo7Y2oq3NzcoSjBueHg= =pCQa -----END PGP SIGNATURE----- --------------ms050800080000040600000306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNTIzMTU0ODE5WjAjBgkqhkiG9w0BCQQxFgQUSPFfVfJ4wMXpsFnD ZQgWLBpsf5YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAMghhdFiY3dvcB+i8I//B23V30o3BilK 6E5zLd8Q8cN5RhrE86ByX5wQY7HwrWnsO48xKSGXQxwpeyvs7Tx7llt1C++ZT2wBj5VBOcE4 f7bDWaHboZUIRR9MNoiJmAVDiZD2caj9YTKmDLf2H5bT59AZKd+EVaDIgmfW9LImxHDq30+7 cqEjwyph+X8CtzXtuHTJfzmEMXP4UcyUxDHtZecHZtHOs4k91FeG+sNtlyZFc9ae05ZfZnIa ve4lUKJBKFeEC8ThuhMX9Pk+oZKQwQZmiJzK8Hgv/j7e+jdnPoIGWD5pmE//vG7+K+mX6BWr iH/zgC7o1l77/R7CUD+WfM0AAAAAAAA= --------------ms050800080000040600000306-- From owner-atom-syntax@mail.imc.org Tue May 23 12:06:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZOj-0005ru-P5 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:06:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZOi-000607-Bg for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:06:17 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFpDCR098123; Tue, 23 May 2006 08:51:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFpDCp098122; Tue, 23 May 2006 08:51:13 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFpCw3098108 for ; Tue, 23 May 2006 08:51:13 -0700 (MST) (envelope-from ugo.cei@gmail.com) Received: by wx-out-0102.google.com with SMTP id t5so344217wxc for ; Tue, 23 May 2006 08:51:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:reply-to:content-transfer-encoding:from:subject:date:to:x-mailer; b=Il66iziOssDo96y+8rnHiejO/InNdg+KlkI2UY2QMxbX1gkcReJ2vEv5WIEqEJ+WA7GzQU6VZp+D13SwfibXV1ZK1xkhL4TWYRtWEGO1uijpv0LzcVKoZEaX7gQq5U5Vyrvp7i8vRpFgiWD5FiigPnbCoXTXJZVi6Gzapu3XrTY= Received: by 10.70.133.7 with SMTP id g7mr6550516wxd; Tue, 23 May 2006 08:51:09 -0700 (PDT) Received: from ?10.0.1.3? ( [87.2.152.164]) by mx.gmail.com with ESMTP id h37sm6510417wxd.2006.05.23.08.51.07; Tue, 23 May 2006 08:51:08 -0700 (PDT) In-Reply-To: <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Reply-To: atom-syntax@imc.org From: Ugo Cei Subject: Re: Fyi, Apache project proposal Date: Tue, 23 May 2006 17:51:03 +0200 To: atom-syntax@imc.org X-Mailer: Apple Mail (2.750) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4NFpDw3098115 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NFpDCR098123 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d at On May 23, 2006, at 4:53 PM, Walter Underwood wrote: > The goal is a reference implementation. The goal is to be exactly =20 > correct. > Being in a particular language, or even being fast enough to be =20 > usable, > is beside the point. In particular, a reference implementation should > always choose code readability over speed. > > If the goal is to have a standard, free implementation that =20 > everyone uses, > that is different from a reference implementation and the goals should > say that. Yes, sorry, I wasn't considering it from this angle. By the way, someone commented on my blog that: "ARI (or whatever it will be called) will *NOT* be a reference =20 implementation. According to Roy F, the IETF doesn=92t allow reference =20 implementations, just implementations" Ugo --=20 Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/ From owner-atom-syntax@mail.imc.org Tue May 23 12:06:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZPA-0005vn-3s for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:06:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZP5-00060N-In for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:06:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NFlWJw096712; Tue, 23 May 2006 08:47:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NFlWWd096711; Tue, 23 May 2006 08:47:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4NFlUwA096675 for ; Tue, 23 May 2006 08:47:31 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 23 May 2006 15:47:24 -0000 Received: from xdsl-81-173-175-128.netcologne.de (EHLO klangraum) [81.173.175.128] by mail.gmx.net (mp035) with SMTP; 23 May 2006 17:47:24 +0200 X-Authenticated: #163624 Date: Tue, 23 May 2006 17:47:29 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal Message-ID: <20060523154729.GY32180@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad * Sylvain Hellegouarch [2006-05-23 17:20]: > As we have already seen on this list, RFC4287 lacks of > precision in some context, therefore I wonder what being > "exactly correct" represents. Did I miss something? I remember several oversights of omission, but none of imprecision. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 23 12:23:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZfR-0003si-3l for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:23:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZfO-0006Qy-Lu for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:23:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NG8gmY002329; Tue, 23 May 2006 09:08:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NG8gWX002328; Tue, 23 May 2006 09:08:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NG8fpJ002315 for ; Tue, 23 May 2006 09:08:42 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1321339wra for ; Tue, 23 May 2006 09:08:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=e4X2/ClZ2V8YO8ogmfEj2RpUvqjisLifh4onOeiKCe+cYZRMDz3DMjHQ2xHbsH5pd5rYoIkrQFfOjnz/wjL/6exJStmT4CaeHylFKuYlKvuEy27NBUkNsj+slPtHOte7sp5eb9a9bT7BpikSxK8pYJFPyaUbGq+1hHqBAk56Mn0= Received: by 10.54.60.26 with SMTP id i26mr6080608wra; Tue, 23 May 2006 09:08:41 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 44sm5086661wri.2006.05.23.09.08.40; Tue, 23 May 2006 09:08:41 -0700 (PDT) Message-ID: <44733376.8080403@gmail.com> Date: Tue, 23 May 2006 09:08:22 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NG8gmY002329 X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 FWIW, I removed the term "reference implemenation" from the proposal to properly reflect the nature of the implementation. Ugo Cei wrote: >=20 > at > On May 23, 2006, at 4:53 PM, Walter Underwood wrote: >=20 >> The goal is a reference implementation. The goal is to be exactly >> correct. >> Being in a particular language, or even being fast enough to be usable= , >> is beside the point. In particular, a reference implementation should >> always choose code readability over speed. >> >> If the goal is to have a standard, free implementation that everyone >> uses, >> that is different from a reference implementation and the goals should >> say that. >=20 > Yes, sorry, I wasn't considering it from this angle. >=20 > By the way, someone commented on my blog that: >=20 > "ARI (or whatever it will be called) will *NOT* be a reference > implementation. According to Roy F, the IETF doesn=92t allow reference > implementations, just implementations" >=20 > >=20 > Ugo >=20 >=20 >=20 > --Ugo Cei > Blog: http://agylen.com/ > Open Source Zone: http://oszone.org/ > Evil or Not?: http://evilornot.info/ > Company: http://www.sourcesense.com/ >=20 >=20 >=20 >=20 From owner-atom-syntax@mail.imc.org Tue May 23 12:24:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZgk-0004xT-W8 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:24:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZgh-0006SL-I4 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:24:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NG5vVU001694; Tue, 23 May 2006 09:05:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NG5v2H001693; Tue, 23 May 2006 09:05:57 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NG5uAT001681 for ; Tue, 23 May 2006 09:05:56 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1320787wra for ; Tue, 23 May 2006 09:05:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ksensfh87AkZFr1wnkLrom+ZKteDfQhTdYZR7EZBBSXvaCplMwLFgxEsdMImJd3dLic/4Z08U3XdTyYBWU2ZCMl0VypIIcxyBp1DTy4p9vgVLtWmK4i8u+WmjRBBgQbUcSc7WdpT31xansUwMTSu1JlHaezltpYiju+XD9oudto= Received: by 10.54.60.26 with SMTP id i26mr6077764wra; Tue, 23 May 2006 09:05:55 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 14sm5580960wrl.2006.05.23.09.05.50; Tue, 23 May 2006 09:05:55 -0700 (PDT) Message-ID: <447332C8.2090207@gmail.com> Date: Tue, 23 May 2006 09:05:28 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> <447329BF.8080309@metalab.unc.edu> <44732EC3.7050403@jabber.org> In-Reply-To: <44732EC3.7050403@jabber.org> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Right. IETF specs cannot have an official reference implementation. The best we can do, in this case, is to have a number of implementations available that strive to a) implement the spec as completely as possible and b) interoperate with one another as best as possible. The "reference implementation" then becomes a union of everything these available alternatives seem to get right. We made a mistake calling our stuff a "reference implementation" but it was an honest one born out of frustration trying to come up with a name our lawyers would actually clear (naming the damn thing was actually holding up our ability to open source it). - James Peter Saint-Andre wrote: > Elliotte Harold wrote: > >>> Of course, this requires the reference implementation to be developed >>> with the same authority that the spec writers have. That's not at all >>> the case here, so I suspect "reference implementation" is a false >>> statement. This will not be the reference implementation, and shouldn't >>> call itself one. > > Is it ever the case (at least in the IETF context) that the developers > of a reference implementation have the same authority that the spec > authors have? As far as I can see, the authority of the spec authors (if > there is such authority) is granted by the Internet Standards Process > itself. But the Internet Standards Process talks about specifications > rather than implementations, so I don't see how any developers could > have the same kind of authority (even if they were the spec authors). > Ergo we can never have an "authorized" reference implementation for any > IETF standard. > > Peter > > -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.shtml > From owner-atom-syntax@mail.imc.org Tue May 23 12:44:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia02-0001Vm-EN for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:44:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fia01-0007IZ-2y for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:44:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NGTlIZ007077; Tue, 23 May 2006 09:29:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NGTlLG007076; Tue, 23 May 2006 09:29:47 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+grICTMzgBEXQEOrhu25RjCZbP/7KyrzI@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NGTkhp007069 for ; Tue, 23 May 2006 09:29:47 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-19-211.range81-159.btcentralplus.com [81.159.19.211]) (authenticated bits=0) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NGTdGk011280; Tue, 23 May 2006 11:29:45 -0500 Message-ID: <44733868.1030401@defuze.org> Date: Tue, 23 May 2006 17:29:28 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: James M Snell CC: Atom Syntax Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> <447329BF.8080309@metalab.unc.edu> <44732EC3.7050403@jabber.org> <447332C8.2090207@gmail.com> In-Reply-To: <447332C8.2090207@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a That sounds good to me. Please not though that I didn't care about the language, my only questions were: 1. Why not using an existing project? 2. How interoperable had you planned to be? It seems these questions have more or less been answered so I'm fine :) - Sylvain > Right. IETF specs cannot have an official reference implementation. The > best we can do, in this case, is to have a number of implementations > available that strive to a) implement the spec as completely as possible > and b) interoperate with one another as best as possible. The > "reference implementation" then becomes a union of everything these > available alternatives seem to get right. > > We made a mistake calling our stuff a "reference implementation" but it > was an honest one born out of frustration trying to come up with a name > our lawyers would actually clear (naming the damn thing was actually > holding up our ability to open source it). > > From owner-atom-syntax@mail.imc.org Tue May 23 12:49:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia46-000293-8I for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:49:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fia42-0007TY-RI for atompub-archive@lists.ietf.org; Tue, 23 May 2006 12:49:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NGVrOC007539; Tue, 23 May 2006 09:31:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NGVrPR007538; Tue, 23 May 2006 09:31:53 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NGVpho007503 for ; Tue, 23 May 2006 09:31:53 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (83-70-224-224.b-ras1.prp.dublin.eircom.net [83.70.224.224]) by chilco.textdrive.com (Postfix) with ESMTP id 91351DBDA6 for ; Tue, 23 May 2006 16:31:45 +0000 (UTC) Message-ID: <447338EE.1090200@dehora.net> Date: Tue, 23 May 2006 17:31:42 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Fyi, Apache project proposal References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <23739.194.221.74.7.1148390751.squirrel@mail1.python-hosting.com> In-Reply-To: <23739.194.221.74.7.1148390751.squirrel@mail1.python-hosting.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Sylvain Hellegouarch wrote: > >> Demokritos might be quite well advanced but unfortunately Python code >> is not very suited for us poor souls who still have to struggle with >> java environments ;-) >> > > I guess I kind of got that as well. That being said, it will be nice of > the project at some point can state exactly how it will either support > other environments or at least what bridges it will offer to those, > because equally to the fact Python is not suited to your needs, Java is > not even on my book ;) > > I definitely don't want to start a language flame but I merely want to > understand if that project will concern me on the long run or not. Dude, Rails like totally does all that already. :-) cheers Bill From owner-atom-syntax@mail.imc.org Tue May 23 15:22:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FicSI-0001so-FA for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:22:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FicSA-000694-Ts for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:22:10 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJ8LJf038930; Tue, 23 May 2006 12:08:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJ8Lgl038929; Tue, 23 May 2006 12:08:21 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJ8K0w038922 for ; Tue, 23 May 2006 12:08:20 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4NJ8IxW000958 for ; Tue, 23 May 2006 13:08:19 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZQ00501FCZE700@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 23 May 2006 13:08:18 -0600 (MDT) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZQ004EQFTTKQF0@mail-amer.sun.com>; Tue, 23 May 2006 13:08:18 -0600 (MDT) Date: Tue, 23 May 2006 12:08:18 -0700 From: Tim Bray Subject: Re: Feed Thread in Last Call In-reply-to: To: Byrne Reese Cc: James M Snell , atom-syntax Message-id: <018022AA-2AD0-4DDA-9F38-305DF77065A4@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <4468FD76.6050805@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On May 17, 2006, at 12:46 PM, Byrne Reese wrote: > Speaking up: > > http://www.majordojo.com/atom/ > standardizing_the_atom_thread_extension.ph > p > > No surprise I guess, but I am a huge +1. Lock this spec down and ship > it. Me too. Does something useful, does no harm, if it's broken in some way it'll be harmlessly routed around. I suspect that implementations that are stupid about the contents of will be fixed pretty soon. -Tim From owner-atom-syntax@mail.imc.org Tue May 23 15:34:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ficdo-0006qp-K6 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:34:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ficdn-00077B-6d for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:34:04 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJGODp040664; Tue, 23 May 2006 12:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJGOWZ040663; Tue, 23 May 2006 12:16:24 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJGNwA040649 for ; Tue, 23 May 2006 12:16:23 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k4NJGMKe023029 for ; Tue, 23 May 2006 13:16:23 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZQ00I01G174W00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 23 May 2006 13:16:22 -0600 (MDT) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZQ00C6MG7ABN31@mail-amer.sun.com>; Tue, 23 May 2006 13:16:22 -0600 (MDT) Date: Tue, 23 May 2006 12:16:23 -0700 From: Tim Bray Subject: Re: Feed Thread in Last Call In-reply-to: <97566250.20060518141543@djpowell.net> To: David Powell Cc: James M Snell , atom-syntax , Lisa Dusseault Message-id: <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On May 18, 2006, at 6:15 AM, David Powell wrote: > What I see as a problem is that reasonable implementations will not > preserve Atom documents bit-for-bit, so they will need to explicitly > support this draft if they don't want to corrupt data by dropping the > thr:count attributes. By the letter of RFC4287 there is no problem > with the draft, but practically there is something like a layering > concern if an extension requires existing conformant implementations > to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim > I notice that you said "implemented support" - that is fine for > user-agents etc, but I don't believe that Atom infrastructure should > be required to "implement support" for each new bit of content that > publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim From owner-atom-syntax@mail.imc.org Tue May 23 15:43:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ficmv-0001s2-8H for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:43:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ficmt-0007z9-Sd for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:43:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJQm9O042647; Tue, 23 May 2006 12:26:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJQmj6042646; Tue, 23 May 2006 12:26:48 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJQl8P042640 for ; Tue, 23 May 2006 12:26:48 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1361134wra for ; Tue, 23 May 2006 12:26: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:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FcCLUWjheODfPiopMD/SILy/ExPY27YdlMqy+rinhjJJQH9QdT7OEHnQxf9AFlniKJEkHwBHyOcmmO5KYUa5PWSWj75yNwTNT7wiLBRiK5dBH8X7tO0iCCwwi3XggtXW93+ZpFpIEVn3/arQsSe0KdjVrYyNjrovrWjbUkpsWhU= Received: by 10.54.105.19 with SMTP id d19mr2014270wrc; Tue, 23 May 2006 12:26:47 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g3sm246514wra.2006.05.23.12.26.46; Tue, 23 May 2006 12:26:47 -0700 (PDT) Message-ID: <447361F4.5070300@gmail.com> Date: Tue, 23 May 2006 12:26:44 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> In-Reply-To: <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 +1. What Tim said. - James Tim Bray wrote: > On May 18, 2006, at 6:15 AM, David Powell wrote: > >> What I see as a problem is that reasonable implementations will not >> preserve Atom documents bit-for-bit, so they will need to explicitly >> support this draft if they don't want to corrupt data by dropping the >> thr:count attributes. By the letter of RFC4287 there is no problem >> with the draft, but practically there is something like a layering >> concern if an extension requires existing conformant implementations >> to be changed. > > At the end of the day, the marketplace will work within the constraints > of what 4287 allows; my feeling is that there are going to be a ton of > extensions that will attach unforeseen metadata at arbitrary points with > Atom documents, and implementations that fail to store these and make > them retrievable will quickly be seen as broken. -Tim > >> I notice that you said "implemented support" - that is fine for >> user-agents etc, but I don't believe that Atom infrastructure should >> be required to "implement support" for each new bit of content that >> publishers put into their feeds. > > On the contrary; I think that implementors who fail to deal with the > fact that people will be adding their own non-Atom stuff at every > conceivable place in an Atom feed are being very stupid, because this > will happen whatever we say. -Tim > From owner-atom-syntax@mail.imc.org Tue May 23 15:43:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ficn2-0001sV-Em for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:43:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ficn0-0007zF-28 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:43:36 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJXdOU044001; Tue, 23 May 2006 12:33:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJXdBb044000; Tue, 23 May 2006 12:33:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJXdrI043993 for ; Tue, 23 May 2006 12:33:39 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1362420wra for ; Tue, 23 May 2006 12:33:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=DM5/k/f8FMoGCMoA+q+IbF/HtAwDHUXtXSP8SXZMZVcm5mK0U8FKeJN+nl8PvoJgoJaI2TEcwpiyGEo72rIUZGhyKjZZsLZrUl4yjQI0S66Whe2EytwGrCL27orhB9eZg8nmQwOXHO8wRqpdk9WYoVgWx9gneY/PkEF1N2DrdU4= Received: by 10.54.121.3 with SMTP id t3mr6303824wrc; Tue, 23 May 2006 12:33:38 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 44sm5232935wri.2006.05.23.12.33.37; Tue, 23 May 2006 12:33:38 -0700 (PDT) Message-ID: <4473638E.2050106@gmail.com> Date: Tue, 23 May 2006 12:33:34 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Feed Thread Updated 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d I've just sent off Draft -11 of Feed Thread that incorporates the following updates per the feedback offered during the last-call discussions: 1. thr:when renamed to thr:updated. This is minor, I don't think it was necessary, but some folks seemed to prefer thr:updated over thr:when. 2. New thr:total entry extension for representing the total comment count. This is essentially a drop-in replacement for slash:comments, as suggested by Aristotle, and is explicitly defined not to interact with the thr:count attribute on replies links. 3. ref attribute is now required in thr:in-reply-to. If the parent resource does not have a unique identifier, it's IRI SHOULD be used. 4. Also on the in-reply-to element, ref MUST NOT be considered to be dereferenceable. href and source MUST be dereferenceable 5. The volatility of the thr:count, thr:when, and thr:total extensions is discussed. (e.g. they can change frequently and independently of the containing entry). 6. The authority/precision of the thr:count, thr:when and thr:total extensions is discussed (e.g. they may not be 100% accurate, but that's ok) 7. The fact that some implementations may not be able to fully utilize the extensions is discussed. 8. The security considerations have been expanded to highlight the possibility of distributed comment spam and potential repudiation issues. I believe this addresses all of the last call issues besides those raised by David Powell, which I'm not convinced need addressing at this point. The new draft will appear in a day or so. - James From owner-atom-syntax@mail.imc.org Tue May 23 15:44:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fico8-0002AR-TA for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:44:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fico6-00083j-EL for atompub-archive@lists.ietf.org; Tue, 23 May 2006 15:44:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJUS33043345; Tue, 23 May 2006 12:30:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJUSIR043344; Tue, 23 May 2006 12:30:28 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJURsm043317 for ; Tue, 23 May 2006 12:30:27 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4NJULBY001696; Tue, 23 May 2006 12:30:21 -0700 (PDT) Received: from [17.219.211.201] (unknown [17.219.211.201]) by relay5.apple.com (Apple SCV relay) with ESMTP id 19B04324002; Tue, 23 May 2006 12:30:21 -0700 (PDT) In-Reply-To: <447361F4.5070300@gmail.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <447361F4.5070300@gmail.com> Mime-Version: 1.0 (Apple Message framework v751) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1ABE7836-65CA-431F-A7D0-4DDBB3F1D142@apple.com> Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Ernest Prabhakar Subject: Re: Feed Thread in Last Call Date: Tue, 23 May 2006 12:30:26 -0700 To: James M Snell X-Mailer: Apple Mail (2.751) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I've had a hard time following this thread, but for what its worth I buy Tim's reasoning. +1 On May 23, 2006, at 12:26 PM, James M Snell wrote: > > +1. What Tim said. > > - James > > Tim Bray wrote: >> On May 18, 2006, at 6:15 AM, David Powell wrote: >> >>> What I see as a problem is that reasonable implementations will not >>> preserve Atom documents bit-for-bit, so they will need to explicitly >>> support this draft if they don't want to corrupt data by dropping >>> the >>> thr:count attributes. By the letter of RFC4287 there is no problem >>> with the draft, but practically there is something like a layering >>> concern if an extension requires existing conformant implementations >>> to be changed. >> >> At the end of the day, the marketplace will work within the >> constraints >> of what 4287 allows; my feeling is that there are going to be a >> ton of >> extensions that will attach unforeseen metadata at arbitrary >> points with >> Atom documents, and implementations that fail to store these and make >> them retrievable will quickly be seen as broken. -Tim >> >>> I notice that you said "implemented support" - that is fine for >>> user-agents etc, but I don't believe that Atom infrastructure should >>> be required to "implement support" for each new bit of content that >>> publishers put into their feeds. >> >> On the contrary; I think that implementors who fail to deal with the >> fact that people will be adding their own non-Atom stuff at every >> conceivable place in an Atom feed are being very stupid, because this >> will happen whatever we say. -Tim >> > From owner-atom-syntax@mail.imc.org Tue May 23 16:56:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FidvQ-0003Uc-0z for atompub-archive@lists.ietf.org; Tue, 23 May 2006 16:56:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidvO-0003M9-KT for atompub-archive@lists.ietf.org; Tue, 23 May 2006 16:56:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NKfWxr057768; Tue, 23 May 2006 13:41:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NKfWxW057767; Tue, 23 May 2006 13:41:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NKfV7M057760 for ; Tue, 23 May 2006 13:41:31 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4NKfTSX011511 for ; Tue, 23 May 2006 14:41:30 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZQ00201JMMNN00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 23 May 2006 14:41:29 -0600 (MDT) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZQ00DLVK54EEX2@mail-amer.sun.com>; Tue, 23 May 2006 14:41:29 -0600 (MDT) Date: Tue, 23 May 2006 13:41:29 -0700 From: Tim Bray Subject: Re: Fyi, Apache project proposal In-reply-to: <44732BC8.10904@gmail.com> To: James M Snell Cc: atom-syntax@imc.org Message-id: <93AEF8B1-EA0A-4E16-927C-0358A98D50E5@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <44732BC8.10904@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On May 23, 2006, at 8:35 AM, James M Snell wrote: > The goal is to have a reference implementation that is also usable. > However, I do have to be careful here, the IETF doesn't really do > reference implemenations so the naming of this project is a bit wrong. > We really shouldn't be calling it a "reference implementation" > although > that is the kind of thing we're wanting this to be. Yes, I think it's a good idea for Apache to include tools for processing Atom data and implementing the Atom protocol. The only reason I can imagine for doing this is so that people could use it and thus avoid re-inventing the Atomic wheel. Apache does not have, and would not claim to have, the standing to do a "reference" in the sense of having any normative force. So yes, I think the term "reference" is probably misleading enough to constitute a problem. Why not just call it something breathtakingly original like Apache Atom Library or some such? -Tim From owner-atom-syntax@mail.imc.org Tue May 23 17:01:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fie04-0004HD-R1 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:01:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fie03-0003XQ-EX for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:01:08 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NKnIEE059075; Tue, 23 May 2006 13:49:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NKnIcv059074; Tue, 23 May 2006 13:49:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NKnElG059040; Tue, 23 May 2006 13:49:15 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 23 May 2006 13:49:20 -0700 To: Atom WG , atom-protocol@imc.org From: Paul Hoffman Subject: Atompub WG meeting at the Montreal IETF Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Greetings again. The Atompub WG will have our first (and maybe last!) face-to-face meeting at the upcoming IETF meeting in Montreal at the beginning of July. The timing of us having our first WG meeting may seem odd, given the fact that we completed the Atom format document long ago, and are making good progress on the publishing protocol. However, there are reasons other than "moving documents forwards" for WGs to meet. Lisa Dusseault, our Area Director, asked us to have a meeting so that people active in the Atompub WG can have more interaction with the IETF, and vice versa. There is interest in the Atom format from other WGs, and there may be interest in the Atom publishing protocol as well. I propose the following agenda, which should fit well into a one-hour slot: - Intro: 10 mins - Brief overview of protocol status: 10 mins - Use of Atom format in other WGs: 30 mins - draft-saintandre-atompub-notify - Overlap with calendar formats - Overlap with mail Note that we are explicitly *not* going to discuss extensions to the Atom format at this WG meeting because they are not part of the WG charter. Lisa has said that she may help arrange a BoF session on creating a new Working Group for Atom extensions, and having at least a higher-level discussion of what extensions are out there would be appropriate in that BoF. But, to use asterisks again, such discussion is *not* part of the Atompub WG meeting. See for details about the IETF meeting. I will let the WG know when there are preliminary and near-permanent agendas for the meeting. It would be good to meet some of you there! --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 23 17:36:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FieXr-0001fn-A9 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:36:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FieXp-00053e-Up for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:36:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLLXce064183; Tue, 23 May 2006 14:21:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLLXqR064182; Tue, 23 May 2006 14:21:33 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX1+0SDcRLY28m2sLU6a7vsSDeMiCeCTgmCY@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLLVWl064161; Tue, 23 May 2006 14:21:32 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-19-211.range81-159.btcentralplus.com [81.159.19.211]) (authenticated bits=0) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NLLUUX029712; Tue, 23 May 2006 16:21:31 -0500 Message-ID: <44737CCF.5060102@defuze.org> Date: Tue, 23 May 2006 22:21:19 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <4473650F.1060100@defuze.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > > Welcome to the messy world of standards. There might be a need for an > updated FTE RFC. On the other hand, if the market gives a big yawn, > there is probably no need to update the RFC if no one is using it. On > the third hand, it doesn't hurt to have it updated anyway; there are > lots of RFCs that have barely any implementations. There is probably a > fourth hand consideration as well. > > There is no clear delineation point for when an extension should > become an RFC. The IETF plays it by ear. For some protocols, lots of > extensions as RFCs has been a boon; for others, just a bother. We > won't know where the Atom format fits in that range for a few years. > Thanks a lot for that honest answer Paul. Appreciated :) - Sylvain From owner-atom-syntax@mail.imc.org Tue May 23 17:39:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiebW-0003LP-BK for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:39:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiebW-0005XO-9y for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:39:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FieMq-0004G2-Rl for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:24:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLD2oX062774; Tue, 23 May 2006 14:13:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLD2cF062773; Tue, 23 May 2006 14:13:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLCup9062743 for ; Tue, 23 May 2006 14:13:00 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4473650F.1060100@defuze.org> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <4473650F.1060100@defuze.org> Date: Tue, 23 May 2006 14:10:10 -0700 To: Atom WG From: Paul Hoffman Subject: Re: Feed Thread in Last Call Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.6 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote: >>At the end of the day, the marketplace will work within the >>constraints of what 4287 allows; my feeling is that there are going >>to be a ton of extensions that will attach unforeseen metadata at >>arbitrary points with Atom documents, and implementations that fail >>to store these and make them retrievable will quickly be seen as >>broken. -Tim >> >Sounds about right. Where do we stop then? If the marketplace >decides, is there a need to submit the FTE to the IETF? Will any >extensions need to be submitted? Only Atom per see needed to be >standardised in such a case. Welcome to the messy world of standards. There might be a need for an updated FTE RFC. On the other hand, if the market gives a big yawn, there is probably no need to update the RFC if no one is using it. On the third hand, it doesn't hurt to have it updated anyway; there are lots of RFCs that have barely any implementations. There is probably a fourth hand consideration as well. There is no clear delineation point for when an extension should become an RFC. The IETF plays it by ear. For some protocols, lots of extensions as RFCs has been a boon; for others, just a bother. We won't know where the Atom format fits in that range for a few years. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 23 17:44:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiefZ-00057C-Jb for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:44:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiefY-0005sj-00 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:44:01 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLVdUv065945; Tue, 23 May 2006 14:31:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLVdnl065944; Tue, 23 May 2006 14:31:39 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLVcI2065938 for ; Tue, 23 May 2006 14:31:38 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4NLVcgI012994 for ; Tue, 23 May 2006 15:31:38 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZQ00101LO52X00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Tue, 23 May 2006 15:31:38 -0600 (MDT) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZQ0042KMGPKRD0@mail-amer.sun.com>; Tue, 23 May 2006 15:31:38 -0600 (MDT) Date: Tue, 23 May 2006 14:31:37 -0700 From: Tim Bray Subject: Re: Feed Thread in Last Call In-reply-to: <1711287765.20060520164942@djpowell.net> To: David Powell Cc: Lisa Dusseault , atom-syntax Message-id: <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1 X-Priority: 3 (Normal) References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <1711287765.20060520164942@djpowell.net> X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by balder-227.proper.com id k4NLVdI2065939 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4NLVdUv065945 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length) I'm going to re-organize David's argument a little and deal with one =20 of his last points first. > Foreign attributes are bad, and are inherently less interoperable > than Extension Elements. I would say that furious debates about elements-vs-attributes have =20 been going on since the dawn of XML in 1998, but that would be =20 untrue; they've been going on since the dawn of XML's precursor SGML =20 in 1986. They have never led anywhere. After you've noticed that if =20 you need nested element structure you're stuck with elements, and if =20 you don't want to have two things with the same names attributes can =20 help, there really aren't any deterministic decision procedures. I note with pleasure that *all* known XML APIs allow you to retrieve =20 elements and attributes with about the same degree of difficulty. So, my conclusion: I disagree with Powell. Let people put extensions =20 wherever they feel like putting them (they will anyhow), remembering =20 that human-readability is a virtue. If models try to micro-manage =20 the element/attribute thing, those models are broken, don't use =20 them. If software arbitrarily discards markup because the markup =20 doesn't match its idiosyncratic ideas about elements and attributes, =20 that software is non-comformant and non-interoperable. > Software that deals with XML such as an XHTML document, doesn't have > much choice but to model the document using generic XML concepts and > tools - Infosets, DOM, SAX, strings containing XML tags, etc. > > For Atom though, it is useful to model feeds and entries in terms of > some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF, > but that is a dirty word around these parts). Well yes, but each and every one of those non-XML models fails to =20 capture the information content of perfectly-legal XML in one way or =20 another. The Atom data format *could* have been designed in such a =20 way as to be conformant with one or more of those models, but it =20 wasn't. Extensions to Atom can be designed in such a way as to fit =20 into some particular data model, or not. So I think it's really questionable to try to normatively reverse =20 engineer the WG consensus to try to pretend that Atom documents can =20 usefully be processed as anything but XML. > Section 6 of RFC4287 is flawed. It is an ugly mix I agree. In fact, what Simple Extension *really* says is "this =20 property can trivially be modeled in RDF" and Structured Extension =20 really says is "doesn't directly map to RDF", but I failed to =20 convince the WG either to remove this hand-waving or to be clear =20 about what we really meant. Having said that, these notions =20 fortunately have exactly zero normative effect on implementors. > of my (overly) > strict PaceExtensionConstruct proposal[1], and an (overly) liberal > philosophy that the existence of foreign markup anywhere won't break > implementations, so shouldn't be disallowed. I have no comment on your proposal, but the philosophy you describe =20 does in fact represent the consensus of the WG and the IETF =20 community; your opinion that it is overly liberal is interesting but =20 not particularly relevant to implementors. > atompub's charter states: > >> Atom consists of: >> * A conceptual model of a resource >> * A concrete syntax for this model > > Extension elements are defined to have both a model and a syntax, but > Atom's allowance for foreign attributes to appear anywhere is a case > of syntax that has no corresponding model. Atom doesn't really explain > what foreign attributes are intended for. Extension elements also, as noted above, have *no normative effect*. =20 It is arguable that the design of Atom departed from the charter in =20 that the model was never explicitly specified. To me, this seems =20 like sound design; the success of the Web has been based on careful =20 specification of the content and sequence of the interchanged =20 messages without any attempt to standardize on a model. This is A =20 Good Thing, and demonstrably works. And Atom also doesn't really explain what foreign elements are =20 intended for either. > It seems like they could be > an extension point, but given that many implementations will have an > application model that isn't based on the XML Infoset (as described > above), There's a word for implementations (especially intermediaries, as you =20 notice) that aren't based on the Infoset: broken. Because RFC4287 is =20 explicitly defined only in terms of the infoset. Go ahead and try to =20 impose any models that are appropriate for your application needs; I =20 do this all the time. But don't change the Infoset. > it seems very unwise to create an extension proposal which > depends on the precise syntax of an element being preserved. The "precise syntax" claim is utterly bogus. RFC4287 properly =20 standardizes at the Infoset level, thus it makes zero difference =20 whether I say Caf=E9 or Café. I =20 personally think that an extension proposal should (a) be useful (b) be readable (c) not rely on anything that isn't preserved in the XML Infoset > foreign attributes appear to provide a > class of extension (if that is what it is) that will be much less > interoperable. This is only true for software which ignores the fact that RFC4287 is =20 specified only in terms of the XML Infoset. If you lose information =20 because it doesn't match up with some ex post facto model you've =20 dreamed up, you cannot expect to achieve interoperability. > Some guidance in how to design extensions is definitely missing from > the RFC, perhaps an Informational RFC explaining the issues would be > appropriate. Agreed. But I predict you'll have a devilish hard time building any =20 consensus that goes further than my (a), (b), and (c) above. > The lack of standardisation is not necessarily a bad thing, > implementations are free to implement what is appropriate to their > requirements - if implementations were required to preserve everything > perfectly it would massively raise the cost of integrating Atom with > existing systems. For good interoperability, they should not do violence to the content =20 of what they are given, as seen in information-set terms. Not much =20 more (or less) can be asked. > As an extension proposal makes greater requirements on software, the > chances of information loss, and interop problems increases. Obviously, but the notion that this depends on whether you use an =20 attribute or an element seems really, really bizarre to me. An =20 intermediary that drops markup it doesn't recognize won't last long =20 in the marketplace, whether those are elements or attributes. > Interoperability should take priority of concerns that 'approach X =20 > looks > better than Y', and other unjustifiable minor concerns. Yes, and interoperability is based on the normative rules in RFC4287, =20 right? > Perhaps foreign attributes could be clarified as being a > 3rd class of extension and reincorporated into the Atom model, with > the disclaimer that they are less interoperable than Simple & > Structured Extensions? I would vociferously resist any such claim. -Tim From owner-atom-syntax@mail.imc.org Tue May 23 17:44:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fieg1-00058r-0r for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:44:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiefz-0005wT-JX for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:44:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLVCqS065880; Tue, 23 May 2006 14:31:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLVCIl065877; Tue, 23 May 2006 14:31:12 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLVBtT065838 for ; Tue, 23 May 2006 14:31:11 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1383462wra for ; Tue, 23 May 2006 14:31:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=po9WArXiUk/7/3f83yh3mlPPO5+McF3Ojs2ybbDreyVmKcybFph3pdRw0XMJWg/+wRL2ldzpYQQW+F18mC2a5h88lFzP3CpUzB6kVItpMXbPqThFZy6r3MyjYZT3Wzv/ZAktxdOZudcNnOHEeQzJZHnhq+NJTssarOxj1IyCW2c= Received: by 10.54.111.2 with SMTP id j2mr6263595wrc; Tue, 23 May 2006 14:30:15 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 39sm6564077wrl.2006.05.23.14.31.03; Tue, 23 May 2006 14:31:04 -0700 (PDT) Message-ID: <44737F15.1040206@gmail.com> Date: Tue, 23 May 2006 14:31:01 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG , atom-protocol@imc.org Subject: Re: Atompub WG meeting at the Montreal IETF References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This sounds good so long as we can get the extensions BOF scheduled the on the same day as the WG meeting. Also, it would be great if we could get together for some face-to-face interop testing before and/or after the WG meeting. - James Paul Hoffman wrote: > > Greetings again. The Atompub WG will have our first (and maybe last!) > face-to-face meeting at the upcoming IETF meeting in Montreal at the > beginning of July. > > The timing of us having our first WG meeting may seem odd, given the > fact that we completed the Atom format document long ago, and are making > good progress on the publishing protocol. However, there are reasons > other than "moving documents forwards" for WGs to meet. Lisa Dusseault, > our Area Director, asked us to have a meeting so that people active in > the Atompub WG can have more interaction with the IETF, and vice versa. > There is interest in the Atom format from other WGs, and there may be > interest in the Atom publishing protocol as well. > > I propose the following agenda, which should fit well into a one-hour slot: > > - Intro: 10 mins > - Brief overview of protocol status: 10 mins > - Use of Atom format in other WGs: 30 mins > - draft-saintandre-atompub-notify > - Overlap with calendar formats > - Overlap with mail > > Note that we are explicitly *not* going to discuss extensions to the > Atom format at this WG meeting because they are not part of the WG > charter. Lisa has said that she may help arrange a BoF session on > creating a new Working Group for Atom extensions, and having at least a > higher-level discussion of what extensions are out there would be > appropriate in that BoF. But, to use asterisks again, such discussion is > *not* part of the Atompub WG meeting. > > See for details about the > IETF meeting. I will let the WG know when there are preliminary and > near-permanent agendas for the meeting. It would be good to meet some of > you there! > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-atom-syntax@mail.imc.org Tue May 23 17:58:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fietp-0002SO-J1 for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:58:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fieto-0006Y8-8A for atompub-archive@lists.ietf.org; Tue, 23 May 2006 17:58:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLlqQV068906; Tue, 23 May 2006 14:47:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLlqrL068905; Tue, 23 May 2006 14:47:52 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLlp25068880 for ; Tue, 23 May 2006 14:47:52 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so1892802pyf for ; Tue, 23 May 2006 14:47:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b0sGr/2IjarZywRR/sR4SoNNFvnN7zRClaHRud6JQqzCgmbRx3rQ9Jj/XbdHrEldwmlYUvcebMRjXhGezb9XfsOCA0761aLd3c1V8+8/FvpBLY+K6OJ3J5mToOJ0o/VRLCUrcevfiVr3Z3iUy1FuF5N53jCAq9sPIGQ8/34AdMw= Received: by 10.35.53.18 with SMTP id f18mr3374404pyk; Tue, 23 May 2006 14:47:46 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Tue, 23 May 2006 14:47:46 -0700 (PDT) Message-ID: <68fba5c50605231447o2b43cae4wc96fce5c9f4f80c0@mail.gmail.com> Date: Tue, 23 May 2006 17:47:46 -0400 From: "Robert Sayre" To: "Tim Bray" Subject: Re: Feed Thread in Last Call Cc: "David Powell" , "Lisa Dusseault" , atom-syntax In-Reply-To: <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <1711287765.20060520164942@djpowell.net> <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4NLlq25068898 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 5/23/06, Tim Bray wrote: > > I would vociferously resist any such claim. OTOH, there are more than a few products on the market right now that back up just such a claim. So there's an existence proof, and most of the APIs I've seen *do* make use simple vs. structured, but you may be right that the market will change that. In otherwords, there is little point in continuing this discussion... just like you and I agreed 150+ messages ago... -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 23 18:13:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fif8G-0007fa-Nn for atompub-archive@lists.ietf.org; Tue, 23 May 2006 18:13:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fif8F-00076R-Cp for atompub-archive@lists.ietf.org; Tue, 23 May 2006 18:13:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLwJeV070694; Tue, 23 May 2006 14:58:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NLwJlN070692; Tue, 23 May 2006 14:58:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NLvhJH070575; Tue, 23 May 2006 14:57:45 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <44737F15.1040206@gmail.com> References: <44737F15.1040206@gmail.com> Date: Tue, 23 May 2006 14:56:58 -0700 To: James M Snell From: Paul Hoffman Subject: Re: Atompub WG meeting at the Montreal IETF Cc: Atom WG , atom-protocol@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 2:31 PM -0700 5/23/06, James M Snell wrote: >This sounds good so long as we can get the extensions BOF scheduled the > on the same day as the WG meeting. Good point. The fact that the WG meeting is one hour strongly suggests that we will be on Tuesday afternoon, the traditional time for one-hour slots. If Lisa's BoF is also one hour, it is very likely to be that day as well. If she goes for an informal Bar BoF, it could be lunch or dinner that day. > Also, it would be great if we could >get together for some face-to-face interop testing before and/or after >the WG meeting. That can be arranged for the weekend before; I'll be in Montreal early. Depending on the number of people, we could just get together in a hallway somewhere, or maybe in someone's Montreal office, or something. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue May 23 18:18:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifCX-0001Fb-TP for atompub-archive@lists.ietf.org; Tue, 23 May 2006 18:18:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fidjn-0002yJ-1D for atompub-archive@lists.ietf.org; Tue, 23 May 2006 16:44:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FidLi-0002xN-1H for atompub-archive@lists.ietf.org; Tue, 23 May 2006 16:19:27 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJeQN7045528; Tue, 23 May 2006 12:40:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4NJeQSs045527; Tue, 23 May 2006 12:40:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.python-hosting.com (IDENT:U2FsdGVkX18DaZcJab14p0zBFW9pEJS3SFfzL8nyAFc@mail1.python-hosting.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4NJePhC045511 for ; Tue, 23 May 2006 12:40:25 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-19-211.range81-159.btcentralplus.com [81.159.19.211]) (authenticated bits=0) by mail1.python-hosting.com (8.12.11.20060308/8.13.3) with ESMTP id k4NJeA5G021921; Tue, 23 May 2006 14:40:13 -0500 Message-ID: <4473650F.1060100@defuze.org> Date: Tue, 23 May 2006 20:39:59 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Tim Bray CC: David Powell , James M Snell , atom-syntax , Lisa Dusseault Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> In-Reply-To: <47484681-73CF-4546-BAD9-C0CF31DF00BE@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: X-Spam-Score: -2.6 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > > At the end of the day, the marketplace will work within the > constraints of what 4287 allows; my feeling is that there are going to > be a ton of extensions that will attach unforeseen metadata at > arbitrary points with Atom documents, and implementations that fail to > store these and make them retrievable will quickly be seen as broken. > -Tim > > Sounds about right. Where do we stop then? If the marketplace decides, is there a need to submit the FTE to the IETF? Will any extensions need to be submitted? Only Atom per see needed to be standardised in such a case. - Sylvain From owner-atom-syntax@mail.imc.org Wed May 24 03:59:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioHa-00068j-Nj for atompub-archive@lists.ietf.org; Wed, 24 May 2006 03:59:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FioHW-0000mi-50 for atompub-archive@lists.ietf.org; Wed, 24 May 2006 03:59:54 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4O7lB8B089778; Wed, 24 May 2006 00:47:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4O7lBmZ089777; Wed, 24 May 2006 00:47:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4O7lAca089762 for ; Wed, 24 May 2006 00:47:11 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so1495488nzi for ; Wed, 24 May 2006 00:47:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=rpobEZj0pOt4M9N54FypXqOYvkqoHidttFikqI+hdWzd6/4Q/1pjzpofb0lO1it46iN0DzIsfoVSaXxLZXaarTVNS6Zvb078oYCjeav/gBe0/x9E7ufSvYd9CxG2yY4qh4K6Pc2A+aaMcJXfvrbUjk2erTm4jVQBhk2RHAItgzI= Received: by 10.64.88.11 with SMTP id l11mr3055259qbb; Wed, 24 May 2006 00:47:10 -0700 (PDT) Received: by 10.65.183.20 with HTTP; Wed, 24 May 2006 00:47:10 -0700 (PDT) Message-ID: Date: Wed, 24 May 2006 01:47:10 -0600 From: "M. David Peterson" To: "Atom Syntax" Subject: ASPdotAtom MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_44680_26529441.1148456830470" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e ------=_Part_44680_26529441.1148456830470 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSd2ZSBjaG9zZW4gYSAic2h1dC11cCBhbmQgY29kZSIgYXBwcm9hY2ggdG8gdGhlIG92ZXJhbGwg QXRvbS1yZWxhdGVkCnByb2plY3RzIEkgaGF2ZSBnb2luZywgc29tZXRoaW5nIEknbSBzdXJlIG1h bnkgb2YgeW91LCBpZiBub3Qgbm90aWNlZCwgYXJlCm5vbmUtdGhlLWxlc3MgdGhhbmtmdWwgZm9y IHRoZSAiYnJlYWsiIDopCgpIb3dldmVyLCBJIHRob3VnaHQgSSB3b3VsZCBwb2ludCBvdXQgcGFy dCBvZiB0aGUgY29tbWVudHMgZnJvbSB0aGlzIG1vcm5pbmdzCmNoZWNraW4sCgpjb3VwbGUgdGhp bmdzIG9mIG1ham9yIHNpZ25pZmljYW5jZSBpbiB0aGlzIGNoZWNrIGluOiBJJ3ZlIHdyaXR0ZW4g YSBxdWljawo+IEFTUC5ORVQgaGFuZGxlciBmb3IgZmlsZXMgd2l0aCBhIC5vbXggKEBvbXggPSBh dG9taXggPSBhdG9taWN4bWwgPSAieWVhaCwKPiB5ZWFoLCBzdWUgbWUgZm9yIHRoZSBkYW1hZ2Vz IG9uIHlvdXIgb3Zlci1kZWxpY2F0ZS1zZWxmIiA7KSkgZmlsZSBleHRlbnNpb24KPiB0byBhdXRv bWF0aWNhbGx5IGJlIGhhbmRsZWQgYnkgdGhlIEV4dGYuTmV0Lk9teC5Bc3BOZXRIYW5kbGVyIGNs YXNzLCB3aGljaAo+IGluc3RhbnRpYXRlcyBhIFNheG9uLWJhc2VkIHRyYW5zZm9ybWF0aW9uLiBU aGlzIHJlcXVpcmVzIHRoYXQgeW91IHJlZ2lzdGVyCj4gdGhlIC5vbXggZXh0ZW5zaW9uIHRvIGJl IGhhbmRsZWQgYnkgdGhlIGFzcG5ldF9pc2FwaS5kbGwgZm9yIGFueSBzdXBwb3J0ZWQKPiB2ZXJz aW9uIG9mIHRoZSAuTkVUIHBsYXRmb3JtICgxLjEgYW5kIDIuMCBhcmUgYm90aCBzdXBwb3J0ZWQg YnkgU2F4b24gb24KPiAuTkVUKS4gWW91IHdpbGwgYWxzbyBuZWVkIHRvIGFkZCBkZWZhdWx0Lm9t eCB0byB0aGUgdG9wIG9mIHRoZSBEb2N1bWVudAo+IGxpc3QgZm9yIHlvdXIgQVNQLk5FVCBhcHBs aWNhdGlvbi4gUGxlYXNlIHNlZSB0aGUgQVNQLk5FVCBkb2N1bWVudGF0aW9uIHRvCj4gdW5kZXJz dGFuZCBob3cgdG8gZ28gYWJvdXQgdGhpcy4gUHJldHR5IHNpbXBsZSBzdHVmZiwgYnV0IGl0IG1h a2VzIG91ciBsaWZlCj4gYSBXSE9MRSBMT1QgRUFTSUVSLCBhbmQgYSBXSE9MRSBMT1QgRkFTVEVS IGFzIGFsbCB3ZSBuZWVkIHRvIGRvIGlzIGNyZWF0ZSBhCj4gZGVmYXVsdC5vbXggYXRvbSBmaWxl IHRoYXQgcmVmZXJlbmNlcyBhbGwgb2YgdGhlIGF0b206ZmVlZCBvciBhdG9tOmVudHJ5Cj4gYmFz ZWQgYXRvbSBmaWxlcyBuZWNlc3NhcnkgZm9yIGVhY2ggcGFnZSwgcGFzc2luZyBpdCB0byBhIHBy ZS1jb21waWxlZAo+IEFTUC5ORVQgaGFuZGxlciBmb3IgcHJvY2Vzc2luZy4gU28gaW4gZWFjaCBk aXJlY3Rvcnkgb2YgYW55IGdpdmVuIHdlYgo+IGFwcGxpY2F0aW9uIHRoZSBvbmx5IGZpbGUgdGhh dCBuZWVkcyB0byBleGlzdCBpcyBhbiBhdG9tIGZpbGUgY2FsbGVkCj4gZGVmYXVsdC5vbXggdGhh dCBjb250YWlucyByZWZlcmVuY2VzIHRvIHRoZSBmaWxlcyB0aGF0IGNvbnRhaW4gdGhlCj4gY29u dGVudCwgdGhlIGZpbGVzIGNvbnRhaW4gdGhlIHRlbXBsYXRlIHRvIGJ1aWxkIHRoZSBvdXRwdXQg YWdhaW5zdCwgZXRjLi4uCj4KCkkgbGVhdmUgYWdhaW4gaW4gcGVhY2UsIGJ1dCBJIHRob3VnaHQg eW91IGFsbCBtaWdodCBmaW5kIGludGVyZXN0IGluIHRoZQppZGVhIHRoYXQgQXRvbSBoYXMgZm91 bmQgaXRzIHdheSBpbnRvIHRoZSB0b3Agb2YgdGhlIGRlZmF1bHQgZG9jdW1lbnQKcG9zaXRpb24g YXMgbXkgb3duIHBlcnNvbmFsICJzY3JpcHRpbmcgbGFuZ3VhZ2UiIG9mIGNob2ljZSBmb3IKQVNQ Lk5FVC1iYXNlZGFwcGxpY2F0aW9ucy4KClRoZSBjdXJyZW50IGluc3RhbmNlIEAgaHR0cDovL2V4 dGYubmV0IHByb3ZpZGVzIGJvdGggYSBzYW1wbGUgb2YgdGhpcyBpbgphY3Rpb24sIGFzIHdlbGwg YXMgbGlua3MgdG8gdGhlIHRyYWMgaW50ZXJmYWNlIHdoaWNoIGNvbnRhaW5zIHRoZSByZXBvc2l0 b3J5CmluZm8gaWYgeW91IHdhbnQgdG8gY2hlY2sgaXQgb3V0IGFuZCBwbGF5IGFyb3VuZCB3aXRo IGl0LCBvciBzaW1wbHkgdXNlIHRoZQppbnRlcmZhY2UgdG8gdmlldyB0aGUgc291cmNlIG9ubGlu ZS4gIFN0aWxsIExPVFMgbW9yZSB0byB3cml0ZSBmb3IgdGhlCm92ZXJhbGwgYXBwbGljYXRpb24s IHNvIEknbSBiYWNrIGF0IGl0Li4uICBXaGVuIHNvbWV0aGluZyBvZiBzaWduaWZpY2FuY2UgaXMK Y2hlY2tlZCBpbiB0aGF0IGJyaW5ncyB0aGluZ3MgdG8gYSB2ZXJzaW9uZWQgZGVsaXZlcnkgc3Rh Z2UsIEknbGwgbGV0IHlvdQphbGwga25vdy4uLgoKRW5qb3kgeW91ciBkYXkgOikKCi0tIAo8TTpE Lz4KCk0uIERhdmlkIFBldGVyc29uCmh0dHA6Ly93d3cueHNsdGJsb2cuY29tLwo= ------=_Part_44680_26529441.1148456830470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSd2ZSBjaG9zZW4gYSAmcXVvdDtzaHV0LXVwIGFuZCBjb2RlJnF1b3Q7IGFwcHJvYWNoIHRvIHRo ZSBvdmVyYWxsIEF0b20tcmVsYXRlZCBwcm9qZWN0cyBJIGhhdmUgZ29pbmcsIHNvbWV0aGluZyBJ J20gc3VyZSBtYW55IG9mIHlvdSwgaWYgbm90IG5vdGljZWQsIGFyZSBub25lLXRoZS1sZXNzIHRo YW5rZnVsIGZvciB0aGUgJnF1b3Q7YnJlYWsmcXVvdDsgOik8YnI+PGJyPkhvd2V2ZXIsIEkgdGhv dWdodCBJIHdvdWxkIHBvaW50IG91dCBwYXJ0IG9mIHRoZSBjb21tZW50cyBmcm9tIHRoaXMgbW9y bmluZ3MgY2hlY2tpbiwKPGJyPjxicj48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFw eCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBh ZGRpbmctbGVmdDogMWV4OyIgY2xhc3M9ImdtYWlsX3F1b3RlIj5jb3VwbGUgdGhpbmdzIG9mIG1h am9yIHNpZ25pZmljYW5jZSBpbiB0aGlzIGNoZWNrIGluOiBJJ3ZlIHdyaXR0ZW4gYQpxdWljayA8 YSBocmVmPSJodHRwOi8vQVNQLk5FVCI+QVNQLk5FVDwvYT4gaGFuZGxlciBmb3IgZmlsZXMgd2l0 aCBhIC5vbXggKEBvbXggPSBhdG9taXggPSBhdG9taWN4bWwKPSAmcXVvdDt5ZWFoLCB5ZWFoLCBz dWUgbWUgZm9yIHRoZSBkYW1hZ2VzIG9uIHlvdXIgb3Zlci1kZWxpY2F0ZS1zZWxmJnF1b3Q7IDsp KQpmaWxlIGV4dGVuc2lvbiB0byBhdXRvbWF0aWNhbGx5IGJlIGhhbmRsZWQgYnkgdGhlCkV4dGYu TmV0Lk9teC5Bc3BOZXRIYW5kbGVyIGNsYXNzLCB3aGljaCBpbnN0YW50aWF0ZXMgYSBTYXhvbi1i YXNlZAp0cmFuc2Zvcm1hdGlvbi4gVGhpcyByZXF1aXJlcyB0aGF0IHlvdSByZWdpc3RlciB0aGUg Lm9teCBleHRlbnNpb24gdG8KYmUgaGFuZGxlZCBieSB0aGUgYXNwbmV0X2lzYXBpLmRsbCBmb3Ig YW55IHN1cHBvcnRlZCB2ZXJzaW9uIG9mIHRoZQouTkVUIHBsYXRmb3JtICgxLjEgYW5kIDIuMCBh cmUgYm90aCBzdXBwb3J0ZWQgYnkgU2F4b24gb24gLk5FVCkuIFlvdQp3aWxsIGFsc28gbmVlZCB0 byBhZGQgZGVmYXVsdC5vbXggdG8gdGhlIHRvcCBvZiB0aGUgRG9jdW1lbnQgbGlzdCBmb3IKeW91 ciA8YSBocmVmPSJodHRwOi8vQVNQLk5FVCI+QVNQLk5FVDwvYT4gYXBwbGljYXRpb24uIFBsZWFz ZSBzZWUgdGhlIDxhIGhyZWY9Imh0dHA6Ly9BU1AuTkVUIj5BU1AuTkVUPC9hPiBkb2N1bWVudGF0 aW9uIHRvCnVuZGVyc3RhbmQgaG93IHRvIGdvIGFib3V0IHRoaXMuIFByZXR0eSBzaW1wbGUgc3R1 ZmYsIGJ1dCBpdCBtYWtlcyBvdXIKbGlmZSBhIFdIT0xFIExPVCBFQVNJRVIsIGFuZCBhIFdIT0xF IExPVCBGQVNURVIgYXMgYWxsIHdlIG5lZWQgdG8gZG8gaXMKY3JlYXRlIGEgZGVmYXVsdC5vbXgg YXRvbSBmaWxlIHRoYXQgcmVmZXJlbmNlcyBhbGwgb2YgdGhlIGF0b206ZmVlZCBvcgphdG9tOmVu dHJ5IGJhc2VkIGF0b20gZmlsZXMgbmVjZXNzYXJ5IGZvciBlYWNoIHBhZ2UsIHBhc3NpbmcgaXQg dG8gYQpwcmUtY29tcGlsZWQgPGEgaHJlZj0iaHR0cDovL0FTUC5ORVQiPkFTUC5ORVQ8L2E+IGhh bmRsZXIgZm9yIHByb2Nlc3NpbmcuIFNvIGluIGVhY2ggZGlyZWN0b3J5IG9mCmFueSBnaXZlbiB3 ZWIgYXBwbGljYXRpb24gdGhlIG9ubHkgZmlsZSB0aGF0IG5lZWRzIHRvIGV4aXN0IGlzIGFuIGF0 b20KZmlsZSBjYWxsZWQgZGVmYXVsdC5vbXggdGhhdCBjb250YWlucyByZWZlcmVuY2VzIHRvIHRo ZSBmaWxlcyB0aGF0CmNvbnRhaW4gdGhlIGNvbnRlbnQsIHRoZSBmaWxlcyBjb250YWluIHRoZSB0 ZW1wbGF0ZSB0byBidWlsZCB0aGUgb3V0cHV0CmFnYWluc3QsIGV0Yy4uLjxiciBjbGVhcj0iYWxs Ij48L2Jsb2NrcXVvdGU+PGJyPkkgbGVhdmUgYWdhaW4gaW4gcGVhY2UsIGJ1dCBJIHRob3VnaHQg eW91IGFsbCBtaWdodCBmaW5kIGludGVyZXN0IGluIHRoZSBpZGVhIHRoYXQgQXRvbSBoYXMgZm91 bmQgaXRzIHdheSBpbnRvIHRoZSB0b3Agb2YgdGhlIGRlZmF1bHQgZG9jdW1lbnQgcG9zaXRpb24g YXMgbXkgb3duIHBlcnNvbmFsICZxdW90O3NjcmlwdGluZyBsYW5ndWFnZSZxdW90OyBvZiBjaG9p Y2UgZm9yIApBU1AuTkVULWJhc2VkIGFwcGxpY2F0aW9ucy48YnI+PGJyPlRoZSBjdXJyZW50IGlu c3RhbmNlIEAgPGEgaHJlZj0iaHR0cDovL2V4dGYubmV0Ij5odHRwOi8vZXh0Zi5uZXQ8L2E+IHBy b3ZpZGVzIGJvdGggYSBzYW1wbGUgb2YgdGhpcyBpbiBhY3Rpb24sIGFzIHdlbGwgYXMgbGlua3Mg dG8gdGhlIHRyYWMgaW50ZXJmYWNlIHdoaWNoIGNvbnRhaW5zIHRoZSByZXBvc2l0b3J5IGluZm8g aWYgeW91IHdhbnQgdG8gY2hlY2sgaXQgb3V0IGFuZCBwbGF5IGFyb3VuZCB3aXRoIGl0LCBvciBz aW1wbHkgdXNlIHRoZSBpbnRlcmZhY2UgdG8gdmlldyB0aGUgc291cmNlIG9ubGluZS4mbmJzcDsg U3RpbGwgTE9UUyBtb3JlIHRvIHdyaXRlIGZvciB0aGUgb3ZlcmFsbCBhcHBsaWNhdGlvbiwgc28g SSdtIGJhY2sgYXQgaXQuLi4mbmJzcDsgV2hlbiBzb21ldGhpbmcgb2Ygc2lnbmlmaWNhbmNlIGlz IGNoZWNrZWQgaW4gdGhhdCBicmluZ3MgdGhpbmdzIHRvIGEgdmVyc2lvbmVkIGRlbGl2ZXJ5IHN0 YWdlLCBJJ2xsIGxldCB5b3UgYWxsIGtub3cuLi4KPGJyPjxicj5FbmpveSB5b3VyIGRheSA6KTxi cj48YnI+LS0gPGJyPiZsdDtNOkQvJmd0Ozxicj48YnI+TS4gRGF2aWQgUGV0ZXJzb248YnI+PGEg aHJlZj0iaHR0cDovL3d3dy54c2x0YmxvZy5jb20vIj5odHRwOi8vd3d3LnhzbHRibG9nLmNvbS88 L2E+Cg== ------=_Part_44680_26529441.1148456830470-- From owner-atom-syntax@mail.imc.org Wed May 24 04:17:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioYX-0004oR-J2 for atompub-archive@lists.ietf.org; Wed, 24 May 2006 04:17:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FioYV-0001Y5-UH for atompub-archive@lists.ietf.org; Wed, 24 May 2006 04:17:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4O84BnL092995; Wed, 24 May 2006 01:04:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4O84BlZ092994; Wed, 24 May 2006 01:04:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4O84Afh092980 for ; Wed, 24 May 2006 01:04:10 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so1498218nzi for ; Wed, 24 May 2006 01:04:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XKNH9WtnMaCIhmQwAG6tIRWDl6TWsy4EMux99tSEYORVn3YJqNw6LsU8Ib7QaIMApTe0AJMP+FrgUoKI5hQo0/rhA6jHNZdH5MIvvHAijyKKEmULzqgoq9Es7fdhiIcSiScOhcrUCT1BOZPqxclgiFlWZXJ4DfD4iFqO7MlWusE= Received: by 10.65.74.12 with SMTP id b12mr2480580qbl; Wed, 24 May 2006 01:04:07 -0700 (PDT) Received: by 10.65.183.20 with HTTP; Wed, 24 May 2006 01:04:07 -0700 (PDT) Message-ID: Date: Wed, 24 May 2006 02:04:07 -0600 From: "M. David Peterson" To: "Atom Syntax" Subject: Re: ASPdotAtom In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_44916_33499389.1148457847334" References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c ------=_Part_44916_33499389.1148457847334 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline U29tZXRoaW5nIEkgZm9yZ290IHRvIG1lbnRpb246IFRoZXJlIGFyZSB0aHJlZSBwcmltYXJ5IHJl YXNvbnMgdGhhdCBJCmJlbGlldmUgbWFrZSB0aGlzIGEgY29tcGVsbGluZyBzb2x1dGlvbiwKCjEp IE9uZSBtYXN0ZXIgYXRvbSBmZWVkIC0tPCBtYW55IHNlcnZlcnMgPSBxdWljaywgZWFzeSwgYW5k IGF1dG9tYXRpYwphcHBsaWNhdGlvbiBkZXBsb3ltZW50IGFuZCBzZXJ2ZXIgc3luY2hyb25pemF0 aW9uLgoKMikgdmlhIExpdmVDbGlwYm9hcmQ6R2xvYmFsQ2xpcCA+IENvcHkgPiBQYXN0ZSA+IERl cGxveQoKMykgU2ltcGxlIHBvbGljeSBlbmZvcmNlbWVudCB1c2luZyBSTkcsIFNjaGVtYXRyb24s IFhNTCBTY2hlbWEsIGV0Yy4uLgoKT24gNS8yNC8wNiwgTS4gRGF2aWQgUGV0ZXJzb24gPHhtbGhh Y2tlckBnbWFpbC5jb20+IHdyb3RlOgo+Cj4gSSd2ZSBjaG9zZW4gYSAic2h1dC11cCBhbmQgY29k ZSIgYXBwcm9hY2ggdG8gdGhlIG92ZXJhbGwgQXRvbS1yZWxhdGVkCj4gcHJvamVjdHMgSSBoYXZl IGdvaW5nLCBzb21ldGhpbmcgSSdtIHN1cmUgbWFueSBvZiB5b3UsIGlmIG5vdCBub3RpY2VkLCBh cmUKPiBub25lLXRoZS1sZXNzIHRoYW5rZnVsIGZvciB0aGUgImJyZWFrIiA6KQo+Cj4gSG93ZXZl ciwgSSB0aG91Z2h0IEkgd291bGQgcG9pbnQgb3V0IHBhcnQgb2YgdGhlIGNvbW1lbnRzIGZyb20g dGhpcwo+IG1vcm5pbmdzIGNoZWNraW4sCj4KPiBjb3VwbGUgdGhpbmdzIG9mIG1ham9yIHNpZ25p ZmljYW5jZSBpbiB0aGlzIGNoZWNrIGluOiBJJ3ZlIHdyaXR0ZW4gYSBxdWljawo+ID4gQVNQLk5F VCBoYW5kbGVyIGZvciBmaWxlcyB3aXRoIGEgLm9teCAoQG9teCA9IGF0b21peCA9IGF0b21pY3ht bCA9Cj4gPiAieWVhaCwgeWVhaCwgc3VlIG1lIGZvciB0aGUgZGFtYWdlcyBvbiB5b3VyIG92ZXIt ZGVsaWNhdGUtc2VsZiIgOykpIGZpbGUKPiA+IGV4dGVuc2lvbiB0byBhdXRvbWF0aWNhbGx5IGJl IGhhbmRsZWQgYnkgdGhlIEV4dGYuTmV0Lk9teC5Bc3BOZXRIYW5kbGVyY2xhc3MsIHdoaWNoIGlu c3RhbnRpYXRlcyBhIFNheG9uLWJhc2VkIHRyYW5zZm9ybWF0aW9uLiBUaGlzIHJlcXVpcmVzIHRo YXQKPiA+IHlvdSByZWdpc3RlciB0aGUgLm9teCBleHRlbnNpb24gdG8gYmUgaGFuZGxlZCBieSB0 aGUgYXNwbmV0X2lzYXBpLmRsbCBmb3IKPiA+IGFueSBzdXBwb3J0ZWQgdmVyc2lvbiBvZiB0aGUg Lk5FVCBwbGF0Zm9ybSAoMS4xIGFuZCAyLjAgYXJlIGJvdGgKPiA+IHN1cHBvcnRlZCBieSBTYXhv biBvbiAuTkVUKS4gWW91IHdpbGwgYWxzbyBuZWVkIHRvIGFkZCBkZWZhdWx0Lm9teCB0bwo+ID4g dGhlIHRvcCBvZiB0aGUgRG9jdW1lbnQgbGlzdCBmb3IgeW91ciBBU1AuTkVUIGFwcGxpY2F0aW9u LiBQbGVhc2Ugc2VlCj4gPiB0aGUgQVNQLk5FVCBkb2N1bWVudGF0aW9uIHRvIHVuZGVyc3RhbmQg aG93IHRvIGdvIGFib3V0IHRoaXMuIFByZXR0eQo+ID4gc2ltcGxlIHN0dWZmLCBidXQgaXQgbWFr ZXMgb3VyIGxpZmUgYSBXSE9MRSBMT1QgRUFTSUVSLCBhbmQgYSBXSE9MRSBMT1QKPiA+IEZBU1RF UiBhcyBhbGwgd2UgbmVlZCB0byBkbyBpcyBjcmVhdGUgYSBkZWZhdWx0Lm9teCBhdG9tIGZpbGUg dGhhdAo+ID4gcmVmZXJlbmNlcyBhbGwgb2YgdGhlIGF0b206ZmVlZCBvciBhdG9tOmVudHJ5IGJh c2VkIGF0b20gZmlsZXMgbmVjZXNzYXJ5IGZvcgo+ID4gZWFjaCBwYWdlLCBwYXNzaW5nIGl0IHRv IGEgcHJlLWNvbXBpbGVkIEFTUC5ORVQgaGFuZGxlciBmb3IgcHJvY2Vzc2luZy4KPiA+IFNvIGlu IGVhY2ggZGlyZWN0b3J5IG9mIGFueSBnaXZlbiB3ZWIgYXBwbGljYXRpb24gdGhlIG9ubHkgZmls ZSB0aGF0IG5lZWRzCj4gPiB0byBleGlzdCBpcyBhbiBhdG9tIGZpbGUgY2FsbGVkIGRlZmF1bHQu b214IHRoYXQgY29udGFpbnMgcmVmZXJlbmNlcyB0bwo+ID4gdGhlIGZpbGVzIHRoYXQgY29udGFp biB0aGUgY29udGVudCwgdGhlIGZpbGVzIGNvbnRhaW4gdGhlIHRlbXBsYXRlIHRvIGJ1aWxkCj4g PiB0aGUgb3V0cHV0IGFnYWluc3QsIGV0Yy4uLgo+ID4KPgo+IEkgbGVhdmUgYWdhaW4gaW4gcGVh Y2UsIGJ1dCBJIHRob3VnaHQgeW91IGFsbCBtaWdodCBmaW5kIGludGVyZXN0IGluIHRoZQo+IGlk ZWEgdGhhdCBBdG9tIGhhcyBmb3VuZCBpdHMgd2F5IGludG8gdGhlIHRvcCBvZiB0aGUgZGVmYXVs dCBkb2N1bWVudAo+IHBvc2l0aW9uIGFzIG15IG93biBwZXJzb25hbCAic2NyaXB0aW5nIGxhbmd1 YWdlIiBvZiBjaG9pY2UgZm9yCj4gQVNQLk5FVC1iYXNlZCBhcHBsaWNhdGlvbnMuCj4KPiBUaGUg Y3VycmVudCBpbnN0YW5jZSBAIGh0dHA6Ly9leHRmLm5ldCBwcm92aWRlcyBib3RoIGEgc2FtcGxl IG9mIHRoaXMgaW4KPiBhY3Rpb24sIGFzIHdlbGwgYXMgbGlua3MgdG8gdGhlIHRyYWMgaW50ZXJm YWNlIHdoaWNoIGNvbnRhaW5zIHRoZSByZXBvc2l0b3J5Cj4gaW5mbyBpZiB5b3Ugd2FudCB0byBj aGVjayBpdCBvdXQgYW5kIHBsYXkgYXJvdW5kIHdpdGggaXQsIG9yIHNpbXBseSB1c2UgdGhlCj4g aW50ZXJmYWNlIHRvIHZpZXcgdGhlIHNvdXJjZSBvbmxpbmUuICBTdGlsbCBMT1RTIG1vcmUgdG8g d3JpdGUgZm9yIHRoZQo+IG92ZXJhbGwgYXBwbGljYXRpb24sIHNvIEknbSBiYWNrIGF0IGl0Li4u ICBXaGVuIHNvbWV0aGluZyBvZiBzaWduaWZpY2FuY2UgaXMKPiBjaGVja2VkIGluIHRoYXQgYnJp bmdzIHRoaW5ncyB0byBhIHZlcnNpb25lZCBkZWxpdmVyeSBzdGFnZSwgSSdsbCBsZXQgeW91Cj4g YWxsIGtub3cuLi4KPgo+IEVuam95IHlvdXIgZGF5IDopCj4KPiAtLQo+IDxNOkQvPgo+Cj4gTS4g RGF2aWQgUGV0ZXJzb24KPiBodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8KPgoKCgotLSAKPE06RC8+ CgpNLiBEYXZpZCBQZXRlcnNvbgpodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8K ------=_Part_44916_33499389.1148457847334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U29tZXRoaW5nIEkgZm9yZ290IHRvIG1lbnRpb246IFRoZXJlIGFyZSB0aHJlZSBwcmltYXJ5IHJl YXNvbnMgdGhhdCBJIGJlbGlldmUgbWFrZSB0aGlzIGEgY29tcGVsbGluZyBzb2x1dGlvbiw8YnI+ PGJyPjEpIE9uZSBtYXN0ZXIgYXRvbSBmZWVkIC0tJmx0OyBtYW55IHNlcnZlcnMgPSBxdWljaywg ZWFzeSwgYW5kIGF1dG9tYXRpYyBhcHBsaWNhdGlvbiBkZXBsb3ltZW50IGFuZCBzZXJ2ZXIgc3lu Y2hyb25pemF0aW9uLgo8YnI+PGJyPjIpIHZpYSBMaXZlQ2xpcGJvYXJkOkdsb2JhbENsaXAgJmd0 OyBDb3B5ICZndDsgUGFzdGUgJmd0OyBEZXBsb3k8YnI+PGJyPjMpIFNpbXBsZSBwb2xpY3kgZW5m b3JjZW1lbnQgdXNpbmcgUk5HLCBTY2hlbWF0cm9uLCBYTUwgU2NoZW1hLCBldGMuLi4gPGJyPjxi cj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNS8yNC8wNiwgPGIgY2xhc3M9Imdt YWlsX3NlbmRlcm5hbWUiPgpNLiBEYXZpZCBQZXRlcnNvbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0 bzp4bWxoYWNrZXJAZ21haWwuY29tIj54bWxoYWNrZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4 OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2PkkndmUgY2hvc2VuIGEgJnF1b3Q7c2h1dC11cCBh bmQgY29kZSZxdW90OyBhcHByb2FjaCB0byB0aGUgb3ZlcmFsbCBBdG9tLXJlbGF0ZWQgcHJvamVj dHMgSSBoYXZlIGdvaW5nLCBzb21ldGhpbmcgSSdtIHN1cmUgbWFueSBvZiB5b3UsIGlmIG5vdCBu b3RpY2VkLCBhcmUgbm9uZS10aGUtbGVzcyB0aGFua2Z1bCBmb3IgdGhlICZxdW90O2JyZWFrJnF1 b3Q7IDopPGJyPjxicj5Ib3dldmVyLCBJIHRob3VnaHQgSSB3b3VsZCBwb2ludCBvdXQgcGFydCBv ZiB0aGUgY29tbWVudHMgZnJvbSB0aGlzIG1vcm5pbmdzIGNoZWNraW4sCjxicj48YnI+PGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBt YXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiIGNsYXNzPSJnbWFp bF9xdW90ZSI+Y291cGxlIHRoaW5ncyBvZiBtYWpvciBzaWduaWZpY2FuY2UgaW4gdGhpcyBjaGVj ayBpbjogSSd2ZSB3cml0dGVuIGEKcXVpY2sgPGEgaHJlZj0iaHR0cDovL0FTUC5ORVQiIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+QVNQLk5FVDwvYT4gaGFuZGxlciBmb3IgZmlsZXMgd2l0aCBhIC5vbXggKEBvbXgg PSBhdG9taXggPSBhdG9taWN4bWwKPSAmcXVvdDt5ZWFoLCB5ZWFoLCBzdWUgbWUgZm9yIHRoZSBk YW1hZ2VzIG9uIHlvdXIgb3Zlci1kZWxpY2F0ZS1zZWxmJnF1b3Q7IDspKQpmaWxlIGV4dGVuc2lv biB0byBhdXRvbWF0aWNhbGx5IGJlIGhhbmRsZWQgYnkgdGhlCkV4dGYuTmV0Lk9teC5Bc3BOZXRI YW5kbGVyIGNsYXNzLCB3aGljaCBpbnN0YW50aWF0ZXMgYSBTYXhvbi1iYXNlZAp0cmFuc2Zvcm1h dGlvbi4gVGhpcyByZXF1aXJlcyB0aGF0IHlvdSByZWdpc3RlciB0aGUgLm9teCBleHRlbnNpb24g dG8KYmUgaGFuZGxlZCBieSB0aGUgYXNwbmV0X2lzYXBpLmRsbCBmb3IgYW55IHN1cHBvcnRlZCB2 ZXJzaW9uIG9mIHRoZQouTkVUIHBsYXRmb3JtICgxLjEgYW5kIDIuMCBhcmUgYm90aCBzdXBwb3J0 ZWQgYnkgU2F4b24gb24gLk5FVCkuIFlvdQp3aWxsIGFsc28gbmVlZCB0byBhZGQgZGVmYXVsdC5v bXggdG8gdGhlIHRvcCBvZiB0aGUgRG9jdW1lbnQgbGlzdCBmb3IKeW91ciA8YSBocmVmPSJodHRw Oi8vQVNQLk5FVCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5BU1AuTkVUPC9hPiBhcHBsaWNhdGlvbi4gUGxlYXNl IHNlZSB0aGUgPGEgaHJlZj0iaHR0cDovL0FTUC5ORVQiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CkFTUC5ORVQ8 L2E+IGRvY3VtZW50YXRpb24gdG8KdW5kZXJzdGFuZCBob3cgdG8gZ28gYWJvdXQgdGhpcy4gUHJl dHR5IHNpbXBsZSBzdHVmZiwgYnV0IGl0IG1ha2VzIG91cgpsaWZlIGEgV0hPTEUgTE9UIEVBU0lF UiwgYW5kIGEgV0hPTEUgTE9UIEZBU1RFUiBhcyBhbGwgd2UgbmVlZCB0byBkbyBpcwpjcmVhdGUg YSBkZWZhdWx0Lm9teCBhdG9tIGZpbGUgdGhhdCByZWZlcmVuY2VzIGFsbCBvZiB0aGUgYXRvbTpm ZWVkIG9yCmF0b206ZW50cnkgYmFzZWQgYXRvbSBmaWxlcyBuZWNlc3NhcnkgZm9yIGVhY2ggcGFn ZSwgcGFzc2luZyBpdCB0byBhCnByZS1jb21waWxlZCA8YSBocmVmPSJodHRwOi8vQVNQLk5FVCIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj5BU1AuTkVUPC9hPiBoYW5kbGVyIGZvciBwcm9jZXNzaW5nLiBTbyBpbiBl YWNoIGRpcmVjdG9yeSBvZgphbnkgZ2l2ZW4gd2ViIGFwcGxpY2F0aW9uIHRoZSBvbmx5IGZpbGUg dGhhdCBuZWVkcyB0byBleGlzdCBpcyBhbiBhdG9tCmZpbGUgY2FsbGVkIGRlZmF1bHQub214IHRo YXQgY29udGFpbnMgcmVmZXJlbmNlcyB0byB0aGUgZmlsZXMgdGhhdApjb250YWluIHRoZSBjb250 ZW50LCB0aGUgZmlsZXMgY29udGFpbiB0aGUgdGVtcGxhdGUgdG8gYnVpbGQgdGhlIG91dHB1dAph Z2FpbnN0LCBldGMuLi48YnIgY2xlYXI9ImFsbCI+PC9ibG9ja3F1b3RlPjxicj5JIGxlYXZlIGFn YWluIGluIHBlYWNlLCBidXQgSSB0aG91Z2h0IHlvdSBhbGwgbWlnaHQgZmluZCBpbnRlcmVzdCBp biB0aGUgaWRlYSB0aGF0IEF0b20gaGFzIGZvdW5kIGl0cyB3YXkgaW50byB0aGUgdG9wIG9mIHRo ZSBkZWZhdWx0IGRvY3VtZW50IHBvc2l0aW9uIGFzIG15IG93biBwZXJzb25hbCAmcXVvdDtzY3Jp cHRpbmcgbGFuZ3VhZ2UmcXVvdDsgb2YgY2hvaWNlIGZvciAKQVNQLk5FVC1iYXNlZCBhcHBsaWNh dGlvbnMuPGJyPjxicj5UaGUgY3VycmVudCBpbnN0YW5jZSBAIDxhIGhyZWY9Imh0dHA6Ly9leHRm Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vZXh0Zi5uZXQ8L2E+IHByb3ZpZGVzIGJvdGggYSBz YW1wbGUgb2YgdGhpcyBpbiBhY3Rpb24sIGFzIHdlbGwgYXMgbGlua3MgdG8gdGhlIHRyYWMgaW50 ZXJmYWNlIHdoaWNoIGNvbnRhaW5zIHRoZSByZXBvc2l0b3J5IGluZm8gaWYgeW91IHdhbnQgdG8g Y2hlY2sgaXQgb3V0IGFuZCBwbGF5IGFyb3VuZCB3aXRoIGl0LCBvciBzaW1wbHkgdXNlIHRoZSBp bnRlcmZhY2UgdG8gdmlldyB0aGUgc291cmNlIG9ubGluZS4mbmJzcDsgU3RpbGwgTE9UUyBtb3Jl IHRvIHdyaXRlIGZvciB0aGUgb3ZlcmFsbCBhcHBsaWNhdGlvbiwgc28gSSdtIGJhY2sgYXQgaXQu Li4mbmJzcDsgV2hlbiBzb21ldGhpbmcgb2Ygc2lnbmlmaWNhbmNlIGlzIGNoZWNrZWQgaW4gdGhh dCBicmluZ3MgdGhpbmdzIHRvIGEgdmVyc2lvbmVkIGRlbGl2ZXJ5IHN0YWdlLCBJJ2xsIGxldCB5 b3UgYWxsIGtub3cuLi4KPGJyPjxicj5FbmpveSB5b3VyIGRheSA6KTxicj48L2Rpdj48ZGl2Pjxz cGFuIGNsYXNzPSJzZyI+PGJyPi0tIDxicj4mbHQ7TTpELyZndDs8YnI+PGJyPk0uIERhdmlkIFBl dGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyIgdGFyZ2V0PSJfYmxh bmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp Ij5odHRwOi8vd3d3LnhzbHRibG9nLmNvbS8KPC9hPgo8L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj4mbHQ7TTpELyZndDs8YnI+PGJy Pk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+ aHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPgo= ------=_Part_44916_33499389.1148457847334-- From owner-atom-syntax@mail.imc.org Wed May 24 06:09:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiqJP-0004VH-Ix for atompub-archive@lists.ietf.org; Wed, 24 May 2006 06:09:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiqJO-00062k-23 for atompub-archive@lists.ietf.org; Wed, 24 May 2006 06:09:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4O9m8jd016390; Wed, 24 May 2006 02:48:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4O9m8wt016389; Wed, 24 May 2006 02:48:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4O9m6f1016363 for ; Wed, 24 May 2006 02:48:07 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 24 May 2006 09:48:00 -0000 Received: from xdsl-81-173-175-40.netcologne.de (EHLO klangraum) [81.173.175.40] by mail.gmx.net (mp035) with SMTP; 24 May 2006 11:48:00 +0200 X-Authenticated: #163624 Date: Wed, 24 May 2006 11:48:06 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Model vs Syntax (was: Feed Thread in Last Call) Message-ID: <20060524094806.GY32180@klangraum> Mail-Followup-To: atom-syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <1711287765.20060520164942@djpowell.net> <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4O9m8jd016390 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da * Tim Bray [2006-05-23 23:40]: > On May 20, 2006, at 8:49 AM, David Powell wrote: > >Foreign attributes are bad, and are inherently less > >interoperable than Extension Elements. >=20 > I would say that furious debates about elements-vs-attributes > have been going on since the dawn of XML in 1998, but that > would be untrue; they've been going on since the dawn of XML's > precursor SGML in 1986. They have never led anywhere. After > you've noticed that if you need nested element structure you're > stuck with elements, and if you don't want to have two things > with the same names attributes can help, there really aren't > any deterministic decision procedures. >=20 > I note with pleasure that *all* known XML APIs allow you to > retrieve elements and attributes with about the same degree of > difficulty. As I read David=E2=80=99s argument, this has nothing to do with elements vs attributes and everything to do with Extension Elements vs foreign markup. It doesn=E2=80=99t make a whiff of difference to David=E2= =80=99s argumen whether the Feed Thread Extension standardised on providing this information as child elements or attributes of atom:link. The considerations are exactly the same: model vs syntax. ---- By and large, I agree with him that it would have been beneficial to specify Atom just a little more closely at a model level. But I also agree with you that aspiring to much higher rigor beyond the Infoset level is unnecessary. My retrospective opinion is that the correct approach would have been to specify that an Atom Feed Document consists of a series of completely independent Atom Entries, each of which can be interpreted in isolation of any others as well as of the Atom Feed Document that they are found in (modulo Person Construct inheritance). This would explicitly allow consumers to rely on this atomicity (pun intended), thus preventing any extensions from crossing these boundaries. This goes beyond the mere interchange of messages to a definition of a standardised model, though as you can see, it=E2=80=99s a very loose one. I contend it is also the model used implicitly by any useful aggregator which tracks feed content over time. Section 6.4 is more myopic and simultaneously more presbyopic than that. This omission shouldn=E2=80=99t matter much in practice. RFC 4287 enables such a world view implicitly anyway (eg. by only allowing feed metadata to appear at the top of a Feed Document and declining to assign any significance to the order of entries). Extensions which require considering an Atom Feed Document as an overall unit rather than as a collection will hopefully fail to gain much acceptance by virtue of high burden on implementors. But being explicit about this model would have made RFC 4287 a better spec. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 24 06:42:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiqp1-00087N-96 for atompub-archive@lists.ietf.org; Wed, 24 May 2006 06:42:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiqoz-0007bO-Te for atompub-archive@lists.ietf.org; Wed, 24 May 2006 06:42:35 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4OAR5is026116; Wed, 24 May 2006 03:27:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4OAR5u2026115; Wed, 24 May 2006 03:27:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4OAR5Bj026088 for ; Wed, 24 May 2006 03:27:05 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.2.180] (83-70-224-224.b-ras1.prp.dublin.eircom.net [83.70.224.224]) by chilco.textdrive.com (Postfix) with ESMTP id 736AADBCCF for ; Wed, 24 May 2006 10:26:59 +0000 (UTC) Message-ID: <447434F1.5080801@dehora.net> Date: Wed, 24 May 2006 11:26:57 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: atom-syntax Subject: Re: Model vs Syntax References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <1711287765.20060520164942@djpowell.net> <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> <20060524094806.GY32180@klangraum> In-Reply-To: <20060524094806.GY32180@klangraum> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4OAR5is026116 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 A. Pagaltzis wrote: > By and large, I agree with him that it would have been beneficial > to specify Atom just a little more closely at a model level. But > I also agree with you that aspiring to much higher rigor beyond > the Infoset level is unnecessary. >=20 > My retrospective opinion is that the correct approach would have > been to specify that an Atom Feed Document consists of a series > of completely independent Atom Entries, each of which can be > interpreted in isolation of any others as well as of the Atom > Feed Document that they are found in (modulo Person Construct > inheritance). This would explicitly allow consumers to rely on > this atomicity (pun intended), thus preventing any extensions > from crossing these boundaries. >=20 > This goes beyond the mere interchange of messages to a definition > of a standardised model, though as you can see, it=E2=80=99s a very loo= se > one. I contend it is also the model used implicitly by any useful > aggregator which tracks feed content over time. I think this group would not have been able to agree on what "a little=20 more" was, the current situation makes sense to me. IMO, the Infoset is=20 no basis for a model; it's there for spec writers and marshalling off=20 the wire. cheers Bill From owner-atom-syntax@mail.imc.org Wed May 24 09:59:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FittG-0003JM-0N for atompub-archive@lists.ietf.org; Wed, 24 May 2006 09:59:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FittD-00005d-KL for atompub-archive@lists.ietf.org; Wed, 24 May 2006 09:59:09 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ODl6sI070468; Wed, 24 May 2006 06:47:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4ODl6UK070467; Wed, 24 May 2006 06:47:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ODl5UI070433 for ; Wed, 24 May 2006 06:47:05 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so2073006pyf for ; Wed, 24 May 2006 06:47:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RL/du8pMsIXVeY4ajoIoIWMx3kSyEiwIvdnLmF73NLq96OTs1+II0BJ8SZQdb6g8yHgCsvQ0COxpVYrdMIdLgfLjb6KF/IuUw68sGk3NmVU0UHtNxfmcOiQVvwQG41Naxg7ERhj3Iqq4RTQpSEfZVdYIOuKmFOQGKXKiPQLZ7yo= Received: by 10.35.34.20 with SMTP id m20mr1308777pyj; Wed, 24 May 2006 06:47:00 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 24 May 2006 06:47:00 -0700 (PDT) Message-ID: <68fba5c50605240647r2184923dkbd0aabc57e74fbef@mail.gmail.com> Date: Wed, 24 May 2006 09:47:00 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Atompub WG meeting at the Montreal IETF Cc: "Atom WG" , atom-protocol@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4ODl5UI070454 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 5/23/06, Paul Hoffman wrote: > > The timing of us having our first WG meeting may seem odd, given the > fact that we completed the Atom format document long ago, and are > making good progress on the publishing protocol. We are? Pull the trigger, already. > > I propose the following agenda, which should fit well into a one-hour slot: > Looks like that will be a very good use of time. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 24 10:04:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FityJ-0005XY-0m for atompub-archive@lists.ietf.org; Wed, 24 May 2006 10:04:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FityH-0000LT-MS for atompub-archive@lists.ietf.org; Wed, 24 May 2006 10:04:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ODi6vW069806; Wed, 24 May 2006 06:44:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4ODi6Us069805; Wed, 24 May 2006 06:44:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4ODi5R7069791 for ; Wed, 24 May 2006 06:44:06 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so2072139pyf for ; Wed, 24 May 2006 06:44:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kQOawTisf6Z8hGit3R0Uf97etdjrj/ii8b/H2H4/6oBu31TvldBgvWWJ35KzHKDUfNQEzbiyv6Zm1opG6yttcPAjdCAkILvwvwPUhuO+6DCByzLEyilgP6y74ZE1GDj9PuvfXj5HiJFXOTnGn5AKsh8VDb+uI82BWze1F4HNckw= Received: by 10.35.70.17 with SMTP id x17mr406051pyk; Wed, 24 May 2006 06:44:05 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Wed, 24 May 2006 06:44:05 -0700 (PDT) Message-ID: <68fba5c50605240644r4b3aa2c8lbbc12b603f9b7bc@mail.gmail.com> Date: Wed, 24 May 2006 09:44:05 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Fyi, Apache project proposal Cc: "Atom Syntax" In-Reply-To: <447332C8.2090207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <44723430.1050606@gmail.com> <44730083.2060909@metalab.unc.edu> <15391.194.221.74.7.1148389161.squirrel@mail1.python-hosting.com> <39CBEFFC3DB52599E5403DE3@adsl-64-166-133-246.dsl.snfc21.pacbell.net> <39416.194.221.74.7.1148396991.squirrel@mail1.python-hosting.com> <447329BF.8080309@metalab.unc.edu> <44732EC3.7050403@jabber.org> <447332C8.2090207@gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4ODi6R7069800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On 5/23/06, James M Snell wrote: > > We made a mistake calling our stuff a "reference implementation" It's OK. We're used to this kind of thing coming from your direction. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 24 17:11:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0dn-0008W9-Lh for atompub-archive@lists.ietf.org; Wed, 24 May 2006 17:11:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0dk-00016k-9S for atompub-archive@lists.ietf.org; Wed, 24 May 2006 17:11:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4OKmBdf072473; Wed, 24 May 2006 13:48:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4OKmBOR072472; Wed, 24 May 2006 13:48:11 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4OKmAEo072465 for ; Wed, 24 May 2006 13:48:10 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i7so1590153wra for ; Wed, 24 May 2006 13:48: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:mime-version:to:subject:content-type:content-transfer-encoding; b=bKbhUoZqrGTV53jSRbibdgn26UqJ6DILSwLgiEiJbWp1V6iwFvhqnttAw/XheJ0KO73MT0YKAM04Oh7ZHw9XCzjWkwM7SHs/hpu1XgZISk0m8ZA4xLZ/mr17L2qGw4687vqOfX052rZMw3alBbGGMD8fJ6jmbnxYTboxHjc1LTM= Received: by 10.54.93.16 with SMTP id q16mr3989320wrb; Wed, 24 May 2006 13:48:06 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 14sm7574079wrl.2006.05.24.13.48.05; Wed, 24 May 2006 13:48:05 -0700 (PDT) Message-ID: <4474C682.3040001@gmail.com> Date: Wed, 24 May 2006 13:48:02 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax Subject: Feed Thread draft -11 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 FYI http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-11.txt - James From owner-atom-syntax@mail.imc.org Thu May 25 20:06:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPqn-0004lT-7j for atompub-archive@lists.ietf.org; Thu, 25 May 2006 20:06:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjPqh-0007qX-Mj for atompub-archive@lists.ietf.org; Thu, 25 May 2006 20:06:45 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4PNqk4n053516; Thu, 25 May 2006 16:52:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4PNqkFw053515; Thu, 25 May 2006 16:52:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout01-winn.ispmail.ntl.com (mta07-winn.ispmail.ntl.com [81.103.221.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4PNqi9Y053455 for ; Thu, 25 May 2006 16:52:45 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20060525235238.MZSX29343.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Fri, 26 May 2006 00:52:38 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060525235238.NKKP24467.aamtaout02-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Fri, 26 May 2006 00:52:38 +0100 Date: Fri, 26 May 2006 00:52:37 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <128376965.20060526005237@djpowell.net> To: Tim Bray CC: atom-syntax Subject: Re: Feed Thread in Last Call In-Reply-To: <3ED0B390-41B9-483F-BC05-8C855116EBDB@sun.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <446C926E.6080605@gmail.com> <68fba5c50605180856q1c3b073ag627d0199773ab7a7@mail.gmail.com> <1711287765.20060520164942@djpowell.net> <3ED0B390-41B9-483F-BC05-8C855116EBDB@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Tuesday, May 23, 2006, 10:31:37 PM, Tim Bray wrote: > I would say that furious debates about elements-vs-attributes have > been going on since the dawn of XML in 1998, but that would be > untrue; they've been going on since the dawn of XML's precursor SGML > in 1986. They have never led anywhere. After you've noticed that if > you need nested element structure you're stuck with elements, and if > you don't want to have two things with the same names attributes can > help, there really aren't any deterministic decision procedures. > I note with pleasure that *all* known XML APIs allow you to retrieve > elements and attributes with about the same degree of difficulty. What Aristotle said. Yes, I agree, but debate over elements vs attributes in generic XML isn't relevant. > So, my conclusion: I disagree with Powell. Let people put extensions > wherever they feel like putting them (they will anyhow), remembering > that human-readability is a virtue. If models try to micro-manage > the element/attribute thing, those models are broken, don't use > them. > If software arbitrarily discards markup because the markup > doesn't match its idiosyncratic ideas about elements and attributes, > that software is non-comformant and non-interoperable. I'm a bit surprised that you're saying this. I'm not sure why you think it is non-conformant to discard extensions. RFC4287 doesn't describe any conformance criteria for Atom intermediaries. Over on atom-protocol, there were a number of implementors who are ignoring/rewriting client-supplied atom:ids - about the most fundamental way that you could possibly change an atom document - and you didn't seem to disapprove of this? People have also said in the past that they planned not to preserve extensions, and I don't remember there being many objections. If it is non-conformant and non-interoperable to discard extensions, then why doesn't APP prohibit it? >> Extension elements are defined to have both a model and a syntax, but >> Atom's allowance for foreign attributes to appear anywhere is a case >> of syntax that has no corresponding model. Atom doesn't really explain >> what foreign attributes are intended for. > Extension elements also, as noted above, have *no normative effect*. I don't know what "no normative effect" means. > This is only true for software which ignores the fact that RFC4287 is > specified only in terms of the XML Infoset. If you lose information > because it doesn't match up with some ex post facto model you've > dreamed up, you cannot expect to achieve interoperability. But every implementor is dreaming up ex post facto models. > Obviously, but the notion that this depends on whether you use an > attribute or an element seems really, really bizarre to me. An > intermediary that drops markup it doesn't recognize won't last long > in the marketplace, whether those are elements or attributes. It is easier to support extensibility in 3 places, than on every possible element in the document. Storing entry extensions in a database table is possible, storing atom:updated attributes, is getting silly. >> Interoperability should take priority of concerns that 'approach X >> looks >> better than Y', and other unjustifiable minor concerns. > Yes, and interoperability is based on the normative rules in RFC4287, > right? Wrong (in my opinion). There are no normative rules for the behaviour of Atom intermediaries. Given the absence of such rules, the next best way to ensure interoperability to understand the typical behaviour of Atom implementations: the fact that it is easier for some implementations to support "Extension Elements" in the 3 defined extension points than foreign attributes on every element in an Atom document; that this translates to more implementations supporting extension elements than attributes; and that this implies that an extension would be more interoperable if it chooses Section 6.4 markup over undefined foreign markup. -- Dave From owner-atom-syntax@mail.imc.org Fri May 26 09:46:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjceR-0002ZM-L5 for atompub-archive@lists.ietf.org; Fri, 26 May 2006 09:46:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjceJ-000234-76 for atompub-archive@lists.ietf.org; Fri, 26 May 2006 09:46:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QDVpgQ070469; Fri, 26 May 2006 06:31:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QDVpue070468; Fri, 26 May 2006 06:31:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QDVnko070436 for ; Fri, 26 May 2006 06:31:50 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1FjcPs-0008Qo-6J; Fri, 26 May 2006 15:31:48 +0200 Received: from ultra13.rbg.informatik.tu-darmstadt.de ([130.83.160.103]) by mx1.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.61-RC1 #1) id 1FjcPs-00028o-4Y; Fri, 26 May 2006 15:31:48 +0200 Message-ID: <4477033C.4060602@rbg.informatik.tu-darmstadt.de> Date: Fri, 26 May 2006 15:31:40 +0200 From: Andreas Sewe Organization: Fachbereich Informatik, TU Darmstadt User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Holderness CC: James M Snell , atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> In-Reply-To: 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 James Holderness wrote: > For the second I'd recommend this: > > href="http://www.snellspace.com/public/alternate2" /> > href="http://www.snellspace.com/public/alternate" /> > href="http://www.snellspace.com/public/alternate2" /> > > Also, where does it say that the @rel attribute is case sensitive? I > couldn't find anything in RFC4287, but in HTML at least link types are > definately case INsensitive [1]. Well, I guess section 4.2.7.2. states this implicitly; names registered within the IANA Registry of Link Relation ("alternate") are to be interpreted as being equivalent to an IRI (). And the path component of IRIs is case-sensitive. But the test cases should IMHO not test whether "ALTERNATE" works, since it should not, but whether "http://www.iana.org/assignments/relation/alternate" does. But then again my reading of 4.2.7.2 might be wrong. Regards, Andreas > [1] http://www.w3.org/TR/html401/types.html#h-6.12 From owner-atom-syntax@mail.imc.org Fri May 26 10:25:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdFg-0004Tf-Nk for atompub-archive@lists.ietf.org; Fri, 26 May 2006 10:25:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjbco-0004TP-NK for atompub-archive@lists.ietf.org; Fri, 26 May 2006 08:41:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjbWU-00071M-Rr for atompub-archive@lists.ietf.org; Fri, 26 May 2006 08:34:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QCLhUp024927; Fri, 26 May 2006 05:21:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QCLhaB024926; Fri, 26 May 2006 05:21:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav15.bay109.hotmail.com [64.4.19.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QCLgmJ024915 for ; Fri, 26 May 2006 05:21:42 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 May 2006 05:21:42 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV15.phx.gbl with DAV; Fri, 26 May 2006 12:21:40 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "James M Snell" , References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> Subject: Re: Link rel test cases Date: Fri, 26 May 2006 13:21:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 26 May 2006 12:21:42.0294 (UTC) FILETIME=[F23E2B60:01C680BE] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.6 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Just following up on these tests. Both are in need of flanking links to catch aggregators that just return the first or the last link regardless of the @rel. For the first test I'd recommend something like this: For the second I'd recommend this: As an example, JetBrains Omea currently passes both your tests as they are. If they were changed as recommended, it would fail both of them. Also, where does it say that the @rel attribute is case sensitive? I couldn't find anything in RFC4287, but in HTML at least link types are definately case INsensitive [1]. Regards James [1] http://www.w3.org/TR/html401/types.html#h-6.12 James M Snell wrote: > Yes, I'll make those changes this evening. > > James Holderness wrote: >> May I suggest you add a third link with rel="ALTERNATE" in your second >> test. As it is you're catching aggregators that choose the first of >> multiple alternate links, but not catching those that choose the last >> link. From owner-atom-syntax@mail.imc.org Fri May 26 12:03:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjemi-00075A-0a for atompub-archive@lists.ietf.org; Fri, 26 May 2006 12:03:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjemg-0001nT-HX for atompub-archive@lists.ietf.org; Fri, 26 May 2006 12:03:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QFcukh053249; Fri, 26 May 2006 08:38:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QFcuwx053248; Fri, 26 May 2006 08:38:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QFctUD053230 for ; Fri, 26 May 2006 08:38:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so368586wri for ; Fri, 26 May 2006 08:38:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=L2Y4MoIP/2fkxUIz8U+8nzD47h55LmUqgiYYEidM/gCwC5oZqvPyzJeXWB1cZ6d/ECT23VhZ5kFCOBP2Nv1TIT9YjOGnLj6LOOEb8EuxeYNNTMjnprjA35p1aWIG3cuAL10NzVr4ylMps90PWjVs4moTjdfWOAlqKFDwSBWD26U= Received: by 10.54.132.6 with SMTP id f6mr1756278wrd; Fri, 26 May 2006 08:38:22 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 14sm2267783wrl.2006.05.26.08.38.21; Fri, 26 May 2006 08:38:22 -0700 (PDT) Message-ID: <447720EB.7030206@gmail.com> Date: Fri, 26 May 2006 08:38:19 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> In-Reply-To: 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Updated. Two additional tests were also added. - James James Holderness wrote: > Just following up on these tests. Both are in need of flanking links to > catch aggregators that just return the first or the last link regardless > of the @rel. For the first test I'd recommend something like this: > > href="http://www.snellspace.com/public/random" /> > href="http://www.snellspace.com/public/alternate" /> > href="http://www.snellspace.com/public/random" /> > > For the second I'd recommend this: > > href="http://www.snellspace.com/public/alternate2" /> > href="http://www.snellspace.com/public/alternate" /> > href="http://www.snellspace.com/public/alternate2" /> > > As an example, JetBrains Omea currently passes both your tests as they > are. If they were changed as recommended, it would fail both of them. > > Also, where does it say that the @rel attribute is case sensitive? I > couldn't find anything in RFC4287, but in HTML at least link types are > definately case INsensitive [1]. > > Regards > James > > [1] http://www.w3.org/TR/html401/types.html#h-6.12 > > James M Snell wrote: >> Yes, I'll make those changes this evening. >> >> James Holderness wrote: >>> May I suggest you add a third link with rel="ALTERNATE" in your second >>> test. As it is you're catching aggregators that choose the first of >>> multiple alternate links, but not catching those that choose the last >>> link. > From owner-atom-syntax@mail.imc.org Fri May 26 13:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfkb-0006WU-DV for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:05:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfkV-00010w-Ve for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:05:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QGsGeO001884; Fri, 26 May 2006 09:54:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QGsG81001883; Fri, 26 May 2006 09:54:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QGsFCp001800 for ; Fri, 26 May 2006 09:54:15 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060526165409.UGDN29040.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Fri, 26 May 2006 17:54:09 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20060526165408.IYRR16286.aamtaout03-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Fri, 26 May 2006 17:54:08 +0100 Date: Fri, 26 May 2006 17:54:08 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <1499268688.20060526175408@djpowell.net> To: Andreas Sewe CC: James Holderness , James M Snell , Subject: Re: Link rel test cases In-Reply-To: <4477033C.4060602@rbg.informatik.tu-darmstadt.de> References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Friday, May 26, 2006, 2:31:40 PM, Andreas Sewe wrote: > But the test cases should IMHO not test whether "ALTERNATE" works, since > it should not, but whether > "http://www.iana.org/assignments/relation/alternate" does. But then > again my reading of 4.2.7.2 might be wrong. I agree. link@rel is case sensitive as it is an IRI-ref, therefore ALTERNATE isn't correct. Any resemblance of HTML's link rel is purely coincidental. Actually, as @rel is an IRI-ref with "http://www.iana.org/assignments/relation/" as its base-IRI, sick stuff like this should work: -- Dave From owner-atom-syntax@mail.imc.org Fri May 26 13:09:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfor-0002EE-6Z for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:09:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjfon-0001ru-MW for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:09:49 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QGrQpL001338; Fri, 26 May 2006 09:53:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QGrQ2X001336; Fri, 26 May 2006 09:53:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav8.bay109.hotmail.com [64.4.19.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QGrQ9g001327 for ; Fri, 26 May 2006 09:53:26 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 May 2006 09:53:25 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV8.phx.gbl with DAV; Fri, 26 May 2006 16:53:23 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <447720EB.7030206@gmail.com> Subject: Re: Link rel test cases Date: Fri, 26 May 2006 17:53:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 26 May 2006 16:53:25.0802 (UTC) FILETIME=[E7E410A0:01C680E4] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f I'm still seeing the same old feed. Ran it through the feedvalidator too so I don't think it's a cache problem on my side. Is there any reason why it shouldn't show up straight away? I'm looking at this URL btw: http://www.snellspace.com/public/linkreltest.xml Regards James James M Snell wrote: > Updated. Two additional tests were also added. > > James Holderness wrote: >> Just following up on these tests. Both are in need of flanking links to >> catch aggregators that just return the first or the last link regardless >> of the @rel. From owner-atom-syntax@mail.imc.org Fri May 26 13:19:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfyS-0005KR-03 for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:19:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfyQ-00038F-Jk for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:19:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QH5H40008500; Fri, 26 May 2006 10:05:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QH5HC4008499; Fri, 26 May 2006 10:05:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav8.bay109.hotmail.com [64.4.19.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QH5GjG008482 for ; Fri, 26 May 2006 10:05:16 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 May 2006 10:05:16 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV8.phx.gbl with DAV; Fri, 26 May 2006 17:05:14 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <1499268688.20060526175408@djpowell.net> Subject: Re: Link rel test cases Date: Fri, 26 May 2006 18:05:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 26 May 2006 17:05:16.0156 (UTC) FILETIME=[8F4B7BC0:01C680E6] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 David Powell wrote: > Actually, as @rel is an IRI-ref with > "http://www.iana.org/assignments/relation/" as its base-IRI, sick > stuff like this should work: > > No it shouldn't. It's not actually an IRI-ref. From section 4.2.7.2: The value of "rel" MUST be a string that is non-empty and matches either the "isegment-nz-nc" or the "IRI" production in [RFC3987]. Note that use of a relative reference other than a simple name is not allowed. Regards James From owner-atom-syntax@mail.imc.org Fri May 26 13:53:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjgUr-0000A3-Fa for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:53:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjgUp-0008Me-1y for atompub-archive@lists.ietf.org; Fri, 26 May 2006 13:53:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHZJPM027586; Fri, 26 May 2006 10:35:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QHZJxV027585; Fri, 26 May 2006 10:35:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav3.bay109.hotmail.com [64.4.19.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHZJnx027570 for ; Fri, 26 May 2006 10:35:19 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 May 2006 10:35:18 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV3.phx.gbl with DAV; Fri, 26 May 2006 17:35:14 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> Subject: Re: Link rel test cases Date: Fri, 26 May 2006 18:35:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 26 May 2006 17:35:18.0781 (UTC) FILETIME=[C1BE3AD0:01C680EA] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Andreas Sewe wrote: >> Also, where does it say that the @rel attribute is case sensitive? I >> couldn't find anything in RFC4287, but in HTML at least link types are >> definately case INsensitive [1]. > > Well, I guess section 4.2.7.2. states this implicitly; names registered > within the IANA Registry of Link Relation ("alternate") are to be > interpreted as being equivalent to an IRI > (). And the path > component of IRIs is case-sensitive. I considered that, but if you want to assume IRI comparison semantics, then does that mean a link type of "%61lternate" is equivalent to "alternate" too? Or what about "HTTP://www.IANA.org:80/assignments/relation/alternate"? Logically I would assume the simple string comparison in section 5.3.1 of RFC3987, but I was hoping this would be documented somewhere more explicitly. An atom:id is an IRI too, but it explicitly specifies character-by-character, case-sensitive comparisons. By not doing the same for link relations the spec kind of leaves things open to interpretation. > But the test cases should IMHO not test whether "ALTERNATE" works, since > it should not, but whether > "http://www.iana.org/assignments/relation/alternate" does. That's what the first test case is supposed to be doing. Regards James From owner-atom-syntax@mail.imc.org Fri May 26 14:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgr9-0004ba-HI for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:16:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgr7-0001gb-3u for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:16:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHvapS041373; Fri, 26 May 2006 10:57:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QHvahc041372; Fri, 26 May 2006 10:57:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHvYBq041343 for ; Fri, 26 May 2006 10:57:35 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id c30so29096pyc for ; Fri, 26 May 2006 10:57:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R49fub8XJus01reFIg1YgLOoZSAsZ62+wE9r+ngSymcid8DgffOrcQelG57iwHY0rP4IUGmkjiiHnh+aLQvBYvry2we14+iQ+NBQIOUJmBcqV6eokE9B4ihMeAIeUcUvXpOO6XkNAc/kyXnbAAN/BPPGMr6DilhuQWeLNgmFKm0= Received: by 10.35.9.2 with SMTP id m2mr991050pyi; Fri, 26 May 2006 10:57:03 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Fri, 26 May 2006 10:57:03 -0700 (PDT) Message-ID: <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> Date: Fri, 26 May 2006 13:57:03 -0400 From: "Robert Sayre" To: "James Holderness" Subject: Re: Link rel test cases Cc: atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4QHvZBq041361 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On 5/26/06, James Holderness wrote: > > Logically I would assume the simple string comparison in section 5.3.1 of > RFC3987, but I was hoping this would be documented somewhere more > explicitly. An atom:id is an IRI too, but it explicitly specifies > character-by-character, case-sensitive comparisons. By not doing the same > for link relations the spec kind of leaves things open to interpretation. RFC3986, section 6 and RFC3987, section 5 document this procedure very well. The comparison ladder reduces false negatives in exchange for processing effort. If you think the ladder is worth climbing in this case, go for it. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Fri May 26 14:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhBP-0006Ct-CB for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:37:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjhBN-00034S-V9 for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:37:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHM3uV019275; Fri, 26 May 2006 10:22:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QHM3Vq019274; Fri, 26 May 2006 10:22:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QHM3oX019254 for ; Fri, 26 May 2006 10:22:03 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so388116wri for ; Fri, 26 May 2006 10:22:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Wyr56MouYQnZi1EZup3r48cdc+NiSsS2PsMcF0gAIZG9hBUNhIUyaE8Ny2tSQsZCGjD52/y+1HnJionluD5BpeO4wthiUclmCfcSZ9IdTNU4rJJQvBoh/8/Iom8vfGS0AT0mK3svGi9dKEq7DTxwMuBkyl3Jo7dO9fJbyk51WV8= Received: by 10.54.141.18 with SMTP id o18mr754225wrd; Fri, 26 May 2006 10:21:30 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 9sm578148wrl.2006.05.26.10.21.29; Fri, 26 May 2006 10:21:30 -0700 (PDT) Message-ID: <44773917.5050903@gmail.com> Date: Fri, 26 May 2006 10:21:27 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: David Powell CC: Andreas Sewe , James Holderness , atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <1499268688.20060526175408@djpowell.net> In-Reply-To: <1499268688.20060526175408@djpowell.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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 David Powell wrote: >[snip] > Actually, as @rel is an IRI-ref with > "http://www.iana.org/assignments/relation/" as its base-IRI, sick > stuff like this should work: > > > From 4.2.7.2 : "Note that use of a relative reference other than a simple name is not allowed." so it's either "alternate" or the full URI "http://www.iana.org/assignments/relation/alternate". No other form is allowed. - James From owner-atom-syntax@mail.imc.org Fri May 26 14:53:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhR7-0005Al-Dz for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:53:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjhR6-0005Lq-0N for atompub-archive@lists.ietf.org; Fri, 26 May 2006 14:53:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QIbADf066768; Fri, 26 May 2006 11:37:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QIbAQW066761; Fri, 26 May 2006 11:37:10 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QIb9PJ066745 for ; Fri, 26 May 2006 11:37:09 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 67so401034wri for ; Fri, 26 May 2006 11:37:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sXwzzWSjF0ZMpAPJ13epRcx/MVSH+kJL8RvLKpegmUYbM/P6Y6QHM6vmsJ7yLlbBwXcmZiQF4xmCe4AOAGEQa3OHJPBaFmmVDoiodspkw/3HBX/212yIwSnGtuXCTSEaGv13FbhyGe56pDAML4SR45+5o5PO43jUd58vpGSsKR8= Received: by 10.54.127.4 with SMTP id z4mr823939wrc; Fri, 26 May 2006 11:36:39 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 6sm1504859wrl.2006.05.26.11.36.38; Fri, 26 May 2006 11:36:38 -0700 (PDT) Message-ID: <44774AA7.90200@gmail.com> Date: Fri, 26 May 2006 11:36:23 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <447720EB.7030206@gmail.com> In-Reply-To: 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Doh! I had updated the wrong test file. - James James Holderness wrote: > > I'm still seeing the same old feed. Ran it through the feedvalidator too > so I don't think it's a cache problem on my side. Is there any reason > why it shouldn't show up straight away? I'm looking at this URL btw: > > http://www.snellspace.com/public/linkreltest.xml > > Regards > James > > James M Snell wrote: >> Updated. Two additional tests were also added. >> >> James Holderness wrote: >>> Just following up on these tests. Both are in need of flanking links to >>> catch aggregators that just return the first or the last link regardless >>> of the @rel. > > From owner-atom-syntax@mail.imc.org Fri May 26 15:08:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjhfG-0004sa-Id for atompub-archive@lists.ietf.org; Fri, 26 May 2006 15:08:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjhfF-0007UN-4z for atompub-archive@lists.ietf.org; Fri, 26 May 2006 15:08:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QIsKV9077986; Fri, 26 May 2006 11:54:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QIsKNu077985; Fri, 26 May 2006 11:54:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mtaout02-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QIsI2E077915 for ; Fri, 26 May 2006 11:54:19 -0700 (MST) (envelope-from djpowell@djpowell.net) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060526185413.YWLD29040.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Fri, 26 May 2006 19:54:13 +0100 Received: from cpc1-stok1-0-0-cust263.bagu.cable.ntl.com ([86.4.229.8]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20060526185413.SOYG19763.aamtaout01-winn.ispmail.ntl.com@cpc1-stok1-0-0-cust263.bagu.cable.ntl.com>; Fri, 26 May 2006 19:54:13 +0100 Date: Fri, 26 May 2006 19:54:12 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <954552624.20060526195412@djpowell.net> To: "Robert Sayre" CC: "James Holderness" , atom-syntax@imc.org Subject: Re: Link rel test cases In-Reply-To: <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@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: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Friday, May 26, 2006, 6:57:03 PM, Robert Sayre wrote: > On 5/26/06, James Holderness wrote: >> >> Logically I would assume the simple string comparison in section 5.3.1 of >> RFC3987, but I was hoping this would be documented somewhere more >> explicitly. An atom:id is an IRI too, but it explicitly specifies >> character-by-character, case-sensitive comparisons. By not doing the same >> for link relations the spec kind of leaves things open to interpretation. > RFC3986, section 6 and RFC3987, section 5 document this procedure very > well. The comparison ladder reduces false negatives in exchange for > processing effort. If you think the ladder is worth climbing in this > case, go for it. Yeah, equally if you are a publisher, and don't want to restrict interoperability to just the set of clients that climb the ladder, then don't do anything stupid. We probably should have specified the "simple string comparison" method; it is more satisfying to call an implementation that publishes not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'. -- Dave From owner-atom-syntax@mail.imc.org Fri May 26 16:26:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjitd-0000cI-Tu for atompub-archive@lists.ietf.org; Fri, 26 May 2006 16:26:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjib0-0007Kp-8V for atompub-archive@lists.ietf.org; Fri, 26 May 2006 16:07:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjiMW-00048C-Qa for atompub-archive@lists.ietf.org; Fri, 26 May 2006 15:52:50 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QJbRos004367; Fri, 26 May 2006 12:37:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4QJbR8C004366; Fri, 26 May 2006 12:37:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4QJbPXZ004352 for ; Fri, 26 May 2006 12:37:26 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so224670pye for ; Fri, 26 May 2006 12:37:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rJzSheSwQr/g+ueHl9NTzgf8Tdi5Bfdpei9/PeH23buoRoQiNPoNtjZNfnVLRbaTy+nvcruGDW2y1Ezjy22u2zo4O5zrsBLUDnQM473mD6jCmri1PUK9dSznB/8gyHDCqCI5yrsLsagXtxZvXjgROT7XoMidpHVMbvLxxR+Eqts= Received: by 10.35.91.15 with SMTP id t15mr1109131pyl; Fri, 26 May 2006 12:37:25 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Fri, 26 May 2006 12:37:25 -0700 (PDT) Message-ID: <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> Date: Fri, 26 May 2006 15:37:25 -0400 From: "Robert Sayre" To: "David Powell" Subject: Re: Link rel test cases Cc: "James Holderness" , atom-syntax@imc.org In-Reply-To: <954552624.20060526195412@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k4QJbQXZ004360 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.1 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 5/26/06, David Powell wrote: > > We probably should have specified the "simple string comparison" > method; it is more satisfying to call an implementation that publishes > not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'. Huh, I personally feel that the comparison ladder is better. Sort of like, "if it comes down to that, we can't help you", even for atom:id. The WG definitely felt simple string comparison was needed for atom:id, so we spent *a lot* of time on that text. I don't feel that effort would pay off here, at all. Especially since a consumer that matched "HTTP://www.IANA.org:80/assignments/relation/alternate" would be in error. That's ridiculous standards weenie stuff, don't you think? -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Sun May 28 21:59:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkX2r-0004VF-48 for atompub-archive@lists.ietf.org; Sun, 28 May 2006 21:59:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkWt2-0002BP-KN for atompub-archive@lists.ietf.org; Sun, 28 May 2006 21:49:44 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4T1T1b1028383; Sun, 28 May 2006 18:29:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4T1T1ZG028382; Sun, 28 May 2006 18:29:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from svcstatl07.hotspot.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4T1T016028359 for ; Sun, 28 May 2006 18:29:01 -0700 (MST) (envelope-from bob@wyman.us) Received: from BOBSLAPTOP (173.66.250.10.in-addr.arpa [10.250.66.173]) by svcstatl07.hotspot.t-mobile.com (8.12.10+Sun/8.12.10) with ESMTP id k4T1SvLU020709; Sun, 28 May 2006 21:28:58 -0400 (EDT) From: "Bob Wyman" To: "'James M Snell'" , "'atom-syntax'" Subject: RE: Fyi, Apache project proposal Date: Sun, 28 May 2006 21:28:52 -0400 Message-ID: <002701c682bf$41bae690$ad42fa0a@BOBSLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ972ffGhZaxJDwTWGuNAkSK/JADwEzsDYQ In-Reply-To: <44723430.1050606@gmail.com> X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 adultscore=0 adjust=0 reason=mlx engine=3.1.0-06051700 definitions=3.0.0-06052808 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 James M Snell mentioned his Apache Project... It would be *very* nice if you could see your way to implementing "RFC3229+feed"[1] support in your implementation. As I think you know, the use of this mechanism results in massive reductions in the bandwidth and client-side processing required in fetching updates to Atom feeds. Also, Microsoft will be supporting RFC3229+feed in their browsers[2], thus, we can anticipate that support for fetching delta-feeds will soon be considered expected. The only "issue" with Apache is that Apache *still* does not support the "226" response code... bob wyman [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html http://bobwyman.pubsub.com/main/2004/09/implementations.html http://www.intertwingly.net/blog/2004/09/15/Syndication-with-RFC3229 [2] http://bobwyman.pubsub.com/main/2006/04/microsoft_to_su.html From owner-atom-syntax@mail.imc.org Sun May 28 22:36:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkXcQ-0004sW-4R for atompub-archive@lists.ietf.org; Sun, 28 May 2006 22:36:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkXcN-0005sc-Mp for atompub-archive@lists.ietf.org; Sun, 28 May 2006 22:36:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4T2Ktxx062884; Sun, 28 May 2006 19:20:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4T2KtO2062882; Sun, 28 May 2006 19:20:55 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4T2KsQK062859 for ; Sun, 28 May 2006 19:20:54 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id c30so175888pyc for ; Sun, 28 May 2006 19:20:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ecEqtTRdSzQ0vYFZbr0Pk6LLdY520pkybztVBRwyeE4Xk2MBw5nF3RcldQZELrt2Pr/GD9+pphyXJ/pgVeFawFpYntbRdnnOCnMGzP6W9wqhBE8TiyNIUQRBCUbo8Haiif9uDJVdS0bNscD90IaGTQsXgT3iM2KyDHxapNUiAkg= Received: by 10.35.95.12 with SMTP id x12mr2516492pyl; Sun, 28 May 2006 19:20:54 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id f20sm265493pyf.2006.05.28.19.20.53; Sun, 28 May 2006 19:20:54 -0700 (PDT) Message-ID: <447A5A81.2000101@gmail.com> Date: Sun, 28 May 2006 19:20:49 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Bob Wyman CC: "'atom-syntax'" Subject: Re: Fyi, Apache project proposal References: <002701c682bf$41bae690$ad42fa0a@BOBSLAPTOP> In-Reply-To: <002701c682bf$41bae690$ad42fa0a@BOBSLAPTOP> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Yep, I've already implemented support for this in the as yet unavailable client code I've been working (rather slowly, unfortunately) to clean up. - James Bob Wyman wrote: > James M Snell mentioned his Apache Project... > > It would be *very* nice if you could see your way to implementing > "RFC3229+feed"[1] support in your implementation. As I think you know, the > use of this mechanism results in massive reductions in the bandwidth and > client-side processing required in fetching updates to Atom feeds. Also, > Microsoft will be supporting RFC3229+feed in their browsers[2], thus, we can > anticipate that support for fetching delta-feeds will soon be considered > expected. The only "issue" with Apache is that Apache *still* does not > support the "226" response code... > > bob wyman > > [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html > http://bobwyman.pubsub.com/main/2004/09/implementations.html > http://www.intertwingly.net/blog/2004/09/15/Syndication-with-RFC3229 > [2] http://bobwyman.pubsub.com/main/2006/04/microsoft_to_su.html > > > From owner-atom-syntax@mail.imc.org Tue May 30 01:59:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxGf-00027O-SR for atompub-archive@lists.ietf.org; Tue, 30 May 2006 01:59:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxGc-0003Rt-DO for atompub-archive@lists.ietf.org; Tue, 30 May 2006 01:59:49 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4U5kfvf069997; Mon, 29 May 2006 22:46:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4U5kftn069996; Mon, 29 May 2006 22:46:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4U5kc11069894 for ; Mon, 29 May 2006 22:46:39 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4U5kO0l018822; Tue, 30 May 2006 14:46:25 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 6c4c_a18467d4_ef9f_11da_9ef5_0014221f2a2d; Tue, 30 May 2006 14:46:23 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4U5iW9G009058; Tue, 30 May 2006 14:45:08 +0900 Message-Id: <6.0.0.20.2.20060530124651.0983a180@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 30 May 2006 12:51:19 +0900 To: "Robert Sayre" , "David Powell" From: Martin Duerst Subject: Re: Link rel test cases Cc: "James Holderness" , atom-syntax@imc.org In-Reply-To: <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.co m> References: <444C2C01.5040005@intertwingly.net> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 At 04:37 06/05/27, Robert Sayre wrote: >Huh, I personally feel that the comparison ladder is better. Sort of >like, "if it comes down to that, we can't help you", even for atom:id. >The WG definitely felt simple string comparison was needed for >atom:id, so we spent *a lot* of time on that text. I think for simple IDs, where there is no expectation of resolution, character-by-character comparison is better. But either way, the spec is the way it is now. >I don't feel that effort would pay off here, at all. Especially since >a consumer that matched >"HTTP://www.IANA.org:80/assignments/relation/alternate" would be in >error. That's ridiculous standards weenie stuff, don't you think? Yes, a content producer that expected a) HTTP://www.IANA.org:80/assignments/relation/alternate to always be different from b) http://www.iana.org/assignments/relation/alternate would be stupid. But on the other hand, a content producer that expected a) and b) to always be treated the same would be ridiculous, too. The conclusion is that a content producer that uses HTTP://www.IANA.org:80/assignments/relation/alternate at all does something wrong. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Tue May 30 01:59:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxGh-00027z-SO for atompub-archive@lists.ietf.org; Tue, 30 May 2006 01:59:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxGc-0003Rs-DO for atompub-archive@lists.ietf.org; Tue, 30 May 2006 01:59:51 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4U5knYg070091; Mon, 29 May 2006 22:46:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4U5knsq070090; Mon, 29 May 2006 22:46:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4U5kmcs070014 for ; Mon, 29 May 2006 22:46:48 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4U5ke9E003643; Tue, 30 May 2006 14:46:40 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1cec_aa762b3e_ef9f_11da_88b5_0014221fa3c9; Tue, 30 May 2006 14:46:39 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4U5iW9K009058; Tue, 30 May 2006 14:46:17 +0900 Message-Id: <6.0.0.20.2.20060530140054.09840c10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 30 May 2006 14:03:42 +0900 To: James M Snell , atom-syntax@imc.org From: Martin Duerst Subject: Re: Link rel test cases In-Reply-To: <444E95F6.8060700@gmail.com> References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 06:34 06/04/26, James M Snell wrote: > >A couple more link rel test cases: >http://www.snellspace.com/public/linkreltest.xml > >See the bottom of: http://www.intertwingly.net/wiki/pie/LinkConformanceTests Just a short comment: the use of unregistered, (see http://www.iana.org/assignments/urn-namespaces) made-up urn namespaces such as linkreltest in urn:linkreltest:feed doesn't really match well with the fact that atom is an IETF format, and tests are supposed to be correct and conforming by themselves. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Tue May 30 10:07:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4so-0003Zb-6t for atompub-archive@lists.ietf.org; Tue, 30 May 2006 10:07:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4sh-0005LN-Q2 for atompub-archive@lists.ietf.org; Tue, 30 May 2006 10:07:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UDo3WW088563; Tue, 30 May 2006 06:50:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UDo3L9088562; Tue, 30 May 2006 06:50:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4UDo273088478 for ; Tue, 30 May 2006 06:50:02 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 30 May 2006 13:49:56 -0000 Received: from xdsl-81-173-175-40.netcologne.de (EHLO klangraum) [81.173.175.40] by mail.gmx.net (mp021) with SMTP; 30 May 2006 15:49:56 +0200 X-Authenticated: #163624 Date: Tue, 30 May 2006 15:50:09 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Link rel test cases Message-ID: <20060530135009.GK3748@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060530124651.0983a180@localhost> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 * Martin Duerst [2006-05-30 08:00]: > The conclusion is that a content producer that uses > HTTP://www.IANA.org:80/assignments/relation/alternate at all > does something wrong. +1 Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Tue May 30 12:22:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6zh-0002UW-IY for atompub-archive@lists.ietf.org; Tue, 30 May 2006 12:22:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl6zf-00033f-36 for atompub-archive@lists.ietf.org; Tue, 30 May 2006 12:22:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UG4J1b078298; Tue, 30 May 2006 09:04:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UG4JQd078296; Tue, 30 May 2006 09:04:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UG4GWZ078265 for ; Tue, 30 May 2006 09:04:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so13630wra for ; Tue, 30 May 2006 09:04:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ahJLLWXZVa14EzqGyq7c5ZcpfdRnxAYvQE/vIZaCx1g0Cl/ng4dhURqyVbKufvG5jJ3Nc8aAT+E+6zOpbBMecFpuOl/ZlbqwEgeNBaG6VI66aXqynkO0p6NCKnf+UuWHntF4Tt2TgfO2nwXAPS2K26DnMLnHuD3MrC56dFr+TBY= Received: by 10.54.121.18 with SMTP id t18mr3308457wrc; Tue, 30 May 2006 09:04:16 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 24sm5965253wrl.2006.05.30.09.04.15; Tue, 30 May 2006 09:04:16 -0700 (PDT) Message-ID: <447C6CE1.9070401@gmail.com> Date: Tue, 30 May 2006 09:03:45 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <6.0.0.20.2.20060530140054.09840c10@localhost> In-Reply-To: <6.0.0.20.2.20060530140054.09840c10@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Fixed! Changed to use tag: Martin Duerst wrote: > At 06:34 06/04/26, James M Snell wrote: >> A couple more link rel test cases: >> http://www.snellspace.com/public/linkreltest.xml >> >> See the bottom of: http://www.intertwingly.net/wiki/pie/LinkConformanceTests > > Just a short comment: the use of unregistered, > (see http://www.iana.org/assignments/urn-namespaces) > made-up urn namespaces such as linkreltest in > urn:linkreltest:feed > doesn't really match well with the fact that > atom is an IETF format, and tests are supposed > to be correct and conforming by themselves. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > From owner-atom-syntax@mail.imc.org Tue May 30 15:08:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl9ZQ-0007jO-HD for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:08:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl9ZN-000184-Ts for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:08:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UIn6CH086427; Tue, 30 May 2006 11:49:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UIn6HX086426; Tue, 30 May 2006 11:49:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UIn54V086390; Tue, 30 May 2006 11:49:05 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A477F14226F; Tue, 30 May 2006 11:49:04 -0700 (PDT) In-Reply-To: <44737F15.1040206@gmail.com> References: <44737F15.1040206@gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Paul Hoffman , Atom WG , atom-protocol@imc.org Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Atompub WG meeting at the Montreal IETF Date: Tue, 30 May 2006 11:48:50 -0700 To: James M Snell X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 The deadline for requesting an official BOF is Monday. The IAB and IESG are having a bit of discussion of upcoming BOFs this Thursday, even before the Monday deadline, so it would be good to have an indication of a possible request ASAP :) If an official BOF does not come together, there's always Bar BOFs, or even a mini-BOF (pseudo- BOF?) in the Apps Area meeting which is typically the Monday morning of IETF week. I'm also trying to put together some topics of general interest for the Apps Area open meeting, and there's the HTTP Authentication or anti-Phishing BOF which has already been requested and should be of interest to Atom people. I personally have had a lot of people tell me of interest in Atom extensions but it's hard to tell if there's a real possibility of the work items gelling into a charter. Lisa On May 23, 2006, at 2:31 PM, James M Snell wrote: > > This sounds good so long as we can get the extensions BOF scheduled > the > on the same day as the WG meeting. Also, it would be great if we > could > get together for some face-to-face interop testing before and/or after > the WG meeting. > > - James > > Paul Hoffman wrote: >> >> Greetings again. The Atompub WG will have our first (and maybe last!) >> face-to-face meeting at the upcoming IETF meeting in Montreal at the >> beginning of July. >> >> The timing of us having our first WG meeting may seem odd, given the >> fact that we completed the Atom format document long ago, and are >> making >> good progress on the publishing protocol. However, there are reasons >> other than "moving documents forwards" for WGs to meet. Lisa >> Dusseault, >> our Area Director, asked us to have a meeting so that people >> active in >> the Atompub WG can have more interaction with the IETF, and vice >> versa. >> There is interest in the Atom format from other WGs, and there may be >> interest in the Atom publishing protocol as well. >> >> I propose the following agenda, which should fit well into a one- >> hour slot: >> >> - Intro: 10 mins >> - Brief overview of protocol status: 10 mins >> - Use of Atom format in other WGs: 30 mins >> - draft-saintandre-atompub-notify >> - Overlap with calendar formats >> - Overlap with mail >> >> Note that we are explicitly *not* going to discuss extensions to the >> Atom format at this WG meeting because they are not part of the WG >> charter. Lisa has said that she may help arrange a BoF session on >> creating a new Working Group for Atom extensions, and having at >> least a >> higher-level discussion of what extensions are out there would be >> appropriate in that BoF. But, to use asterisks again, such >> discussion is >> *not* part of the Atompub WG meeting. >> >> See for details about the >> IETF meeting. I will let the WG know when there are preliminary and >> near-permanent agendas for the meeting. It would be good to meet >> some of >> you there! >> >> --Paul Hoffman, Director >> --Internet Mail Consortium >> >> > From owner-atom-syntax@mail.imc.org Tue May 30 15:28:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl9ss-0007Z6-1p for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:28:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl9sp-0002tf-Lc for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:28:06 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UJAKRI099464; Tue, 30 May 2006 12:10:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UJAKWU099463; Tue, 30 May 2006 12:10:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UJAJ4k099451 for ; Tue, 30 May 2006 12:10:20 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6813014228B; Tue, 30 May 2006 12:10:19 -0700 (PDT) In-Reply-To: <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43FF5905-EE08-4180-A48F-05C070DBC258@osafoundation.org> Cc: David Powell , James M Snell , atom-syntax Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Feed Thread in Last Call Date: Tue, 30 May 2006 12:10:09 -0700 To: Tim Bray X-Mailer: Apple Mail (2.749.3) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On May 23, 2006, at 12:16 PM, Tim Bray wrote: > On May 18, 2006, at 6:15 AM, David Powell wrote: > >> What I see as a problem is that reasonable implementations will not >> preserve Atom documents bit-for-bit, so they will need to explicitly >> support this draft if they don't want to corrupt data by dropping the >> thr:count attributes. By the letter of RFC4287 there is no problem >> with the draft, but practically there is something like a layering >> concern if an extension requires existing conformant implementations >> to be changed. > > At the end of the day, the marketplace will work within the > constraints of what 4287 allows; my feeling is that there are going > to be a ton of extensions that will attach unforeseen metadata at > arbitrary points with Atom documents, and implementations that fail > to store these and make them retrievable will quickly be seen as > broken. -Tim I find this to be a pretty compelling argument. Unless RFC4287 were rewritten (with a time machine, perhaps) to forbid extensions in attributes, extension writers will occasionally put data in attributes, and the libraries will have to deal with this, regardless of how the Thread proposal works. Lisa From owner-atom-syntax@mail.imc.org Tue May 30 15:58:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAMR-0000vi-L9 for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:58:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAMQ-00085k-9c for atompub-archive@lists.ietf.org; Tue, 30 May 2006 15:58:39 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UJl2AP023150; Tue, 30 May 2006 12:47:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UJl2eC023149; Tue, 30 May 2006 12:47:02 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UJl0vO023114 for ; Tue, 30 May 2006 12:47:01 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id l37so5500nfc for ; Tue, 30 May 2006 12:46:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QSNfqSHxVWTBem98tAIQZzdoeP8H21FyBfzIL/E7Ssaey3E5xxFEqS0XZ5iBm6JMy6Lv/6+SeYD0JROK0hgT2xcLrs7dGBK9g3/mKK9mjU34AxOclNTcjx8xChvbKZG8YNK2t8upt5wi1e/k81hcGPBtmT9X0ctEhqe44hpSpYU= Received: by 10.49.59.2 with SMTP id m2mr75378nfk; Tue, 30 May 2006 12:46:58 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Tue, 30 May 2006 12:46:58 -0700 (PDT) Message-ID: <68fba5c50605301246g35f4f916r278d689c1c89b145@mail.gmail.com> Date: Tue, 30 May 2006 15:46:58 -0400 From: "Robert Sayre" To: "Lisa Dusseault" Subject: Re: Feed Thread in Last Call Cc: "Tim Bray" , "David Powell" , "James M Snell" , atom-syntax In-Reply-To: <43FF5905-EE08-4180-A48F-05C070DBC258@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <43FF5905-EE08-4180-A48F-05C070DBC258@osafoundation.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On 5/30/06, Lisa Dusseault wrote: > > > At the end of the day, the marketplace will work within the > > constraints of what 4287 allows; my feeling is that there are going > > to be a ton of extensions that will attach unforeseen metadata at > > arbitrary points with Atom documents, and implementations that fail > > to store these and make them retrievable will quickly be seen as > > broken. -Tim > > I find this to be a pretty compelling argument. I don't find Tim's argument particularly compelling. It's crystal ball stuff, and implementations are free to ignore *any* part of an Atom document. In this case, it's another case of a WG member claiming something is broken without a shred of spec text to back it up. If Tim and others want that to be true, they have an RFC to revise. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 30 16:20:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAhd-0000fh-2H for atompub-archive@lists.ietf.org; Tue, 30 May 2006 16:20:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAha-0000Ib-MS for atompub-archive@lists.ietf.org; Tue, 30 May 2006 16:20:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UK5wcf034567; Tue, 30 May 2006 13:05:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UK5wi5034566; Tue, 30 May 2006 13:05:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UK5v9V034555 for ; Tue, 30 May 2006 13:05:58 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so61638wra for ; Tue, 30 May 2006 13:05:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=D21Sgxqob0+gPFPGUgOup6tKYNHCjHVWXLPISwayB6eQ5PGKOjP2SIxRt0irOxuYHygxurNe2nl99jfi9SmZV/GwQjYXfpIsuiDMiLBSIdqfqJYq1jJF6nwPA4kXIw4YQA8wOPJUE9oLpo61keCiWWCoo0KjDcWPxyAxjQnZ9JE= Received: by 10.54.133.17 with SMTP id g17mr643610wrd; Tue, 30 May 2006 13:05:57 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 15sm352183wrl.2006.05.30.13.05.55; Tue, 30 May 2006 13:05:56 -0700 (PDT) Message-ID: <447CA5A0.6070006@gmail.com> Date: Tue, 30 May 2006 13:05:52 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Robert Sayre CC: Lisa Dusseault , Tim Bray , David Powell , atom-syntax Subject: Re: Feed Thread in Last Call References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <43FF5905-EE08-4180-A48F-05C070DBC258@osafoundation.org> <68fba5c50605301246g35f4f916r278d689c1c89b145@mail.gmail.com> In-Reply-To: <68fba5c50605301246g35f4f916r278d689c1c89b145@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Robert Sayre wrote: >[snip] > document. In this case, it's another case of a WG member claiming > something is broken without a shred of spec text to back it up. If Tim The exact same can be said of the argument that the use of extension attributes is broken. There's not a shred of spec text to back it up. > and others want that to be true, they have an RFC to revise. > The spec is clear. Extension attributes are allowed by the spec. Implementations that do not support extension attributes are choosing not to support a feature allowed by the spec. Whether that makes those implementations "broken" or not is debatable. Personally, I don't see them as "broken", I just see them as extremely short-sighted. - James From owner-atom-syntax@mail.imc.org Tue May 30 16:32:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAt2-0003qJ-JW for atompub-archive@lists.ietf.org; Tue, 30 May 2006 16:32:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAt1-0000v7-85 for atompub-archive@lists.ietf.org; Tue, 30 May 2006 16:32:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UKIf4o042307; Tue, 30 May 2006 13:18:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4UKIfnL042306; Tue, 30 May 2006 13:18:41 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4UKIdwC042275 for ; Tue, 30 May 2006 13:18:40 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so4008nfc for ; Tue, 30 May 2006 13:18:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nvW+zLW0suRnDNPLDaYfbtwJGa1suMfYr6xHkQy9Aq7XxMbeChm1PRsEv7A5bADt4caRMgxXr8WVl4xLx4PA3uBjXT8ZxBt6R3k5E5GvHb1CPheVC6h5I0Iin47aPrz8Dn1Ftfd5aN3PRiNy9qzuSUiLmOKDA0ll5Uwlh8TjxHI= Received: by 10.49.63.10 with SMTP id q10mr103148nfk; Tue, 30 May 2006 13:10:18 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Tue, 30 May 2006 13:10:17 -0700 (PDT) Message-ID: <68fba5c50605301310l18fceb80q56f90bdbc163c91a@mail.gmail.com> Date: Tue, 30 May 2006 16:10:17 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread in Last Call Cc: "Lisa Dusseault" , "Tim Bray" , "David Powell" , atom-syntax In-Reply-To: <447CA5A0.6070006@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4468FD76.6050805@gmail.com> <68fba5c50605151933j50a9d5dawb9c53e5e94a838a5@mail.gmail.com> <44694BEB.6090203@gmail.com> <97566250.20060518141543@djpowell.net> <47484681-73CF-4546-BAD9-C0CF31DF00BE@sun.com> <43FF5905-EE08-4180-A48F-05C070DBC258@osafoundation.org> <68fba5c50605301246g35f4f916r278d689c1c89b145@mail.gmail.com> <447CA5A0.6070006@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On 5/30/06, James M Snell wrote: > > Robert Sayre wrote: > >[snip] > > document. In this case, it's another case of a WG member claiming > > something is broken without a shred of spec text to back it up. If Tim > > The exact same can be said of the argument that the use of extension > attributes is broken. There's not a shred of spec text to back it up. > I didn't say the use of extension attributes is broken. I said your extension has no reason to use them, remember? You never gave a technical reason for the change between last call and the previous version. > Personally, I don't see them as "broken", I just see them as extremely short-sighted. That's how I see your extension. Hey, maybe you could do RFC4287bis as an individual submission! -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 30 20:15:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlENA-0004Od-8z for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:15:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEN4-0006US-Si for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:15:40 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V03Wwh081786; Tue, 30 May 2006 17:03:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V03WUF081785; Tue, 30 May 2006 17:03:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav16.bay109.hotmail.com [64.4.19.88]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V03WlY081775 for ; Tue, 30 May 2006 17:03:32 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 May 2006 17:03:31 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV16.phx.gbl with DAV; Wed, 31 May 2006 00:03:31 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <6.0.0.20.2.20060530140054.09840c10@localhost> <447C6CE1.9070401@gmail.com> Subject: Re: Link rel test cases Date: Wed, 31 May 2006 01:01:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 31 May 2006 00:03:31.0874 (UTC) FILETIME=[A7292820:01C68445] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Unfortunately it looks like you managed to break the XML while doing this. The id tag in the second entry is not closed properly. Regards James James M Snell wrote: > Fixed! Changed to use tag: > > Martin Duerst wrote: >> Just a short comment: the use of unregistered, >> (see http://www.iana.org/assignments/urn-namespaces) >> made-up urn namespaces such as linkreltest in >> urn:linkreltest:feed >> doesn't really match well with the fact that >> atom is an IETF format, and tests are supposed >> to be correct and conforming by themselves. From owner-atom-syntax@mail.imc.org Tue May 30 20:28:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEZe-00030G-Om for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:28:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEZd-0007lZ-CG for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:28:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0IaX7091609; Tue, 30 May 2006 17:18:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V0Iafq091608; Tue, 30 May 2006 17:18:36 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0IZmF091585 for ; Tue, 30 May 2006 17:18:35 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so404147wxc for ; Tue, 30 May 2006 17:18:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=bQVTVQz3d9hB5naOfwx/EsmZKmooJ8DkTe4FfCxOJa45iES6Gegv+nrCnpUOdDNNlS1tZh1ty56s6vQNHn/gXf9a1lpBiq/nFprOqkySlL7miT7Vb/RJ9kUpZeAnt46PDK0ZD1NfUGiU4dWMnTzjyIv9LXwjvoilg4PFnFnwaIo= Received: by 10.70.6.1 with SMTP id 1mr4218045wxf; Tue, 30 May 2006 17:18:34 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id h17sm472334wxd.2006.05.30.17.18.32; Tue, 30 May 2006 17:18:34 -0700 (PDT) Message-ID: <447CE0D6.9050505@gmail.com> Date: Tue, 30 May 2006 17:18:30 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: James Holderness CC: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425143930.GC29846@klangraum> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <6.0.0.20.2.20060530140054.09840c10@localhost> <447C6CE1.9070401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Doh! Dangnabbit. Fixed. For real this time. James Holderness wrote: > > Unfortunately it looks like you managed to break the XML while doing > this. The id tag in the second entry is not closed properly. > > Regards > James > > James M Snell wrote: >> Fixed! Changed to use tag: >> >> Martin Duerst wrote: >>> Just a short comment: the use of unregistered, >>> (see http://www.iana.org/assignments/urn-namespaces) >>> made-up urn namespaces such as linkreltest in >>> urn:linkreltest:feed >>> doesn't really match well with the fact that >>> atom is an IETF format, and tests are supposed >>> to be correct and conforming by themselves. > > From owner-atom-syntax@mail.imc.org Tue May 30 20:38:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEip-0000HS-Ew for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:38:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEin-0001Sh-23 for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:38:03 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0RKx2097031; Tue, 30 May 2006 17:27:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V0RKIR097029; Tue, 30 May 2006 17:27:20 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav9.bay109.hotmail.com [64.4.19.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0RH7Y097005 for ; Tue, 30 May 2006 17:27:20 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 May 2006 17:27:17 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV9.phx.gbl with DAV; Wed, 31 May 2006 00:27:12 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> Subject: Re: Link rel test cases Date: Wed, 31 May 2006 01:25:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 31 May 2006 00:27:17.0436 (UTC) FILETIME=[F8DCA7C0:01C68448] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Martin Duerst wrote: > Yes, a content producer that expected > a) HTTP://www.IANA.org:80/assignments/relation/alternate > to always be different from > b) http://www.iana.org/assignments/relation/alternate > would be stupid. But on the other hand, a content producer > that expected a) and b) to always be treated the same would > be ridiculous, too. I agree completely, but as a content consumer I still need to know whether to use IRI::Compare or String::Compare when I do encounter some ridiculous feed that uses example (a). I'm hoping for a simple answer along the lines of "Use IRI:Compare", "Use String::Compare", or "The spec doesn't say, so you may use whatever you prefer". Also, I would think the authors of the feedvalidator would probably want to know whether a feed that used example (a) should be considered invalid as well as ridiculous. In other words, does it deserve an error, or merely a warning? Regards James From owner-atom-syntax@mail.imc.org Tue May 30 20:52:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlEwN-0006J3-0R for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:52:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlEwL-0003Th-Lm for atompub-archive@lists.ietf.org; Tue, 30 May 2006 20:52:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0gJXo006834; Tue, 30 May 2006 17:42:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V0gJjh006833; Tue, 30 May 2006 17:42:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V0gHxY006812 for ; Tue, 30 May 2006 17:42:18 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id p48so24028nfa for ; Tue, 30 May 2006 17:42:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TN/V8tUnI6zYwp6Ex5/tgaqjmNlTQYNqRymLGDl4M11DucyPLSFbvtRvf8o0GeDQjsE64xW0z4AUVBwOIwtqSs8peBLpzyadprBoDElUW42eELukSgpu/+STbZFOFzp1n9K3+4QaNvpSFyX3ygn/4F3cMUB16ZKM33Mr0xNn34o= Received: by 10.49.2.17 with SMTP id e17mr222192nfi; Tue, 30 May 2006 17:42:16 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Tue, 30 May 2006 17:42:16 -0700 (PDT) Message-ID: <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> Date: Tue, 30 May 2006 20:42:16 -0400 From: "Robert Sayre" To: "James Holderness" Subject: Re: Link rel test cases Cc: atom-syntax@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On 5/30/06, James Holderness wrote: > > of "Use IRI:Compare", "Use String::Compare", or "The spec doesn't say, so > you may use whatever you prefer". The URI/IRI specs say "use whatever you prefer". If you don't like that, have James add it to his revision of 4287. :) -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 30 21:19:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFMr-0006rI-3p for atompub-archive@lists.ietf.org; Tue, 30 May 2006 21:19:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlFMp-0005QI-Ob for atompub-archive@lists.ietf.org; Tue, 30 May 2006 21:19:25 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V14HrV020787; Tue, 30 May 2006 18:04:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V14Hwk020786; Tue, 30 May 2006 18:04:17 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from hotmail.com (bay109-dav3.bay109.hotmail.com [64.4.19.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V14GBZ020771 for ; Tue, 30 May 2006 18:04:16 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 May 2006 18:04:16 -0700 Message-ID: Received: from 81.178.229.106 by BAY109-DAV3.phx.gbl with DAV; Wed, 31 May 2006 01:04:12 +0000 X-Originating-IP: [81.178.229.106] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <444C2C01.5040005@intertwingly.net> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> Subject: Re: Link rel test cases Date: Wed, 31 May 2006 02:02:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 31 May 2006 01:04:16.0281 (UTC) FILETIME=[23658890:01C6844E] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Robert Sayre wrote: >> of "Use IRI:Compare", "Use String::Compare", or "The spec doesn't say, so >> you may use whatever you prefer". > > The URI/IRI specs say "use whatever you prefer". If you don't like > that, have James add it to his revision of 4287. :) Thanks. That's not how I read RFC3987, but I'm happy to accept your interpretation. Regards James From owner-atom-syntax@mail.imc.org Tue May 30 22:02:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlG2q-0001n6-Fw for atompub-archive@lists.ietf.org; Tue, 30 May 2006 22:02:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlG2p-0000RD-4b for atompub-archive@lists.ietf.org; Tue, 30 May 2006 22:02:48 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V1nRlH050760; Tue, 30 May 2006 18:49:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V1nR9e050759; Tue, 30 May 2006 18:49:27 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V1nPI6050725 for ; Tue, 30 May 2006 18:49:26 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id l24so79923nfc for ; Tue, 30 May 2006 18:49:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uXZFE766/PCOYNWWTlgMW4fmWtMdQ8lrOzneTapAg61mML3TbefHBikUVUxtmrayAWI0c2b+S3beWdgWX+eyT8bwUjFLUhuVp+F32V4WPI6PbUur0U7ZTqV25mQBjKQZ0uBTahNacgjR/xUvkXJbWKX6C5M099UX+TmOHwRjTtE= Received: by 10.49.88.4 with SMTP id q4mr270488nfl; Tue, 30 May 2006 18:49:24 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Tue, 30 May 2006 18:49:24 -0700 (PDT) Message-ID: <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> Date: Tue, 30 May 2006 21:49:24 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: Fwd: Link rel test cases In-Reply-To: <447CF39B.4060603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I think James forgot to cc the list ---------- Forwarded message ---------- From: James M Snell Date: May 30, 2006 9:38 PM Subject: Re: Link rel test cases To: Robert Sayre Robert Sayre wrote: > [snip]...have James add it to his revision of 4287. :) > > Pardon, what the hell are you talking about? Do you really, honestly believe that being a complete ass is a productive use of anyone's time? - James -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue May 30 22:38:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlGbP-0007RA-2T for atompub-archive@lists.ietf.org; Tue, 30 May 2006 22:38:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlGbN-0003B6-Mr for atompub-archive@lists.ietf.org; Tue, 30 May 2006 22:38:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V2PUeo074370; Tue, 30 May 2006 19:25:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V2PUYS074369; Tue, 30 May 2006 19:25:30 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V2PRdB074340 for ; Tue, 30 May 2006 19:25:28 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id l24so86627nfc for ; Tue, 30 May 2006 19:25:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oVI+pinPvykxYsEzGUIJoXu0NIoHFYZ3Bjl6X+bNXDPQlQfdMbi6stbamAlbeDoCwMeNtIRJJChiaKCUEdcagqxEUxR53NpmSlmaei9L/9m6wkLG2NGCQNb3E1Gp5A/tEsfR4WHOnaWJCSwovLhoZkjoZJ78VN+8w8QcciFdZzc= Received: by 10.49.90.3 with SMTP id s3mr296498nfl; Tue, 30 May 2006 19:25:27 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Tue, 30 May 2006 19:25:27 -0700 (PDT) Message-ID: <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> Date: Tue, 30 May 2006 22:25:27 -0400 From: "Robert Sayre" To: "James M Snell" , "Atom Syntax" Subject: Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] In-Reply-To: <447CFD0A.7040801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hmm, do you harass everyone who disagrees with you like this? I am kind of taken aback by this unprofessional conduct. I don't see how I am supposed to participate in an IETF working group if the document authors are going to engage in this kind of vitriol. I wonder if you think it's ok to write this kind of thing in private email. I'm disappointed. :/ On 5/30/06, James M Snell wrote: > [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] > > Had I meant to cc the list, it stands to reason that I would have cc'd > the list. > > I've grown quite tired of this > Insult-James-And-Everything-He-Does-And-Says campaign of yours. You are > accomplishing nothing. Get a life and move on. > > - James > > [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] > > Robert Sayre wrote: > > > > I think James forgot to cc the list > > > > ---------- Forwarded message ---------- > > From: James M Snell > > Date: May 30, 2006 9:38 PM > > Subject: Re: Link rel test cases > > To: Robert Sayre > > > > > > > > > > Robert Sayre wrote: > >> [snip]...have James add it to his revision of 4287. :) > >> > >> > > > > Pardon, what the hell are you talking about? Do you really, honestly > > believe that being a complete ass is a productive use of anyone's time? > > > > - James > > > > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed May 31 01:45:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJWL-0004g0-CS for atompub-archive@lists.ietf.org; Wed, 31 May 2006 01:45:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlJNr-0003Ec-TN for atompub-archive@lists.ietf.org; Wed, 31 May 2006 01:36:47 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V5JhhK089470; Tue, 30 May 2006 22:19:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4V5JhMP089469; Tue, 30 May 2006 22:19:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4V5JgOF089278 for ; Tue, 30 May 2006 22:19:43 -0700 (MST) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4V5JQca001697; Wed, 31 May 2006 14:19:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 3de4_073ea43e_f065_11da_9d95_0014221fa3c9; Wed, 31 May 2006 14:19:25 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4V5IF8P032352; Wed, 31 May 2006 14:18:41 +0900 Message-Id: <6.0.0.20.2.20060531141131.043f8970@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 31 May 2006 14:15:39 +0900 To: "James Holderness" , From: Martin Duerst Subject: Re: Link rel test cases In-Reply-To: References: <444C2C01.5040005@intertwingly.net> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 At 10:02 06/05/31, James Holderness wrote: > >Robert Sayre wrote: >>> of "Use IRI:Compare", "Use String::Compare", or "The spec doesn't say, so >>> you may use whatever you prefer". >> >> The URI/IRI specs say "use whatever you prefer". If you don't like >> that, have James add it to his revision of 4287. :) > >Thanks. That's not how I read RFC3987, but I'm happy to accept your interpretation. Well, RFC 3987 (and 3986) don't *exactly* say "use whatever you prefer", but for the case at hand, what they say comes pretty close. What they try to do is give advice on what kind of normalization or comparison function(s) is/are adequate in which case. Given that it's difficult to immagine every possible case in advace, the advice they give unfortuanetly has to be somewhat vague. BTW, as a co-author of RFC 3987, I of course appreciate any suggestion on how to make it clearer, and any suggestions for fixes or changes (should they be necessary). These should be directed to public-iri@w3.org. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From owner-atom-syntax@mail.imc.org Wed May 31 06:32:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNzp-0002Vu-8k for atompub-archive@lists.ietf.org; Wed, 31 May 2006 06:32:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlNzi-00055w-RL for atompub-archive@lists.ietf.org; Wed, 31 May 2006 06:32:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VAJ86a074028; Wed, 31 May 2006 03:19:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VAJ8vK074025; Wed, 31 May 2006 03:19:08 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VAJ6G2073938 for ; Wed, 31 May 2006 03:19:06 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 10:19:00 -0000 Received: from xdsl-213-196-240-78.netcologne.de (EHLO klangraum) [213.196.240.78] by mail.gmx.net (mp033) with SMTP; 31 May 2006 12:19:00 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 12:19:11 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Sorry this is on-list; Robert does not seem to appreciate off-list mail Message-ID: <20060531101911.GR3748@klangraum> Mail-Followup-To: atom-syntax Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VAJ86a074028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Please note the datetimes: * Robert Sayre [2006-05-30 22:30]: > On 5/30/06, James M Snell wrote: > > > >[snip] [In a thread which had absolutely nothing to do with James=E2=80=99 extensions:] * Robert Sayre [2006-05-31 02:50]: > The URI/IRI specs say "use whatever you prefer". If you don't > like that, have James add it to his revision of 4287. :) * Robert Sayre [2006-05-31 04:00]: > I think James forgot to cc the list >=20 > ---------- Forwarded message ---------- > From: James M Snell * Robert Sayre [2006-05-31 04:40]: > Hmm, do you harass everyone who disagrees with you like this? > [snip] >=20 > On 5/30/06, James M Snell wrote: > >[snip] * Robert Sayre [2006-05-19 22:50]: > I find interacting with you {{James --Ed.}} to be a giant time > sink. My new policy will be to explain my problem *once*, and > then I will verify that my concerns (if any) have been > addressed at some later date when there is a revised document > available. If my concerns aren't addressed, I will make a > concerted effort to avoid writing or being responsible for > maintaining any relevant functionality. I have no further commentary to offer. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 06:54:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlOLo-0005Wt-Mx for atompub-archive@lists.ietf.org; Wed, 31 May 2006 06:54:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlOLk-0006i3-3s for atompub-archive@lists.ietf.org; Wed, 31 May 2006 06:54:56 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VAeu90087321; Wed, 31 May 2006 03:40:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VAeugK087320; Wed, 31 May 2006 03:40:56 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VAetGJ087296 for ; Wed, 31 May 2006 03:40:55 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id 34so610nzf for ; Wed, 31 May 2006 03:40:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gdyuQGoeH52ZU5VO4617FBEM+yBGZ9eZ38Ea7ADRTNvtlhzyS1yzKX3XkNQV7dV7Jg5bR32EYrpx0iZ8cXxsYzZx+kehkElhYzIocBPIThsHVqLDL/UJUE26CVRGZhUwjwieVsCDmpWEkt+CVzA8N+Ps/RumqzcaSqCST0WaDBo= Received: by 10.65.215.12 with SMTP id s12mr28283qbq; Wed, 31 May 2006 03:40:54 -0700 (PDT) Received: by 10.65.183.20 with HTTP; Wed, 31 May 2006 03:40:54 -0700 (PDT) Message-ID: Date: Wed, 31 May 2006 04:40:54 -0600 From: "M. David Peterson" To: atom-syntax Subject: Re: Sorry this is on-list; Robert does not seem to appreciate off-list mail In-Reply-To: <20060531101911.GR3748@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24837_21506841.1149072054875" References: <20060531101911.GR3748@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 ------=_Part_24837_21506841.1149072054875 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was following this thread, and was doing my best to keep my mouth shut, but I can't do that any longer. I will avoid making statements that are intended to offend. What I will say is this: Messages specifically labeled 'off-list' should be respected as such. There are a million different reasons why someone might want to continue a conversation, good or bad, off of the list it was started. Just like "what happens on the road, stays on the road", "what happens off-list, stays off-list". If someone proves that they can't handle themselves in this regard, then trust becomes a SERIOUS issue. What happens more often than not is that the attempt to make someone else look like a fool has the opposite effect. On 5/31/06, A. Pagaltzis wrote: > > > > Please note the datetimes: > > > * Robert Sayre [2006-05-30 22:30]: > > On 5/30/06, James M Snell wrote: > > > > > >[snip] > > > [In a thread which had absolutely nothing to do with James' > extensions:] > * Robert Sayre [2006-05-31 02:50]: > > The URI/IRI specs say "use whatever you prefer". If you don't > > like that, have James add it to his revision of 4287. :) > > > * Robert Sayre [2006-05-31 04:00]: > > I think James forgot to cc the list > > > > ---------- Forwarded message ---------- > > From: James M Snell > > > * Robert Sayre [2006-05-31 04:40]: > > Hmm, do you harass everyone who disagrees with you like this? > > [snip] > > > > On 5/30/06, James M Snell wrote: > > >[snip] > > > * Robert Sayre [2006-05-19 22:50]: > > I find interacting with you {{James --Ed.}} to be a giant time > > sink. My new policy will be to explain my problem *once*, and > > then I will verify that my concerns (if any) have been > > addressed at some later date when there is a revised document > > available. If my concerns aren't addressed, I will make a > > concerted effort to avoid writing or being responsible for > > maintaining any relevant functionality. > > > I have no further commentary to offer. > > Regards, > -- > Aristotle Pagaltzis // > > -- M. David Peterson http://www.xsltblog.com/ ------=_Part_24837_21506841.1149072054875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was following this thread, and was doing my best to keep my mouth shut, but I can't do that any longer.  I will avoid making statements that are intended to offend.

What I will say is this:  Messages specifically labeled 'off-list' should be respected as such.  There are a million different reasons why someone might want to continue a conversation, good or bad, off of the list it was started.  Just like "what happens on the road, stays on the road", "what happens off-list, stays off-list".

If someone proves that they can't handle themselves in this regard, then trust becomes a SERIOUS issue.  What happens more often than not is that the attempt to make someone else look like a fool has the opposite effect.

On 5/31/06, A. Pagaltzis <pagaltzis@gmx.de> wrote:


Please note the datetimes:


* Robert Sayre <sayrer@gmail.com> [2006-05-30 22:30]:
> On 5/30/06, James M Snell <jasnell@gmail.com > wrote:
> >
> >[snip]


[In a thread which had absolutely nothing to do with James'
extensions:]
* Robert Sayre <sayrer@gmail.com> [2006-05-31 02:50]:
> The URI/IRI specs say "use whatever you prefer". If you don't
> like that, have James add it to his revision of 4287. :)


* Robert Sayre <sayrer@gmail.com > [2006-05-31 04:00]:
> I think James forgot to cc the list
>
> ---------- Forwarded message ----------
> From: James M Snell <jasnell@gmail.com>


* Robert Sayre <sayrer@gmail.com> [2006-05-31 04:40]:
> Hmm, do you harass everyone who disagrees with you like this?
> [snip]
>
> On 5/30/06, James M Snell < jasnell@gmail.com> wrote:
> >[snip]


* Robert Sayre <sayrer@gmail.com> [2006-05-19 22:50]:
> I find interacting with you {{James --Ed.}} to be a giant time
> sink. My new policy will be to explain my problem *once*, and
> then I will verify that my concerns (if any) have been
> addressed at some later date when there is a revised document
> available. If my concerns aren't addressed, I will make a
> concerted effort to avoid writing or being responsible for
> maintaining any relevant functionality.


I have no further commentary to offer.

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




--
<M:D/>

M. David Peterson
http://www.xsltblog.com/ ------=_Part_24837_21506841.1149072054875-- From owner-atom-syntax@mail.imc.org Wed May 31 08:13:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPZi-0002Mn-ER for atompub-archive@lists.ietf.org; Wed, 31 May 2006 08:13:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlPZf-0006tS-2s for atompub-archive@lists.ietf.org; Wed, 31 May 2006 08:13:22 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VC0p49032876; Wed, 31 May 2006 05:00:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VC0pmE032875; Wed, 31 May 2006 05:00:51 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VC0naJ032861 for ; Wed, 31 May 2006 05:00:50 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so6937nfc for ; Wed, 31 May 2006 05:00:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZtiSqGIuY/GQkBq1YSMT8AYrCvjxTbd8PMkXmH4daJ4bOJyvgw5IND9gMUsGYDIxFunI0Y3oieEP1hfbjeYA4ubKUm25yasIwfiOS8AGMgvJ/4NsGYu4lP0DJ0/sePAf0HaYPd8wcXAkyFsF8+/xFPYiPY7NZ25WdJB1JmdOe3w= Received: by 10.48.48.7 with SMTP id v7mr145783nfv; Wed, 31 May 2006 05:00:35 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Wed, 31 May 2006 05:00:35 -0700 (PDT) Message-ID: <68fba5c50605310500s26d07574hddbff3e2a4264371@mail.gmail.com> Date: Wed, 31 May 2006 08:00:35 -0400 From: "Robert Sayre" To: atom-syntax Subject: Re: Sorry this is on-list; Robert does not seem to appreciate off-list mail In-Reply-To: <20060531101911.GR3748@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060531101911.GR3748@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad On 5/31/06, A. Pagaltzis wrote: > > I have no further commentary to offer. > Promise? I'm sick of getting rude mail from James after he's flown off the handle. I doubt I'll receive any more. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 31 08:57:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQGQ-0003KZ-3Q for atompub-archive@lists.ietf.org; Wed, 31 May 2006 08:57:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQGH-0001v8-LQ for atompub-archive@lists.ietf.org; Wed, 31 May 2006 08:57:30 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VCf9iJ056805; Wed, 31 May 2006 05:41:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VCf9bQ056802; Wed, 31 May 2006 05:41:09 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VCf7Zr056736 for ; Wed, 31 May 2006 05:41:08 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 12:41:01 -0000 Received: from xdsl-81-173-168-27.netcologne.de (EHLO klangraum) [81.173.168.27] by mail.gmx.net (mp018) with SMTP; 31 May 2006 14:41:01 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 14:41:16 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Link rel test cases Message-ID: <20060531124116.GV3748@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VCf9iJ056805 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a * James Holderness [2006-05-31 02:40]: > I agree completely, but as a content consumer I still need to > know whether to use IRI::Compare or String::Compare when I do > encounter some ridiculous feed that uses example (a). I'm > hoping for a simple answer along the lines of "Use > IRI:Compare", "Use String::Compare", or "The spec doesn't say, > so you may use whatever you prefer". RFC4287 defines the relation value in terms of IRIs, but does not require that relations be compared as such, and then constrains the set of values to a subset of IRIs. This constrained set is more amenable to simple string comparison. My interpretation of these facts is that string comparison is explicitly expected. Given then that all implementations that I have read the source of do indeed compare relation values as strings, my conclusion is that while you are free to compare them as IRIs, doing so is unwise; likewise, while you are free to specify registered relation values in your published feeds as absolute IRIs including the http://www.iana.org/assignments/relation/ base, doing so is unwise. The spec indeed doesn=E2=80=99t say, so you may indeed use whatever you prefer. That does not mean all preferences are equally wise. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 11:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSMV-0001sJ-JH for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:11:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSMT-0006pb-HI for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:11:55 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VEtsmR015667; Wed, 31 May 2006 07:55:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VEtshG015666; Wed, 31 May 2006 07:55:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VEtq4q015616 for ; Wed, 31 May 2006 07:55:53 -0700 (MST) (envelope-from prabhaka@apple.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4VEtjXr007435; Wed, 31 May 2006 07:55:45 -0700 (PDT) Received: from [17.112.109.64] (unknown [17.112.109.64]) by relay5.apple.com (Apple SCV relay) with ESMTP id 242BF324002; Wed, 31 May 2006 07:55:44 -0700 (PDT) In-Reply-To: <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> References: <444C2C01.5040005@intertwingly.net> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: James M Snell , Atom Syntax Content-Transfer-Encoding: 7bit From: Ernest Prabhakar Subject: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] Date: Wed, 31 May 2006 07:55:42 -0700 To: Robert Sayre X-Mailer: Apple Mail (2.752) X-Brightmail-Tracker: AAAAAA== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hi Robert, While I'm not entirely thrilled with James, and I believe you provide some useful perspective, if you think it is appropriate and ethical to respond by posting private email to the list, I must reluctantly conclude that this list is better off without you. Sincerely, Ernest Prabhakar On May 30, 2006, at 7:25 PM, Robert Sayre wrote: > > Hmm, do you harass everyone who disagrees with you like this? I am > kind of taken aback by this unprofessional conduct. I don't see how I > am supposed to participate in an IETF working group if the document > authors are going to engage in this kind of vitriol. I wonder if you > think it's ok to write this kind of thing in private email. I'm > disappointed. :/ > > On 5/30/06, James M Snell wrote: >> [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] >> >> Had I meant to cc the list, it stands to reason that I would have >> cc'd >> the list. >> >> I've grown quite tired of this >> Insult-James-And-Everything-He-Does-And-Says campaign of yours. >> You are >> accomplishing nothing. Get a life and move on. >> >> - James >> >> [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] >> >> Robert Sayre wrote: >> > >> > I think James forgot to cc the list >> > >> > ---------- Forwarded message ---------- >> > From: James M Snell >> > Date: May 30, 2006 9:38 PM >> > Subject: Re: Link rel test cases >> > To: Robert Sayre >> > >> > >> > >> > >> > Robert Sayre wrote: >> >> [snip]...have James add it to his revision of 4287. :) >> >> >> >> >> > >> > Pardon, what the hell are you talking about? Do you really, >> honestly >> > believe that being a complete ass is a productive use of >> anyone's time? >> > >> > - James >> > >> > >> > > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > From owner-atom-syntax@mail.imc.org Wed May 31 11:42:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSq0-0007WT-5z for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:42:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSpy-0001Zz-F9 for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:42:24 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VFO3SY023645; Wed, 31 May 2006 08:24:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VFO3Pu023644; Wed, 31 May 2006 08:24:03 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VFO1FV023635 for ; Wed, 31 May 2006 08:24:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i30so42135wra for ; Wed, 31 May 2006 08:24:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=OrZifiK+pP5X4kldmLjA4tITG+2G5omnD8gvxyZjrW6kdNcIQY98bnbJTWpUbBjSc3Oqk6s+pJPc463D4DclpXnfxIPyAUsqCWUdY2Q+5ixqBvjHfOplNqvmx8D9SLKV3rMpEC9I3qHAq6rNkQNEUans6lmOPTnZY9VWtxVp7jk= Received: by 10.54.113.3 with SMTP id l3mr286995wrc; Wed, 31 May 2006 08:24:01 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 11sm1629667wrl.2006.05.31.08.24.00; Wed, 31 May 2006 08:24:01 -0700 (PDT) Message-ID: <447DB4F6.9070804@gmail.com> Date: Wed, 31 May 2006 08:23:34 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <20060531124116.GV3748@klangraum> In-Reply-To: <20060531124116.GV3748@klangraum> 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 A. Pagaltzis wrote: >[snip] > RFC4287 defines the relation value in terms of IRIs, but does not > require that relations be compared as such, and then constrains > the set of values to a subset of IRIs. This constrained set is > more amenable to simple string comparison. My interpretation of > these facts is that string comparison is explicitly expected. > +1. I don't believe any reasonable implementation should be expected to do anything more than a simple case-sensitive string comparison of the IRI. If an implementation chooses to be forgiving and perform some form of normalized comparison, then that's the implementations choice. In Abdera, I went ahead and checked in a change that normalizes the IRI then compares the result with the "http://www.iana.org/assignments/relation/alternate" form. > Given then that all implementations that I have read the source > of do indeed compare relation values as strings, my conclusion is > that while you are free to compare them as IRIs, doing so is > unwise; likewise, while you are free to specify registered > relation values in your published feeds as absolute IRIs > including the http://www.iana.org/assignments/relation/ base, > doing so is unwise. > I wouldn't say comparing as IRI's in unwise as much as it is simply very forgiving. Publishing a feed that uses rel values that are not in a normalized form is unwise as your pretty much guaranteeing that folks won't be able to process your feed properly. - James From owner-atom-syntax@mail.imc.org Wed May 31 11:56:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlT3g-0006Wa-1e for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:56:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlT3d-0003AY-9r for atompub-archive@lists.ietf.org; Wed, 31 May 2006 11:56:32 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VFibvu029126; Wed, 31 May 2006 08:44:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VFib35029122; Wed, 31 May 2006 08:44:37 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VFiZes029109 for ; Wed, 31 May 2006 08:44:36 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so96615nfc for ; Wed, 31 May 2006 08:44:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YE+cd07vqOTQnvX85afah5DdkWAFMyOu/4jSFAWQY4Wd7+IshlLeMnuDgrW7KLOL7vUahhWUiNHlblzBzrRvc2Zu4dLk1zaOaHAFJp+AUgprLDBzX6XdYj/a/FGla+AO+PfwjCz1yYYXJOodhCIhx9vJc4bI+ZzNasRu1Ov6c6M= Received: by 10.48.242.14 with SMTP id p14mr428848nfh; Wed, 31 May 2006 08:44:33 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Wed, 31 May 2006 08:44:33 -0700 (PDT) Message-ID: <68fba5c50605310844x5001d3b7n1b8a9d04c82ec2e0@mail.gmail.com> Date: Wed, 31 May 2006 11:44:33 -0400 From: "Robert Sayre" To: "Ernest Prabhakar" Subject: Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] Cc: "James M Snell" , "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <444C2C01.5040005@intertwingly.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 5/31/06, Ernest Prabhakar wrote: > > While I'm not entirely thrilled with James, and I believe you provide > some useful perspective, > if you think it is appropriate and ethical to respond by posting > private email to the list, I must reluctantly conclude that this list > is better off without you. > James has taken private conversations on-list: [ ] yes [ ] no So please, spare me the lecture. I don't want to get nasty emails from James anymore. My problem is solved. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 31 13:10:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUD5-0008Ml-Bn for atompub-archive@lists.ietf.org; Wed, 31 May 2006 13:10:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUD2-0001Bm-Vs for atompub-archive@lists.ietf.org; Wed, 31 May 2006 13:10:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VGrwpC047402; Wed, 31 May 2006 09:53:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VGrw31047401; Wed, 31 May 2006 09:53:58 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VGruWA047351 for ; Wed, 31 May 2006 09:53:56 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 16:53:50 -0000 Received: from xdsl-81-173-168-27.netcologne.de (EHLO klangraum) [81.173.168.27] by mail.gmx.net (mp034) with SMTP; 31 May 2006 18:53:50 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 18:54:05 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] Message-ID: <20060531165405.GB3748@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> <68fba5c50605310844x5001d3b7n1b8a9d04c82ec2e0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605310844x5001d3b7n1b8a9d04c82ec2e0@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VGrwpC047402 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad * Robert Sayre [2006-05-31 17:55]: > So please, spare me the lecture. I don't want to get nasty > emails from James anymore. My problem is solved. If you hadn=E2=80=99t dropped an asinine jab at him into a completely unrelated thread you might not have created the problem that you would then need to =E2=80=9Csolve=E2=80=9D in the first place. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 13:39:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUfO-0004Ub-Fx for atompub-archive@lists.ietf.org; Wed, 31 May 2006 13:39:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUfM-0004Yw-4u for atompub-archive@lists.ietf.org; Wed, 31 May 2006 13:39:34 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VHNhDC055371; Wed, 31 May 2006 10:23:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VHNhiO055370; Wed, 31 May 2006 10:23:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VHNfuQ055360 for ; Wed, 31 May 2006 10:23:42 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id g2so135152nfe for ; Wed, 31 May 2006 10:23:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iRHnwgbUysirj+7YJUB0mT+k3WZ6r5hOe/+SZLFnELk53RXqGuejkDC3c4SY8gNWS61Sds6BmeVl2SOYsyFT3elQ00vooEaRb3HMoyT/c9BWPaJdGrEX//OnIdTF0oIIXakp13Vu0BQUBEwK7IbhpXmTZ8oiFKCZyrBrm9Udqm8= Received: by 10.48.218.9 with SMTP id q9mr590917nfg; Wed, 31 May 2006 10:23:40 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Wed, 31 May 2006 10:23:39 -0700 (PDT) Message-ID: <68fba5c50605311023k373c9c52h89253daedabeb0e9@mail.gmail.com> Date: Wed, 31 May 2006 13:23:39 -0400 From: "Robert Sayre" To: atom-syntax@imc.org Subject: Re: Link rel test cases In-Reply-To: <20060531124116.GV3748@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <20060531124116.GV3748@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 5/31/06, A. Pagaltzis wrote: > > My interpretation of > these facts is that string comparison is explicitly expected. Incorrect. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 31 14:10:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV9k-0003di-Vg for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:10:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV9k-0006Xt-UM for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:10:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlUvz-0003C9-Nh for atompub-archive@lists.ietf.org; Wed, 31 May 2006 13:56:46 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VHYW26058208; Wed, 31 May 2006 10:34:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VHYWlN058207; Wed, 31 May 2006 10:34:32 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VHYR7G058198 for ; Wed, 31 May 2006 10:34:30 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id g2so138203nfe for ; Wed, 31 May 2006 10:34:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I6i7Pa6lpIOgB19JYYoXz2tgb9IH1ccunIUA2w+R3A2IB1U6tuo02AOYnmTdZ4tT7YnNHg4r4ZcLrbTla3uRf0JdWCQT/hQLzRUlDl4baZX9RJudvyEHjy3LhQdd9GEPhFNtE55hgm1Nq+5xW6oa5moiMIORIcgA0fxfjtDTfjg= Received: by 10.49.35.4 with SMTP id n4mr612701nfj; Wed, 31 May 2006 10:34:27 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Wed, 31 May 2006 10:34:27 -0700 (PDT) Message-ID: <68fba5c50605311034l33ba0c8dy4b89147476690c99@mail.gmail.com> Date: Wed, 31 May 2006 13:34:27 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] In-Reply-To: <20060531165405.GB3748@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> <68fba5c50605310844x5001d3b7n1b8a9d04c82ec2e0@mail.gmail.com> <20060531165405.GB3748@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.6 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 5/31/06, A. Pagaltzis wrote: > > If you hadn't dropped an asinine jab at him into a completely > unrelated thread you might not have created the problem that you > would then need to "solve" in the first place. Actually, those were just the latest two. But you didn't know that, did you? How about you go back to writing your Atom code? If you have further comments, send them somewhere else. If you send them to me, I'll be sure to put them with the other unread emails from you. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 31 14:12:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVBE-0004Az-E4 for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:12:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVBD-0006nF-14 for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:12:28 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VHv1cn064282; Wed, 31 May 2006 10:57:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VHv1r1064281; Wed, 31 May 2006 10:57:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VHuvTf064235 for ; Wed, 31 May 2006 10:57:00 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 17:56:51 -0000 Received: from xdsl-81-173-168-27.netcologne.de (EHLO klangraum) [81.173.168.27] by mail.gmx.net (mp019) with SMTP; 31 May 2006 19:56:51 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 19:57:07 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Link rel test cases Message-ID: <20060531175707.GD3748@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <20060531124116.GV3748@klangraum> <68fba5c50605311023k373c9c52h89253daedabeb0e9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605311023k373c9c52h89253daedabeb0e9@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VHv1cn064282 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi Robert, * Robert Sayre [2006-05-31 19:35]: > On 5/31/06, A. Pagaltzis wrote: > > > >My interpretation of these facts is that string comparison is > >explicitly expected. >=20 > Incorrect. I don=E2=80=99t see how, although I can see how what I wrote might be ambiguous. Substitute =E2=80=9Cexpected=E2=80=9D by =E2=80=9Canticipated = and provided for=E2=80=9D to get something closer to what I meant, perhaps. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 14:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVGS-0006Yh-Jl for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:17:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVGR-00077R-3q for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:17:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VI4YxT065889; Wed, 31 May 2006 11:04:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VI4Y1n065888; Wed, 31 May 2006 11:04:34 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VI4XEB065870 for ; Wed, 31 May 2006 11:04:33 -0700 (MST) (envelope-from Tim.Bray@Sun.COM) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4VI4XmO004319 for ; Wed, 31 May 2006 12:04:33 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0500H015ZW0O00@mail-amer.sun.com> (original mail from Tim.Bray@Sun.COM) for atom-syntax@imc.org; Wed, 31 May 2006 12:04:33 -0600 (MDT) Received: from [192.168.102.100] ([154.20.170.13]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J050022667KFSH0@mail-amer.sun.com>; Wed, 31 May 2006 12:04:32 -0600 (MDT) Date: Wed, 31 May 2006 11:04:33 -0700 From: Tim Bray Subject: Re: Link rel test cases In-reply-to: To: James Holderness Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Priority: 3 References: <444C2C01.5040005@intertwingly.net> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On May 30, 2006, at 5:25 PM, James Holderness wrote: > I agree completely, but as a content consumer I still need to know > whether to use IRI::Compare or String::Compare when I do encounter > some ridiculous feed that uses example (a). I'm hoping for a simple > answer along the lines of "Use IRI:Compare", "Use String::Compare", > or "The spec doesn't say, so you may use whatever you prefer". Both are perfectly legal. IRI::Compare will avoid some false negatives at the cost of burning some CPU cycles. Postel's law would suggest using IRI::Compare initially, but if a profiler revealed it to be a performance bottleneck, I'd nuke it in favor of strcmp() without a second's hesitation. I actually wouldn't be surprised if that happened; case-insensitivity and Unicode sit poorly together and are a notorious source of performance sinkholes. -Tim From owner-atom-syntax@mail.imc.org Wed May 31 14:30:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVT7-0004Ok-1f for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:30:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVT5-0007p2-N9 for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:30:57 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIEhHW068593; Wed, 31 May 2006 11:14:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VIEhi1068592; Wed, 31 May 2006 11:14:43 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIEcqt068560 for ; Wed, 31 May 2006 11:14:40 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so156581nfc for ; Wed, 31 May 2006 11:14:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gi/3+dzOOPxrwBOS4ZN466WaLHLIq1nJqTpQi9yFqn2DEc2uiAHUoAVy7+sWRMKljbAhe6rZvA/autMd6hnnf/XFaAsfJjkKLv+rVoWcZ6UIOCShP5NlEGjKXJLQovHtxDn3n23qaJCMGhiJKPBGWim/Qqc6bAU0UkGr3nX1OGk= Received: by 10.48.48.7 with SMTP id v7mr671355nfv; Wed, 31 May 2006 11:14:37 -0700 (PDT) Received: by 10.48.207.6 with HTTP; Wed, 31 May 2006 11:14:37 -0700 (PDT) Message-ID: <68fba5c50605311114v36bc7214i9fd5968cc5d0c8f0@mail.gmail.com> Date: Wed, 31 May 2006 14:14:37 -0400 From: "Robert Sayre" To: atom-syntax@imc.org Subject: Re: Link rel test cases In-Reply-To: <20060531175707.GD3748@klangraum> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <20060531124116.GV3748@klangraum> <68fba5c50605311023k373c9c52h89253daedabeb0e9@mail.gmail.com> <20060531175707.GD3748@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.9 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 5/31/06, A. Pagaltzis wrote: > > Hi Robert, > > * Robert Sayre [2006-05-31 19:35]: > > On 5/31/06, A. Pagaltzis wrote: > > > > > >My interpretation of these facts is that string comparison is > > >explicitly expected. > > > > Incorrect. > > I don't see how If it was explicit, you wouldn't need to interpret. Thanks for playing. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed May 31 14:36:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVYf-00063s-Bf for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:36:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVYd-0000YN-Vm for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:36:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIE69W068454; Wed, 31 May 2006 11:14:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VIE6CR068453; Wed, 31 May 2006 11:14:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VIE4PO068425 for ; Wed, 31 May 2006 11:14:05 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 18:13:57 -0000 Received: from xdsl-81-173-168-27.netcologne.de (EHLO klangraum) [81.173.168.27] by mail.gmx.net (mp033) with SMTP; 31 May 2006 20:13:57 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 20:14:12 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST] Message-ID: <20060531181412.GE3748@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <447CF39B.4060603@gmail.com> <68fba5c50605301849g37bc0895hb22e7e64bede0104@mail.gmail.com> <447CFD0A.7040801@gmail.com> <68fba5c50605301925x3cdaf777i74001d402277a1d9@mail.gmail.com> <68fba5c50605310844x5001d3b7n1b8a9d04c82ec2e0@mail.gmail.com> <20060531165405.GB3748@klangraum> <68fba5c50605311034l33ba0c8dy4b89147476690c99@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605311034l33ba0c8dy4b89147476690c99@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VIE69W068454 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 * Robert Sayre [2006-05-31 19:55]: > On 5/31/06, A. Pagaltzis wrote: > >If you hadn't dropped an asinine jab at him into a completely > >unrelated thread you might not have created the problem that > >you would then need to "solve" in the first place. >=20 > Actually, those were just the latest two. But you didn't know > that, did you? No, I didn=E2=80=99t. You sure picked an unfortunate sample to forward back to the list, though. > How about you go back to writing your Atom code? How about you leave conjecture out of your commentary about other people=E2=80=99s activities? > If you have further comments, send them somewhere else. If you > send them to me, I'll be sure to put them with the other unread > emails from you. Duly noted. I only ever remember sending you a single email anyway, and that was a thank-you note for one really good criticism you posted here somewhat recently that even refrained from any personal attacks. What a pity that it would go unread. Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 14:42:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVe1-0007rg-Kb for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:42:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVe0-0001S6-8m for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:42:13 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIKJrC070123; Wed, 31 May 2006 11:20:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VIKJl3070122; Wed, 31 May 2006 11:20:19 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIKIew070115 for ; Wed, 31 May 2006 11:20:19 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so78409wra for ; Wed, 31 May 2006 11:20:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BXGOcz5nFq1Tg+Btmlp1FH6Oy71Au9uCr44h/GnIYmRVZNbfNupmSJxIfNr+DnX0OupzakJhe1krljf4nf60IGXlGa+Wny5y9gskzeZONs4ezqaiWqBGi3xdbgX5VY5Tbc1aWHRiw+UmW0E0x1yCZPEPvuEqsQC9Xt46zpSvEQ8= Received: by 10.54.114.4 with SMTP id m4mr437217wrc; Wed, 31 May 2006 11:20:17 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g9sm1846094wra.2006.05.31.11.20.16; Wed, 31 May 2006 11:20:17 -0700 (PDT) Message-ID: <447DDE5E.5050808@gmail.com> Date: Wed, 31 May 2006 11:20:14 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <20060425210446.GE29846@klangraum> <444E95F6.8060700@gmail.com> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 +1 Tim Bray wrote: > > On May 30, 2006, at 5:25 PM, James Holderness wrote: > >> I agree completely, but as a content consumer I still need to know >> whether to use IRI::Compare or String::Compare when I do encounter >> some ridiculous feed that uses example (a). I'm hoping for a simple >> answer along the lines of "Use IRI:Compare", "Use String::Compare", or >> "The spec doesn't say, so you may use whatever you prefer". > > Both are perfectly legal. IRI::Compare will avoid some false negatives > at the cost of burning some CPU cycles. Postel's law would suggest > using IRI::Compare initially, but if a profiler revealed it to be a > performance bottleneck, I'd nuke it in favor of strcmp() without a > second's hesitation. I actually wouldn't be surprised if that happened; > case-insensitivity and Unicode sit poorly together and are a notorious > source of performance sinkholes. -Tim > > From owner-atom-syntax@mail.imc.org Wed May 31 14:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVls-0004Th-Fg for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:50:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVlq-0002Ef-3a for atompub-archive@lists.ietf.org; Wed, 31 May 2006 14:50:20 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VIb1Cv074390; Wed, 31 May 2006 11:37:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VIb1h2074389; Wed, 31 May 2006 11:37:01 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k4VIb0Mq074354 for ; Wed, 31 May 2006 11:37:00 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 31 May 2006 18:36:51 -0000 Received: from xdsl-81-173-168-27.netcologne.de (EHLO klangraum) [81.173.168.27] by mail.gmx.net (mp035) with SMTP; 31 May 2006 20:36:51 +0200 X-Authenticated: #163624 Date: Wed, 31 May 2006 20:37:06 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Link rel test cases Message-ID: <20060531183706.GG3748@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <20060531124116.GV3748@klangraum> <68fba5c50605311023k373c9c52h89253daedabeb0e9@mail.gmail.com> <20060531175707.GD3748@klangraum> <68fba5c50605311114v36bc7214i9fd5968cc5d0c8f0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68fba5c50605311114v36bc7214i9fd5968cc5d0c8f0@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k4VIb1Cv074390 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 * Robert Sayre [2006-05-31 20:25]: > >> On 5/31/06, A. Pagaltzis wrote: > >> > > >> >My interpretation of these facts is that string comparison > >> >is explicitly expected. >=20 > If it was explicit, you wouldn't need to interpret. Okay, more imprecise wording. Make that =E2=80=9Cspecifically anticipated.=E2=80=9D Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed May 31 15:25:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWJX-0004e0-Kz for atompub-archive@lists.ietf.org; Wed, 31 May 2006 15:25:07 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWJT-00060F-6t for atompub-archive@lists.ietf.org; Wed, 31 May 2006 15:25:07 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VJA6TF082317; Wed, 31 May 2006 12:10:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k4VJA6MF082316; Wed, 31 May 2006 12:10:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4VJA3ug082307 for ; Wed, 31 May 2006 12:10:04 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so88430wra for ; Wed, 31 May 2006 12:10:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HrqwMIjUAIG4q7vLCfiDPuN6XxNNj9tDkYPejx9VH6yLMwLiQOhN94fyO7avL1J8xNw2LdxcEm5gG3lOzsmoLuUPb0Kx7tMncQZFdLUEugY7LnY373KSK5raBe0ehMJ1Dt+AGj4Y51PUq9ZDVzjU7gwaYhKrY0vojd2bTCO+NuM= Received: by 10.54.156.10 with SMTP id d10mr426031wre; Wed, 31 May 2006 12:10:02 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 25sm329847wra.2006.05.31.12.10.01; Wed, 31 May 2006 12:10:02 -0700 (PDT) Message-ID: <447DEA04.90100@gmail.com> Date: Wed, 31 May 2006 12:09:56 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Martin Duerst CC: atom-syntax@imc.org Subject: Re: Link rel test cases References: <444C2C01.5040005@intertwingly.net> <444EAEFB.5020901@gmail.com> <4477033C.4060602@rbg.informatik.tu-darmstadt.de> <68fba5c50605261057q4a7f1c28raf0cd78983d901e0@mail.gmail.com> <954552624.20060526195412@djpowell.net> <68fba5c50605261237w33d9ce14i879cb4e03fab73f5@mail.gmail.com> <6.0.0.20.2.20060530124651.0983a180@localhost> <68fba5c50605301742n4a649bect5d0338e67e894c47@mail.gmail.com> <6.0.0.20.2.20060531141131.043f8970@localhost> In-Reply-To: <6.0.0.20.2.20060531141131.043f8970@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 For me, the difference tends to fall in terms of whether or not the IRI is intended to be dereferenceable or not. If the IRI is intended to be used solely as an indentifier (e.g. atom:id, XML Namespaces, etc), then character-comparison (at a maximum) is appropriate. If the IRI is intended to be a navigatable reference, then some degree of normalization is appropriate. In the case of the link/@rel and category/@scheme, Atom does not say whether or not the IRI's should be considered to be dereferenceable. @rel and @scheme are clearly intended to be used primarily as identifiers. - James Martin Duerst wrote: >[snip] > Well, RFC 3987 (and 3986) don't *exactly* say "use whatever you prefer", > but for the case at hand, what they say comes pretty close. > What they try to do is give advice on what kind of normalization > or comparison function(s) is/are adequate in which case. > Given that it's difficult to immagine every possible case in > advace, the advice they give unfortuanetly has to be somewhat > vague. > > BTW, as a co-author of RFC 3987, I of course appreciate any > suggestion on how to make it clearer, and any suggestions for > fixes or changes (should they be necessary). These should be > directed to public-iri@w3.org. > > Regards, Martin. > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > >