From owner-atom-syntax@mail.imc.org Tue Jun 06 21:05:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmU5-000253-QW for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 21:05:21 -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 1FnmU5-0006iE-OJ for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 21:05:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnmU4-0006c6-0L for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 21:05: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 k570hPtw014755; Tue, 6 Jun 2006 17:43: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 k570hPRs014754; Tue, 6 Jun 2006 17:43: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k570hOvX014724 for ; Tue, 6 Jun 2006 17:43:25 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from JOHNPANZER.ad.aol.aoltw.net (h-10-169-155-222.nscp.aoltw.net [10.169.155.222]) by mcom.com (8.10.0/8.10.0) with ESMTP id k570hJG19169 for ; Tue, 6 Jun 2006 17:43:19 -0700 (PDT) Date: Tue, 6 Jun 2006 17:43:19 -0700 From: "John Panzer" Subject: Discoverability of feeds with differing licences To: atom-syntax Message-ID: <44862127.8010508@aol.net> X-Mailer: AOL Communicator (20030919.3 Win) Organization: AOL MIME-Version: 1.0 Content-Type: TEXT/HTML; CHARSET=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.0 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 All,

Some sites offer two versions of feeds; one is a 'headline only' version and the other a 'full' version.  Other than the content, a significant distinction in some cases is the license applied to the data in each feed.  (See http://wiki.creativecommons.org/Syndication.)  For example, the Engadget site offers a headline only feed with (the equivalent of a) by-sa Creative Commons license, while its full text is by-nc-sa, prohibiting copying for commercial use.

Okay, so far so good.  But let's say I'm an ad supported aggregator (commercial use of content). I cannot therefore display the 'full' feed and I'll need to truncate or elide the content.  However, I could display the 'excerpt' feed with no problems.  It would be nice if I could discover the related 'headlines' feed (which I can display with full fidelity) if the user tries to subscribe to the 'full' feed through my ad supported aggregator.  However, right now, there's no automatic way to do that.

A link@rel seems appropriate; I'm thinking of doing this:

<link rel="alternate" type="application/atom+xml" title="Headlines Only" href="..."/>

...and then relying on software to determine that (1) there's another alternative version of the feed that (2) has a different license (requires fetching the feed of course) and (3) perhaps should be offered as an alternative to the user, or used instead of blindly truncating text.

My major question is whether a "headline only" feed is an "alternate" representation, or perhaps an "index" to the full feed, or perhaps a new relation (or two) is needed.

Thoughts?

--
AbstractioneerJohn Panzer
System Architect
http://abstractioneer.org
 From owner-atom-syntax@mail.imc.org Tue Jun 06 21:06:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmUy-00026s-4v for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 21:06:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmUv-0006kb-Lz for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 21:06: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 k570sD3D018110; Tue, 6 Jun 2006 17:54: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 k570sDOB018109; Tue, 6 Jun 2006 17:54: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 mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k570sCqB018085 for ; Tue, 6 Jun 2006 17:54:12 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (snv-global1.corp.yahoo.com [216.145.49.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A646AA3202 for ; Tue, 6 Jun 2006 20:54:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Paging, Feed History, etc. Date: Tue, 6 Jun 2006 17:54:14 -0700 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: 82c9bddb247d9ba4471160a9a865a5f3 I've been talking to a number of people face-to-face about Feed History and the use cases for it, and I've come to a position where I believe there are two major use cases out there for putting together multiple feeds to form one big, virtual feed. 1) So-called "incremental" feeds, where changes are happening at the "front end" of the feed, while less recent entries are pretty much static. If a change is required in an old entry, either a new revised entry with the same ID, or something like a tombstone is required. Publishers can easily make stable archives of old entries available, and clients wish to take advantage of caching, etc. to avoid re- transferring old entries again and again. A high degree of fidelity may be required; e.g., it should be possible to accurately reconstruct the entire state of the feed with no missed entries. E.g., a blog feed, but this could also be seen as an "event feed", where the entries are changes to the state of the underlying resources. 2) So-called "paging" feeds, where the entries are often the results to a query, being paged through in groups so as to not overwhelm the server and/or communications link. Entries may be arbitrarily added, deleted and reordered. Clients expect to access what the portions they need in relatively quick succession, and do not require absolute fidelity. E.g., OpenSearch query results. The entries in the feed directly correspond to the underlying resources, 1-to-1. These are very different things. Incremental feeds require that the server keep state around per-feed, which isn't viable for something like query results, but fine for a blog. Paging feeds can lose entries (e.g., if http://example.org/index.page?page=1 refers to http://example.org/index.atom?page=2, page 2's contents can change between the two fetches), which is OK for some applications, and not for others. As such, I'm pretty much convinced that they need to be dealt with separately. Originally, I proposed that Feed History use "prev-archive" link relations, but many people pushed back on that in favour of the more generic "previous" and "next". Given the above, I'd like to see if anyone would still object to having separate relation sets for incremental feeds ("prev-archive" and friends) and paging feeds ("previous", "next" and friends). If people think that's a good idea, I can prepare a new draft that attempts to address both. The intent would be to be compatible with current usage by OpenSearch, GData, etc., while giving people the option to use something more reliable when necessary. Thoughts? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Jun 06 22:09:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnnUB-0007ew-CL for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:09:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnnU8-0004dw-Ub for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:09: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 k571tu3E035735; Tue, 6 Jun 2006 18:55: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 k571tuw5035732; Tue, 6 Jun 2006 18:55: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k571tte9035698 for ; Tue, 6 Jun 2006 18:55:55 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.20] (sera-10-169-186-20.nscp.aoltw.net [10.169.186.20]) by mcom.com (8.10.0/8.10.0) with ESMTP id k571tnG21128 for ; Tue, 6 Jun 2006 18:55:49 -0700 (PDT) Message-ID: <4486322C.20307@aol.net> Date: Tue, 06 Jun 2006 18:55:56 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Paging, Feed History, etc. 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.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Mark Nottingham wrote: > > I've been talking to a number of people face-to-face about Feed > History and the use cases for it, and I've come to a position where I > believe there are two major use cases out there for putting together > multiple feeds to form one big, virtual feed. > > 1) So-called "incremental" feeds, where changes are happening at the > "front end" of the feed, while less recent entries are pretty much > static. If a change is required in an old entry, either a new revised > entry with the same ID, or something like a tombstone is required. > Publishers can easily make stable archives of old entries available, > and clients wish to take advantage of caching, etc. to avoid re- > transferring old entries again and again. A high degree of fidelity > may be required; e.g., it should be possible to accurately > reconstruct the entire state of the feed with no missed entries. > E.g., a blog feed, but this could also be seen as an "event feed", > where the entries are changes to the state of the underlying resources. > > 2) So-called "paging" feeds, where the entries are often the results > to a query, being paged through in groups so as to not overwhelm the > server and/or communications link. Entries may be arbitrarily added, > deleted and reordered. Clients expect to access what the portions > they need in relatively quick succession, and do not require absolute > fidelity. E.g., OpenSearch query results. The entries in the feed > directly correspond to the underlying resources, 1-to-1. > > These are very different things. Incremental feeds require that the > server keep state around per-feed, which isn't viable for something > like query results, but fine for a blog. Paging feeds can lose > entries (e.g., if http://example.org/index.page?page=1 refers to > http://example.org/index.atom?page=2, page 2's contents can change > between the two fetches), which is OK for some applications, and not > for others. > > As such, I'm pretty much convinced that they need to be dealt with > separately. > > Originally, I proposed that Feed History use "prev-archive" link > relations, but many people pushed back on that in favour of the more > generic "previous" and "next". > > Given the above, I'd like to see if anyone would still object to > having separate relation sets for incremental feeds ("prev-archive" > and friends) and paging feeds ("previous", "next" and friends). > > If people think that's a good idea, I can prepare a new draft that > attempts to address both. The intent would be to be compatible with > current usage by OpenSearch, GData, etc., while giving people the > option to use something more reliable when necessary. > > Thoughts? +1. I think this is worthwhile[1] and I'd have no objections, even if this requires changing our implementation of previous/next. Having attempted an implementation, I believe there's a substantial risk of confusion between incremental and paging relations and different names would help a lot. Also, I can easily see us wanting to implement both incremental feeds and paging feeds in the same application at least. -John [1] Full disclosure: I'm one of the people who talked to Mark face to face about this. From owner-atom-syntax@mail.imc.org Tue Jun 06 22:37:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnve-00044R-SG for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:37:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnvd-0007sg-Bo for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:37: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 k572L5aX042714; Tue, 6 Jun 2006 19:21:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k572L5jZ042713; Tue, 6 Jun 2006 19:21:05 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k572L2xG042692 for ; Tue, 6 Jun 2006 19:21:03 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so69030nzd for ; Tue, 06 Jun 2006 19:21: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=jxvL25xqClyp/7pmqYG+aYym9uaN5C3KEbFSpcvSJuKsZBkY0ZV2/TuhQi4pJj/uzpaDuQMV4zAYlxGnF3OPhMaVu/ZTsNo9qAVkyMp1SvTTk0HF5Mgingc8s/yyeQM76dK4A7ke1K23yOAx/y8xDR1woY/NyajYyaa7YmeKjv8= Received: by 10.65.114.17 with SMTP id r17mr25162qbm; Tue, 06 Jun 2006 19:21:02 -0700 (PDT) Received: by 10.65.215.14 with HTTP; Tue, 6 Jun 2006 19:21:02 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2006 20:21:02 -0600 From: "M. David Peterson" To: "John Panzer" Subject: Re: Discoverability of feeds with differing licences Cc: atom-syntax , "Bruce D'Arcus" In-Reply-To: <44862127.8010508@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44862127.8010508@aol.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hey John, This is obviously an important question that also relates to the GlobalClip/Citation work that I Bruce D'Arcus (Cc'd) and myself are working on to allow the ability to extract all of the relative meta-data, including licensing information, as part of a copy/paste operation [web page > Oo.o, Word, etc...]. Thus far I have been using the documentation on Creative Commons (http://creativecommons.org/technology/metadata/index_html) that covers this area quite extensively. My question: Is there any reason why the RDF method described at the above link should not be the method promoted as the de facto standard? I completely understand your reasoning behind looking to find a solution to correctly propagate and promote a particular method for content producers in whom use multiple licenses dependent upon various factors such as those you've mentioned. While using the rel attribute seems to be an easy route, I'm not so sure that all of the various distinctions can be properly handled by a single attribute. With this in mind, it *seems* that given the existing RDF route promoted by CreativeCommons covers all of the necessary pieces to allow for such things, this would by far be the best route to promote to content producers. Thoughts? On 6/6/06, John Panzer wrote: > > All, > > Some sites offer two versions of feeds; one is a 'headline only' version > and the other a 'full' version. Other than the content, a significant > distinction in some cases is the license applied to the data in each feed. > (See http://wiki.creativecommons.org/Syndication.) For > example, the Engadget site offers a headline only feed with (the equivalent > of a) by-sa Creative Commons license, while its full text is by-nc-sa, > prohibiting copying for commercial use. > > Okay, so far so good. But let's say I'm an ad supported aggregator > (commercial use of content). I cannot therefore display the 'full' feed and > I'll need to truncate or elide the content. However, I could display the > 'excerpt' feed with no problems. It would be nice if I could discover the > related 'headlines' feed (which I can display with full fidelity) if the > user tries to subscribe to the 'full' feed through my ad supported > aggregator. However, right now, there's no automatic way to do that. > > A link@rel seems appropriate; I'm thinking of doing this: > > href="..."/> > > ...and then relying on software to determine that (1) there's another > alternative version of the feed that (2) has a different license (requires > fetching the feed of course) and (3) perhaps should be offered as an > alternative to the user, or used instead of blindly truncating text. > > My major question is whether a "headline only" feed is an "alternate" > representation, or perhaps an "index" to the full feed, or perhaps a new > relation (or two) is needed. > > Thoughts? > > -- > John Panzer > System Architect > http://abstractioneer.org > -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Tue Jun 06 22:40:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnxr-0004Zh-Rj for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:40:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnxq-0007wk-Cg for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 22:40: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 k572Og6F043765; Tue, 6 Jun 2006 19:24: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 k572Ogow043764; Tue, 6 Jun 2006 19:24: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 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 k572OfE5043748 for ; Tue, 6 Jun 2006 19:24:41 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so69553nzd for ; Tue, 06 Jun 2006 19:24: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:content-transfer-encoding:content-disposition:references; b=QGPKQXX4n4deF4tOwvClon5IxQNJfi+3xTcjmy0BQCmGE4Tn8x/C0A+QAPP54Chu93Iv/a1xcQVP2AxgGzPXZ+snaVmVZrICNLgQq7t9xJtuwjlXcD2hTS4pPGD0TvpmP/g4Sw50HlKF08L8JfxGMyzstrRWogwrZ0TX+A+EL+U= Received: by 10.65.234.10 with SMTP id l10mr24843qbr; Tue, 06 Jun 2006 19:24:41 -0700 (PDT) Received: by 10.65.215.14 with HTTP; Tue, 6 Jun 2006 19:24:41 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2006 20:24:41 -0600 From: "M. David Peterson" To: "Mark Nottingham" Subject: Re: Paging, Feed History, etc. Cc: "Atom Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Definite +1 On 6/6/06, Mark Nottingham wrote: > > I've been talking to a number of people face-to-face about Feed > History and the use cases for it, and I've come to a position where I > believe there are two major use cases out there for putting together > multiple feeds to form one big, virtual feed. > > 1) So-called "incremental" feeds, where changes are happening at the > "front end" of the feed, while less recent entries are pretty much > static. If a change is required in an old entry, either a new revised > entry with the same ID, or something like a tombstone is required. > Publishers can easily make stable archives of old entries available, > and clients wish to take advantage of caching, etc. to avoid re- > transferring old entries again and again. A high degree of fidelity > may be required; e.g., it should be possible to accurately > reconstruct the entire state of the feed with no missed entries. > E.g., a blog feed, but this could also be seen as an "event feed", > where the entries are changes to the state of the underlying resources. > > 2) So-called "paging" feeds, where the entries are often the results > to a query, being paged through in groups so as to not overwhelm the > server and/or communications link. Entries may be arbitrarily added, > deleted and reordered. Clients expect to access what the portions > they need in relatively quick succession, and do not require absolute > fidelity. E.g., OpenSearch query results. The entries in the feed > directly correspond to the underlying resources, 1-to-1. > > These are very different things. Incremental feeds require that the > server keep state around per-feed, which isn't viable for something > like query results, but fine for a blog. Paging feeds can lose > entries (e.g., if http://example.org/index.page?page=1 refers to > http://example.org/index.atom?page=2, page 2's contents can change > between the two fetches), which is OK for some applications, and not > for others. > > As such, I'm pretty much convinced that they need to be dealt with > separately. > > Originally, I proposed that Feed History use "prev-archive" link > relations, but many people pushed back on that in favour of the more > generic "previous" and "next". > > Given the above, I'd like to see if anyone would still object to > having separate relation sets for incremental feeds ("prev-archive" > and friends) and paging feeds ("previous", "next" and friends). > > If people think that's a good idea, I can prepare a new draft that > attempts to address both. The intent would be to be compatible with > current usage by OpenSearch, GData, etc., while giving people the > option to use something more reliable when necessary. > > Thoughts? > > > -- > Mark Nottingham http://www.mnot.net/ > > -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Tue Jun 06 23:27:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnohB-0003P4-KR for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23:27:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnoh9-0004m1-2Y for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23:27: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 k573EuSN059162; Tue, 6 Jun 2006 20:14: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 k573EuPj059161; Tue, 6 Jun 2006 20:14: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k573Eufp059129 for ; Tue, 6 Jun 2006 20:14:56 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.20] (sera-10-169-186-20.nscp.aoltw.net [10.169.186.20]) by mcom.com (8.10.0/8.10.0) with ESMTP id k573EnG23393; Tue, 6 Jun 2006 20:14:49 -0700 (PDT) Message-ID: <448644AB.4070804@aol.net> Date: Tue, 06 Jun 2006 20:14:51 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. David Peterson" CC: atom-syntax , "Bruce D'Arcus" Subject: Re: Discoverability of feeds with differing licences References: <44862127.8010508@aol.net> 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.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Hi David -- Not sure whether you're referring to feed licensing in general, or to the problem of feeds with differing licenses and their relationships. Can you clarify? In either case, I think that requiring RDF in order to license a piece of content would inhibit uptake. I think that's why most of the methods described at http://wiki.creativecommons.org/Syndication don't embed RDF directly. Of course they are indirectly referencing RDF in the case of Creative Commons licenses, so people who have RDF processors can certainly apply them constructively. However the license relations are not limited to RDF. In general, on a discussion, design, and implementation level, trying to deal with is a lot easier to deal with than It's also, of course, much shorter, which becomes important when you consider the use of per-entry licenses in synthetic feeds. The same arguments apply to microformats, I think, which is why rel-license exists... which might be relevant to GlobalClip. John M. David Peterson wrote: > > Hey John, > > This is obviously an important question that also relates to the > GlobalClip/Citation work that I Bruce D'Arcus (Cc'd) and myself are > working on to allow the ability to extract all of the relative > meta-data, including licensing information, as part of a copy/paste > operation [web page > Oo.o, Word, etc...]. > > Thus far I have been using the documentation on Creative Commons > (http://creativecommons.org/technology/metadata/index_html) that > covers this area quite extensively. > > My question: Is there any reason why the RDF method described at the > above link should not be the method promoted as the de facto standard? > > I completely understand your reasoning behind looking to find a > solution to correctly propagate and promote a particular method for > content producers in whom use multiple licenses dependent upon various > factors such as those you've mentioned. While using the rel attribute > seems to be an easy route, I'm not so sure that all of the various > distinctions can be properly handled by a single attribute. With this > in mind, it *seems* that given the existing RDF route promoted by > CreativeCommons covers all of the necessary pieces to allow for such > things, this would by far be the best route to promote to content > producers. > > Thoughts? > > On 6/6/06, John Panzer wrote: > >> >> All, >> >> Some sites offer two versions of feeds; one is a 'headline only' >> version >> and the other a 'full' version. Other than the content, a significant >> distinction in some cases is the license applied to the data in each >> feed. >> (See http://wiki.creativecommons.org/Syndication.) For >> example, the Engadget site offers a headline only feed with (the >> equivalent >> of a) by-sa Creative Commons license, while its full text is by-nc-sa, >> prohibiting copying for commercial use. >> >> Okay, so far so good. But let's say I'm an ad supported aggregator >> (commercial use of content). I cannot therefore display the 'full' >> feed and >> I'll need to truncate or elide the content. However, I could display >> the >> 'excerpt' feed with no problems. It would be nice if I could >> discover the >> related 'headlines' feed (which I can display with full fidelity) if the >> user tries to subscribe to the 'full' feed through my ad supported >> aggregator. However, right now, there's no automatic way to do that. >> >> A link@rel seems appropriate; I'm thinking of doing this: >> >> > href="..."/> >> >> ...and then relying on software to determine that (1) there's another >> alternative version of the feed that (2) has a different license >> (requires >> fetching the feed of course) and (3) perhaps should be offered as an >> alternative to the user, or used instead of blindly truncating text. >> >> My major question is whether a "headline only" feed is an "alternate" >> representation, or perhaps an "index" to the full feed, or perhaps a new >> relation (or two) is needed. >> >> Thoughts? >> >> -- >> John Panzer >> System Architect >> http://abstractioneer.org >> > > From owner-atom-syntax@mail.imc.org Tue Jun 06 23:43:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnoxa-0004Mc-4Z for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23:43:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnoxY-0006kP-EP for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23: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 k573X04o065027; Tue, 6 Jun 2006 20:33: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 k573X0FF065026; Tue, 6 Jun 2006 20:33: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 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 k573Wx28065006 for ; Tue, 6 Jun 2006 20:32:59 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so78975nzd for ; Tue, 06 Jun 2006 20:32: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=MqTB3hkeZnpG+p6rGdkWu+ff13/wmXvKVu6mtd8dV7spr915PKmtDmPJ1evM0Zisy//vppxodLZisO0E3TT/133Ml3WfgkQuPrjHMkqPogQVkZbcY/JNyklhRX2BMMjJXr3FEa0hjrrFBTo9r9hwQI/BWPD9QZTxU6hRQ40qqYA= Received: by 10.65.216.13 with SMTP id t13mr37485qbq; Tue, 06 Jun 2006 20:32:58 -0700 (PDT) Received: by 10.65.215.14 with HTTP; Tue, 6 Jun 2006 20:32:58 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2006 21:32:58 -0600 From: "M. David Peterson" To: "John Panzer" Subject: Re: Discoverability of feeds with differing licences Cc: atom-syntax , "Bruce D'Arcus" In-Reply-To: <448644AB.4070804@aol.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44862127.8010508@aol.net> <448644AB.4070804@aol.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 I'm not sure why I didn't realize this before, but as soon as you put "license" into the rel attribute it clicked for me. Okay, then I guess the question is not whether the RDF route shouldn't be promoted, but rather does the rel="[license]" approach allows for enough implied information to be extracted to be implemented in a way that allows for contained information to represent a "tag" that points to the proper RDF information that in turn points to the proper resource. The code to make something like this work and work well is SUPER easy, and off the top of my head I can't think of one reason why rel="cc:by-sa" shouldn't just work and work well by simply keeping a local RDF data store, or pointing to a community based data store to pull out the proper URI information that this particular license then relates to. Whats REALLY nice about this approach is the inherent ability to make a simple change the RDF data and have this propagate across an entire domain/organization appropriately. So if CC updates to a new version of the by-sa license, which obviously can and more than likely will happen at some point in the future given that the current 2.5 license suggests that a 1.x and 2.x family is already represented. Of course there are those who are going to jump in and suggest "Don't use Qnames in content cuz' of reason a, b, c" do which my response would be "already have a fix... I've just never published it." Maybe now would be a good time to publish that fix? :D On 6/6/06, John Panzer wrote: > Hi David -- > > Not sure whether you're referring to feed licensing in general, or to > the problem of feeds with differing licenses and their relationships. > Can you clarify? > > In either case, I think that requiring RDF in order to license a piece > of content would inhibit uptake. I think that's why most of the methods > described at http://wiki.creativecommons.org/Syndication don't embed RDF > directly. Of course they are indirectly referencing RDF in the case of > Creative Commons licenses, so people who have RDF processors can > certainly apply them constructively. However the license relations are > not limited to RDF. > > In general, on a discussion, design, and implementation level, trying to > deal with > > > > is a lot easier to deal with than > > > > It's also, of course, much shorter, which becomes important when you > consider the use of per-entry licenses in synthetic feeds. > > The same arguments apply to microformats, I think, which is why > rel-license exists... which might be relevant to GlobalClip. > > John > > M. David Peterson wrote: > > > > > Hey John, > > > > This is obviously an important question that also relates to the > > GlobalClip/Citation work that I Bruce D'Arcus (Cc'd) and myself are > > working on to allow the ability to extract all of the relative > > meta-data, including licensing information, as part of a copy/paste > > operation [web page > Oo.o, Word, etc...]. > > > > Thus far I have been using the documentation on Creative Commons > > (http://creativecommons.org/technology/metadata/index_html) that > > covers this area quite extensively. > > > > My question: Is there any reason why the RDF method described at the > > above link should not be the method promoted as the de facto standard? > > > > I completely understand your reasoning behind looking to find a > > solution to correctly propagate and promote a particular method for > > content producers in whom use multiple licenses dependent upon various > > factors such as those you've mentioned. While using the rel attribute > > seems to be an easy route, I'm not so sure that all of the various > > distinctions can be properly handled by a single attribute. With this > > in mind, it *seems* that given the existing RDF route promoted by > > CreativeCommons covers all of the necessary pieces to allow for such > > things, this would by far be the best route to promote to content > > producers. > > > > Thoughts? > > > > On 6/6/06, John Panzer wrote: > > > >> > >> All, > >> > >> Some sites offer two versions of feeds; one is a 'headline only' > >> version > >> and the other a 'full' version. Other than the content, a significant > >> distinction in some cases is the license applied to the data in each > >> feed. > >> (See http://wiki.creativecommons.org/Syndication.) For > >> example, the Engadget site offers a headline only feed with (the > >> equivalent > >> of a) by-sa Creative Commons license, while its full text is by-nc-sa, > >> prohibiting copying for commercial use. > >> > >> Okay, so far so good. But let's say I'm an ad supported aggregator > >> (commercial use of content). I cannot therefore display the 'full' > >> feed and > >> I'll need to truncate or elide the content. However, I could display > >> the > >> 'excerpt' feed with no problems. It would be nice if I could > >> discover the > >> related 'headlines' feed (which I can display with full fidelity) if the > >> user tries to subscribe to the 'full' feed through my ad supported > >> aggregator. However, right now, there's no automatic way to do that. > >> > >> A link@rel seems appropriate; I'm thinking of doing this: > >> > >> >> href="..."/> > >> > >> ...and then relying on software to determine that (1) there's another > >> alternative version of the feed that (2) has a different license > >> (requires > >> fetching the feed of course) and (3) perhaps should be offered as an > >> alternative to the user, or used instead of blindly truncating text. > >> > >> My major question is whether a "headline only" feed is an "alternate" > >> representation, or perhaps an "index" to the full feed, or perhaps a new > >> relation (or two) is needed. > >> > >> Thoughts? > >> > >> -- > >> John Panzer > >> System Architect > >> http://abstractioneer.org > >> > > > > > > -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Tue Jun 06 23:53:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnp6x-00083K-07 for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23:53:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnp6u-0008Kc-8V for atompub-archive@lists.ietf.org; Tue, 06 Jun 2006 23:53: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 k573betb066684; Tue, 6 Jun 2006 20:37: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 k573berx066683; Tue, 6 Jun 2006 20:37: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 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 k573bdZd066675 for ; Tue, 6 Jun 2006 20:37:39 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so79594nzd for ; Tue, 06 Jun 2006 20:37: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:content-transfer-encoding:content-disposition:references; b=iOPrfhoeXJAm0bix8d5a2lGRnVRfO1IampoTgxPe3tw1Sj5FgGF55Put2gIXXVmOP2O6GQj8tq0KWfnP0KsrBDmR0eIV/8lDwH+L4dqvZeV/fDLbTbjD8d2lqRQvdw8ZGsWXZxavygy0XCILDrRSG+jsmu8yaWG0JsXJWhs3wkE= Received: by 10.64.114.10 with SMTP id m10mr55782qbc; Tue, 06 Jun 2006 20:37:38 -0700 (PDT) Received: by 10.65.215.14 with HTTP; Tue, 6 Jun 2006 20:37:38 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2006 21:37:38 -0600 From: "M. David Peterson" To: "John Panzer" Subject: Re: Discoverability of feeds with differing licences Cc: atom-syntax , "Bruce D'Arcus" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44862127.8010508@aol.net> <448644AB.4070804@aol.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Didn't finish out that last thought in the fourth paragraph. --- ... future given that the current 2.5 license suggests that a 1.x and 2.x family is already represented, + then this will simply propagate as soon as the RDF data is updated appropriately. --- On 6/6/06, M. David Peterson wrote: > I'm not sure why I didn't realize this before, but as soon as you put > "license" into the rel attribute it clicked for me. > > Okay, then I guess the question is not whether the RDF route shouldn't > be promoted, but rather does the rel="[license]" approach allows for > enough implied information to be extracted to be implemented in a way > that allows for contained information to represent a "tag" that points > to the proper RDF information that in turn points to the proper > resource. > > The code to make something like this work and work well is SUPER easy, > and off the top of my head I can't think of one reason why > rel="cc:by-sa" shouldn't just work and work well by simply keeping a > local RDF data store, or pointing to a community based data store to > pull out the proper URI information that this particular license then > relates to. > > Whats REALLY nice about this approach is the inherent ability to make > a simple change the RDF data and have this propagate across an entire > domain/organization appropriately. So if CC updates to a new version > of the by-sa license, which obviously can and more than likely will > happen at some point in the future given that the current 2.5 license > suggests that a 1.x and 2.x family is already represented. > > Of course there are those who are going to jump in and suggest "Don't > use Qnames in content cuz' of reason a, b, c" do which my response > would be "already have a fix... I've just never published it." > > Maybe now would be a good time to publish that fix? :D > > > On 6/6/06, John Panzer wrote: > > Hi David -- > > > > Not sure whether you're referring to feed licensing in general, or to > > the problem of feeds with differing licenses and their relationships. > > Can you clarify? > > > > In either case, I think that requiring RDF in order to license a piece > > of content would inhibit uptake. I think that's why most of the methods > > described at http://wiki.creativecommons.org/Syndication don't embed RDF > > directly. Of course they are indirectly referencing RDF in the case of > > Creative Commons licenses, so people who have RDF processors can > > certainly apply them constructively. However the license relations are > > not limited to RDF. > > > > In general, on a discussion, design, and implementation level, trying to > > deal with > > > > > > > > is a lot easier to deal with than > > > > > > > > It's also, of course, much shorter, which becomes important when you > > consider the use of per-entry licenses in synthetic feeds. > > > > The same arguments apply to microformats, I think, which is why > > rel-license exists... which might be relevant to GlobalClip. > > > > John > > > > M. David Peterson wrote: > > > > > > > > Hey John, > > > > > > This is obviously an important question that also relates to the > > > GlobalClip/Citation work that I Bruce D'Arcus (Cc'd) and myself are > > > working on to allow the ability to extract all of the relative > > > meta-data, including licensing information, as part of a copy/paste > > > operation [web page > Oo.o, Word, etc...]. > > > > > > Thus far I have been using the documentation on Creative Commons > > > (http://creativecommons.org/technology/metadata/index_html) that > > > covers this area quite extensively. > > > > > > My question: Is there any reason why the RDF method described at the > > > above link should not be the method promoted as the de facto standard? > > > > > > I completely understand your reasoning behind looking to find a > > > solution to correctly propagate and promote a particular method for > > > content producers in whom use multiple licenses dependent upon various > > > factors such as those you've mentioned. While using the rel attribute > > > seems to be an easy route, I'm not so sure that all of the various > > > distinctions can be properly handled by a single attribute. With this > > > in mind, it *seems* that given the existing RDF route promoted by > > > CreativeCommons covers all of the necessary pieces to allow for such > > > things, this would by far be the best route to promote to content > > > producers. > > > > > > Thoughts? > > > > > > On 6/6/06, John Panzer wrote: > > > > > >> > > >> All, > > >> > > >> Some sites offer two versions of feeds; one is a 'headline only' > > >> version > > >> and the other a 'full' version. Other than the content, a significant > > >> distinction in some cases is the license applied to the data in each > > >> feed. > > >> (See http://wiki.creativecommons.org/Syndication.) For > > >> example, the Engadget site offers a headline only feed with (the > > >> equivalent > > >> of a) by-sa Creative Commons license, while its full text is by-nc-sa, > > >> prohibiting copying for commercial use. > > >> > > >> Okay, so far so good. But let's say I'm an ad supported aggregator > > >> (commercial use of content). I cannot therefore display the 'full' > > >> feed and > > >> I'll need to truncate or elide the content. However, I could display > > >> the > > >> 'excerpt' feed with no problems. It would be nice if I could > > >> discover the > > >> related 'headlines' feed (which I can display with full fidelity) if the > > >> user tries to subscribe to the 'full' feed through my ad supported > > >> aggregator. However, right now, there's no automatic way to do that. > > >> > > >> A link@rel seems appropriate; I'm thinking of doing this: > > >> > > >> > >> href="..."/> > > >> > > >> ...and then relying on software to determine that (1) there's another > > >> alternative version of the feed that (2) has a different license > > >> (requires > > >> fetching the feed of course) and (3) perhaps should be offered as an > > >> alternative to the user, or used instead of blindly truncating text. > > >> > > >> My major question is whether a "headline only" feed is an "alternate" > > >> representation, or perhaps an "index" to the full feed, or perhaps a new > > >> relation (or two) is needed. > > >> > > >> Thoughts? > > >> > > >> -- > > >> John Panzer > > >> System Architect > > >> http://abstractioneer.org > > >> > > > > > > > > > > > > > -- > > > M. David Peterson > http://www.xsltblog.com/ > -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Wed Jun 07 03:15:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnsG2-0007Wr-6V for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 03:15:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnsG0-0007H0-Rf for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 03:15: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 k57716vw031073; Wed, 7 Jun 2006 00:01:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k57716PL031072; Wed, 7 Jun 2006 00:01:06 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail1.webfaction.com (IDENT:U2FsdGVkX18FiX3B9les8k0stpUKVWRUiu1PvTx0p30@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57713vh031057 for ; Wed, 7 Jun 2006 00:01:05 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (IDENT:U2FsdGVkX19ivIXOpU7FmH1ZSZEUCQP28u2DVITlEdI@localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k57712Rr006336 for ; Wed, 7 Jun 2006 02:01:02 -0500 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id k57712Xb006334; Wed, 7 Jun 2006 08:01:02 +0100 X-Authentication-Warning: mail1.webfaction.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.webfaction.com with HTTP; Wed, 7 Jun 2006 08:01:02 +0100 (BST) Message-ID: <26231.194.221.74.7.1149663662.squirrel@mail1.webfaction.com> In-Reply-To: References: Date: Wed, 7 Jun 2006 08:01:02 +0100 (BST) Subject: Re: Paging, Feed History, etc. From: "Sylvain Hellegouarch" To: "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: 7aefe408d50e9c7c47615841cb314bed > > Definite +1 > +1 as well. From owner-atom-syntax@mail.imc.org Wed Jun 07 07:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwVd-00066V-1X for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 07:47:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwVb-00087n-Br for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 07:47: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 k57BQgkH003296; Wed, 7 Jun 2006 04:26: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 k57BQgj4003295; Wed, 7 Jun 2006 04:26: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 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 k57BQfpv003273 for ; Wed, 7 Jun 2006 04:26:42 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 04:26:38 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV15.phx.gbl with DAV; Wed, 07 Jun 2006 11:26:35 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: Subject: Re: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 12:26:34 +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: 07 Jun 2006 11:26:38.0410 (UTC) FILETIME=[3DEE7AA0:01C68A25] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I'm going to reserve judgement until I see what exactly it is you're proposing, but I'm not particularly keen to change our existing implementation. Our of curiosity, do you know of *any* client applications that actually support feed paging? Or have expressed an intention to support feed paging? By client application I mean something a user can download and install on their system and use as a feed reader. Last time I checked I couldn't find any on Windows. Is there better support on Linux and Macs? Regards James From owner-atom-syntax@mail.imc.org Wed Jun 07 09:16:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnxu3-0001mM-8f for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 09:16:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnxu1-0008Vf-MJ for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 09:16: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 k57D28n0028768; Wed, 7 Jun 2006 06:02: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 k57D28au028767; Wed, 7 Jun 2006 06:02: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.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57D27g0028748 for ; Wed, 7 Jun 2006 06:02:07 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so156757nzd for ; Wed, 07 Jun 2006 06:02: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:content-transfer-encoding:content-disposition:references; b=qHoKblblggWzz/8r1l6VPw6decNTl9KxE8/rvJJ7f8bostQMmJB+lxUMII/VU0dZ5T3B01r7+DzvYrsQr4xlTu6xWPdJmPaON8xwjRNm9EJ78jlr5YkhU3ortXUINfzrCEJWmT3xwpP5MQvXcEht9fBBbN0EIuoCx/25N7U2V/Q= Received: by 10.64.210.4 with SMTP id i4mr331675qbg; Wed, 07 Jun 2006 06:02:06 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Wed, 7 Jun 2006 06:02:06 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 15:02:06 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Paging, Feed History, etc. 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 k57D27g0028759 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 k57D28n0028768 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e [sorry, autocompletion got it to atom-protocol] 2006/6/7, Mark Nottingham : > > I've been talking to a number of people face-to-face about Feed > History and the use cases for it, and I've come to a position where I > believe there are two major use cases out there for putting together > multiple feeds to form one big, virtual feed. > > 1) So-called "incremental" feeds, where changes are happening at the > "front end" of the feed, while less recent entries are pretty much > static. If a change is required in an old entry, either a new revised > entry with the same ID, or something like a tombstone is required. > Publishers can easily make stable archives of old entries available, > and clients wish to take advantage of caching, etc. to avoid re- > transferring old entries again and again. A high degree of fidelity > may be required; e.g., it should be possible to accurately > reconstruct the entire state of the feed with no missed entries. > E.g., a blog feed, but this could also be seen as an "event feed", > where the entries are changes to the state of the underlying resources. > > 2) So-called "paging" feeds, where the entries are often the results > to a query, being paged through in groups so as to not overwhelm the > server and/or communications link. Entries may be arbitrarily added, > deleted and reordered. Clients expect to access what the portions > they need in relatively quick succession, and do not require absolute > fidelity. E.g., OpenSearch query results. The entries in the feed > directly correspond to the underlying resources, 1-to-1. > > These are very different things. Incremental feeds require that the > server keep state around per-feed, which isn't viable for something > like query results, but fine for a blog. Paging feeds can lose > entries (e.g., if http://example.org/index.page?page=3D1 refers to > http://example.org/index.atom?page=3D2, page 2's contents can change > between the two fetches), which is OK for some applications, and not > for others. > > As such, I'm pretty much convinced that they need to be dealt with > separately. I'm not sure they're as different as you're saying=E2=80=A6 From the client point of view, isn't an incremental feed just the same as a paging feed, except that you're assured you won't loose entries (well, that's not really true actually: "live feed document" can change while you're following next/previous links, and could even result in a new "archived feed document"). If applications need paging around snapshots to avoid loosing entries, then they (servers) can create a snapshot of a query result set that the client will page through (with some TTL before the snapshot is deleted). Actually, what changes is how clients deal with them, but those different feeds probably won't be consume by the same clients: an incremental feed is designed to be subscribed by a "feed reader" while others are for more specific uses (search results, shared lists with or without ranking info, etc.) I'm not saying you won't use the same client application to process those feeds, but the client is assumed to behave differently depending whether it's dealing with an incremental feed or another paging feed (i.e. a snapshot feed split into small "pages"). That behaviour is not dependent upon the relations between the "chunks" but in how to deal with the feed: if it's an incremental feed, I'll use a "feed state reconstruction algorithm" to avoid downloading entries that have not changed, and will probably also keep local copies of those entries; if it's a "paged snapshot feed", the set of entries in the all the "chunks" replaces the previous set, and some "algorithm" (preconditions and/or IM) can still be used to try to avoid downloading chunks that have not changed. The only difference that *might* exist in dealing with the relations is that, for an incremental feed, as soon as a requests returns a 304 (Not Modified), you can stop "paging", whereas for paged snapshot feeds the next chunk might have changed=E2=80=A6 But the real relationship between these pages/chunks/etc. is the same: one comes after/before the other. A "dumb" client could download the whole set of pages/chunks/etc. each time, again and again, and will still have the same set of entries. The "feed state reconstruction algorithm" is some kind of optimization to help not wasting bandwidth: it doesn't change the way you follow links, just the way you optimize retrievals. So a "flag" in the feed telling which kind of optimization you can use without loosing information is enough; something like the fh:incremental element in version -04 of your draft. > Originally, I proposed that Feed History use "prev-archive" link > relations, but many people pushed back on that in favour of the more > generic "previous" and "next". I think I originally pushed the other way around [1], but for different reasons. If it's clear that previous/next deals with "pages" or "chunks" of the same feed, then I'm OK with them, and other use cases will need new rel values. [1] http://www.imc.org/atom-syntax/mail-archive/msg17372.html > Given the above, I'd like to see if anyone would still object to > having separate relation sets for incremental feeds ("prev-archive" > and friends) and paging feeds ("previous", "next" and friends). Given the above, yes. Consider it a "-0" though, not a "-1", as I might need some more thinking (or people trying to convince me). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Jun 07 11:00:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzVt-0005ie-FC for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 11:00:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzVs-0005y9-3J for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 11:00: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 k57Ejqac058835; Wed, 7 Jun 2006 07:45: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 k57Ejq4h058834; Wed, 7 Jun 2006 07:45: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 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 k57Ejpxx058828 for ; Wed, 7 Jun 2006 07:45:52 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so178404nzd for ; Wed, 07 Jun 2006 07:45: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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WDR+mwujUG6b7gCdxDNVRA8EIgbMegrUpnMrAoyS2n66f/H0rKs0oI2CRBGCknGZ6QeScJcUp/vxDDkorYYxGvEMmsquImCneXVoRt7XY6mJzGsxmHJwZ37jsTQUQSh+iv10PrcUZj9o05eP9saVgpPNjoFclrWV/1DA3D9DzRI= Received: by 10.65.224.1 with SMTP id b1mr486845qbr; Wed, 07 Jun 2006 07:45:51 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 1sm308941qbh.2006.06.07.07.45.50; Wed, 07 Jun 2006 07:45:51 -0700 (PDT) Message-ID: <4486E69A.6050108@gmail.com> Date: Wed, 07 Jun 2006 07:45:46 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: James Holderness CC: Atom Syntax Subject: Re: Paging, Feed History, etc. 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: 9182cfff02fae4f1b6e9349e01d62f32 We have a client that is specific to our Open Activities platform that uses feed paging. It's not a general feed reader, tho. I believe our general feed reader component will support paging (maybe does, haven't checked on it in a while). - James James Holderness wrote: > > I'm going to reserve judgement until I see what exactly it is you're > proposing, but I'm not particularly keen to change our existing > implementation. > > Our of curiosity, do you know of *any* client applications that actually > support feed paging? Or have expressed an intention to support feed > paging? By client application I mean something a user can download and > install on their system and use as a feed reader. Last time I checked I > couldn't find any on Windows. Is there better support on Linux and Macs? > > Regards > James > > From owner-atom-syntax@mail.imc.org Wed Jun 07 11:36:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo05L-0001lz-Ti for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 11:36:43 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo05J-0007rH-HG for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 11:36: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 k57FBk9e066992; Wed, 7 Jun 2006 08:11:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k57FBk0d066991; Wed, 7 Jun 2006 08:11:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57FBjSq066962 for ; Wed, 7 Jun 2006 08:11:45 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [192.168.1.5] (adsl-71-131-32-180.dsl.sntc01.pacbell.net [71.131.32.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 0AFD9A3293; Wed, 7 Jun 2006 11:11:43 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Cc: "Atom Syntax" Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 08:11:49 -0700 To: James Holderness 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On 2006/06/07, at 4:26 AM, James Holderness wrote: > I'm going to reserve judgement until I see what exactly it is > you're proposing, but I'm not particularly keen to change our > existing implementation. Understood. I've been reluctant to change the spec for just that reason, but the split has become pretty apparent. > Our of curiosity, do you know of *any* client applications that > actually support feed paging? Or have expressed an intention to > support feed paging? By client application I mean something a user > can download and install on their system and use as a feed reader. > Last time I checked I couldn't find any on Windows. Is there better > support on Linux and Macs? I think most of the use cases for paging have to do with things like GData, OpenSearch, etc -- i.e., query results. That sort of thing isn't targetted at desktop aggregators AFAICT; it seems to be more for machine->machine communication, or for browsing a result set. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 07 12:20:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0m0-0002RB-GM for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 12:20:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0lx-0005Ay-Rk for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 12:20: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 k57G3R2L084600; Wed, 7 Jun 2006 09:03: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 k57G3RQD084599; Wed, 7 Jun 2006 09:03: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 hotmail.com (bay109-dav5.bay109.hotmail.com [64.4.19.77]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57G3QTn084583 for ; Wed, 7 Jun 2006 09:03:27 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 09:03:26 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV5.phx.gbl with DAV; Wed, 07 Jun 2006 16:03:26 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Subject: Re: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 17:03:26 +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: 07 Jun 2006 16:03:26.0565 (UTC) FILETIME=[E929D150:01C68A4B] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Mark Nottingham wrote: >> Our of curiosity, do you know of *any* client applications that actually >> support feed paging? > > I think most of the use cases for paging have to do with things like > GData, OpenSearch, etc -- i.e., query results. That sort of thing isn't > targetted at desktop aggregators AFAICT; it seems to be more for > machine->machine communication, or for browsing a result set. Actually when I said "feed paging" I meant that as a general term, i.e. feed history too. As for machine->machine communication, if these feeds aren't meant for desktop aggregators then does it really matter that they function differently? You can describe one algorithm for use in machine->machine communication and another for use by desktop aggregators downloading "regular" feeds. Both can use the same link relations because they should never come into contact with each other. Having said that I still don't see how a machine->machine algorithm for retrieving a paged feed can be different from your current feed history algorithm and still be useful. Lets say I was a search engine returning paged results. A search is performed that returns 200 results. I return 20 pages, 10 results per page. First time around a client supporting the feed history algorithm would retrieve all 20 pages no problem. So far I see no difference between how a desktop aggregator would behave and how machine->machine communication would function. The second time the client connects (assuming there is a second time) it sends through an etag and/or last-modified date so the search engine knows which results it already has. Say there are 3 new results since the previous retrieval. Either the search engine is smart enough to just return those 3 results or it's going to ignore the etag and return everything - 21 pages, 10 results per page, new items could be anywhere. As a desktop aggregator I guarantee you I'm not going to want to download 20+ pages every hour just to find the 3 new items that *might* be there. Fortunately the feed history algorithm would stop me after the first page, and I'm thankful for that. Would a machine->machine communication be any different? Would they really want to download every single one of those 203 results just to find the 3 new items? If that's what they really want to do, then they can always ignore the "stop when you encounter a link you've already retrieved" part of the feed history algorithm. We don't need a special link relationship for that. If anything, I would think Thomas' suggestion of some kind of flag should be enough. I just can't see anyone wanting to do something like that, though, desktop aggregator or machine->machine communication. Regards James From owner-atom-syntax@mail.imc.org Wed Jun 07 13:30:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1rg-0002lf-11 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:30:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1rc-0005r1-L7 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:30: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 k57HG2U1010197; Wed, 7 Jun 2006 10:16: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 k57HG2cm010193; Wed, 7 Jun 2006 10:16: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 mail1.webfaction.com (IDENT:U2FsdGVkX1992JttYG85oG5PXInvbyVdEEge8OpN7kM@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57HG112010130 for ; Wed, 7 Jun 2006 10:16:01 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-111-157.range81-159.btcentralplus.com [81.159.111.157]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k57HFtdg026546; Wed, 7 Jun 2006 12:15:56 -0500 Message-ID: <448709C2.5030100@defuze.org> Date: Wed, 07 Jun 2006 18:15:46 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Mark Nottingham CC: James Holderness , Atom Syntax Subject: Re: Paging, Feed History, etc. References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> In-Reply-To: <4C24B905-57CE-46DF-B120-48A890A7F6C2@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: 1ac7cc0a4cd376402b85bc1961a86ac2 > > I think most of the use cases for paging have to do with things like > GData, OpenSearch, etc -- i.e., query results. That sort of thing > isn't targetted at desktop aggregators AFAICT; it seems to be more for > machine->machine communication, or for browsing a result set. Which sets the question of what is the target of the specification and Atom in general. We mainly center the discussion around aggregators but I hope you all agree that Atom aims at much more than simple news feed, right? - Sylvain From owner-atom-syntax@mail.imc.org Wed Jun 07 13:51:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2C0-0002WX-0n for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:51:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2By-0001bm-Kp for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:51: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 k57HP5pj013786; Wed, 7 Jun 2006 10:25: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 k57HP5C5013785; Wed, 7 Jun 2006 10:25: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57HP4RO013745 for ; Wed, 7 Jun 2006 10:25:04 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.20] (sera-10-169-186-20.nscp.aoltw.net [10.169.186.20]) by mcom.com (8.10.0/8.10.0) with ESMTP id k57HOwG06892 for ; Wed, 7 Jun 2006 10:24:59 -0700 (PDT) Message-ID: <44870BEA.1020205@aol.net> Date: Wed, 07 Jun 2006 10:24:58 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Paging, Feed History, etc. References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.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.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb James Holderness wrote: > > Mark Nottingham wrote: > >>> Our of curiosity, do you know of *any* client applications that >>> actually support feed paging? >> >> >> I think most of the use cases for paging have to do with things like >> GData, OpenSearch, etc -- i.e., query results. That sort of thing >> isn't targetted at desktop aggregators AFAICT; it seems to be more >> for machine->machine communication, or for browsing a result set. > > > Actually when I said "feed paging" I meant that as a general term, > i.e. feed history too. > > As for machine->machine communication, if these feeds aren't meant for > desktop aggregators then does it really matter that they function > differently? You can describe one algorithm for use in > machine->machine communication and another for use by desktop > aggregators downloading "regular" feeds. Both can use the same link > relations because they should never come into contact with each other. > Having said that I still don't see how a machine->machine algorithm > for retrieving a paged feed can be different from your current feed > history algorithm and still be useful. Our current "previous" links aren't permalinks; they're more like OpenSearch indexes: http://example.org/feed.xml?start=50&len=10. So clients can't usefully cache them the way they could, say, http://example.org/feed.xml?month=may2006. We may well want to offer both types of links, even in the same feed, to support different traversals of the underlying resource(s). One issue we have today is that we're compatible with neither OpenSearch nor feed-history :(. -John From owner-atom-syntax@mail.imc.org Wed Jun 07 13:59:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2JU-0003Kj-Gd for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:59:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2JT-0002TY-3j for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 13:59: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 k57HTO7m015191; Wed, 7 Jun 2006 10:29: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 k57HTOxt015190; Wed, 7 Jun 2006 10:29: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 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 k57HTN54015179 for ; Wed, 7 Jun 2006 10:29:24 -0700 (MST) (envelope-from robyates70@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so201117wra for ; Wed, 07 Jun 2006 10:29:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=eJ1JNTeCpiVTPWof/yLsyqusRqpq5ujSYd5HixFUZkXZCSSffcFH56BpdGnzX/cKy+gbn60MmoFtVgJXNIjCEFqP4fimuv52H/Y9JcKTYMoB4DlmbVUn59HSIPGMY06OxrUIWcped+/FncCfzsVbsgE7HDD1A4/kGp/eX2MUzds= Received: by 10.54.124.15 with SMTP id w15mr1002241wrc; Wed, 07 Jun 2006 10:29:23 -0700 (PDT) Received: from ?9.33.34.88? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 64sm928695wra.2006.06.07.10.29.22; Wed, 07 Jun 2006 10:29:23 -0700 (PDT) Message-ID: <44870CF4.80509@gmail.com> Date: Wed, 07 Jun 2006 13:29:24 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: when should two entries have the same id? 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.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This relates to work that we are doing with the publishing protocol, but is syntax related. In an implementation of APP a single entry can appear both in the APP collection and in any number of arbitrary feeds that the site subsequently offers. These feeds / collections can be optimized differently depending on the client. For example, an entry in the collection feed may have its content "out of lined" whereas the "same" entry rendered in a feed may have its content inlined. There are other different optimizations that we are investigating, that cause the entry representation in various feeds / collections to be different, even though it has originated from the same source. So are these representations in the different feeds / collections the same entry or different entries? Should they have the same id? and if a feedreader comes across two entries with the same atom id, what, if anything, can it infer from that? is it only that they came from the same source? Many Thanks, Rob From owner-atom-syntax@mail.imc.org Wed Jun 07 14:04:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2OO-0004ES-F9 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:04:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2OM-00031y-0d for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:04: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 k57HXTqX016686; Wed, 7 Jun 2006 10:33: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 k57HXTAl016685; Wed, 7 Jun 2006 10:33:29 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57HXS21016678 for ; Wed, 7 Jun 2006 10:33:28 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (snv-global1.corp.yahoo.com [216.145.49.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 98E4DA3297; Wed, 7 Jun 2006 13:33:27 -0400 (EDT) In-Reply-To: References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 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: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 10:33:34 -0700 To: James Holderness 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: 25620135586de10c627e3628c432b04a On 2006/06/07, at 9:03 AM, James Holderness wrote: > > As for machine->machine communication, if these feeds aren't meant > for desktop aggregators then does it really matter that they > function differently? You can describe one algorithm for use in > machine->machine communication and another for use by desktop > aggregators downloading "regular" feeds. Both can use the same link > relations because they should never come into contact with each > other. Having said that I still don't see how a machine->machine > algorithm for retrieving a paged feed can be different from your > current feed history algorithm and still be useful. I don't see a clean split between machine-to-machine vs. desktop aggregator cases; for example, an incremental-style feed can be useful both on the desktop (to make sure I see all of your blog entries) as well as with processes (to make sure that my program doesn't miss a critical event if it has some downtime or loss of connectivity). Similarly, some of the cases I've heard for paging-style feeds are with desktop clients (e.g., "get me the next results, please") and some are with processes (e.g., processing search results automatically). The difference has more to do with a) what guarantees the server wants to provide, and b) what resources they're willing to devote towards meeting those guarantees. > Lets say I was a search engine returning paged results. A search is > performed that returns 200 results. I return 20 pages, 10 results > per page. First time around a client supporting the feed history > algorithm would retrieve all 20 pages no problem. So far I see no > difference between how a desktop aggregator would behave and how > machine->machine communication would function. > > The second time the client connects (assuming there is a second > time) it sends through an etag and/or last-modified date so the > search engine knows which results it already has. Say there are 3 > new results since the previous retrieval. Either the search engine > is smart enough to just return those 3 results or it's going to > ignore the etag and return everything - 21 pages, 10 results per > page, new items could be anywhere. > > As a desktop aggregator I guarantee you I'm not going to want to > download 20+ pages every hour just to find the 3 new items that > *might* be there. Fortunately the feed history algorithm would stop > me after the first page, and I'm thankful for that. Would a machine- > >machine communication be any different? Would they really want to > download every single one of those 203 results just to find the 3 > new items? These are pretty much the assumptions that I was making previously. The degree of precision that FH currently provides isn't desirable for search results. Feed History also requires that the server maintain state about a particular feed, which is unworkable for search results; e.g., to implement feed history for search results, a server would have to mint a whole new set of feed documents for every query, and keep them around. That's not workable for most search engines (Yahoo, Google, Amazon, whatever), so they need another option -- one that needs to be clearly distinct from FH. This brings me to my other motivation -- I found that most people who use "previous" and "next" don't understand the assumptions that FH makes about archive stability, and point them at URIs like "http:// example.org/feed.atom?page=3". That will break the FH algorithm badly, reducing the value of the mechanism as a whole, because people will stop trusting it. The link relation for implementing the incremental approach needs to have the stability semantics baked in and explicit. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 07 14:19:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2d6-0005C5-1Z for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:19:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2d4-000489-JP for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:19: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 k57Hs37r023563; Wed, 7 Jun 2006 10:54: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 k57Hs3gH023562; Wed, 7 Jun 2006 10:54: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 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 k57Hs1Da023556 for ; Wed, 7 Jun 2006 10:54:02 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so218252nzd for ; Wed, 07 Jun 2006 10:54:01 -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=f5gHTBkwawBTzdE3vHjnSSPI4dTQzy3uc6/PuBEksaBPqQfDChBFbkw7DIsEAGunH69CsXEgH6opP7BZBYC8f3sn8M1oFQj5KPNofCPIShrf6mjRww3l+Icm1fFCWvPLkDdFEYFbwR6WJqYhSZRKj79MGYhu2ozt8dGkKFmTEwE= Received: by 10.64.196.8 with SMTP id t8mr733260qbf; Wed, 07 Jun 2006 10:54:00 -0700 (PDT) Received: by 10.65.215.14 with HTTP; Wed, 7 Jun 2006 10:54:00 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 11:54:00 -0600 From: "M. David Peterson" To: sh@defuze.org Subject: Re: Paging, Feed History, etc. Cc: "Mark Nottingham" , "James Holderness" , "Atom Syntax" In-Reply-To: <448709C2.5030100@defuze.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> <448709C2.5030100@defuze.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 You can use Atom for news feeds too?! Wow! So many uses, so little time (please know I am being sarcastic... Just agreeing with Sylvain's point in my own "personalized style" sort of way ;) On 6/7/06, Sylvain Hellegouarch wrote: > > > > > > I think most of the use cases for paging have to do with things like > > GData, OpenSearch, etc -- i.e., query results. That sort of thing > > isn't targetted at desktop aggregators AFAICT; it seems to be more for > > machine->machine communication, or for browsing a result set. > Which sets the question of what is the target of the specification and > Atom in general. We mainly center the discussion around aggregators but > I hope you all agree that Atom aims at much more than simple news feed, > right? > > - Sylvain > > -- M. David Peterson http://www.xsltblog.com/ From owner-atom-syntax@mail.imc.org Wed Jun 07 14:28:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2ll-0002OQ-Mo for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:28:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2lk-0004MB-0Y for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:28: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 k57Hvbn9024711; Wed, 7 Jun 2006 10:57: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 k57Hvbt9024710; Wed, 7 Jun 2006 10:57: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57HvaHH024702 for ; Wed, 7 Jun 2006 10:57:36 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 81516 invoked by uid 17064); 7 Jun 2006 17:57:35 -0000 Received: from unknown (HELO [10.20.30.152]) ([195.101.242.1]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Jun 2006 17:57:35 -0000 In-Reply-To: <44870CF4.80509@gmail.com> References: <44870CF4.80509@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: when should two entries have the same id? Date: Wed, 7 Jun 2006 19:57:35 +0200 To: Robert Yates 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f You can have two entries or feeds with the same id, as long as they have different updated time stamps. It's very much the same as you being Robert Yates all your life, but having different sizes throughout your life. At any point in time you have all the same properties... Henry On 7 Jun 2006, at 19:29, Robert Yates wrote: > > This relates to work that we are doing with the publishing > protocol, but is syntax related. > > In an implementation of APP a single entry can appear both in the > APP collection and in any number of arbitrary feeds that the site > subsequently offers. > > These feeds / collections can be optimized differently depending on > the client. For example, an entry in the collection feed may have > its content "out of lined" whereas the "same" entry rendered in a > feed may have its content inlined. There are other different > optimizations that we are investigating, that cause the entry > representation in various feeds / collections to be different, even > though it has originated from the same source. > > So are these representations in the different feeds / collections > the same entry or different entries? Should they have the same id? > and if a feedreader comes across two entries with the same atom id, > what, if anything, can it infer from that? is it only that they > came from the same source? > > Many Thanks, > > Rob From owner-atom-syntax@mail.imc.org Wed Jun 07 14:35:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2rt-0003eg-1a for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:35:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2rr-0006FN-Mc for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:35: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 k57I86BI027933; Wed, 7 Jun 2006 11: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 k57I86jA027931; Wed, 7 Jun 2006 11: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 mail1.webfaction.com (IDENT:U2FsdGVkX1++IGnHfWa1Wan+ykwJx0QYq0Y20bDMT6o@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57I851Q027915 for ; Wed, 7 Jun 2006 11:08:05 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-111-157.range81-159.btcentralplus.com [81.159.111.157]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k57I7xfH028120; Wed, 7 Jun 2006 13:08:00 -0500 Message-ID: <448715F6.9090101@defuze.org> Date: Wed, 07 Jun 2006 19:07:50 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Henry Story CC: Robert Yates , atom-syntax@imc.org Subject: Re: when should two entries have the same id? References: <44870CF4.80509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > > You can have two entries or feeds with the same id, as long as they > have different updated time stamps. > It's very much the same as you being Robert Yates all your life, but > having different sizes throughout your life. At any point in time you > have all the same properties... /me wonders how long before a wiki engine based on Atom :) From owner-atom-syntax@mail.imc.org Wed Jun 07 14:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2vv-00082w-O4 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:39:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2vu-00075V-6z for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:39: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 k57IGeCX030696; Wed, 7 Jun 2006 11:16: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 k57IGeeP030694; Wed, 7 Jun 2006 11:16: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 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 k57IGdNt030663 for ; Wed, 7 Jun 2006 11:16:40 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 11:16:36 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV11.phx.gbl with DAV; Wed, 07 Jun 2006 18:16:32 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Subject: Re: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 19:16:32 +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: 07 Jun 2006 18:16:36.0554 (UTC) FILETIME=[839162A0:01C68A5E] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Mark Nottingham wrote: > These are pretty much the assumptions that I was making previously. The > degree of precision that FH currently provides isn't desirable for search > results. Feed History also requires that the server maintain state about > a particular feed, which is unworkable for search results; e.g., to > implement feed history for search results, a server would have to mint a > whole new set of feed documents for every query, and keep them around. Not necessarily. They only need to be able to sort results on a most-recently-discovered date. When a client connects to them with an etag representing date X, they return only those results have been discovered since date X. I can believe that there are search engines for which even that isn't feasible, but then FH as we know is not possible, and those feeds are essentially useless from a subscription point of view. They can still use the paging links so you can connect to a search engine for a once-off paged set of results. They just need to return 304 on any subsequent requests (i.e. anything with an etag) in case someone makes the mistake of subscribing to one of those feeds. If you have something else in mind for that kind of server I'm curious to know what it is. In other words can you envision a server that wants to do paging, doesn't have enough state information to be able to do FH, but still would like to allow subscriptions? How would it work? > This brings me to my other motivation -- I found that most people who use > "previous" and "next" don't understand the assumptions that FH makes > about archive stability, and point them at URIs like "http:// > example.org/feed.atom?page=3". I don't see how changing the name of the link is going to magically fix that. If people aren't understanding the significance of archive stability, then perhaps it needs to be highlighted more prominently in the FH spec. > That will break the FH algorithm badly I don't think it's that bad. It loses some of its functionality, but it's no worse than having no paging at all. And you still have the ability to retrieve the full history on first download. John Panzer wrote: > Our current "previous" links aren't permalinks; they're more like > OpenSearch indexes: http://example.org/feed.xml?start=50&len=10. So > clients can't usefully cache them the way they could, say, > http://example.org/feed.xml?month=may2006. I understand that, but do you realise that those links are essentially useless for anything other than the first retrieval? As a client there's nothing I can do with them after the first download. I don't have a problem with that if that's all you can do, though. It's still better than no paging at all. And it still works (within the boundaries of what is feasible) using the FH algorithm as it currently stands. I don't see what else you can write into the spec that would make your feed work any better than it currently does. Regards James From owner-atom-syntax@mail.imc.org Wed Jun 07 14:46:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo32z-0005LH-FC for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:46:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo32u-0007RJ-VI for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:46: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 k57IUfSa035218; Wed, 7 Jun 2006 11:30: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 k57IUfw4035217; Wed, 7 Jun 2006 11:30: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.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k57IUdva035158 for ; Wed, 7 Jun 2006 11:30:39 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Jun 2006 18:30:31 -0000 Received: from xdsl-213-196-254-12.netcologne.de (EHLO klangraum) [213.196.254.12] by mail.gmx.net (mp028) with SMTP; 07 Jun 2006 20:30:31 +0200 X-Authenticated: #163624 Date: Wed, 7 Jun 2006 20:30:30 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: when should two entries have the same id? Message-ID: <20060607183030.GK6092@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <44870CF4.80509@gmail.com> <448715F6.9090101@defuze.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <448715F6.9090101@defuze.org> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de * Sylvain Hellegouarch [2006-06-07 20:20]: > /me wonders how long before a wiki engine based on Atom :) You mean ? :) Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Jun 07 14:55:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3Bq-000116-SD for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:55:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3Bo-0008Kd-EH for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 14:55: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 k57IUw94035328; Wed, 7 Jun 2006 11:30: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 k57IUwAM035327; Wed, 7 Jun 2006 11:30: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.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57IUvcr035321 for ; Wed, 7 Jun 2006 11:30:57 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so226889nzd for ; Wed, 07 Jun 2006 11:30:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rE3Y5tgWNQHJSiz4pV7IAVYeJySNorsH5Eaw0HtBrc044sWY4MVMYhxAe09iwlblFvWjHFFWAFc/n6X5QL1V5nztHrjGjgQze3nDTWHr7wt78/ImB42Sr+4TM6HCGHvNHQkao0XjfS7qBTTkDpf1dzmPHbKFmXCuBRa1SYCFDEo= Received: by 10.64.151.5 with SMTP id y5mr851283qbd; Wed, 07 Jun 2006 11:30:56 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Wed, 7 Jun 2006 11:30:56 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 20:30:56 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Paging, Feed History, etc. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 2006/6/7, Mark Nottingham : > > The degree of precision that FH currently provides isn't desirable > for search results. Feed History also requires that the server > maintain state about a particular feed, which is unworkable for > search results; e.g., to implement feed history for search results, a > server would have to mint a whole new set of feed documents for every > query, and keep them around. That's not workable for most search > engines (Yahoo, Google, Amazon, whatever), so they need another > option -- one that needs to be clearly distinct from FH. > > This brings me to my other motivation -- I found that most people who > use "previous" and "next" don't understand the assumptions that FH > makes about archive stability, and point them at URIs like "http:// > example.org/feed.atom?page=3". That will break the FH algorithm > badly, reducing the value of the mechanism as a whole, because people > will stop trusting it. The link relation for implementing the > incremental approach needs to have the stability semantics baked in > and explicit. As I previously said, the current FH algorithm isn't workable for all the use cases (notably with paged non-incremental feeds, those feeds being snapshots or "live feeds") but that doesn't mean there's a need for other rel values. I think FH could: - (more explicitly) RECOMMEND using stable "chunks" so that caching can be used (maybe using an "overview" section similar to the APP's section 5) - provide algorithms as an "how-to optimize bandwith et al. and not retrieve the whole set of pages/chunks", not as a "you should/must do that to comply to this spec" - provide different algorithms for incremental and non-incremental feeds, non-incremental feeds retrieval having to go through all the pages/chunks and not stop as soon as there's no more change (but the whole algorithm remains almost the same) - RECOMMEND using RFC3229 w/ feeds (problem: this is not an I-D), particularly for non-incremental feeds (Atom does not define order for the entries in the feed, order has to be told by extensions, e.g. Feed Rank, so there's no problem retrieving only a subset of the whole feed, even if new/updated entries would be sparsed in the feed if retrieved without RFC3229 w/ feeds), and NOT RECOMMEND (or even a "MUST NOT") using paging for RFC3229 responses: either you return the whole set of changes, or you choose to ignore the "IM" request and return the feed as if the client didn't use RFC3229) - use 304 (Not Modified) instead of IRI-comparison, enlightening the fact that web servers like Apache provide such response out-of-the-bow when delivering files (this should incite people to using stable chunks/pages by saving them to files, instead of making use of CGI applications with database requests). The fact that many implementations currently return feeds (whether or not they're using paging/history) without processing preconditions (If-Modified-Since or If-Not-Match) shouldn't influence the FH design, many of these implementations are deployments of CMSes like WordPress, and those can be fixed. Maybe the Feed Validator can have an option to test this: it would retrieve the feed twice (at least), using If-Modified-Since and/or If-Not-Match for the second request, and showing a warning if the feed hasn't changed and the second GET didn't result in a 304 (Not Modified). Please note that I haven't went back read the FH draft since weeks, so some of my comments might not be accurate (I've a pretty good memory but data-losses might still happen ;-) ) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Jun 07 15:04:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3KF-0006e8-Qb for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15:04:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3KE-0000WL-CU for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15:04: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 k57IfRst038771; Wed, 7 Jun 2006 11:41: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 k57IfRLC038770; Wed, 7 Jun 2006 11:41: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.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57IfQ9b038761 for ; Wed, 7 Jun 2006 11:41:26 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so215053wra for ; Wed, 07 Jun 2006 11:41: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:subject:references:in-reply-to:content-type:content-transfer-encoding; b=JALiF9SpOpH0OEwlJ0waqj36xN/mRS7z300A2UJMZhcUON3nKx0Um3OuIizkZvKLFgND/tELjBB7vNWHFuHqSg22Emrb+YaVdUDM7FCFWPZL9H8H/Mb8q4K/b6eIJhU1xgqVrb2Wa4ESYTgBbl8sQ0sa8bvVAH5VLCBhaXgkL3U= Received: by 10.54.116.7 with SMTP id o7mr850479wrc; Wed, 07 Jun 2006 11:40:14 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 6sm1820799wrl.2006.06.07.11.41.22; Wed, 07 Jun 2006 11:41:23 -0700 (PDT) Message-ID: <44871DBB.5050503@gmail.com> Date: Wed, 07 Jun 2006 11:40:59 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: when should two entries have the same id? References: <44870CF4.80509@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: f60d0f7806b0c40781eee6b9cd0b2135 Henry Story wrote: > > You can have two entries or feeds with the same id, as long as they have > different updated time stamps. That's not quite accurate. Two entries with the same atom:id may appear within the same atom:feed only if they have different atom:updated elements. The spec is silent on whether or not two entries existing in *separate documents* may have identical atom:id and atom:updated values. Consider the case where my personal weblog publishes two Atom feeds. One is a "full-content" feed that publishes content as XHTML. The second is a "partial-content" feed that strips the markup and publishes content as plain text in the atom:summary while containing an atom:content with a src attribute to the original XHTML. They exist in two separate Atom documents and both are based on the same underlying blog post. The atom:id and atom:updated values for each entry are identical. Another example. I post an iCal file to an APP collection. In the collection feed, I see a "media link entry" that uses content/@src to point to the iCal. However, another feed that is used to provide a summary of upcoming events has entries whose content element contains an XHTML rendering of the iCal files. Each entry in the summary feed corresponds to exactly one entry in the APP collection; should they or should they not use the same atom:id and atom:updated values? - James > It's very much the same as you being Robert Yates all your life, but > having different sizes throughout your life. At any point in time you > have all the same properties... > > Henry > > On 7 Jun 2006, at 19:29, Robert Yates wrote: > >> >> This relates to work that we are doing with the publishing protocol, >> but is syntax related. >> >> In an implementation of APP a single entry can appear both in the APP >> collection and in any number of arbitrary feeds that the site >> subsequently offers. >> >> These feeds / collections can be optimized differently depending on >> the client. For example, an entry in the collection feed may have its >> content "out of lined" whereas the "same" entry rendered in a feed may >> have its content inlined. There are other different optimizations >> that we are investigating, that cause the entry representation in >> various feeds / collections to be different, even though it has >> originated from the same source. >> >> So are these representations in the different feeds / collections the >> same entry or different entries? Should they have the same id? and if >> a feedreader comes across two entries with the same atom id, what, if >> anything, can it infer from that? is it only that they came from the >> same source? >> >> Many Thanks, >> >> Rob > > From owner-atom-syntax@mail.imc.org Wed Jun 07 15:09:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3PR-0001DI-Lo for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15:09:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3PQ-0000w4-9d for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15: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 k57ImXtb041520; Wed, 7 Jun 2006 11: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 k57ImXx4041519; Wed, 7 Jun 2006 11: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 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 k57ImUD7041494 for ; Wed, 7 Jun 2006 11:48:32 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so231078nzd for ; Wed, 07 Jun 2006 11:48:29 -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=IzNC4YNGpMuHdCHT65eJEWlYZe3NkNhG8b5dIua5qkU0K95QpblgbIX9fIKAkrYSPKdsacawWrxqZ1t99PFbLoFDGSj4WSxNGM/hv7LdWEPiYNYM/ZSORZUFXilwBv2Q2rFHow65DnJ1GB2cdB+xBt4wJ6YaYqKgIq/8p6ZQWZQ= Received: by 10.65.234.10 with SMTP id l10mr870630qbr; Wed, 07 Jun 2006 11:48:29 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Wed, 7 Jun 2006 11:48:29 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 20:48:29 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: when should two entries have the same id? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <44870CF4.80509@gmail.com> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k57ImWD7041505 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 k57ImXtb041520 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 2006/6/7, Henry Story : > > You can have two entries or feeds with the same id, as long as they > have different updated time stamps. > It's very much the same as you being Robert Yates all your life, but > having different sizes throughout your life. At any point in time you > have all the same properties... Er, you can have two entries or feeds with the same if *and* updated time stamps, as long as =E2=80=93for entries=E2=80=93 they do not appear = in the same Atom Feed Document (and even this constraint might be removed in a later revision of the spec, if I recall some past discussions on this list correctly). What one need to remember is that atom:id is an identifier for the resource throughout its life, and that this is needed because entries might not always be atomically retrieved (otherwise, "permaLinks" would been enough). The atom:id is an identifier for the resource, not for the representation, so you might very well have the same entry (with the same atom:id) with inlined content in one feed and out-of-line content in another (or any other variation). The behavior of consumers when they meet those different Atom representations of the same entry is left undefined in the spec, and I personnaly have no opinion at all (as I have been given such feeds, and a) I'm not subscribed to any aggregate feed and b) I don't aggregate feeds I'm subscribed to, each one lives in its own "folder" in Thunderbird)=E2=80=A6 --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Jun 07 15:44:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3wf-0007Vm-Kr for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15:44:01 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3we-0006aK-6u for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 15: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 k57JR0GO054620; Wed, 7 Jun 2006 12:27: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 k57JR0mx054619; Wed, 7 Jun 2006 12:27: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57JQxB9054605 for ; Wed, 7 Jun 2006 12:26:59 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 36499 invoked by uid 17064); 7 Jun 2006 19:26:59 -0000 Received: from unknown (HELO [10.20.30.152]) ([195.101.242.1]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Jun 2006 19:26:59 -0000 In-Reply-To: <44871DBB.5050503@gmail.com> References: <44870CF4.80509@gmail.com> <44871DBB.5050503@gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D283A2E-9348-435C-96CC-8819C0A3FAA8@bblfish.net> Cc: atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: when should two entries have the same id? Date: Wed, 7 Jun 2006 21:26:58 +0200 To: James M Snell 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: 6e922792024732fb1bb6f346e63517e4 Yes, I know, the atom syntax doc does not make statements about what happens in different feeds. But that does not mean that we are not forced logically to a conclusion. There was a very in depth discussion of this by the way on the atom semantics [1] mail list this February. I think the Atom Protocol is forcing the issue towards there being only one entry per update time stamp. When you publish an entry with an updated time stamp it is going to have to appear in a feed at some point. And that won't be possible unless you overwrite one or the other entries. Also think of agregators. If you have the same entry with the same id but different content, which is it going to choose? Henry [1] http://groups.google.com/group/atom-owl/browse_frm/thread/ 357e36c4ee9cd31b/ On 7 Jun 2006, at 20:40, James M Snell wrote: > Henry Story wrote: >> >> You can have two entries or feeds with the same id, as long as >> they have >> different updated time stamps. > > That's not quite accurate. Two entries with the same atom:id may > appear > within the same atom:feed only if they have different atom:updated > elements. The spec is silent on whether or not two entries > existing in > *separate documents* may have identical atom:id and atom:updated > values. > > Consider the case where my personal weblog publishes two Atom feeds. > One is a "full-content" feed that publishes content as XHTML. The > second is a "partial-content" feed that strips the markup and > publishes > content as plain text in the atom:summary while containing an > atom:content with a src attribute to the original XHTML. They > exist in > two separate Atom documents and both are based on the same underlying > blog post. The atom:id and atom:updated values for each entry are > identical. > > Another example. I post an iCal file to an APP collection. In the > collection feed, I see a "media link entry" that uses content/@src to > point to the iCal. However, another feed that is used to provide a > summary of upcoming events has entries whose content element > contains an > XHTML rendering of the iCal files. Each entry in the summary feed > corresponds to exactly one entry in the APP collection; should they or > should they not use the same atom:id and atom:updated values? > > - James > >> It's very much the same as you being Robert Yates all your life, but >> having different sizes throughout your life. At any point in time you >> have all the same properties... >> >> Henry >> >> On 7 Jun 2006, at 19:29, Robert Yates wrote: >> >>> >>> This relates to work that we are doing with the publishing protocol, >>> but is syntax related. >>> >>> In an implementation of APP a single entry can appear both in the >>> APP >>> collection and in any number of arbitrary feeds that the site >>> subsequently offers. >>> >>> These feeds / collections can be optimized differently depending on >>> the client. For example, an entry in the collection feed may >>> have its >>> content "out of lined" whereas the "same" entry rendered in a >>> feed may >>> have its content inlined. There are other different optimizations >>> that we are investigating, that cause the entry representation in >>> various feeds / collections to be different, even though it has >>> originated from the same source. >>> >>> So are these representations in the different feeds / collections >>> the >>> same entry or different entries? Should they have the same id? >>> and if >>> a feedreader comes across two entries with the same atom id, >>> what, if >>> anything, can it infer from that? is it only that they came from the >>> same source? >>> >>> Many Thanks, >>> >>> Rob >> >> From owner-atom-syntax@mail.imc.org Wed Jun 07 16:34:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4jJ-0003CQ-Pg for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 16:34:17 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4jI-0006N0-Cn for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 16:34: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 k57KHdtX069521; Wed, 7 Jun 2006 13:17: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 k57KHdkY069518; Wed, 7 Jun 2006 13:17: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 mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57KHcsw069482 for ; Wed, 7 Jun 2006 13:17:38 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.241.143] (sera-10-169-186-16.nscp.aoltw.net [10.169.186.16]) by mcom.com (8.10.0/8.10.0) with ESMTP id k57KHQg12122 for ; Wed, 7 Jun 2006 13:17:27 -0700 (PDT) Message-ID: <44873456.6080001@aol.net> Date: Wed, 07 Jun 2006 13:17:26 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Copyright, licensing, and feeds 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: 9182cfff02fae4f1b6e9349e01d62f32 After my earlier post about discoverability of related feeds, I realized that I had neglected to explain the background behind what I'm thinking about fully. Here are all of the gory details: http://journals.aol.com/panzerjohn/abstractioneer/entries/1338 I'm attempting to promote the use of explicit licenses in feeds, and Creative Commons is one great source of predefined licenses suitable for the kinds of things that people want to use feeds for today: http://creativecommons.org/weblog/entry/5928 This is actually an interoperability issue: If I need to consult my legal department before displaying the content of a feed to a user, it's likely to simply not happen. Of course this is not fundamentally a technical problem, it's a social problem, but I'm trying to promote the technical underpinnings that will make social solutions possible. A stable technical underpinning is one of the things that's necessary here. -- John Panzer System Architect, AOL http://abstractioneer.org From owner-atom-syntax@mail.imc.org Wed Jun 07 17:49:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5ty-0003TA-Le for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 17:49:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5tx-0002eT-94 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 17:49: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 k57LbIGe012731; Wed, 7 Jun 2006 14:37: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 k57LbI3K012730; Wed, 7 Jun 2006 14:37: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 nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.192]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57LbHr6012722 for ; Wed, 7 Jun 2006 14:37:17 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so269604nzd for ; Wed, 07 Jun 2006 14:37:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=up8OfKp+UxP+3cHAh2Ou+USXnCnu2Dr1CAELy2Lkaao7C8ghlEXU/lRm321da5pPfzqytQHkjroFm1gTPW9yG2118QPEDB6sRFLnhQjHuX8U1/3+9ui4YixsReJ5Cu3dskWIwjn+IKa88fJjD4PgLS6lfkqtlkC0Lxph8LHe8ms= Received: by 10.64.204.6 with SMTP id b6mr1116853qbg; Wed, 07 Jun 2006 14:37:16 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Wed, 7 Jun 2006 14:37:16 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 23:37:16 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: when should two entries have the same id? In-Reply-To: <44873B80.7070800@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <44870CF4.80509@gmail.com> <44873B80.7070800@gmail.com> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k57LbHr6012723 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 k57LbIGe012731 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 2006/6/7, Robert Yates : > Thomas Broyer wrote: > > > and that this is needed because entries > > might not always be atomically retrieved (otherwise, "permaLinks" > > would been enough). > > I don't understand what you mean "atomically retrieved" and hence why > permaLinks would not have been enough. By "atomically retrieved", I mean that you don't necessary have an Atom Entry Document for each entry in a feed (actually, many CMSes don't currently provide Atom Entry Documents, the only Atom documents they provide are one or two feeds). As Atom goes beyond content management =C3=A0 la blogs, there are also us= e cases where the is no "alternate" representation: the entry in the feed is the only representation of the resource, there's no way to identify it using an URI, other than explicitely associate one through the atom:id element. Finally, atom:id is different from a permaLink in the sens that it's only an identifier that might not be dereferenceable (or, to be more accurate, that might not return anything but an error when dereferenced): it's not a link, it's an identifier, which has the form of an IRI, just as XML Namespaces are identified by URIs. The advantage of such a design choice is that you can move entries (hence changing "permaLinks") without changing their identifier. This is particularly useful when, for example, switching from TypePad to Blogger, and then to WordPress.Com, and then to a self-hosted blogging system, and then changing the blogging system (and changing feed and entry URIs, even if it's not a Good Thing [1]). A Good Practice for these identifiers =E2=80=93at least when you're an individual=E2=80=93 is to make them "tag" URIs [2] [1] http://www.w3.org/Provider/Style/URI [2] http://www.taguri.org/ --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Jun 07 17:49:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo5uV-0003dv-DU for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 17:49:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo5uR-0002f1-Vm for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 17:49: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 k57LX00d010559; Wed, 7 Jun 2006 14:33: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 k57LX0cv010558; Wed, 7 Jun 2006 14:33: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 mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57LWxuM010520 for ; Wed, 7 Jun 2006 14:32:59 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (snv-global1.corp.yahoo.com [216.145.49.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id BF110A3206; Wed, 7 Jun 2006 17:32:56 -0400 (EDT) In-Reply-To: References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 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: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 14:33:02 -0700 To: James Holderness 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: e1e48a527f609d1be2bc8d8a70eb76cb On 2006/06/07, at 11:16 AM, James Holderness wrote: > Mark Nottingham wrote: >> These are pretty much the assumptions that I was making >> previously. The degree of precision that FH currently provides >> isn't desirable for search results. Feed History also requires >> that the server maintain state about a particular feed, which is >> unworkable for search results; e.g., to implement feed history >> for search results, a server would have to mint a whole new set >> of feed documents for every query, and keep them around. > > Not necessarily. They only need to be able to sort results on a > most-recently-discovered date. When a client connects to them with > an etag representing date X, they return only those results have > been discovered since date X. I can believe that there are search > engines for which even that isn't feasible, but then FH as we know > is not possible, and those feeds are essentially useless from a > subscription point of view. > > They can still use the paging links so you can connect to a search > engine for a once-off paged set of results. They just need to > return 304 on any subsequent requests (i.e. anything with an etag) > in case someone makes the mistake of subscribing to one of those > feeds. If you have something else in mind for that kind of server > I'm curious to know what it is. In other words can you envision a > server that wants to do paging, doesn't have enough state > information to be able to do FH, but still would like to allow > subscriptions? How would it work? I'm not sure how ETags and 304s come into it -- it sounds like you're proposing using either the entry-level updated date or the entry- level id as input to a server-side function to select a set of entries from the feed. Can you paint out your proposal in protocol exchanges, please? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 07 18:17:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6Lb-0005Jg-Vq for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18:17:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo6LZ-0003rk-JL for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18:17: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 k57M71EL027341; Wed, 7 Jun 2006 15:07: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 k57M716X027340; Wed, 7 Jun 2006 15:07: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 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 k57M6xlQ027319 for ; Wed, 7 Jun 2006 15:07:00 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 17989 invoked from network); 7 Jun 2006 22:06:28 -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 ; 7 Jun 2006 22:06:28 -0000 Message-ID: <44874D7C.6080504@metalab.unc.edu> Date: Wed, 07 Jun 2006 18:04:44 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: John Panzer CC: atom-syntax Subject: Re: Copyright, licensing, and feeds References: <44873456.6080001@aol.net> In-Reply-To: <44873456.6080001@aol.net> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k57M71EL027341 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab John Panzer wrote: > I'm attempting to promote the use of explicit licenses in feeds, and=20 > Creative Commons is one great source of predefined licenses suitable fo= r=20 > the kinds of things that people want to use feeds for today: >=20 Creative Commons only covers a very small subset of what's needed for=20 feeds. It's completely inadequate for something as simple as "Don't=20 republish this. Period." Much less if you want to say things like, "You=20 can republish it but the cost is one cents per page view, and I have the=20 right to audit your books once per year." --=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 Wed Jun 07 18:35:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6cU-00040Q-P3 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18:35:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo6cT-00056Z-Cm for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18: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 k57MKuub034237; Wed, 7 Jun 2006 15:20: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 k57MKukf034236; Wed, 7 Jun 2006 15:20: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 mcom.com (c3po.aoltw.net [64.236.137.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57MKtDw034191 for ; Wed, 7 Jun 2006 15:20:55 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.241.143] (sera-10-169-186-16.nscp.aoltw.net [10.169.186.16]) by mcom.com (8.10.0/8.10.0) with ESMTP id k57MKcG26271; Wed, 7 Jun 2006 15:20:48 -0700 (PDT) Message-ID: <44875136.7020506@aol.net> Date: Wed, 07 Jun 2006 15:20:38 -0700 From: John Panzer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elliotte Harold CC: atom-syntax Subject: Re: Copyright, licensing, and feeds References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> In-Reply-To: <44874D7C.6080504@metalab.unc.edu> 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.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Elliotte Harold wrote: > > John Panzer wrote: > >> I'm attempting to promote the use of explicit licenses in feeds, and >> Creative Commons is one great source of predefined licenses suitable >> for the kinds of things that people want to use feeds for today: >> > > Creative Commons only covers a very small subset of what's needed for > feeds. It's completely inadequate for something as simple as "Don't > republish this. Period." Much less if you want to say things like, > "You can republish it but the cost is one cents per page view, and I > have the right to audit your books once per year." > That's why I said "one great source"; all the mechanisms I'm recommending are 100% extensible. CC covers two major use cases for feeds: (1) Republish but not for commercial use; you can't resell it, or sell advertising next to the content. This covers for example the Engadget full text feed. (2) Republish freely but maintain an attribution back to the source. This covers the Engadget excerpt feed, which is basically advertising for the main web site. You're free to create your own licenses (but you'll need to pay your own lawyers) and put them on a web site, after which you can use to point to them. My servers will initially not understand those licenses, and will revert to "fair use only" type of usage, until we upgrade our code. -- John Panzer System Architect, AOL http://abstractioneer.org From owner-atom-syntax@mail.imc.org Wed Jun 07 18:46:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo6mp-0003HC-7A for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18:46:03 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo6mn-0007JJ-N2 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 18:46: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 k57MZWMw041551; Wed, 7 Jun 2006 15:35: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 k57MZWpC041546; Wed, 7 Jun 2006 15:35: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-dav1.bay109.hotmail.com [64.4.19.73]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57MZVWJ041490 for ; Wed, 7 Jun 2006 15:35:31 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 15:35:28 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV1.phx.gbl with DAV; Wed, 07 Jun 2006 22:35:26 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Subject: Re: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 23:35:26 +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: 07 Jun 2006 22:35:28.0153 (UTC) FILETIME=[AD1F5090:01C68A82] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Mark Nottingham wrote: > I'm not sure how ETags and 304s come into it -- it sounds like you're > proposing using either the entry-level updated date or the entry- level id > as input to a server-side function to select a set of entries from the > feed. Can you paint out your proposal in protocol exchanges, please? Entry-level updated date is close, but not quite what would be needed. For this to work, it requires that search engines store a date that represents when a result is "discovered". In other words the date that an entry is added to the search engine database. Client connects to server with a specific query. Server returns the first page of results along with an etag representing the current internal datetime as accurately as possible. Client connects to server with "next" link from first page (the link would obviously have to include the query as well as the page number). Server returns the second page of results. etc. Client connects to server with a specific query along with etag returned from the first query. Server returns only those results that match the query *and* have a "discovered" date >= etag date value. Server also returns etag representing the current internal datetime as before. Client connects to server with "next" link from first page (this link would include the query and the page number, but also the the etag value). Server returns the second page of results that match the query *and* have a "discovered" date >= etag value. etc. That make sense? If the server doesn't have the concept of a "discovered" date, then there's not much we can do. We can return a paged set of results, but they can't be updated in any meaningful way so the feed should not be subscribed to. Client connects to server with a specific query. Server returns first page of results along with an etag containing a hash of the star-spanngled banner. Client connects to server with "next" link from first page. Server returns the second page of results. etc. Client connects to server with a specific query along with etag returned from initial query. Server notices that there is an etag, doesn't care what it is set to, and just returns 304 regardless. In other words, you can retrieve the feed once, but never again. That's as good as it gets. Regards James From owner-atom-syntax@mail.imc.org Wed Jun 07 20:08:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo84l-0003fS-CJ for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:08:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo84j-0007DM-TW for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:08: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 k57NhtrY076533; Wed, 7 Jun 2006 16:43: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 k57NhtqE076532; Wed, 7 Jun 2006 16:43: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 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 k57Nhswg076514 for ; Wed, 7 Jun 2006 16:43:54 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so217782wxc for ; Wed, 07 Jun 2006 16:43:53 -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=ibi11+K5YCGhP/zprV/vo6oAmLx8oJ3tP6m4KZgg7Ci1ypRTi/R+DL/LtmPcoHt9quGMJXSfAy7ExfjsXk7kqOeJJULTRq2VZPuoCTS0ElTQhippgR8g9XqubbzDgGOffSxj2O/4u8m8EIpaxkhpv3JeAhf2D+X2PN9+f9ArLKc= Received: by 10.70.44.16 with SMTP id r16mr1358696wxr; Wed, 07 Jun 2006 16:43:53 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Wed, 7 Jun 2006 16:43:53 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 17:43:53 -0600 From: "M. David Peterson" To: "John Panzer" Subject: Re: Copyright, licensing, and feeds Cc: "Elliotte Harold" , atom-syntax In-Reply-To: <44875136.7020506@aol.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11506_24723485.1149723833546" References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 ------=_Part_11506_24723485.1149723833546 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey John, In this example, does rel="license" represent a tagged reference or the URI to the location of the license? On 6/7/06, John Panzer wrote: > > > Elliotte Harold wrote: > > > > > John Panzer wrote: > > > >> I'm attempting to promote the use of explicit licenses in feeds, and > >> Creative Commons is one great source of predefined licenses suitable > >> for the kinds of things that people want to use feeds for today: > >> > > > > Creative Commons only covers a very small subset of what's needed for > > feeds. It's completely inadequate for something as simple as "Don't > > republish this. Period." Much less if you want to say things like, > > "You can republish it but the cost is one cents per page view, and I > > have the right to audit your books once per year." > > > That's why I said "one great source"; all the mechanisms I'm > recommending are 100% extensible. > > CC covers two major use cases for feeds: > > (1) Republish but not for commercial use; you can't resell it, or sell > advertising next to the content. This covers for example the Engadget > full text feed. > (2) Republish freely but maintain an attribution back to the source. > This covers the Engadget excerpt feed, which is basically advertising > for the main web site. > > You're free to create your own licenses (but you'll need to pay your own > lawyers) and put them on a web site, after which you can use rel="license"...> to point to them. My servers will initially not > understand those licenses, and will revert to "fair use only" type of > usage, until we upgrade our code. > > -- > John Panzer > System Architect, AOL > http://abstractioneer.org > > -- M. David Peterson http://www.xsltblog.com/ ------=_Part_11506_24723485.1149723833546 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey John,

In this example, does rel="license" represent a tagged reference or the URI to the location of the license?


On 6/7/06, John Panzer <jpanzer@aol.net> wrote:

Elliotte Harold wrote:

>
> John Panzer wrote:
>
>> I'm attempting to promote the use of explicit licenses in feeds, and
>> Creative Commons is one great source of predefined licenses suitable
>> for the kinds of things that people want to use feeds for today:
>>
>
> Creative Commons only covers a very small subset of what's needed for
> feeds. It's completely inadequate for something as simple as "Don't
> republish this. Period." Much less if you want to say things like,
> "You can republish it but the cost is one cents per page view, and I
> have the right to audit your books once per year."
>
That's why I said "one great source"; all the mechanisms I'm
recommending are 100% extensible.

CC covers two major use cases for feeds:

(1) Republish but not for commercial use; you can't resell it, or sell
advertising next to the content.  This covers for example the Engadget
full text feed.
(2) Republish freely but maintain an attribution back to the source.
This covers the Engadget excerpt feed, which is basically advertising
for the main web site.

You're free to create your own licenses (but you'll need to pay your own
lawyers) and put them on a web site, after which you can use <link
rel="license"...> to point to them.  My servers will initially not
understand those licenses, and will revert to "fair use only" type of
usage, until we upgrade our code.

--
John Panzer
System Architect, AOL
http://abstractioneer.org




--
<M:D/>

M. David Peterson
http://www.xsltblog.com/ ------=_Part_11506_24723485.1149723833546-- From owner-atom-syntax@mail.imc.org Wed Jun 07 20:17:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8DJ-0002SB-3K for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:17:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8DH-0000ln-Nw for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:17: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 k57NuqvN083434; Wed, 7 Jun 2006 16:56: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 k57NuqdL083433; Wed, 7 Jun 2006 16:56: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.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k57NupdI083419 for ; Wed, 7 Jun 2006 16:56:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so272055wra for ; Wed, 07 Jun 2006 16:56: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=ERS+OD6xmO3gf8TJ2EmhFaKE1R8Atf33Wl6EFfXkqscFqAAj//0E946KQb04sf37Iym4YpKE2ftPOCgh/3iJeoImb70GtIGd2VAfVzPdG6IsHMkabBVwkvwNuMRrf3DVSlKX7zaaCDwJK98D89d4Jr1GPOX5gFEHwP+UqhYdiXY= Received: by 10.54.61.16 with SMTP id j16mr1358942wra; Wed, 07 Jun 2006 16:56:50 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 64sm1199251wra.2006.06.07.16.56.48; Wed, 07 Jun 2006 16:56:49 -0700 (PDT) Message-ID: <448767BC.90507@gmail.com> Date: Wed, 07 Jun 2006 16:56:44 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax Subject: Re: Copyright, licensing, and feeds References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> 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: 08170828343bcf1325e4a0fb4584481c I don't want to speak for John, but in the feed thread draft, it's both. The href is intended to be dereferenceable to retrieve some document describing the license. - James M. David Peterson wrote: > Hey John, > > In this example, does rel="license" represent a tagged reference or the > URI to the location of the license? > > [snip] From owner-atom-syntax@mail.imc.org Wed Jun 07 20:27:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8Mh-0005yc-L4 for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:27:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8Mg-0001eA-7R for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 20:27: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 k5806axt087759; Wed, 7 Jun 2006 17:06: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 k5806a4H087758; Wed, 7 Jun 2006 17:06: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 mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5806ZRN087740 for ; Wed, 7 Jun 2006 17:06:35 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (snv-global1.corp.yahoo.com [216.145.49.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 8D821A3233; Wed, 7 Jun 2006 20:06:34 -0400 (EDT) In-Reply-To: References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 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: Paging, Feed History, etc. Date: Wed, 7 Jun 2006 17:06:40 -0700 To: James Holderness 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: c3a18ef96977fc9bcc21a621cbf1174b Are you talking about using ETag HTTP response headers, If-Match request headers, and 304 Not Modified response status codes? That's a gross misapplication of those mechanisms if so, and this will break intermediaries along the path. Even if it's cast as a query parameter in the URI (for example), it requires query support on the server side, a concept of "discovered time" (as you point out), and places constraints on the ordering of the feed. Are you proposing this instead of the mechanism currently described in FH? Alongside it? On 2006/06/07, at 3:35 PM, James Holderness wrote: > > Mark Nottingham wrote: >> I'm not sure how ETags and 304s come into it -- it sounds like >> you're proposing using either the entry-level updated date or the >> entry- level id as input to a server-side function to select a set >> of entries from the feed. Can you paint out your proposal in >> protocol exchanges, please? > > Entry-level updated date is close, but not quite what would be > needed. For this to work, it requires that search engines store a > date that represents when a result is "discovered". In other words > the date that an entry is added to the search engine database. > > Client connects to server with a specific query. > Server returns the first page of results along with an etag > representing the current internal datetime as accurately as possible. > Client connects to server with "next" link from first page (the > link would obviously have to include the query as well as the page > number). > Server returns the second page of results. > etc. > > > > Client connects to server with a specific query along with etag > returned from the first query. > Server returns only those results that match the query *and* have a > "discovered" date >= etag date value. > Server also returns etag representing the current internal datetime > as before. > Client connects to server with "next" link from first page (this > link would include the query and the page number, but also the the > etag value). > Server returns the second page of results that match the query > *and* have a "discovered" date >= etag value. > etc. > > That make sense? > > If the server doesn't have the concept of a "discovered" date, then > there's not much we can do. We can return a paged set of results, > but they can't be updated in any meaningful way so the feed should > not be subscribed to. > > Client connects to server with a specific query. > Server returns first page of results along with an etag containing > a hash of the star-spanngled banner. > Client connects to server with "next" link from first page. > Server returns the second page of results. > etc. > > > > Client connects to server with a specific query along with etag > returned from initial query. > Server notices that there is an etag, doesn't care what it is set > to, and just returns 304 regardless. > > In other words, you can retrieve the feed once, but never again. > That's as good as it gets. > > Regards > James > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 07 21:02:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8vF-0006kd-MO for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 21:02:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8vE-000888-6w for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 21:02: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 k580hL6Y007560; Wed, 7 Jun 2006 17:43: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 k580hLOU007559; Wed, 7 Jun 2006 17:43: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 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 k580hK0Q007543 for ; Wed, 7 Jun 2006 17:43:21 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Jun 2006 17:43:20 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV10.phx.gbl with DAV; Thu, 08 Jun 2006 00:43:18 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Subject: Re: Paging, Feed History, etc. Date: Thu, 8 Jun 2006 01:43:17 +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: 08 Jun 2006 00:43:20.0630 (UTC) FILETIME=[8A466560:01C68A94] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Mark Nottingham wrote: > Are you talking about using ETag HTTP response headers, If-Match request > headers, and 304 Not Modified response status codes? That's a gross > misapplication of those mechanisms if so, and this will break > intermediaries along the path. For the first page I'm talking about an Etag (or Last-Modified) HTTP response header and If-None-Match (or If-Modified-Since) request headers for the retrievals a month later. For page two onwards the state information (date, query and page number) comes from the link urls returned by the first page. I don't see how that's a gross misapplication of those mechanisms, but I'll take your word for it. > Even if it's cast as a query parameter in the URI (for example), it > requires query support on the server side, a concept of "discovered time" > (as you point out), and places constraints on the ordering of the feed. The ordering is not necessarily important. As long as the server can filter out entries that don't match a specific time criteria it can return those entries in any order. > Are you proposing this instead of the mechanism currently described in > FH? Alongside it? What I'm proposing would work with the FH as currently specified as long as the client supported ETag or Last-Modified as well. For me that means no change at all. And I'm not trying to propose this as something that servers have to do. It just seemed to me to be a fairly easy way for a search engine to support subscribable paging if they chose to. And it should work with clients that already support FH so it doesn't require any new links or algorithms. If you have something better in mind that's cool too. So far the plan seems to be: 1. Change the names of the link relations so as to break existing clients. 2. ??? 3. Profit!! Regards James From owner-atom-syntax@mail.imc.org Wed Jun 07 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 1FoAMb-00084b-UX for atompub-archive@lists.ietf.org; Wed, 07 Jun 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 1FoAKG-000052-Rb for atompub-archive@lists.ietf.org; Wed, 07 Jun 2006 22:32: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 k582Kq61058179; Wed, 7 Jun 2006 19:20: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 k582Kq2H058178; Wed, 7 Jun 2006 19:20: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 homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k582KpFs058153 for ; Wed, 7 Jun 2006 19:20:51 -0700 (MST) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id B59134EFAE; Wed, 7 Jun 2006 22:20:49 -0400 (EDT) In-Reply-To: <44873456.6080001@aol.net> References: <44873456.6080001@aol.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> Cc: atom-syntax From: Karl Dubost Subject: Re: Copyright, licensing, and feeds Date: Thu, 8 Jun 2006 11:20:47 +0900 To: John Panzer X-Mailer: Apple Mail (2.750) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k582KpFs058169 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 k582Kq61058179 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Le 06-06-08 =E0 05:17, John Panzer a =E9crit : > I'm attempting to promote the use of explicit licenses in feeds, =20 > and Creative Commons is one great source of predefined licenses =20 > suitable for the kinds of things that people want to use feeds for =20 > today: > http://creativecommons.org/weblog/entry/5928 +1 > This is actually an interoperability issue: If I need to consult =20 > my legal department A bit more than that. As Elliotte said, there are a maelstrom of =20 possibilities and not necessary easy to solve. These days, I'm =20 blocking the access to *all* indexing bots (Google, Yahoo, =20 technorati, etc.) because of the license issue. I had to fight with =20 some of them. When we choose CreativeCommons, Share A Like - No commercial user, we =20 expect that no commercial use will be done. It means no data =20 profiling, no advertisement, etc. As Elliotte said too, it can be =20 opposite, as one's would want to license its content, you can use it =20 but you have to pay me in returns. * First simple solution: No commercial use. Aggregators, indexing bots, Re-bloggers, etc. MUST enforce the =20 license. It means that a company like Technorati or Google could have =20 a P3P declaration saying: "if your data under this license XYZ, we =20 will not be able to index them." and not index them. A Web blog readers which would data mining with the feeds, could =20 say: "Your data will not be used for commercial purpose when you are =20 a paid subscriber." Then it will be users to decide the type of licenses, services and =20 subscriptions they are willing to accept. Respect of the contract. * Difficult choice: Commercial use. Here it's very hard and we are entering in the nightmarish DRMs =20 world. DRMs "could" be good if there were not mixed up with=85 TPM =20 (Technical Protection Mechanism). There are efforts in this direction =20 for Open DRMs http://www.openmediacommons.org/ http://odrl.net/=09 Which will not remove abuse :) --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Thu Jun 08 00:59:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoCcU-0005Im-TA for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 00:59:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoCcS-0003ij-Gh for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 00:59: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 k584jPd4040171; Wed, 7 Jun 2006 21:45: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 k584jPHS040166; Wed, 7 Jun 2006 21:45: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 mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k584jPkc040029 for ; Wed, 7 Jun 2006 21:45:25 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from [10.169.186.4] (sera-10-169-186-4.nscp.aoltw.net [10.169.186.4]) by mcom.com (8.10.0/8.10.0) with ESMTP id k584jDg01908; Wed, 7 Jun 2006 21:45:13 -0700 (PDT) Message-ID: <4487AB58.8060702@aol.net> Date: Wed, 07 Jun 2006 21:45:12 -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-syntax Subject: Re: Copyright, licensing, and feeds References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> In-Reply-To: <448767BC.90507@gmail.com> Content-Type: multipart/alternative; boundary="------------070200000005010104080506" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is a multi-part message in MIME format. --------------070200000005010104080506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Yes, I intended to refer to James' feed license extension: http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ (James, I think you meant "feed license draft" rather than "feed thread draft", right? :) ) James M Snell wrote: >I don't want to speak for John, but in the feed thread draft, it's both. > The href is intended to be dereferenceable to retrieve some document >describing the license. > >- James > >M. David Peterson wrote: > > >>Hey John, >> >>In this example, does rel="license" represent a tagged reference or the >>URI to the location of the license? >> >>[snip] >> >> > > > --------------070200000005010104080506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k584jPd4040171 Yes, I intended to refer to James' feed license extension:

http://ietfreport.isoc.org/idref/dr= aft-snell-atompub-feed-license/

(James, I think you meant "feed license draft" rather than "feed thread draft", right?=C2=A0 :) )

James M Snell wrote: 
I don't want to speak for John, but in the feed thread d=
raft, it's both.
 The href is intended to be dereferenceable to retrieve some document
describing the license.

- James

M. David Peterson wrote:
  
Hey John,

In this example, does rel=3D"license" represent a tagged reference or the
URI to the location of the license?

[snip]

--------------070200000005010104080506-- From owner-atom-syntax@mail.imc.org Thu Jun 08 01:07:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoCk9-0001i4-Lq for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 01:07:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoCk6-0003sr-8g for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 01:07: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 k584tSfF046252; Wed, 7 Jun 2006 21:55: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 k584tS3l046251; Wed, 7 Jun 2006 21:55: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 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 k584tRCc046224 for ; Wed, 7 Jun 2006 21:55:27 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so253515wxc for ; Wed, 07 Jun 2006 21:55: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=TAmNjgpU3KCtxJ9tZEPIWZNZtIa+kj8QXo+ZPpGnuIR9BAJ5xFI8vdm/5KtGrrH4Cbsl+9uL+dcRAiS+S4bFzX0XIpC4r4931rdy2SaDbSj1F6s2H8SN27z3xTJwjBG0Rf5l/HGODE/7vQzqQ5Fd5e9k+P6xiQTtCTbmVDpuYZg= Received: by 10.70.39.19 with SMTP id m19mr1623479wxm; Wed, 07 Jun 2006 21:55:26 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id h16sm1523500wxd.2006.06.07.21.55.26; Wed, 07 Jun 2006 21:55:26 -0700 (PDT) Message-ID: <4487ADB9.4050108@gmail.com> Date: Wed, 07 Jun 2006 21:55:21 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: John Panzer CC: atom-syntax Subject: Re: Copyright, licensing, and feeds References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> <4487AB58.8060702@aol.net> In-Reply-To: <4487AB58.8060702@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: e5ba305d0e64821bf3d8bc5d3bb07228 Doh! Yes, sorry, I've had feed thread on the brain lately. John Panzer wrote: > Yes, I intended to refer to James' feed license extension: > > http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ > > (James, I think you meant "feed license draft" rather than "feed thread > draft", right? :) ) > > James M Snell wrote: >> I don't want to speak for John, but in the feed thread draft, it's both. >> The href is intended to be dereferenceable to retrieve some document >> describing the license. >> >> - James >> >> M. David Peterson wrote: >> >>> Hey John, >>> >>> In this example, does rel="license" represent a tagged reference or the >>> URI to the location of the license? >>> >>> [snip] >>> >> >> > From owner-atom-syntax@mail.imc.org Thu Jun 08 02:02:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDbN-0008J8-Od for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 02:02:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDUw-00087C-Jx for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 01:56: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 k585eOG9072042; Wed, 7 Jun 2006 22:40: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 k585eOLn072041; Wed, 7 Jun 2006 22:40: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k585eNTB072025 for ; Wed, 7 Jun 2006 22:40:23 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so257554wxc for ; Wed, 07 Jun 2006 22:40:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=URy6S2tPkICoh0DH+H9wWGHsg91We4JW0pGR0RVxJN0QTQtF/YLjvUzr8uo917bgugoj2VEFiFe7QDgginjGT/U+RVURcSbvBsZV8mhdwV27J8zZqYxF3B+hf8fjOTCiBj2MiiNX0fH7cdv6+ibZqRV6R3xdvgGjfi2ACV/m8Mo= Received: by 10.70.25.9 with SMTP id 9mr1680673wxy; Wed, 07 Jun 2006 22:40:22 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Wed, 7 Jun 2006 22:40:22 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2006 23:40:22 -0600 From: "M. David Peterson" To: "John Panzer" Subject: Re: Copyright, licensing, and feeds Cc: "James M Snell" , atom-syntax In-Reply-To: <4487AB58.8060702@aol.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15084_28846962.1149745222193" References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> <4487AB58.8060702@aol.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 ------=_Part_15084_28846962.1149745222193 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Okay, cool... This is the first I've seen this, but that obviously nothing of any great concern. I guess my next question is the same as what what you, Elliotte, and Karl have already made the primary focus of this thread, * Beyond providing a way of referencing what license(s) applies to any given entry, how does a machine determine "I am rendering ads on this page, so I can't display the content of this feed, but I can render this feed because the rules for this license allow me to display its content on a page supported by ads? * Does there exist a specification of any sort, that extends from XML Schema, Schematron, RelaxNG, or similar, that would allow me to determine at run time what rules apply to a given license, and based on the rendering schema for any given page, determine which, if any, linked content can be accessed and rendered as part of this page instance? Is this where you plan to take this John, or have I missed the boat completely? On 6/7/06, John Panzer wrote: > > Yes, I intended to refer to James' feed license extension: > > http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ > > (James, I think you meant "feed license draft" rather than "feed thread > draft", right? :) ) > > > James M Snell wrote: > > I don't want to speak for John, but in the feed thread draft, it's both. > The href is intended to be dereferenceable to retrieve some document > describing the license. > > - James > > M. David Peterson wrote: > > Hey John, > > In this example, does rel="license" represent a tagged reference or the > URI to the location of the license? > > [snip] > > > -- M. David Peterson http://www.xsltblog.com/ ------=_Part_15084_28846962.1149745222193 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Okay, cool... This is the first I've seen this, but that obviously nothing of any great concern.

I guess my next question is the same as what what you, Elliotte, and Karl have already made the primary focus of this thread,

* Beyond providing a way of referencing what license(s) applies to any given entry, how does a machine determine "I am rendering ads on this page, so I can't display the content of this feed, but I can render this feed because the rules for this license allow me to display its content on a page supported by ads?

* Does there exist a specification of any sort, that extends from XML Schema, Schematron, RelaxNG, or similar, that would allow me to determine at run time what rules apply to a given license, and based on the rendering schema for any given page, determine which, if any, linked content can be accessed and rendered as part of this page instance?

Is this where you plan to take this John, or have I missed the boat completely?

On 6/7/06, John Panzer <jpanzer@aol.net > wrote:
Yes, I intended to refer to James' feed license extension:

http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/

(James, I think you meant "feed license draft" rather than "feed thread draft", right?  :) )


James M Snell wrote: 
I don't want to speak for John, but in the feed thread draft, it's both.
 The href is intended to be dereferenceable to retrieve some document
describing the license.

- James

M. David Peterson wrote:

  
Hey John,

In this example, does rel="license" represent a tagged reference or the
URI to the location of the license?

[snip]




--
<M:D/>

M. David Peterson
http://www.xsltblog.com/ ------=_Part_15084_28846962.1149745222193-- From owner-atom-syntax@mail.imc.org Thu Jun 08 02:55:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEQl-0006yA-Vm for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 02:55:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoEQk-0007wh-ES for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 02:55: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 k586eKip007241; Wed, 7 Jun 2006 23:40: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 k586eKlu007240; Wed, 7 Jun 2006 23:40: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 nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k586eIxc007204 for ; Wed, 7 Jun 2006 23:40:18 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so362287nzd for ; Wed, 07 Jun 2006 23:40:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QMa7Bn92C4+XE6UgEDaaBowxJBCUoSaOSDSpmpbnxPawANYn5mHQnyUEgGBWBw7zRRtvy2IaJH0HxuEQlWHUG34tDZUR7iVmC3LOlECREZH1vNXE2cD0wHOtuwSh/0nPlZw/J7kgM2EbTXqKhOK+Ri2/M9arCjz+vhMKDbO2k18= Received: by 10.65.75.2 with SMTP id c2mr1256433qbl; Wed, 07 Jun 2006 23:40:18 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Wed, 7 Jun 2006 23:40:18 -0700 (PDT) Message-ID: Date: Thu, 8 Jun 2006 08:40:18 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Paging, Feed History, etc. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k586eJxc007217 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 k586eKip007241 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 2006/6/8, James Holderness : > > Mark Nottingham wrote: > > Are you talking about using ETag HTTP response headers, If-Match req= uest > > headers, and 304 Not Modified response status codes? That's a gross > > misapplication of those mechanisms if so, and this will break > > intermediaries along the path. > > For the first page I'm talking about an Etag (or Last-Modified) HTTP > response header and If-None-Match (or If-Modified-Since) request header= s for > the retrievals a month later. What you described is RFC3229 w/ feeds [1], but you failed to include the new request and response headers and the specific status code, which are necessary because you're changing the behaviour of If-None-Match and 304 (Not Modified) as defined in HTTP/1.1. > For page two onwards the state information (date, query and page number= ) > comes from the link urls returned by the first page. That means you need to keep entry revisions as well, so that if an entry is updated while a client is navigating the paged result set, it is sent the "old" revision (corresponding to the "date" parameter). > > Even if it's cast as a query parameter in the URI (for example), it > > requires query support on the server side, a concept of "discovered = time" > > (as you point out), and places constraints on the ordering of the fe= ed. > > The ordering is not necessarily important. As long as the server can fi= lter > out entries that don't match a specific time criteria it can return tho= se > entries in any order. Yes, ordering is not important. If ranking is necessary, then use the Feed Rank extension (but that means that potentially a great number of entries will be sent back as "modified" in 226 (IM Used) responses just because their ranking has changed) > > Are you proposing this instead of the mechanism currently described = in > > FH? Alongside it? > > What I'm proposing would work with the FH as currently specified as lon= g as > the client supported ETag or Last-Modified as well. For me that means n= o > change at all. You're trying to change HTTP/1.1 behaviour wrt the If-None-Match request-header field and the 304 (Not Modified) status code, so you need to implement RFC3229 w/ feeds (which means dealing with some new headers and a new status code). As I already said, I highly suggest not using paging for 226 (IM Used) responses and rather fall back to "standard GET" in case there are too many changes (i.e. behaving the same way as servers that don't support RFC3229 w/ feeds). My main concern is that RFC3229 w/ feeds is being deployed more and more widely and is still not even an I-D (or I missed something). Maybe FH could be the place to spec it, as another optimization algorithm=E2=80=A6 [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Jun 08 05:53:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHCW-0002Oz-Vj for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 05:53:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHCV-0006tM-EZ for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 05:53: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 k589bWAj004993; Thu, 8 Jun 2006 02:37: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 k589bWP7004992; Thu, 8 Jun 2006 02:37: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-dav14.bay109.hotmail.com [64.4.19.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k589bVrw004978 for ; Thu, 8 Jun 2006 02:37:32 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Jun 2006 02:37:31 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV14.phx.gbl with DAV; Thu, 08 Jun 2006 09:37:29 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Subject: Re: Paging, Feed History, etc. Date: Thu, 8 Jun 2006 10:37:28 +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: 08 Jun 2006 09:37:31.0557 (UTC) FILETIME=[2A1DBD50:01C68ADF] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Thomas Broyer wrote: > What you described is RFC3229 w/ feeds [1], but you failed to include > the new request and response headers and the specific status code, > which are necessary because you're changing the behaviour of > If-None-Match and 304 (Not Modified) as defined in HTTP/1.1. Yep. Sorry, forgot to mention that. > That means you need to keep entry revisions as well, so that if an > entry is updated while a client is navigating the paged result set, it > is sent the "old" revision (corresponding to the "date" parameter). Why? If an entry has been revised either don't send it (they'll get it then next time they refresh), or send it anyway (they'll just get it again the next time they refresh). Is that such a big deal? Or am I missing something? > Yes, ordering is not important. If ranking is necessary, then use the > Feed Rank extension (but that means that potentially a great number of > entries will be sent back as "modified" in 226 (IM Used) responses > just because their ranking has changed) I would have thought IM only applied to the first page. All subsequent pages have a specific query that includes the query, page and time. You're not sending back a partial result in that case. >> What I'm proposing would work with the FH as currently specified as long >> as >> the client supported ETag or Last-Modified as well. For me that means no >> change at all. > > You're trying to change HTTP/1.1 behaviour wrt the If-None-Match > request-header field and the 304 (Not Modified) status code, so you > need to implement RFC3229 w/ feeds (which means dealing with some new > headers and a new status code). No change at all for *me*. As in my client. I already support FH. I already support Etags. I already support 3229. > As I already said, I highly suggest not using paging for 226 (IM Used) > responses and rather fall back to "standard GET" in case there are too > many changes (i.e. behaving the same way as servers that don't support > RFC3229 w/ feeds). I don't get why this is a problem, but if you don't like it don't use it. All I'm saying is, if you're a search engine and you what to create subscribable paged results, this is a method that you can use right now, and it will work with at least one existing FH capable client (I suspect others too). The other proposal on the table is to change all your link names. Arguably a much better proposal than what I'm offering - it certainly seems to have got a lot of +1s - but it will work with precisely no one. Regards James From owner-atom-syntax@mail.imc.org Thu Jun 08 06:19:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHcC-0003H9-DH for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 06:19:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHcB-00007Y-0D for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 06:19: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 k58A65Pl019177; Thu, 8 Jun 2006 03:06: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 k58A65Fi019176; Thu, 8 Jun 2006 03:06: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.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58A60hA019129 for ; Thu, 8 Jun 2006 03:06:04 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so396130nzd for ; Thu, 08 Jun 2006 03:05: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rkaINF3WzrM6iM1mqeJpP8s8TgxHmN7ACY6iCaNCJXYAaeni6i0FhmCJLEzIpkkcyfdvoE2PiDvKGnN8hfufYB4Bsai1PWmxoxOR56H+o8KMbMFg/St7PEm9Udpeh9FezGtoumie2lX1ZfhIaWrGauW194Ga7IUWp6ulUXB2Mww= Received: by 10.65.234.13 with SMTP id l13mr1314238qbr; Thu, 08 Jun 2006 03:05:59 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Thu, 8 Jun 2006 03:05:59 -0700 (PDT) Message-ID: Date: Thu, 8 Jun 2006 12:05:59 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: Paging, Feed History, etc. 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 k58A64hA019168 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 k58A65Pl019177 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 2006/6/8, James Holderness : > > Thomas Broyer wrote: > > That means you need to keep entry revisions as well, so that if an > > entry is updated while a client is navigating the paged result set, i= t > > is sent the "old" revision (corresponding to the "date" parameter). > > Why? If an entry has been revised either don't send it (they'll get it = then > next time they refresh), or send it anyway (they'll just get it again t= he > next time they refresh). > Is that such a big deal? Or am I missing something? Sorry, I thought you wanted search engines to produce "snapshots"... (side note: but in this case, is there a need to pass a "date" parameter to following pages? and if pages are kind of "live", isn't there a risk of data loss? =E2=80=93I mean, this is the Web, so you'll en= d up doing the request for each page, just returning different chunks of the result set; if an entry changes between the request to the first page and the retrieval a following page, your request might put it somewhere else in the result set, changing ordering of entries based on updated time stamps, "discovery date", ranks or else, so your chunks would be different than if the entry hadn't changed, and an entry that have not been retrieved might end up in an already retrieved "chunk by page number", hence the client missing an entry=E2=80= =93 I think this is Mark's concern: this might be an acceptable behaviour in some cases but not all) > > You're trying to change HTTP/1.1 behaviour wrt the If-None-Match > > request-header field and the 304 (Not Modified) status code, so you > > need to implement RFC3229 w/ feeds (which means dealing with some new > > headers and a new status code). > > No change at all for *me*. As in my client. I already support FH. I alr= eady > support Etags. I already support 3229. OK, I though you only supported Etags, as defined by HTTP/1.1 for efficient caching and bandwidth saving. > > As I already said, I highly suggest not using paging for 226 (IM Used= ) > > responses and rather fall back to "standard GET" in case there are to= o > > many changes (i.e. behaving the same way as servers that don't suppor= t > > RFC3229 w/ feeds). > > I don't get why this is a problem, but if you don't like it don't use i= t. Yep, sorry, this is not a problem. > All I'm saying is, if you're a search engine and you what to create > subscribable paged results, this is a method that you can use right now= , and > it will work with at least one existing FH capable client (I suspect ot= hers > too). So we agree ;-) Could you read my recent mails in this thread and confirm that it's the c= ase? > The other proposal on the table is to change all your link names. > Arguably a much better proposal than what I'm offering - it certainly s= eems > to have got a lot of +1s - but it will work with precisely no one. So there now are two -1, isn't it? ;-) --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Jun 08 06:56:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIBs-0000Fr-1s for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 06:56:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoIBp-0004fF-Cw for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 06:56: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 k58AewiQ039006; Thu, 8 Jun 2006 03:40: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 k58Aewgs039004; Thu, 8 Jun 2006 03:40: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 k58Aeut1038931 for ; Thu, 8 Jun 2006 03:40:57 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 08 Jun 2006 10:40:49 -0000 Received: from xdsl-213-196-227-5.netcologne.de (EHLO klangraum) [213.196.227.5] by mail.gmx.net (mp029) with SMTP; 08 Jun 2006 12:40:49 +0200 X-Authenticated: #163624 Date: Thu, 8 Jun 2006 12:40:49 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: Copyright, licensing, and feeds Message-ID: <20060608104049.GQ6092@klangraum> Mail-Followup-To: atom-syntax References: <44873456.6080001@aol.net> <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 * Karl Dubost [2006-06-08 04:30]: > Which will not remove abuse :) Well, will anything short of not publishing your content? I think the point of such an effort is to make life easier for third parties who want to respect your wishes, not to make it harder for third parties who are intent on violating them. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Thu Jun 08 09:01:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoK99-0000dp-6E for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:01:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoK96-0002am-Ps for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:01: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 k58Cjpra006488; Thu, 8 Jun 2006 05: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 k58CjpNk006487; Thu, 8 Jun 2006 05: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 mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58CjoiW006480 for ; Thu, 8 Jun 2006 05:45:50 -0700 (MST) (envelope-from elharo@metalab.unc.edu) Received: (qmail 32530 invoked from network); 8 Jun 2006 12:45:50 -0000 Received: from dsl254-067-087.nyc1.dsl.speakeasy.net (HELO [192.168.254.100]) (elharo@[216.254.67.87]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2006 12:45:50 -0000 Message-ID: <44881B9D.8000400@metalab.unc.edu> Date: Thu, 08 Jun 2006 08:44:13 -0400 From: Elliotte Harold User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: James M Snell CC: atom-syntax@imc.org Subject: Re: when should two entries have the same id? References: <44870CF4.80509@gmail.com> <44871DBB.5050503@gmail.com> In-Reply-To: <44871DBB.5050503@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 k58Cjpra006488 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab James M Snell wrote: > That's not quite accurate. Two entries with the same atom:id may appea= r > within the same atom:feed only if they have different atom:updated > elements. The spec is silent on whether or not two entries existing in > *separate documents* may have identical atom:id and atom:updated values. >=20 They're ids, not guids. Certainly I would expect that there'll be some=20 accidental conflicts. For instance one site might number its posts=20 post1, post2, post3,...; and a different, unrelated site might do the sam= e. --=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 Thu Jun 08 09:18:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKPO-0000oL-Lc for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:18:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKPL-0003s9-7z for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:18: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 k58D7Uxt017028; Thu, 8 Jun 2006 06:07: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 k58D7UG6017027; Thu, 8 Jun 2006 06:07: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58D7T4d017003 for ; Thu, 8 Jun 2006 06:07:29 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 18779 invoked by uid 17064); 8 Jun 2006 13:07:28 -0000 Received: from unknown (HELO [10.20.30.238]) ([195.101.242.1]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Jun 2006 13:07:28 -0000 In-Reply-To: <44881B9D.8000400@metalab.unc.edu> References: <44870CF4.80509@gmail.com> <44871DBB.5050503@gmail.com> <44881B9D.8000400@metalab.unc.edu> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: James M Snell , atom-syntax@imc.org Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: when should two entries have the same id? Date: Thu, 8 Jun 2006 15:07:27 +0200 To: Elliotte Harold 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: 52e1467c2184c31006318542db5614d5 On 8 Jun 2006, at 14:44, Elliotte Harold wrote: > > James M Snell wrote: > >> That's not quite accurate. Two entries with the same atom:id may >> appear >> within the same atom:feed only if they have different atom:updated >> elements. The spec is silent on whether or not two entries >> existing in >> *separate documents* may have identical atom:id and atom:updated >> values. > > They're ids, not guids. Certainly I would expect that there'll be > some accidental conflicts. For instance one site might number its > posts post1, post2, post3,...; and a different, unrelated site > might do the same. No, they are guids. The datatype for an id is a IRI, which is a generalisaiton of URI. IRIs are constructed in such a way that it should be easy to construct universally unique ones without ever having name clashes. If name clashes there are, this will either be due to incompetence or to malevolence. Henry > -- > Elliotte 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=0596527500/ref=nosim/ > cafeaulaitA/ From owner-atom-syntax@mail.imc.org Thu Jun 08 09:33:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoKdl-0001dc-8l for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:33:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoKdi-0004wx-Sx for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 09:33: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 k58DF1B0021224; Thu, 8 Jun 2006 06: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 k58DF1kC021222; Thu, 8 Jun 2006 06: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 mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k58DEv6m021129 for ; Thu, 8 Jun 2006 06:14:59 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Jun 2006 13:14:51 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 08 Jun 2006 15:14:51 +0200 X-Authenticated: #1915285 Message-ID: <448822CD.2090401@gmx.de> Date: Thu, 08 Jun 2006 15:14:53 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Elliotte Harold CC: James M Snell , atom-syntax@imc.org Subject: Re: when should two entries have the same id? References: <44870CF4.80509@gmail.com> <44871DBB.5050503@gmail.com> <44881B9D.8000400@metalab.unc.edu> In-Reply-To: <44881B9D.8000400@metalab.unc.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Elliotte Harold schrieb: > > James M Snell wrote: > >> That's not quite accurate. Two entries with the same atom:id may appear >> within the same atom:feed only if they have different atom:updated >> elements. The spec is silent on whether or not two entries existing in >> *separate documents* may have identical atom:id and atom:updated values. >> > > They're ids, not guids. Certainly I would expect that there'll be some > accidental conflicts. For instance one site might number its posts > post1, post2, post3,...; and a different, unrelated site might do the same. Sorry? That would be a bug. They *are* supposed to be globally unique. See: . Best regards, Julian From owner-atom-syntax@mail.imc.org Thu Jun 08 10:54:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLtx-0007XV-H0 for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 10:54:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLtw-0003v3-44 for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 10:54: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 k58EfMI6064054; Thu, 8 Jun 2006 07: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 k58EfMhc064053; Thu, 8 Jun 2006 07: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58EfKIV064036 for ; Thu, 8 Jun 2006 07:41:21 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so326002wxc for ; Thu, 08 Jun 2006 07: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:in-reply-to:mime-version:content-type:references; b=hrtpBlIKA4vPjKFxEqJBcWGfeFDYwaH4FLjOU7uLlmq7lDX/02EZvpAiXswUFRvygNONOWNjxCdW+uXduwMdM5rESrMmiCM8mqHNqvjKHcRHva9VTsNdzgjoq71rf0vquYMJFYbtDe4aGVXkmyv8YtZVauAIJ0hAoz8C4rh6CJc= Received: by 10.70.8.2 with SMTP id 2mr2149558wxh; Thu, 08 Jun 2006 07:41:20 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Thu, 8 Jun 2006 07:41:20 -0700 (PDT) Message-ID: Date: Thu, 8 Jun 2006 08:41:20 -0600 From: "M. David Peterson" To: atom-syntax Subject: Re: Copyright, licensing, and feeds In-Reply-To: <20060608104049.GQ6092@klangraum> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21022_26284034.1149777680490" References: <44873456.6080001@aol.net> <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> <20060608104049.GQ6092@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ------=_Part_21022_26284034.1149777680490 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Very well stated, Aristotle! On 6/8/06, A. Pagaltzis wrote: > > > * Karl Dubost [2006-06-08 04:30]: > > Which will not remove abuse :) > > Well, will anything short of not publishing your content? > > I think the point of such an effort is to make life easier for > third parties who want to respect your wishes, not to make it > harder for third parties who are intent on violating them. > > Regards, > -- > Aristotle Pagaltzis // > > -- M. David Peterson http://www.xsltblog.com/ ------=_Part_21022_26284034.1149777680490 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Very well stated, Aristotle!

On 6/8/06, A. Pagaltzis <pagaltzis@gmx.de> wrote:

* Karl Dubost <karl@w3.org> [2006-06-08 04:30]:
> Which will not remove abuse :)

Well, will anything short of not publishing your content?

I think the point of such an effort is to make life easier for
third parties who want to respect your wishes, not to make it
harder for third parties who are intent on violating them.

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




--
<M:D/>

M. David Peterson
http://www.xsltblog.com/ ------=_Part_21022_26284034.1149777680490-- From owner-atom-syntax@mail.imc.org Thu Jun 08 14:54:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoPdx-0008CA-L6 for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 14:54:09 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoPdv-0001qd-8y for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 14:54: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 k58Ie4Nc005371; Thu, 8 Jun 2006 11:40: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 k58Ie4RU005370; Thu, 8 Jun 2006 11:40:04 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58Ie1Ox005288 for ; Thu, 8 Jun 2006 11:40:04 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (snv-global1.corp.yahoo.com [216.145.49.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E680DA3202 for ; Thu, 8 Jun 2006 14:39:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <4C24B905-57CE-46DF-B120-48A890A7F6C2@mnot.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B47966C-585C-4F97-AFFF-ECF3B748886A@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: RFC3229 w/ feeds [was: Paging, Feed History, etc.] Date: Thu, 8 Jun 2006 11:40:07 -0700 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: 2409bba43e9c8d580670fda8b695204a On 2006/06/07, at 11:40 PM, Thomas Broyer wrote: > > My main concern is that RFC3229 w/ feeds is being deployed more and > more widely and is still not even an I-D (or I missed something). I have that concern as well. I am also concerned that RFC3229 is an extension of HTTP, but some implementers are acting as if it chages the semantics of already- defined parts of HTTP. For example, a delta must be a subset of the current representation that is returned to a GET; if you GET the feed, it has to return all of the entries that you could retrieve by using delta. I have a feeling that many people are treating it as a dynamic query mechanism that's capable of retrieving any entry that's ever been in the feed, while still only returning the last n entries to a plain GET. If so, they're breaking HTTP, breaking delta, and should use something else. Is this the case, or am I (happily) mistaken? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Jun 08 17:03:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRej-0002tG-KL for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 17:03:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoRei-0004hW-0X for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 17:03: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 k58KjH7L077696; Thu, 8 Jun 2006 13:45: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 k58KjHJB077695; Thu, 8 Jun 2006 13:45: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-dav4.bay109.hotmail.com [64.4.19.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58KjGIZ077651 for ; Thu, 8 Jun 2006 13:45:16 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Jun 2006 13:45:11 -0700 Message-ID: Received: from 85.210.173.8 by BAY109-DAV4.phx.gbl with DAV; Thu, 08 Jun 2006 20:45:10 +0000 X-Originating-IP: [85.210.173.8] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom-Syntax" References: Subject: Re: Paging, Feed History, etc. Date: Thu, 8 Jun 2006 21:45:09 +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: 08 Jun 2006 20:45:11.0238 (UTC) FILETIME=[6F8BF660:01C68B3C] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Thomas Broyer wrote: > Could you read my recent mails in this thread and confirm that it's the > case? I'm sorry, but I can no longer participate in this discussion. I hope everything works out ok. Regards James From owner-atom-syntax@mail.imc.org Thu Jun 08 18:47:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTHT-0004ru-My for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 18:47:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTHS-00074S-BY for atompub-archive@lists.ietf.org; Thu, 08 Jun 2006 18:47: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 k58MXq3k040983; Thu, 8 Jun 2006 15:33: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 k58MXqXF040982; Thu, 8 Jun 2006 15:33: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 mcom.com (r2d2.aoltw.net [64.236.137.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k58MXqkl040916 for ; Thu, 8 Jun 2006 15:33:52 -0700 (MST) (envelope-from jpanzer@aol.net) Received: from JOHNPANZER.ad.aol.aoltw.net (h-10-169-155-222.nscp.aoltw.net [10.169.155.222]) by mcom.com (8.10.0/8.10.0) with ESMTP id k58MXcg02562; Thu, 8 Jun 2006 15:33:39 -0700 (PDT) Date: Thu, 8 Jun 2006 15:33:39 -0700 From: "John Panzer" Subject: Re: Copyright, licensing, and feeds To: "A. Pagaltzis" cc: atom-syntax In-Reply-To: <20060608104049.GQ6092@klangraum> Message-ID: <4488A5C2.4020705@aol.net> References: <44873456.6080001@aol.net> <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> <20060608104049.GQ6092@klangraum> X-Mailer: AOL Communicator (20030919.3 Win) Organization: AOL MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.3 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a A. Pagaltzis wrote on 6/8/2006, 3:40 AM: > > * Karl Dubost [2006-06-08 04:30]: > > Which will not remove abuse :) > > Well, will anything short of not publishing your content? > > I think the point of such an effort is to make life easier for > third parties who want to respect your wishes, not to make it > harder for third parties who are intent on violating them. Aristotle -- Absolutely right. I see an opportunity to make life easier for people who want to play by the rules, and I think there are some simple technical things we can promote to help do that. Attempting to deal with people who choose not to play by the rules is a different, much larger, much less tractable problem. I'm not trying to tackle that one, though feed licenses might be a building block. -- John Panzer System Architect http://abstractioneer.org From owner-atom-syntax@mail.imc.org Fri Jun 09 01:29:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoZYi-0008KM-AO for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 01:29:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoZQF-0005cu-8k for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 01:20: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 k5956BZm074393; Thu, 8 Jun 2006 22:06: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 k5956BPS074392; Thu, 8 Jun 2006 22:06: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 homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5956Apt074370 for ; Thu, 8 Jun 2006 22:06:11 -0700 (MST) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 91C9C4F0C9; Fri, 9 Jun 2006 01:06:09 -0400 (EDT) In-Reply-To: <20060608104049.GQ6092@klangraum> References: <44873456.6080001@aol.net> <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> <20060608104049.GQ6092@klangraum> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <98D7020A-E9CB-430C-B8D8-5D213D81E245@w3.org> Cc: atom-syntax From: Karl Dubost Subject: Re: Copyright, licensing, and feeds Date: Fri, 9 Jun 2006 14:06:05 +0900 To: "A.Pagaltzis" X-Mailer: Apple Mail (2.750) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5956Bpt074384 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 k5956BZm074393 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Le 06-06-08 =E0 19:40, A. Pagaltzis a =E9crit : > * Karl Dubost [2006-06-08 04:30]: >> Which will not remove abuse :) > > Well, will anything short of not publishing your content? > > I think the point of such an effort is to make life easier for > third parties who want to respect your wishes, not to make it > harder for third parties who are intent on violating them. Agreed. And it's why my message (which was really badly written - =20 fatigue) was separating the issue. It's a very important issue, and I =20 really believe a clear spec, framework or let's say technical =20 solution would improve the field. Definitely. I would love to see that happening as soon as possible. It's a mix =20 between social and technical issues. Finding interoperable solutions =20 would help to soften the social issues and frustrations. so again +1 a thousand of times ;) --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Fri Jun 09 02:40:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foafv-0001Gq-2H for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 02:40:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foafs-0007je-HR for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 02:40: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 k596NPG9021254; Thu, 8 Jun 2006 23:23: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 k596NPkW021253; Thu, 8 Jun 2006 23:23: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 homer.w3.org (homer.w3.org [128.30.52.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k596NOT5021244 for ; Thu, 8 Jun 2006 23:23:24 -0700 (MST) (envelope-from karl@w3.org) Received: from [127.0.0.1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6B5E04EF4B for ; Fri, 9 Jun 2006 02:23:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4487AB58.8060702@aol.net> References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> <4487AB58.8060702@aol.net> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <41CAD5DF-9727-4242-90B2-323CAD3A9EB3@w3.org> From: Karl Dubost Subject: Re: Copyright, licensing, and feeds Date: Fri, 9 Jun 2006 15:23:19 +0900 To: atom-syntax Syntax X-Mailer: Apple Mail (2.750) X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k596NOT5021247 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 k596NPG9021254 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Reading the example from http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ [[[ 3. The 'license' link relation An Atom link element with a 'rel' attribute value of 'license' is used to associate a copyright license with an Atom Feed or Entry. Atom entry, feed and source elements MAY each contain any number of license links but MUST NOT contain more than one with the same href value. The IRI specified by the link's 'href' attribute SHOULD be dereferenceable to return a machine or human-readable representation of the license. Implementors should note that, unlike the Atom rights element, which specifies a human-readable statement of the rights held over a entry or feed, license links apply only to the informational content of =20 the containing element. That is, the presence of a license link =20 relation within an Atom feed element does not extend a license over the various contained entry elements. Likewise, the presence of a license link within an Atom source element does not extend a license over the informational content of the containing entry. ]]] -- snell-atompub-feed-license-06.txt http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/=20 #page-3 Thu, 13 Apr 2006 19:27:54 GMT # Some questions about specific use cases 1. Feed composed with multiple sources with different licenses. When a feed aggregator creates a feed from different sources =20 (feeds) with different licenses, what should be the license of the =20 resulting feed? feed (license ???) entry (license A) from feed X entry (license B) from feed Y entry (license B) from feed Y entry (license A) from feed X entry (license C) from feed Z =85 Defining the semantics of the attribute/element is cool, but on the =20 side in the implementation it's not clear what should be by consuming =20 products. As I said in a previous message, it's a tough problem. 2. Should there be a best practices document to invite tools =20 developers to understand and implement licenses mechanism? (As I =20 understand it's not the purpose of this draft). --=20 Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From owner-atom-syntax@mail.imc.org Fri Jun 09 03:52:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fobmk-0006KH-Mf for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 03:52:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fobmf-0006ld-9a for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 03: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 k597fGu5066455; Fri, 9 Jun 2006 00:41:16 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k597fFMu066450; Fri, 9 Jun 2006 00:41:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k597fDxH066149 for ; Fri, 9 Jun 2006 00:41:14 -0700 (MST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.45.41] (210.193.203.50) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 9 Jun 2006 17:40:48 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 09 Jun 2006 17:40:14 +1000 Subject: Re: Copyright, licensing, and feeds From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41CAD5DF-9727-4242-90B2-323CAD3A9EB3@w3.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 9/6/06 4:23 PM, "Karl Dubost" wrote: > 1. Feed composed with multiple sources with different licenses. > When a feed aggregator creates a feed from different sources > (feeds) with different licenses, what should be the license of the > resulting feed? > > feed (license ???) > entry (license A) from feed X > entry (license B) from feed Y > entry (license B) from feed Y > entry (license A) from feed X > entry (license C) from feed Z either no license element at the the feed level (since every entry has their own license), or maybe a license that refers to the collection (eg. you could expose a license for your Top 10 List without necessarily claiming any license for the 10 items in the list). Interesting to think what different licenses might entail though: you could deny breaking up your feed by no-deriv (which would only work to the limit of fair use, ie. I could still cherry pick the occasional entry, although the entry's license might still stop me). If someone were to publish their Top 10 List, you could disallow someone re-aggregating it as a Top 5 List, say. e. From owner-atom-syntax@mail.imc.org Fri Jun 09 03:52:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FobnZ-0006vJ-QL for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 03:52:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FobnX-0006oj-8k for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 03: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 k597aj2p063822; Fri, 9 Jun 2006 00:36: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 k597ajml063821; Fri, 9 Jun 2006 00:36: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 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 k597aiuH063806 for ; Fri, 9 Jun 2006 00:36:44 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id k1so607206nzf for ; Fri, 09 Jun 2006 00:36:43 -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=ttiZsoELJvTTmWg3Mg+EvwCuDVtfSJEAZ1/eAzdiUe3yIxtQwgMGO2vCLmk5hJVvWDerOx2FeoDbj48Y6yWabvMtqquJB963006dL2B3LVjOkY/ST6HLP+CLk5hU6sToKbM44V38W60Nl+QSKaSVMOsi09XV72J7UAOFby5kcm4= Received: by 10.65.51.13 with SMTP id d13mr2767570qbk; Fri, 09 Jun 2006 00:36:43 -0700 (PDT) Received: by 10.65.230.7 with HTTP; Fri, 9 Jun 2006 00:36:43 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 09:36:43 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.] In-Reply-To: <8B47966C-585C-4F97-AFFF-ECF3B748886A@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Disposition: inline References: <8B47966C-585C-4F97-AFFF-ECF3B748886A@mnot.net> X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k597aiuH063815 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 k597aj2p063822 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 2006/6/8, Mark Nottingham : > > > On 2006/06/07, at 11:40 PM, Thomas Broyer wrote: > > > > My main concern is that RFC3229 w/ feeds is being deployed more and > > more widely and is still not even an I-D (or I missed something). > > I have that concern as well. > > I am also concerned that RFC3229 is an extension of HTTP, but some > implementers are acting as if it chages the semantics of already- > defined parts of HTTP. For example, a delta must be a subset of the > current representation that is returned to a GET; if you GET the > feed, it has to return all of the entries that you could retrieve by > using delta. > > I have a feeling that many people are treating it as a dynamic query > mechanism that's capable of retrieving any entry that's ever been in > the feed, while still only returning the last n entries to a plain > GET. If so, they're breaking HTTP, breaking delta, and should use > something else. > > Is this the case, or am I (happily) mistaken? RFC3229 adds a new notion, the one of "instance" and defines that the ETag is computed based on the instance, not the entity (difference between instance and entity being the instance-manipulation =E2=80=93delt= a, diff, or identity, which is the default in bare HTTP=E2=80=93 having been applied). Now, let's define the "feed resource" as the complete set of entries, and its default representation as one which shows only the most recent ones (using a yet-to-be-defined conneg algorithm =E2=80=93e.g. using an Accept-Features feature=E2=80=93, it could be possible to retrieve the wh= ole set of entries). If I'm wront in the above statement (conneg could lead to a "latest entries only" or "full", without abusing HTTP), then don't even read further, this would mean that RFC3229 w/ feed changes the semantics of existing parts of HTTP. Let's take the steps in section 4 of RFC3229: > Conceptually, the various transformations are applied in the > following sequence: > > 1. Upon receiving a GET request, the server uses the URI in the > request to identify the requested resource. > > 2. Optionally, it uses information from the request (and perhaps > additional information) to select a variant of that resource. The server might here use the presence of the A-IM request header to select the "full" representation of the feed rather than the "latest entries only" representations. > 3. At this point, the server may apply a non-identity content- > coding to the instance, or one might have been inherent in its > generation. This also results in a Content-Encoding header. > > 4. The result of the first three steps, at the time when the > request is processed, is an instance. The instance includes a > body (possibly empty) and possibly some instance headers. The > entity tag, if any, is assigned at this point. That is, an > entity tag is associated with an instance, NOT an entity. If I read RFC2616 correctly, nothing prevents the "latest entries only" and "full" representations (or any representation of the same resource) to share the same entity-tag, i.e. nothing prevents a server to assign an entity-tag to a resource rather than its representations. Maybe servers should use a weak etag in this case? But RFC2616 says in section 13.3.3 that "Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request." > 5. The server may then apply an instance-manipulation. For > example, if the request included a Range header, the server may > optionally produce a range response, consisting of the original > set of headers, a Content-Range header, and the appropriate > range(s) from the (possibly encoded) body. Delta encodings are > instance-manipulations, and are computed at this stage. Given the ETag of the previous "version" of the feed, the server can compute the delta and make it a feed of added and updated entries. > 6. The result of the fifth step becomes the entity, consisting of > entity headers and an entity body. > > 7. The server may then apply a non-identity transfer-coding; on- > the-fly compression could be done in this step. If so, a > Transfer-Encoding header is added to the message. > > 8. The results of the seventh step is the message, consisting of a > message body (the transfer-coded version of the entity body), > the entity headers, and additional response and general > headers. --=20 Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Jun 09 04:26:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocJh-0008IU-FB for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 04:26:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FocJf-0002HP-2z for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 04:26: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 k598EfUq085213; Fri, 9 Jun 2006 01: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 k598Ef1B085211; Fri, 9 Jun 2006 01: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 mail.gmx.net (mail.gmx.de [213.165.64.20]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k598Edn2085152 for ; Fri, 9 Jun 2006 01:14:40 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 09 Jun 2006 08:14:31 -0000 Received: from p508FB609.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.182.9] by mail.gmx.net (mp028) with SMTP; 09 Jun 2006 10:14:31 +0200 X-Authenticated: #1915285 Message-ID: <44892DE7.3050401@gmx.de> Date: Fri, 09 Jun 2006 10:14:31 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Thomas Broyer CC: Atom-Syntax Subject: Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.] References: <8B47966C-585C-4F97-AFFF-ECF3B748886A@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Thomas Broyer schrieb: > If I read RFC2616 correctly, nothing prevents the "latest entries > only" and "full" representations (or any representation of the same > resource) to share the same entity-tag, i.e. nothing prevents a server > to assign an entity-tag to a resource rather than its representations. > Maybe servers should use a weak etag in this case? But RFC2616 says in > section 13.3.3 that "Clients MAY issue simple (non-subrange) GET > requests with either weak validators or strong validators. Clients > MUST NOT use weak validators in other forms of request." > ... I think this is a misunderstanding of how HTTP/1.1 is supposed to work. If a server returns the same ETag for different entities returned for the same URL, this will cause breakage of caches. You may want to re-read Section 13.6 of RFC2616 (). Best regards, Julian From owner-atom-syntax@mail.imc.org Fri Jun 09 05:21:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodBQ-0006je-T6 for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:21:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodBP-0000UE-BK for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:21: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 k5993bLL011229; Fri, 9 Jun 2006 02:03: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 k5993b3F011228; Fri, 9 Jun 2006 02:03: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 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 k5993ajJ011221 for ; Fri, 9 Jun 2006 02:03:37 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so480849wxc for ; Fri, 09 Jun 2006 02:03: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:references; b=c6ep/q7Mmp1p6psd43lUasGjnAc+h/1z25cjfSRGoYLgcP3t7iRbpjQEtyZfMc4WuocET8mFYHAWR25r56doJnLYXXhYdMDJvmKF3ve7CLNuGAUlkkyLHrEwNVqb+AfOLRKh+YXDUBTCvvbi+JwAR3DVqQndxfmC4OCpv4hcdY8= Received: by 10.70.44.16 with SMTP id r16mr3214890wxr; Fri, 09 Jun 2006 02:03:36 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Fri, 9 Jun 2006 02:03:36 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 03:03:36 -0600 From: "M. David Peterson" To: "Karl Dubost" Subject: Re: Copyright, licensing, and feeds Cc: "A.Pagaltzis" , atom-syntax In-Reply-To: <98D7020A-E9CB-430C-B8D8-5D213D81E245@w3.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_34921_9454881.1149843816289" References: <44873456.6080001@aol.net> <622765B4-13F5-44DD-994A-6FC9264A4393@w3.org> <20060608104049.GQ6092@klangraum> <98D7020A-E9CB-430C-B8D8-5D213D81E245@w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 ------=_Part_34921_9454881.1149843816289 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Rm9yIHRoZSByZWNvcmQsIEthcmwsIGV2ZW4gdGhvdWdoIHlvdSBmZWx0IGl0IHdhcyBwb29ybHkg d3JpdHRlbiwgYXQgYQpwZXJzb25hbCBsZXZlbCBJIGRpZG4ndCB3YWxrIGF3YXkgd2l0aCB0aGUg ZmVlbGluZyB0aGF0IHlvdXIgcG9pbnQgd2FzCmFueXRoaW5nIG90aGVyIHRoYW4gYSBzaW1wbGUg Im5vIG1hdHRlciB3aGF0IHdlIGRvLCB3ZSdyZSBub3QgZ29pbmcgdG8ga2VlcAp0aGUgd29ybGQg ZnJvbSBhYnVzaW5nIGNvcHlyaWdodHMsIGJ1dCB0aGVyZSdzIHBsZW50eSBvZiB0aGluZ3Mgd2Ug Y2FuIGRvLApzbyBsZXRzIGRvIHRoZW0uIgoKTXkgYWdyZWVtZW50IHdpdGggQXJpc3RvdGxlJ3Mg cG9pbnQsIGFuZCBmcm9tIHdoYXQgSSBjb3VsZCB0ZWxsICh0aG91Z2gKb2J2aW91c2x5IEkgY2Fu J3Qgc3BlYWsgZm9yIEFyaXN0b3RsZSkgQXJpc3RvdGxlJ3MgcmVhc29uaW5nIGZvciB0aGUKZm9s bG93LXVwIHdhcyB0byBoZWxwIGNsYXJpZnkgdGhlIGRpcmVjdGlvbiBhbmQgcHVycG9zZSBvZiBo b3cgdGhpcyB3b3JrCnNob3VsZCBiZSB2aWV3ZWQgYW5kIHdoZXJlIHRoZSBmb2N1cyBzaG91bGQg YmUgcGxhY2VkLiAgQnV0IGVpdGhlciB3YXksIEkKMTAwJSBhZ3JlZSB3aXRoIGhpcyBzdGF0ZW1l bnQgKGFzIGRvIHdlIGFsbCEgOikgYW5kIHdvbmRlciBpZiB0aGlzIHNob3VsZCBiZQpjbGVhcmx5 IG1hcmtlZCBhbmQgbm90ZWQgaW4gYSBjZW50cmFsaXplZCB3aWtpIHNvbWV3aGVyZSAoQ3JlYXRp dmUgQ29tbW9ucywKVzNDKSBhcyB0aGUgcHJpbWFyeSBmb2N1cyBvZiB0aGUgd29yayBkb25lIGlz IHRoaXMgYXJlYT8gIEkgd291bGQgaGFwcGlseQpob3N0IG9uZSwgYnV0IGhvc3RpbmcgYSB3aWtp IGlzbid0IHRoZSBwcm9ibGVtLiAgRmluZGluZyB0aGUgcmlnaHQgcGxhY2UgdG8KaG9zdCBpdCBp cy4KCkFueSBzdWdnZXN0aW9ucz8KCk9uIDYvOC8wNiwgS2FybCBEdWJvc3QgPGthcmxAdzMub3Jn PiB3cm90ZToKPgo+Cj4KPiBMZSAwNi0wNi0wOCDDoCAxOTo0MCwgQS4gUGFnYWx0emlzIGEgw6lj cml0IDoKPiA+ICogS2FybCBEdWJvc3QgPGthcmxAdzMub3JnPiBbMjAwNi0wNi0wOCAwNDozMF06 Cj4gPj4gV2hpY2ggd2lsbCBub3QgcmVtb3ZlIGFidXNlIDopCj4gPgo+ID4gV2VsbCwgd2lsbCBh bnl0aGluZyBzaG9ydCBvZiBub3QgcHVibGlzaGluZyB5b3VyIGNvbnRlbnQ/Cj4gPgo+ID4gSSB0 aGluayB0aGUgcG9pbnQgb2Ygc3VjaCBhbiBlZmZvcnQgaXMgdG8gbWFrZSBsaWZlIGVhc2llciBm b3IKPiA+IHRoaXJkIHBhcnRpZXMgd2hvIHdhbnQgdG8gcmVzcGVjdCB5b3VyIHdpc2hlcywgbm90 IHRvIG1ha2UgaXQKPiA+IGhhcmRlciBmb3IgdGhpcmQgcGFydGllcyB3aG8gYXJlIGludGVudCBv biB2aW9sYXRpbmcgdGhlbS4KPgo+IEFncmVlZC4gQW5kIGl0J3Mgd2h5IG15IG1lc3NhZ2UgKHdo aWNoIHdhcyByZWFsbHkgYmFkbHkgd3JpdHRlbiAtCj4gZmF0aWd1ZSkgd2FzIHNlcGFyYXRpbmcg dGhlIGlzc3VlLiBJdCdzIGEgdmVyeSBpbXBvcnRhbnQgaXNzdWUsIGFuZCBJCj4gcmVhbGx5IGJl bGlldmUgYSBjbGVhciBzcGVjLCBmcmFtZXdvcmsgb3IgbGV0J3Mgc2F5IHRlY2huaWNhbAo+IHNv bHV0aW9uIHdvdWxkIGltcHJvdmUgdGhlIGZpZWxkLiBEZWZpbml0ZWx5Lgo+Cj4gSSB3b3VsZCBs b3ZlIHRvIHNlZSB0aGF0IGhhcHBlbmluZyBhcyBzb29uIGFzIHBvc3NpYmxlLiBJdCdzIGEgbWl4 Cj4gYmV0d2VlbiBzb2NpYWwgYW5kIHRlY2huaWNhbCBpc3N1ZXMuIEZpbmRpbmcgaW50ZXJvcGVy YWJsZSBzb2x1dGlvbnMKPiB3b3VsZCBoZWxwIHRvIHNvZnRlbiB0aGUgc29jaWFsIGlzc3VlcyBh bmQgZnJ1c3RyYXRpb25zLgo+Cj4gc28gYWdhaW4gKzEgYSB0aG91c2FuZCBvZiB0aW1lcyA7KQo+ Cj4KPgo+Cj4gLS0KPiBLYXJsIER1Ym9zdCAtIGh0dHA6Ly93d3cudzMub3JnL1Blb3BsZS9rYXJs Lwo+IFczQyBDb25mb3JtYW5jZSBNYW5hZ2VyLCBRQSBBY3Rpdml0eSBMZWFkCj4gICAgUUEgV2Vi bG9nIC0gaHR0cDovL3d3dy53My5vcmcvUUEvCj4gICAgICAgKioqIEJlIFN0cmljdCBUbyBCZSBD b29sICoqKgo+Cj4KPgo+Cj4KPgoKCi0tIAo8TTpELz4KCk0uIERhdmlkIFBldGVyc29uCmh0dHA6 Ly93d3cueHNsdGJsb2cuY29tLwo= ------=_Part_34921_9454881.1149843816289 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Rm9yIHRoZSByZWNvcmQsIEthcmwsIGV2ZW4gdGhvdWdoIHlvdSBmZWx0IGl0IHdhcyBwb29ybHkg d3JpdHRlbiwgYXQgYSBwZXJzb25hbCBsZXZlbCBJIGRpZG4ndCB3YWxrIGF3YXkgd2l0aCB0aGUg ZmVlbGluZyB0aGF0IHlvdXIgcG9pbnQgd2FzIGFueXRoaW5nIG90aGVyIHRoYW4gYSBzaW1wbGUg JnF1b3Q7bm8gbWF0dGVyIHdoYXQgd2UgZG8sIHdlJ3JlIG5vdCBnb2luZyB0byBrZWVwIHRoZSB3 b3JsZCBmcm9tIGFidXNpbmcgY29weXJpZ2h0cywgYnV0IHRoZXJlJ3MgcGxlbnR5IG9mIHRoaW5n cyB3ZSBjYW4gZG8sIHNvIGxldHMgZG8gdGhlbS4mcXVvdDsKPGJyPjxicj5NeSBhZ3JlZW1lbnQg d2l0aCBBcmlzdG90bGUncyBwb2ludCwgYW5kIGZyb20gd2hhdCBJIGNvdWxkIHRlbGwgKHRob3Vn aCBvYnZpb3VzbHkgSSBjYW4ndCBzcGVhayBmb3IgQXJpc3RvdGxlKSBBcmlzdG90bGUncyByZWFz b25pbmcgZm9yIHRoZSBmb2xsb3ctdXAgd2FzIHRvIGhlbHAgY2xhcmlmeSB0aGUgZGlyZWN0aW9u IGFuZCBwdXJwb3NlIG9mIGhvdyB0aGlzIHdvcmsgc2hvdWxkIGJlIHZpZXdlZCBhbmQgd2hlcmUg dGhlIGZvY3VzIHNob3VsZCBiZSBwbGFjZWQuJm5ic3A7IEJ1dCBlaXRoZXIgd2F5LCBJIDEwMCUg YWdyZWUgd2l0aCBoaXMgc3RhdGVtZW50IChhcyBkbyB3ZSBhbGwhIDopIGFuZCB3b25kZXIgaWYg dGhpcyBzaG91bGQgYmUgY2xlYXJseSBtYXJrZWQgYW5kIG5vdGVkIGluIGEgY2VudHJhbGl6ZWQg d2lraSBzb21ld2hlcmUgKENyZWF0aXZlIENvbW1vbnMsIFczQykgYXMgdGhlIHByaW1hcnkgZm9j dXMgb2YgdGhlIHdvcmsgZG9uZSBpcyB0aGlzIGFyZWE/Jm5ic3A7IEkgd291bGQgaGFwcGlseSBo b3N0IG9uZSwgYnV0IGhvc3RpbmcgYSB3aWtpIGlzbid0IHRoZSBwcm9ibGVtLiZuYnNwOyBGaW5k aW5nIHRoZSByaWdodCBwbGFjZSB0byBob3N0IGl0IGlzLgo8YnI+PGJyPkFueSBzdWdnZXN0aW9u cz88YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA2LzgvMDYsIDxiIGNs YXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5LYXJsIER1Ym9zdDwvYj4gJmx0OzxhIGhyZWY9Im1haWx0 bzprYXJsQHczLm9yZyI+a2FybEB3My5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2Io MjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDog MWV4OyI+Cjxicj48YnI+TGUgMDYtMDYtMDggw6AgMTk6NDAsIEEuIFBhZ2FsdHppcyBhIMOpY3Jp dCA6PGJyPiZndDsgKiBLYXJsIER1Ym9zdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcmxAdzMub3Jn Ij5rYXJsQHczLm9yZzwvYT4mZ3Q7IFsyMDA2LTA2LTA4IDA0OjMwXTo8YnI+Jmd0OyZndDsgV2hp Y2ggd2lsbCBub3QgcmVtb3ZlIGFidXNlIDopPGJyPiZndDs8YnI+Jmd0OyBXZWxsLCB3aWxsIGFu eXRoaW5nIHNob3J0IG9mIG5vdCBwdWJsaXNoaW5nIHlvdXIgY29udGVudD8KPGJyPiZndDs8YnI+ Jmd0OyBJIHRoaW5rIHRoZSBwb2ludCBvZiBzdWNoIGFuIGVmZm9ydCBpcyB0byBtYWtlIGxpZmUg ZWFzaWVyIGZvcjxicj4mZ3Q7IHRoaXJkIHBhcnRpZXMgd2hvIHdhbnQgdG8gcmVzcGVjdCB5b3Vy IHdpc2hlcywgbm90IHRvIG1ha2UgaXQ8YnI+Jmd0OyBoYXJkZXIgZm9yIHRoaXJkIHBhcnRpZXMg d2hvIGFyZSBpbnRlbnQgb24gdmlvbGF0aW5nIHRoZW0uPGJyPjxicj4KQWdyZWVkLiBBbmQgaXQn cyB3aHkgbXkgbWVzc2FnZSAod2hpY2ggd2FzIHJlYWxseSBiYWRseSB3cml0dGVuIC08YnI+ZmF0 aWd1ZSkgd2FzIHNlcGFyYXRpbmcgdGhlIGlzc3VlLiBJdCdzIGEgdmVyeSBpbXBvcnRhbnQgaXNz dWUsIGFuZCBJPGJyPnJlYWxseSBiZWxpZXZlIGEgY2xlYXIgc3BlYywgZnJhbWV3b3JrIG9yIGxl dCdzIHNheSB0ZWNobmljYWw8YnI+c29sdXRpb24gd291bGQgaW1wcm92ZSB0aGUgZmllbGQuIERl ZmluaXRlbHkuCjxicj48YnI+SSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGF0IGhhcHBlbmluZyBhcyBz b29uIGFzIHBvc3NpYmxlLiBJdCdzIGEgbWl4PGJyPmJldHdlZW4gc29jaWFsIGFuZCB0ZWNobmlj YWwgaXNzdWVzLiBGaW5kaW5nIGludGVyb3BlcmFibGUgc29sdXRpb25zPGJyPndvdWxkIGhlbHAg dG8gc29mdGVuIHRoZSBzb2NpYWwgaXNzdWVzIGFuZCBmcnVzdHJhdGlvbnMuPGJyPjxicj5zbyBh Z2FpbiArMSBhIHRob3VzYW5kIG9mIHRpbWVzIDspCjxicj48YnI+PGJyPjxicj48YnI+LS08YnI+ S2FybCBEdWJvc3QgLSA8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9QZW9wbGUva2FybC8iPmh0 dHA6Ly93d3cudzMub3JnL1Blb3BsZS9rYXJsLzwvYT48YnI+VzNDIENvbmZvcm1hbmNlIE1hbmFn ZXIsIFFBIEFjdGl2aXR5IExlYWQ8YnI+Jm5ic3A7Jm5ic3A7IFFBIFdlYmxvZyAtIDxhIGhyZWY9 Imh0dHA6Ly93d3cudzMub3JnL1FBLyI+aHR0cDovL3d3dy53My5vcmcvUUEvCjwvYT48YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KioqIEJlIFN0cmljdCBUbyBCZSBDb29s ICoqKjxicj48YnI+PGJyPjxicj48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNs ZWFyPSJhbGwiPjxicj4tLSA8YnI+Jmx0O006RC8mZ3Q7PGJyPjxicj5NLiBEYXZpZCBQZXRlcnNv bjxicj48YSBocmVmPSJodHRwOi8vd3d3LnhzbHRibG9nLmNvbS8iPmh0dHA6Ly93d3cueHNsdGJs b2cuY29tLzwvYT4K ------=_Part_34921_9454881.1149843816289-- From owner-atom-syntax@mail.imc.org Fri Jun 09 05:38:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodRi-0000zY-PU for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:38:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodRg-00038q-D1 for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:38: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 k599M5UZ020871; Fri, 9 Jun 2006 02:22: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 k599M5Y5020869; Fri, 9 Jun 2006 02:22: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.197]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k599M48b020853 for ; Fri, 9 Jun 2006 02:22:04 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id k1so623131nzf for ; Fri, 09 Jun 2006 02:22: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=MIN/8LV7nf4RRocOFHni8gcr1oB4sDkwMOyz2sY8VCJi3x3CQDN35O3zDtboYvqLjypAv5REs6z6Nf+m5oq5/pbS8+lLkCo3k+Hgu5KRxe5Lo00pC9geEk4/YpvaSf5c1iwSj03MHfGWcOTlcqx+q7p9GvOqHbo+IgLrqoxPJEY= Received: by 10.64.178.2 with SMTP id a2mr2839197qbf; Fri, 09 Jun 2006 02:22:04 -0700 (PDT) Received: by 10.65.100.17 with HTTP; Fri, 9 Jun 2006 02:22:04 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 11:22:04 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: RFC3229 w/ feeds [was: Paging, Feed History, etc.] In-Reply-To: <44892DE7.3050401@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8B47966C-585C-4F97-AFFF-ECF3B748886A@mnot.net> <44892DE7.3050401@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 2006/6/9, Julian Reschke : > I think this is a misunderstanding of how HTTP/1.1 is supposed to work. > > If a server returns the same ETag for different entities returned for > the same URL, this will cause breakage of caches. You may want to > re-read Section 13.6 of RFC2616 > (). But using A-IM, you'll have Cache-Control and Vary headers in responses, which should take care of that, no? (I'm at work have no time to read the pointed section carefully, so please forgive me if I'm wrong) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Jun 09 05:44:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodXr-0005p1-Gy for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:44:47 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodXp-0003i0-Pm for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 05:44: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 k599SoFH024233; Fri, 9 Jun 2006 02:28: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 k599SoAO024232; Fri, 9 Jun 2006 02:28: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k599SnBE024224 for ; Fri, 9 Jun 2006 02:28:49 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so483197wxc for ; Fri, 09 Jun 2006 02:28: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=bOLfXJskt7bUxtosQaWo7AAgqjc3vM0nTidOvFT/2p953dz+WR9UKR2ykiqeDIDvZqFbDuWq+uGGuM6aJvHBB0eBban7hJWyekQr/umcZP7ADRFoJnCcQjr+HxG1Tyaf4OncpIwuwBBi8TmRigdf6p6Vy1cqA5FV70qyLR8ZXgU= Received: by 10.70.62.9 with SMTP id k9mr3268852wxa; Fri, 09 Jun 2006 02:28:48 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Fri, 9 Jun 2006 02:28:48 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 03:28:48 -0600 From: "M. David Peterson" To: "Karl Dubost" Subject: Re: Copyright, licensing, and feeds Cc: "atom-syntax Syntax" In-Reply-To: <41CAD5DF-9727-4242-90B2-323CAD3A9EB3@w3.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35189_23371028.1149845328453" References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> <4487AB58.8060702@aol.net> <41CAD5DF-9727-4242-90B2-323CAD3A9EB3@w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.5 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c ------=_Part_35189_23371028.1149845328453 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Pj4gMS4gRmVlZCBjb21wb3NlZCB3aXRoIG11bHRpcGxlIHNvdXJjZXMgd2l0aCBkaWZmZXJlbnQg bGljZW5zZXMuCiAgICBXaGVuIGEgZmVlZCBhZ2dyZWdhdG9yIGNyZWF0ZXMgYSBmZWVkIGZyb20g ZGlmZmVyZW50IHNvdXJjZXMKKGZlZWRzKSB3aXRoIGRpZmZlcmVudCBsaWNlbnNlcywgd2hhdCBz aG91bGQgYmUgdGhlIGxpY2Vuc2Ugb2YgdGhlCnJlc3VsdGluZyBmZWVkPyA8PAoKVmVyeSBpbXBv cnRhbnQgcG9pbnQgS2FybCEgIFRoYW5rcyBmb3IgYnJpbmdpbmcgaXQgdG8gdGhlIHN1cmZhY2Ug OikKCj4+IERlZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGF0dHJpYnV0ZS9lbGVtZW50IGlz IGNvb2wsIGJ1dCBvbiB0aGUKc2lkZSBpbiB0aGUgaW1wbGVtZW50YXRpb24gaXQncyBub3QgY2xl YXIgd2hhdCBzaG91bGQgYmUgYnkgY29uc3VtaW5nCnByb2R1Y3RzLiBBcyBJIHNhaWQgaW4gYSBw cmV2aW91cyBtZXNzYWdlLCBpdCdzIGEgdG91Z2ggcHJvYmxlbS4gPDwKCkl0ICpzZWVtcyogdGhh dCB0aGUgY2F0ZWdvcnkgZWxlbWVudCB3aXRoIEBzY2hlbWUsIEBsYWJlbCwgQHRlcm0gY291bGQg YWN0CnBhcnRpY3VsbGFyeSB3ZWxsIGluIHJlZ2FyZHMgdG8gYWxsb3dpbmcgZm9yIGEgaHVtYW4g cmVhZGFibGUgZGVmaW5pdGlvbiwgYQpodW1hbi9tYWNoaW5lIHJlYWRhYmxlIGxhYmVsLCBhbmQg YSBodW1hbiBidXQgbW9yZSBpbXBvcnRhbnRseSBtYWNoaW5lCnJlYWRhYmxlIHNjaGVtZSB0aGF0 IGNvdWxkIHJlcHJlc2VudCB0aGUgInJ1bGVzIiBkZWZpbml0aW9uIGZpbGUgaW4gd2hpY2gKY291 bGQgYmUgcGFyc2VkIGFuZCB1c2VkIGFzIHRoZSBwYXNzL2ZhaWwgbWV0aG9kIHRvIGRldGVybWlu ZSB3aGljaCBsaWNlbnNlCmJvdGggY2FuIGFwcGx5IGFzIHdlbGwgYXMgd2hpY2ggb25lIGJlc3Qg YXBwbGllcyB0byB0aGUgc2l0dWF0aW9uLgoKV2hhdCBJIG1lYW4gYnkgdGhpcyBpcyB0aGF0IGlm IHRoZXJlIHdlcmUgdGhyZWUgY2F0ZWdvcnkgZWxlbWVudHMgaW4gd2hpY2gKZWFjaCBjb250YWlu ZWQgQGxhYmxlPSJsaWNlbnNlIiBbMV0sIGlmIGEgYmVzdCBwcmFjdGljZXMgZG9jIHN1Z2dlc3Rl ZApvcmRlcmluZyB0aGVtIGZyb20gbW9zdCBjb25maW5pbmcgdG8gbGVhc3QgKHVzaW5nIGEgMTAw JSBjb21tZXJjaWFsIHVzZSA+CjEwMCUgbm9uLWNvbW1lcmNpYWwgKG9yIHdvdWxkIHRoYXQgbmVl ZCB0byBiZSB0aGUgb3RoZXIgd2F5IGFyb3VuZCB0byBtYWtlCnByb3BlciBzZW5zZT8pIHVzZSBw YXR0ZXJuIGZvciBvcmRlcmluZyB0aGUgY2F0ZWdvcnkgZWxlbWVudHMpLCB0aGVuIGFzIHNvb24K YXMgdGhleSByZWFjaGVkIHRoZSBwb2ludCBpbiB3aGljaCB0aGV5IHBhc3NlZCBhbGwgcnVsZXMg Zm9yIGEgZ2l2ZW4gc2NoZW1lLAp0aGUgbWFjaGluZSBjb3VsZCB0aGVtIHN0b3AgcHJvY2Vzc2lu ZyBzY2hlbWVzIGFuZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUKcmVzdCBvZiB0aGUgcHJvY2Vzc2lu ZyBiYXNlZCBvbiB0aGUgc2V0IG9mIHJ1bGVzIHNldCBmb3J0aCBpbiB0aGUgY3VycmVudAoiaW4t cHJvY2VzcyIgc2NoZW1lLiAgVAoKaGlzLCBvZiBjb3Vyc2UsIHdvdWxkIHN1Z2dlc3QgdGhhdCB0 aGUgYmVzdCB3YXkgdG8gYnVpbGQgb3V0IHRoZSBzY2hlbWUgZmlsZQp3b3VsZCBiZSB0byBzdGFy dCB3aXRoIHRoZSBwYXNzL2ZhaWwgInF1ZXN0aW9ucyIgdG8gdGhlbiBmb2xsb3cgd2l0aCB3aGF0 CmNhbiBhbmQgY2FuIG5vdCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIGZpbmFsIG91dHB1dC4gIE9i dmlvdXNseSBmcm9tIGEKbWFjaGluZSBzdGFuZHBvaW50IHRoaXMgd291bGQgYWxsb3cgZm9yIHRo ZSBtb3N0IGVmZmljaWVudCB1c2FnZSBvZiBYTUwgYXMKdGhlcmUgd291bGQgYmUgbm8gbmVlZCB0 byBjbGltYiB1cCBhbmQgZG93biB0aGUgdHJlZSBsb29raW5nIGZvciB0aGUgbmV4dApzZXQgb2Yg cHJvY2Vzc2luZyBydWxlcyBvbmNlIGEgMTAwJSBwYXNzIGxldmVsIGhhcyBiZWVuIHJlYWNoZWQu ICBUaGlzIHdvdWxkCmFsbG93IGZvciBmb3J3YXJkIG9ubHkgcmVhZGVycyB0byBiZSBpbXBsZW1l bnRlZCwgYW5kIHdvdWxkIG9idmlvdXNseSB3b3JrCndlbGwgd2l0aCB0aGUgc3RyZWFtaW5nIFNB WCsgaW1wbGVtZW50YXRpb25zLgoKT2YgY291cnNlIHRoaXMgbGVhZHMgbmljZWx5IGludG8uLi4K Cj4+IDIuIFNob3VsZCB0aGVyZSBiZSBhIGJlc3QgcHJhY3RpY2VzIGRvY3VtZW50IHRvIGludml0 ZSB0b29scwpkZXZlbG9wZXJzIHRvIHVuZGVyc3RhbmQgYW5kIGltcGxlbWVudCBsaWNlbnNlcyBt ZWNoYW5pc20/ICAoQXMgSQp1bmRlcnN0YW5kIGl0J3Mgbm90IHRoZSBwdXJwb3NlIG9mIHRoaXMg ZHJhZnQpLiA8PAoKWWVzIHBsZWFzZSEgOkQKCk9uIDYvOS8wNiwgS2FybCBEdWJvc3QgPGthcmxA dzMub3JnPiB3cm90ZToKPgo+Cj4gUmVhZGluZyB0aGUgZXhhbXBsZSBmcm9tCj4gICAgICAgICBo dHRwOi8vaWV0ZnJlcG9ydC5pc29jLm9yZy9pZHJlZi9kcmFmdC1zbmVsbC1hdG9tcHViLWZlZWQt bGljZW5zZS8KPiBbW1sKPiAzLiAgVGhlICdsaWNlbnNlJyBsaW5rIHJlbGF0aW9uCj4KPiAgICAg QW4gQXRvbSBsaW5rIGVsZW1lbnQgd2l0aCBhICdyZWwnIGF0dHJpYnV0ZSB2YWx1ZSBvZiAnbGlj ZW5zZScgaXMKPiAgICAgdXNlZCB0byBhc3NvY2lhdGUgYSBjb3B5cmlnaHQgbGljZW5zZSB3aXRo IGFuIEF0b20gRmVlZCBvciBFbnRyeS4KPgo+ICAgICBBdG9tIGVudHJ5LCBmZWVkIGFuZCBzb3Vy Y2UgZWxlbWVudHMgTUFZIGVhY2ggY29udGFpbiBhbnkgbnVtYmVyIG9mCj4gICAgIGxpY2Vuc2Ug bGlua3MgYnV0IE1VU1QgTk9UIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSB3aXRoIHRoZSBzYW1lIGhy ZWYKPiAgICAgdmFsdWUuICBUaGUgSVJJIHNwZWNpZmllZCBieSB0aGUgbGluaydzICdocmVmJyBh dHRyaWJ1dGUgU0hPVUxEIGJlCj4gICAgIGRlcmVmZXJlbmNlYWJsZSB0byByZXR1cm4gYSBtYWNo aW5lIG9yIGh1bWFuLXJlYWRhYmxlIHJlcHJlc2VudGF0aW9uCj4gICAgIG9mIHRoZSBsaWNlbnNl Lgo+Cj4gICAgIEltcGxlbWVudG9ycyBzaG91bGQgbm90ZSB0aGF0LCB1bmxpa2UgdGhlIEF0b20g cmlnaHRzIGVsZW1lbnQsIHdoaWNoCj4gICAgIHNwZWNpZmllcyBhIGh1bWFuLXJlYWRhYmxlIHN0 YXRlbWVudCBvZiB0aGUgcmlnaHRzIGhlbGQgb3ZlciBhIGVudHJ5Cj4gICAgIG9yIGZlZWQsIGxp Y2Vuc2UgbGlua3MgYXBwbHkgb25seSB0byB0aGUgaW5mb3JtYXRpb25hbCBjb250ZW50IG9mCj4g dGhlCj4gICAgIGNvbnRhaW5pbmcgZWxlbWVudC4gIFRoYXQgaXMsIHRoZSBwcmVzZW5jZSBvZiBh IGxpY2Vuc2UgbGluawo+IHJlbGF0aW9uCj4gICAgIHdpdGhpbiBhbiBBdG9tIGZlZWQgZWxlbWVu dCBkb2VzIG5vdCBleHRlbmQgYSBsaWNlbnNlIG92ZXIgdGhlCj4gICAgIHZhcmlvdXMgY29udGFp bmVkIGVudHJ5IGVsZW1lbnRzLiAgTGlrZXdpc2UsIHRoZSBwcmVzZW5jZSBvZiBhCj4gICAgIGxp Y2Vuc2UgbGluayB3aXRoaW4gYW4gQXRvbSBzb3VyY2UgZWxlbWVudCBkb2VzIG5vdCBleHRlbmQg YSBsaWNlbnNlCj4gICAgIG92ZXIgdGhlIGluZm9ybWF0aW9uYWwgY29udGVudCBvZiB0aGUgY29u dGFpbmluZyBlbnRyeS4KPiBdXV0KPgo+IC0tIHNuZWxsLWF0b21wdWItZmVlZC1saWNlbnNlLTA2 LnR4dAo+IGh0dHA6Ly9pZXRmcmVwb3J0Lmlzb2Mub3JnL2lkcmVmL2RyYWZ0LXNuZWxsLWF0b21w dWItZmVlZC1saWNlbnNlLwo+ICNwYWdlLTMKPiBUaHUsIDEzIEFwciAyMDA2IDE5OjI3OjU0IEdN VAo+Cj4KPiAjIFNvbWUgcXVlc3Rpb25zIGFib3V0IHNwZWNpZmljIHVzZSBjYXNlcwo+Cj4gMS4g RmVlZCBjb21wb3NlZCB3aXRoIG11bHRpcGxlIHNvdXJjZXMgd2l0aCBkaWZmZXJlbnQgbGljZW5z ZXMuCj4gICAgIFdoZW4gYSBmZWVkIGFnZ3JlZ2F0b3IgY3JlYXRlcyBhIGZlZWQgZnJvbSBkaWZm ZXJlbnQgc291cmNlcwo+IChmZWVkcykgd2l0aCBkaWZmZXJlbnQgbGljZW5zZXMsIHdoYXQgc2hv dWxkIGJlIHRoZSBsaWNlbnNlIG9mIHRoZQo+IHJlc3VsdGluZyBmZWVkPwo+Cj4gICAgIGZlZWQg KGxpY2Vuc2UgPz8/KQo+ICAgICAgICBlbnRyeSAobGljZW5zZSBBKSBmcm9tIGZlZWQgWAo+ICAg ICAgICBlbnRyeSAobGljZW5zZSBCKSBmcm9tIGZlZWQgWQo+ICAgICAgICBlbnRyeSAobGljZW5z ZSBCKSBmcm9tIGZlZWQgWQo+ICAgICAgICBlbnRyeSAobGljZW5zZSBBKSBmcm9tIGZlZWQgWAo+ ICAgICAgICBlbnRyeSAobGljZW5zZSBDKSBmcm9tIGZlZWQgWgo+ICAgICAgICDigKYKPgo+IERl ZmluaW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGF0dHJpYnV0ZS9lbGVtZW50IGlzIGNvb2wsIGJ1 dCBvbiB0aGUKPiBzaWRlIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBpdCdzIG5vdCBjbGVhciB3aGF0 IHNob3VsZCBiZSBieSBjb25zdW1pbmcKPiBwcm9kdWN0cy4gQXMgSSBzYWlkIGluIGEgcHJldmlv dXMgbWVzc2FnZSwgaXQncyBhIHRvdWdoIHByb2JsZW0uCj4KPiAyLiBTaG91bGQgdGhlcmUgYmUg YSBiZXN0IHByYWN0aWNlcyBkb2N1bWVudCB0byBpbnZpdGUgdG9vbHMKPiBkZXZlbG9wZXJzIHRv IHVuZGVyc3RhbmQgYW5kIGltcGxlbWVudCBsaWNlbnNlcyBtZWNoYW5pc20/ICAoQXMgSQo+IHVu ZGVyc3RhbmQgaXQncyBub3QgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCkuCj4KPgo+Cj4KPgo+ IC0tCj4gS2FybCBEdWJvc3QgLSBodHRwOi8vd3d3LnczLm9yZy9QZW9wbGUva2FybC8KPiBXM0Mg Q29uZm9ybWFuY2UgTWFuYWdlciwgUUEgQWN0aXZpdHkgTGVhZAo+ICAgIFFBIFdlYmxvZyAtIGh0 dHA6Ly93d3cudzMub3JnL1FBLwo+ICAgICAgICoqKiBCZSBTdHJpY3QgVG8gQmUgQ29vbCAqKioK Pgo+Cj4KPgo+Cj4KCgotLSAKPE06RC8+CgpNLiBEYXZpZCBQZXRlcnNvbgpodHRwOi8vd3d3Lnhz bHRibG9nLmNvbS8K ------=_Part_35189_23371028.1149845328453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Jmd0OyZndDsgMS4gRmVlZCBjb21wb3NlZCB3aXRoIG11bHRpcGxlIHNvdXJjZXMgd2l0aCBkaWZm ZXJlbnQgbGljZW5zZXMuPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gYSBmZWVkIGFn Z3JlZ2F0b3IgY3JlYXRlcyBhIGZlZWQgZnJvbSBkaWZmZXJlbnQgc291cmNlczxicj4oZmVlZHMp IHdpdGggZGlmZmVyZW50IGxpY2Vuc2VzLCB3aGF0IHNob3VsZCBiZSB0aGUgbGljZW5zZSBvZiB0 aGU8YnI+cmVzdWx0aW5nIGZlZWQ/ICZsdDsmbHQ7Cjxicj48YnI+VmVyeSBpbXBvcnRhbnQgcG9p bnQgS2FybCEmbmJzcDsgVGhhbmtzIGZvciBicmluZ2luZyBpdCB0byB0aGUgc3VyZmFjZSA6KTxi cj48YnI+Jmd0OyZndDsgRGVmaW5pbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgYXR0cmlidXRlL2Vs ZW1lbnQgaXMgY29vbCwgYnV0IG9uIHRoZTxicj5zaWRlIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBp dCdzIG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSBieSBjb25zdW1pbmcKPGJyPnByb2R1Y3RzLiBB cyBJIHNhaWQgaW4gYSBwcmV2aW91cyBtZXNzYWdlLCBpdCdzIGEgdG91Z2ggcHJvYmxlbS4gJmx0 OyZsdDs8YnI+PGJyPkl0ICpzZWVtcyogdGhhdCB0aGUgY2F0ZWdvcnkgZWxlbWVudCB3aXRoIEBz Y2hlbWUsIEBsYWJlbCwgQHRlcm0gY291bGQgYWN0IHBhcnRpY3VsbGFyeSB3ZWxsIGluIHJlZ2Fy ZHMgdG8gYWxsb3dpbmcgZm9yIGEgaHVtYW4gcmVhZGFibGUgZGVmaW5pdGlvbiwgYSBodW1hbi9t YWNoaW5lIHJlYWRhYmxlIGxhYmVsLCBhbmQgYSBodW1hbiBidXQgbW9yZSBpbXBvcnRhbnRseSBt YWNoaW5lIHJlYWRhYmxlIHNjaGVtZSB0aGF0IGNvdWxkIHJlcHJlc2VudCB0aGUgJnF1b3Q7cnVs ZXMmcXVvdDsgZGVmaW5pdGlvbiBmaWxlIGluIHdoaWNoIGNvdWxkIGJlIHBhcnNlZCBhbmQgdXNl ZCBhcyB0aGUgcGFzcy9mYWlsIG1ldGhvZCB0byBkZXRlcm1pbmUgd2hpY2ggbGljZW5zZSBib3Ro IGNhbiBhcHBseSBhcyB3ZWxsIGFzIHdoaWNoIG9uZSBiZXN0IGFwcGxpZXMgdG8gdGhlIHNpdHVh dGlvbi4KPGJyPjxicj5XaGF0IEkgbWVhbiBieSB0aGlzIGlzIHRoYXQgaWYgdGhlcmUgd2VyZSB0 aHJlZSBjYXRlZ29yeSBlbGVtZW50cyBpbiB3aGljaCBlYWNoIGNvbnRhaW5lZCBAbGFibGU9JnF1 b3Q7bGljZW5zZSZxdW90OyBbMV0sIGlmIGEgYmVzdCBwcmFjdGljZXMgZG9jIHN1Z2dlc3RlZCBv cmRlcmluZyB0aGVtIGZyb20gbW9zdCBjb25maW5pbmcgdG8gbGVhc3QgKHVzaW5nIGEgMTAwJSBj b21tZXJjaWFsIHVzZSAmZ3Q7IDEwMCUgbm9uLWNvbW1lcmNpYWwgKG9yIHdvdWxkIHRoYXQgbmVl ZCB0byBiZSB0aGUgb3RoZXIgd2F5IGFyb3VuZCB0byBtYWtlIHByb3BlciBzZW5zZT8pIHVzZSBw YXR0ZXJuIGZvciBvcmRlcmluZyB0aGUgY2F0ZWdvcnkgZWxlbWVudHMpLCB0aGVuIGFzIHNvb24g YXMgdGhleSByZWFjaGVkIHRoZSBwb2ludCBpbiB3aGljaCB0aGV5IHBhc3NlZCBhbGwgcnVsZXMg Zm9yIGEgZ2l2ZW4gc2NoZW1lLCB0aGUgbWFjaGluZSBjb3VsZCB0aGVtIHN0b3AgcHJvY2Vzc2lu ZyBzY2hlbWVzIGFuZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgcmVzdCBvZiB0aGUgcHJvY2Vzc2lu ZyBiYXNlZCBvbiB0aGUgc2V0IG9mIHJ1bGVzIHNldCBmb3J0aCBpbiB0aGUgY3VycmVudCAmcXVv dDtpbi1wcm9jZXNzJnF1b3Q7IHNjaGVtZS4mbmJzcDsgVAo8YnI+PGJyPmhpcywgb2YgY291cnNl LCB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGJlc3Qgd2F5IHRvIGJ1aWxkIG91dCB0aGUgc2NoZW1l IGZpbGUgd291bGQgYmUgdG8gc3RhcnQgd2l0aCB0aGUgcGFzcy9mYWlsICZxdW90O3F1ZXN0aW9u cyZxdW90OyB0byB0aGVuIGZvbGxvdyB3aXRoIHdoYXQgY2FuIGFuZCBjYW4gbm90IGJlIHVzZWQg YXMgcGFydCBvZiB0aGUgZmluYWwgb3V0cHV0LiZuYnNwOyBPYnZpb3VzbHkgZnJvbSBhIG1hY2hp bmUgc3RhbmRwb2ludCB0aGlzIHdvdWxkIGFsbG93IGZvciB0aGUgbW9zdCBlZmZpY2llbnQgdXNh Z2Ugb2YgWE1MIGFzIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgdG8gY2xpbWIgdXAgYW5kIGRvd24g dGhlIHRyZWUgbG9va2luZyBmb3IgdGhlIG5leHQgc2V0IG9mIHByb2Nlc3NpbmcgcnVsZXMgb25j ZSBhIDEwMCUgcGFzcyBsZXZlbCBoYXMgYmVlbiByZWFjaGVkLiZuYnNwOyBUaGlzIHdvdWxkIGFs bG93IGZvciBmb3J3YXJkIG9ubHkgcmVhZGVycyB0byBiZSBpbXBsZW1lbnRlZCwgYW5kIHdvdWxk IG9idmlvdXNseSB3b3JrIHdlbGwgd2l0aCB0aGUgc3RyZWFtaW5nIFNBWCsgaW1wbGVtZW50YXRp b25zLgo8YnI+PGJyPk9mIGNvdXJzZSB0aGlzIGxlYWRzIG5pY2VseSBpbnRvLi4uIDxicj48YnI+ Jmd0OyZndDsgMi4gU2hvdWxkIHRoZXJlIGJlIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQgdG8g aW52aXRlIHRvb2xzPGJyPmRldmVsb3BlcnMgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IGxp Y2Vuc2VzIG1lY2hhbmlzbT8mbmJzcDsmbmJzcDsoQXMgSTxicj51bmRlcnN0YW5kIGl0J3Mgbm90 IHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQpLiAmbHQ7Jmx0Owo8YnI+PGJyPlllcyBwbGVhc2Uh IDpEPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNi85LzA2LCA8YiBj bGFzcz0iZ21haWxfc2VuZGVybmFtZSI+S2FybCBEdWJvc3Q8L2I+ICZsdDs8YSBocmVmPSJtYWls dG86a2FybEB3My5vcmciPmthcmxAdzMub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdi KDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6 IDFleDsiPgo8YnI+UmVhZGluZyB0aGUgZXhhbXBsZSBmcm9tPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pZXRmcmVwb3J0 Lmlzb2Mub3JnL2lkcmVmL2RyYWZ0LXNuZWxsLWF0b21wdWItZmVlZC1saWNlbnNlLyI+aHR0cDov L2lldGZyZXBvcnQuaXNvYy5vcmcvaWRyZWYvZHJhZnQtc25lbGwtYXRvbXB1Yi1mZWVkLWxpY2Vu c2UvPC9hPjxicj5bW1s8YnI+My4mbmJzcDsmbmJzcDtUaGUgJ2xpY2Vuc2UnIGxpbmsgcmVsYXRp b24KPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbiBBdG9tIGxpbmsgZWxlbWVudCB3 aXRoIGEgJ3JlbCcgYXR0cmlidXRlIHZhbHVlIG9mICdsaWNlbnNlJyBpczxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt1c2VkIHRvIGFzc29jaWF0ZSBhIGNvcHlyaWdodCBsaWNlbnNlIHdpdGgg YW4gQXRvbSBGZWVkIG9yIEVudHJ5Ljxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXRv bSBlbnRyeSwgZmVlZCBhbmQgc291cmNlIGVsZW1lbnRzIE1BWSBlYWNoIGNvbnRhaW4gYW55IG51 bWJlciBvZgo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGljZW5zZSBsaW5rcyBidXQgTVVT VCBOT1QgY29udGFpbiBtb3JlIHRoYW4gb25lIHdpdGggdGhlIHNhbWUgaHJlZjxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt2YWx1ZS4mbmJzcDsmbmJzcDtUaGUgSVJJIHNwZWNpZmllZCBieSB0 aGUgbGluaydzICdocmVmJyBhdHRyaWJ1dGUgU0hPVUxEIGJlPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2RlcmVmZXJlbmNlYWJsZSB0byByZXR1cm4gYSBtYWNoaW5lIG9yIGh1bWFuLXJlYWRh YmxlIHJlcHJlc2VudGF0aW9uCjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvZiB0aGUgbGlj ZW5zZS48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ltcGxlbWVudG9ycyBzaG91bGQg bm90ZSB0aGF0LCB1bmxpa2UgdGhlIEF0b20gcmlnaHRzIGVsZW1lbnQsIHdoaWNoPGJyPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3NwZWNpZmllcyBhIGh1bWFuLXJlYWRhYmxlIHN0YXRlbWVudCBv ZiB0aGUgcmlnaHRzIGhlbGQgb3ZlciBhIGVudHJ5PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O29yIGZlZWQsIGxpY2Vuc2UgbGlua3MgYXBwbHkgb25seSB0byB0aGUgaW5mb3JtYXRpb25hbCBj b250ZW50IG9mCjxicj50aGU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29udGFpbmluZyBl bGVtZW50LiZuYnNwOyZuYnNwO1RoYXQgaXMsIHRoZSBwcmVzZW5jZSBvZiBhIGxpY2Vuc2UgbGlu azxicj5yZWxhdGlvbjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aXRoaW4gYW4gQXRvbSBm ZWVkIGVsZW1lbnQgZG9lcyBub3QgZXh0ZW5kIGEgbGljZW5zZSBvdmVyIHRoZTxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt2YXJpb3VzIGNvbnRhaW5lZCBlbnRyeSBlbGVtZW50cy4mbmJzcDsm bmJzcDtMaWtld2lzZSwgdGhlIHByZXNlbmNlIG9mIGEKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2xpY2Vuc2UgbGluayB3aXRoaW4gYW4gQXRvbSBzb3VyY2UgZWxlbWVudCBkb2VzIG5vdCBl eHRlbmQgYSBsaWNlbnNlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO292ZXIgdGhlIGluZm9y bWF0aW9uYWwgY29udGVudCBvZiB0aGUgY29udGFpbmluZyBlbnRyeS48YnI+XV1dPGJyPjxicj4t LSBzbmVsbC1hdG9tcHViLWZlZWQtbGljZW5zZS0wNi50eHQ8YnI+PGEgaHJlZj0iaHR0cDovL2ll dGZyZXBvcnQuaXNvYy5vcmcvaWRyZWYvZHJhZnQtc25lbGwtYXRvbXB1Yi1mZWVkLWxpY2Vuc2Uv Ij4KaHR0cDovL2lldGZyZXBvcnQuaXNvYy5vcmcvaWRyZWYvZHJhZnQtc25lbGwtYXRvbXB1Yi1m ZWVkLWxpY2Vuc2UvPC9hPjxicj4jcGFnZS0zPGJyPlRodSwgMTMgQXByIDIwMDYgMTk6Mjc6NTQg R01UPGJyPjxicj48YnI+IyBTb21lIHF1ZXN0aW9ucyBhYm91dCBzcGVjaWZpYyB1c2UgY2FzZXM8 YnI+PGJyPjEuIEZlZWQgY29tcG9zZWQgd2l0aCBtdWx0aXBsZSBzb3VyY2VzIHdpdGggZGlmZmVy ZW50IGxpY2Vuc2VzLgo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBhIGZlZWQgYWdn cmVnYXRvciBjcmVhdGVzIGEgZmVlZCBmcm9tIGRpZmZlcmVudCBzb3VyY2VzPGJyPihmZWVkcykg d2l0aCBkaWZmZXJlbnQgbGljZW5zZXMsIHdoYXQgc2hvdWxkIGJlIHRoZSBsaWNlbnNlIG9mIHRo ZTxicj5yZXN1bHRpbmcgZmVlZD88YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ZlZWQg KGxpY2Vuc2UgPz8/KTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW50 cnkgKGxpY2Vuc2UgQSkgZnJvbSBmZWVkIFgKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBlbnRyeSAobGljZW5zZSBCKSBmcm9tIGZlZWQgWTxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW50cnkgKGxpY2Vuc2UgQikgZnJvbSBmZWVkIFk8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudHJ5IChsaWNlbnNlIEEpIGZy b20gZmVlZCBYPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnRyeSAo bGljZW5zZSBDKSBmcm9tIGZlZWQgWjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsg4oCmPGJyPjxicj5EZWZpbmluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBhdHRyaWJ1dGUv ZWxlbWVudCBpcyBjb29sLCBidXQgb24gdGhlCjxicj5zaWRlIGluIHRoZSBpbXBsZW1lbnRhdGlv biBpdCdzIG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSBieSBjb25zdW1pbmc8YnI+cHJvZHVjdHMu IEFzIEkgc2FpZCBpbiBhIHByZXZpb3VzIG1lc3NhZ2UsIGl0J3MgYSB0b3VnaCBwcm9ibGVtLjxi cj48YnI+Mi4gU2hvdWxkIHRoZXJlIGJlIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQgdG8gaW52 aXRlIHRvb2xzPGJyPmRldmVsb3BlcnMgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IGxpY2Vu c2VzIG1lY2hhbmlzbT8mbmJzcDsmbmJzcDsoQXMgSQo8YnI+dW5kZXJzdGFuZCBpdCdzIG5vdCB0 aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0KS48YnI+PGJyPjxicj48YnI+PGJyPjxicj4tLTxicj5L YXJsIER1Ym9zdCAtIDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1Blb3BsZS9rYXJsLyI+aHR0 cDovL3d3dy53My5vcmcvUGVvcGxlL2thcmwvPC9hPjxicj5XM0MgQ29uZm9ybWFuY2UgTWFuYWdl ciwgUUEgQWN0aXZpdHkgTGVhZDxicj4mbmJzcDsmbmJzcDsgUUEgV2VibG9nIC0gCjxhIGhyZWY9 Imh0dHA6Ly93d3cudzMub3JnL1FBLyI+aHR0cDovL3d3dy53My5vcmcvUUEvPC9hPjxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsqKiogQmUgU3RyaWN0IFRvIEJlIENvb2wg KioqPGJyPjxicj48YnI+PGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xl YXI9ImFsbCI+PGJyPi0tIDxicj4mbHQ7TTpELyZndDs8YnI+PGJyPk0uIERhdmlkIFBldGVyc29u PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29tLyI+Cmh0dHA6Ly93d3cueHNsdGJs b2cuY29tLzwvYT4K ------=_Part_35189_23371028.1149845328453-- From owner-atom-syntax@mail.imc.org Fri Jun 09 06:07:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fodtj-0005E4-Ic for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 06:07:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fodtg-0006dX-It for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 06:07: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 k599ssBn038137; Fri, 9 Jun 2006 02:54: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 k599ssXm038136; Fri, 9 Jun 2006 02:54:54 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-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 k599sqnQ038096 for ; Fri, 9 Jun 2006 02:54:52 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by wx-out-0102.google.com with SMTP id s15so485705wxc for ; Fri, 09 Jun 2006 02:54: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:references; b=LPFfMyVkQ5w/rTPyj2KTVMP2hHxP3qL2/L7QXkp97X+lIxo23aRgd1UuQYPd9Xh4Pau6mw4g3Fjrh8HTey34R83pOP7IOFkasVRPxrnZsJvi31sdtbDRyLeBGoSRVwsWN2ZLsB7YmpS69BxXHG1PFahF9aUPrxnNIVRG13Cg7Xg= Received: by 10.70.116.11 with SMTP id o11mr758917wxc; Fri, 09 Jun 2006 02:54:51 -0700 (PDT) Received: by 10.70.108.5 with HTTP; Fri, 9 Jun 2006 02:54:51 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 03:54:51 -0600 From: "M. David Peterson" To: "Karl Dubost" Subject: Re: Copyright, licensing, and feeds Cc: "atom-syntax Syntax" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35481_20094333.1149846891633" References: <44873456.6080001@aol.net> <44874D7C.6080504@metalab.unc.edu> <44875136.7020506@aol.net> <448767BC.90507@gmail.com> <4487AB58.8060702@aol.net> <41CAD5DF-9727-4242-90B2-323CAD3A9EB3@w3.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 ------=_Part_35481_20094333.1149846891633 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline TGV0cyB0cnkgdGhpcyBhZ2FpbiB0byBldmVyeW9uZSBpbnN0ZWFkIG9mIGp1c3QgS2FybCA6KSAo c29ycnkgZm9yIHRoZQpkdXBsaWNhdGUsIEthcmwhKQoKQW5kIHRoZSBmaWxlIGFjY2VzcyBwcm9i bGVtIGlzIG5vdyBmaXhlZC4KLS0tCgpvb29wcy4uLiBmb3Jnb3QgdG8gYWRkIHRoZSBbMV0gZm9v dGVyLgoKSSB3YXMgaW50ZW5kaW5nIHRoaXMgdG8gYmUgYSBxdWVzdGlvbjogIENhbiB0aGVyZSBi ZSBtb3JlIHRoYW4gb25lIGNhdGVnb3J5CmVsZW1lbnQgd2l0aCB0aGUgc2FtZSB2YWx1ZSBmb3Ig bGFiZWw/ICBJIG5lZWQgdG8gbG9vayB0aGlzIHVwLCBidXQgaWYKYW55Ym9keSBrbm93cyBvZmYg aGFuZCBJIHdvdWxkIGFwcHJlY2lhdGUgdGhlIHRpbWUgc2F2ZWQuCgpJZiB0aGV5IGNhbiBub3Qs IHRoZW4gbmFtZXNwYWNlcyBjb21lIGludG8gcGxheSB0byBhbGxvdyBzb21laGluZyBsaWtlCmxp Y2Vuc2U6Y2MtYnktc2EuICBBbmQgeWVzLCBJIGhhdmUgdGhlIGNvZGUgYXZhaWxhYmxlIHRvIG1h a2UgZWFzeSB0aGUKcHJvYmxlbSB3aXRoIFFOYW1lcyBpbiBjb250ZW50LiAgSW4gZmFjdCwgaWYg eW91IGFjY2VzcyBbMV0sIFsyXSB5b3UgY2FuCnByb2JhYmx5IGZpZ3VyZSBvdXQgZm9yIHlvdXJz ZWxmIHdoYXQgSSBhbSByZWZlcmluZyB0by4gIEkgd291bGQgbmVlZCB0bwpjdXN0b21pemUgdGhl IGNvZGUgYmFzZSB0byBiZSBhIGJpdCBtb3JlIHNwZWNpZmljLCBidXQgdGhhdHMgbm90IGEgYmln IGlzc3VlCmFzIGl0cyBsZXNzIHRoZW4gMTAgbWludXRlcyB3b3J0aCBvZiBjb2RpbmcuCgpPbmUg dGhpbmcgSSBqdXN0IG5vdGljZWQgd2hlbiB2aXNpdGluZyB0aGUgc2Vjb25kIGxpbmsgaXMgdGhh dCB0aGUgc291cmNlCmZpbGVzIHNlZW0gdG8gYmUgaW5hY2Nlc3NpYmxlLiAgSSdsbCBzZWUgd2hh dCB0aGUgcHJvYmxlbSBpcywgYW5kIGlmCm5lY2Vzc2FyeSBwbGFjZSB0aGUgZmlsZXMgb24gYW5v dGhlciBzZXJ2ZXIgYW5kIHVwZGF0ZSB0aGF0IHBvc3QKYWNjb3JkaW5nbHkuICBJZiB5b3UgZmlu ZCB0aGV5IGFyZSB1bmFjY2Vzc2libGUsIHRoaXMgaXMgd2h5LCBhbHRob3VnaCBJIGFtCmdvaW5n IHRvIGxvb2sgaW50byB0aGlzIG5vdywgc28gYnkgdGhlIHRpbWUgYW55b25lIG90aGVyIHRoYW4g dGhvc2UgaW4KRXVyb3BlKyByZWFkIHRoaXMsIGl0IHNob3VsZCBtb3N0IGRlZmluaXRlbHkgYmUg Zml4ZWQuCgpbMV0gOgpodHRwOi8vd3d3Lm9yZWlsbHluZXQuY29tL3htbC9ibG9nLzIwMDUvMDgv cGFydF8yX2Fzc2V0c19hdG9tX2ZlZWRzX2FuZF9hLmh0bWwKWzJdIDoKaHR0cDovL3d3dy5vcmVp bGx5bmV0LmNvbS94bWwvYmxvZy8yMDA1LzA5L3BhcnRfM19hc3NldHNfYXRvbV9mZWVkc19hbmRf YS5odG1sCgpPbiA2LzkvMDYsIE0uIERhdmlkIFBldGVyc29uIDx4bWxoYWNrZXJAZ21haWwuY29t PiB3cm90ZToKPgo+ID4+IDEuIEZlZWQgY29tcG9zZWQgd2l0aCBtdWx0aXBsZSBzb3VyY2VzIHdp dGggZGlmZmVyZW50IGxpY2Vuc2VzLgo+ICAgICBXaGVuIGEgZmVlZCBhZ2dyZWdhdG9yIGNyZWF0 ZXMgYSBmZWVkIGZyb20gZGlmZmVyZW50IHNvdXJjZXMKPiAoZmVlZHMpIHdpdGggZGlmZmVyZW50 IGxpY2Vuc2VzLCB3aGF0IHNob3VsZCBiZSB0aGUgbGljZW5zZSBvZiB0aGUKPiByZXN1bHRpbmcg ZmVlZD8gPDwKPgo+IFZlcnkgaW1wb3J0YW50IHBvaW50IEthcmwhICBUaGFua3MgZm9yIGJyaW5n aW5nIGl0IHRvIHRoZSBzdXJmYWNlIDopCj4KPgo+ID4+IERlZmluaW5nIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIGF0dHJpYnV0ZS9lbGVtZW50IGlzIGNvb2wsIGJ1dCBvbiB0aGUKPiBzaWRlIGluIHRo ZSBpbXBsZW1lbnRhdGlvbiBpdCdzIG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSBieSBjb25zdW1p bmcKPiBwcm9kdWN0cy4gQXMgSSBzYWlkIGluIGEgcHJldmlvdXMgbWVzc2FnZSwgaXQncyBhIHRv dWdoIHByb2JsZW0uIDw8Cj4KPiBJdCAqc2VlbXMqIHRoYXQgdGhlIGNhdGVnb3J5IGVsZW1lbnQg d2l0aCBAc2NoZW1lLCBAbGFiZWwsIEB0ZXJtIGNvdWxkIGFjdAo+IHBhcnRpY3VsbGFyeSB3ZWxs IGluIHJlZ2FyZHMgdG8gYWxsb3dpbmcgZm9yIGEgaHVtYW4gcmVhZGFibGUgZGVmaW5pdGlvbiwg YQo+IGh1bWFuL21hY2hpbmUgcmVhZGFibGUgbGFiZWwsIGFuZCBhIGh1bWFuIGJ1dCBtb3JlIGlt cG9ydGFudGx5IG1hY2hpbmUKPiByZWFkYWJsZSBzY2hlbWUgdGhhdCBjb3VsZCByZXByZXNlbnQg dGhlICJydWxlcyIgZGVmaW5pdGlvbiBmaWxlIGluIHdoaWNoCj4gY291bGQgYmUgcGFyc2VkIGFu ZCB1c2VkIGFzIHRoZSBwYXNzL2ZhaWwgbWV0aG9kIHRvIGRldGVybWluZSB3aGljaCBsaWNlbnNl Cj4gYm90aCBjYW4gYXBwbHkgYXMgd2VsbCBhcyB3aGljaCBvbmUgYmVzdCBhcHBsaWVzIHRvIHRo ZSBzaXR1YXRpb24uCj4KPiBXaGF0IEkgbWVhbiBieSB0aGlzIGlzIHRoYXQgaWYgdGhlcmUgd2Vy ZSB0aHJlZSBjYXRlZ29yeSBlbGVtZW50cyBpbiB3aGljaAo+IGVhY2ggY29udGFpbmVkIEBsYWJs ZT0ibGljZW5zZSIgWzFdLCBpZiBhIGJlc3QgcHJhY3RpY2VzIGRvYyBzdWdnZXN0ZWQKPiBvcmRl cmluZyB0aGVtIGZyb20gbW9zdCBjb25maW5pbmcgdG8gbGVhc3QgKHVzaW5nIGEgMTAwJSBjb21t ZXJjaWFsIHVzZSA+Cj4gMTAwJSBub24tY29tbWVyY2lhbCAob3Igd291bGQgdGhhdCBuZWVkIHRv IGJlIHRoZSBvdGhlciB3YXkgYXJvdW5kIHRvIG1ha2UKPiBwcm9wZXIgc2Vuc2U/KSB1c2UgcGF0 dGVybiBmb3Igb3JkZXJpbmcgdGhlIGNhdGVnb3J5IGVsZW1lbnRzKSwgdGhlbiBhcyBzb29uCj4g YXMgdGhleSByZWFjaGVkIHRoZSBwb2ludCBpbiB3aGljaCB0aGV5IHBhc3NlZCBhbGwgcnVsZXMg Zm9yIGEgZ2l2ZW4gc2NoZW1lLAo+IHRoZSBtYWNoaW5lIGNvdWxkIHRoZW0gc3RvcCBwcm9jZXNz aW5nIHNjaGVtZXMgYW5kIG1vdmUgZm9yd2FyZCB3aXRoIHRoZQo+IHJlc3Qgb2YgdGhlIHByb2Nl c3NpbmcgYmFzZWQgb24gdGhlIHNldCBvZiBydWxlcyBzZXQgZm9ydGggaW4gdGhlIGN1cnJlbnQK PiAiaW4tcHJvY2VzcyIgc2NoZW1lLiAgVAo+Cj4gaGlzLCBvZiBjb3Vyc2UsIHdvdWxkIHN1Z2dl c3QgdGhhdCB0aGUgYmVzdCB3YXkgdG8gYnVpbGQgb3V0IHRoZSBzY2hlbWUKPiBmaWxlIHdvdWxk IGJlIHRvIHN0YXJ0IHdpdGggdGhlIHBhc3MvZmFpbCAicXVlc3Rpb25zIiB0byB0aGVuIGZvbGxv dyB3aXRoCj4gd2hhdCBjYW4gYW5kIGNhbiBub3QgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBmaW5h bCBvdXRwdXQuICBPYnZpb3VzbHkgZnJvbSBhCj4gbWFjaGluZSBzdGFuZHBvaW50IHRoaXMgd291 bGQgYWxsb3cgZm9yIHRoZSBtb3N0IGVmZmljaWVudCB1c2FnZSBvZiBYTUwgYXMKPiB0aGVyZSB3 b3VsZCBiZSBubyBuZWVkIHRvIGNsaW1iIHVwIGFuZCBkb3duIHRoZSB0cmVlIGxvb2tpbmcgZm9y IHRoZSBuZXh0Cj4gc2V0IG9mIHByb2Nlc3NpbmcgcnVsZXMgb25jZSBhIDEwMCUgcGFzcyBsZXZl bCBoYXMgYmVlbiByZWFjaGVkLiAgVGhpcyB3b3VsZAo+IGFsbG93IGZvciBmb3J3YXJkIG9ubHkg cmVhZGVycyB0byBiZSBpbXBsZW1lbnRlZCwgYW5kIHdvdWxkIG9idmlvdXNseSB3b3JrCj4gd2Vs bCB3aXRoIHRoZSBzdHJlYW1pbmcgU0FYKyBpbXBsZW1lbnRhdGlvbnMuCj4KPiBPZiBjb3Vyc2Ug dGhpcyBsZWFkcyBuaWNlbHkgaW50by4uLgo+Cj4KPiA+PiAyLiBTaG91bGQgdGhlcmUgYmUgYSBi ZXN0IHByYWN0aWNlcyBkb2N1bWVudCB0byBpbnZpdGUgdG9vbHMKPiBkZXZlbG9wZXJzIHRvIHVu ZGVyc3RhbmQgYW5kIGltcGxlbWVudCBsaWNlbnNlcyBtZWNoYW5pc20/ICAoQXMgSQo+IHVuZGVy c3RhbmQgaXQncyBub3QgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCkuIDw8Cj4KPiBZZXMgcGxl YXNlISA6RAo+Cj4KPiBPbiA2LzkvMDYsIEthcmwgRHVib3N0IDxrYXJsQHczLm9yZz4gd3JvdGU6 Cj4gPgo+ID4KPiA+IFJlYWRpbmcgdGhlIGV4YW1wbGUgZnJvbQo+ID4KPiA+IGh0dHA6Ly9pZXRm cmVwb3J0Lmlzb2Mub3JnL2lkcmVmL2RyYWZ0LXNuZWxsLWF0b21wdWItZmVlZC1saWNlbnNlLwo+ ID4gW1tbCj4gPiAzLiAgVGhlICdsaWNlbnNlJyBsaW5rIHJlbGF0aW9uCj4gPgo+ID4gICAgIEFu IEF0b20gbGluayBlbGVtZW50IHdpdGggYSAncmVsJyBhdHRyaWJ1dGUgdmFsdWUgb2YgJ2xpY2Vu c2UnIGlzCj4gPiAgICAgdXNlZCB0byBhc3NvY2lhdGUgYSBjb3B5cmlnaHQgbGljZW5zZSB3aXRo IGFuIEF0b20gRmVlZCBvciBFbnRyeS4KPiA+Cj4gPiAgICAgQXRvbSBlbnRyeSwgZmVlZCBhbmQg c291cmNlIGVsZW1lbnRzIE1BWSBlYWNoIGNvbnRhaW4gYW55IG51bWJlciBvZgo+ID4gICAgIGxp Y2Vuc2UgbGlua3MgYnV0IE1VU1QgTk9UIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSB3aXRoIHRoZSBz YW1lIGhyZWYKPiA+ICAgICB2YWx1ZS4gIFRoZSBJUkkgc3BlY2lmaWVkIGJ5IHRoZSBsaW5rJ3Mg J2hyZWYnIGF0dHJpYnV0ZSBTSE9VTEQgYmUKPiA+ICAgICBkZXJlZmVyZW5jZWFibGUgdG8gcmV0 dXJuIGEgbWFjaGluZSBvciBodW1hbi1yZWFkYWJsZSByZXByZXNlbnRhdGlvbgo+ID4KPiA+ICAg ICBvZiB0aGUgbGljZW5zZS4KPiA+Cj4gPiAgICAgSW1wbGVtZW50b3JzIHNob3VsZCBub3RlIHRo YXQsIHVubGlrZSB0aGUgQXRvbSByaWdodHMgZWxlbWVudCwgd2hpY2gKPiA+ICAgICBzcGVjaWZp ZXMgYSBodW1hbi1yZWFkYWJsZSBzdGF0ZW1lbnQgb2YgdGhlIHJpZ2h0cyBoZWxkIG92ZXIgYSBl bnRyeQo+ID4gICAgIG9yIGZlZWQsIGxpY2Vuc2UgbGlua3MgYXBwbHkgb25seSB0byB0aGUgaW5m b3JtYXRpb25hbCBjb250ZW50IG9mCj4gPiB0aGUKPiA+ICAgICBjb250YWluaW5nIGVsZW1lbnQu ICBUaGF0IGlzLCB0aGUgcHJlc2VuY2Ugb2YgYSBsaWNlbnNlIGxpbmsKPiA+IHJlbGF0aW9uCj4g PiAgICAgd2l0aGluIGFuIEF0b20gZmVlZCBlbGVtZW50IGRvZXMgbm90IGV4dGVuZCBhIGxpY2Vu c2Ugb3ZlciB0aGUKPiA+ICAgICB2YXJpb3VzIGNvbnRhaW5lZCBlbnRyeSBlbGVtZW50cy4gIExp a2V3aXNlLCB0aGUgcHJlc2VuY2Ugb2YgYQo+ID4gICAgIGxpY2Vuc2UgbGluayB3aXRoaW4gYW4g QXRvbSBzb3VyY2UgZWxlbWVudCBkb2VzIG5vdCBleHRlbmQgYSBsaWNlbnNlCj4gPiAgICAgb3Zl ciB0aGUgaW5mb3JtYXRpb25hbCBjb250ZW50IG9mIHRoZSBjb250YWluaW5nIGVudHJ5Lgo+ID4g XV1dCj4gPgo+ID4gLS0gc25lbGwtYXRvbXB1Yi1mZWVkLWxpY2Vuc2UtMDYudHh0Cj4gPiBodHRw Oi8vaWV0ZnJlcG9ydC5pc29jLm9yZy9pZHJlZi9kcmFmdC1zbmVsbC1hdG9tcHViLWZlZWQtbGlj ZW5zZS8KPiA+ICNwYWdlLTMKPiA+IFRodSwgMTMgQXByIDIwMDYgMTk6Mjc6NTQgR01UCj4gPgo+ ID4KPiA+ICMgU29tZSBxdWVzdGlvbnMgYWJvdXQgc3BlY2lmaWMgdXNlIGNhc2VzCj4gPgo+ID4g MS4gRmVlZCBjb21wb3NlZCB3aXRoIG11bHRpcGxlIHNvdXJjZXMgd2l0aCBkaWZmZXJlbnQgbGlj ZW5zZXMuCj4gPiAgICAgV2hlbiBhIGZlZWQgYWdncmVnYXRvciBjcmVhdGVzIGEgZmVlZCBmcm9t IGRpZmZlcmVudCBzb3VyY2VzCj4gPiAoZmVlZHMpIHdpdGggZGlmZmVyZW50IGxpY2Vuc2VzLCB3 aGF0IHNob3VsZCBiZSB0aGUgbGljZW5zZSBvZiB0aGUKPiA+IHJlc3VsdGluZyBmZWVkPwo+ID4K PiA+ICAgICBmZWVkIChsaWNlbnNlID8/PykKPiA+ICAgICAgICBlbnRyeSAobGljZW5zZSBBKSBm cm9tIGZlZWQgWAo+ID4gICAgICAgIGVudHJ5IChsaWNlbnNlIEIpIGZyb20gZmVlZCBZCj4gPiAg ICAgICAgZW50cnkgKGxpY2Vuc2UgQikgZnJvbSBmZWVkIFkKPiA+ICAgICAgICBlbnRyeSAobGlj ZW5zZSBBKSBmcm9tIGZlZWQgWAo+ID4gICAgICAgIGVudHJ5IChsaWNlbnNlIEMpIGZyb20gZmVl ZCBaCj4gPiAgICAgICAg4oCmCj4gPgo+ID4gRGVmaW5pbmcgdGhlIHNlbWFudGljcyBvZiB0aGUg YXR0cmlidXRlL2VsZW1lbnQgaXMgY29vbCwgYnV0IG9uIHRoZQo+ID4gc2lkZSBpbiB0aGUgaW1w bGVtZW50YXRpb24gaXQncyBub3QgY2xlYXIgd2hhdCBzaG91bGQgYmUgYnkgY29uc3VtaW5nCj4g PiBwcm9kdWN0cy4gQXMgSSBzYWlkIGluIGEgcHJldmlvdXMgbWVzc2FnZSwgaXQncyBhIHRvdWdo IHByb2JsZW0uCj4gPgo+ID4gMi4gU2hvdWxkIHRoZXJlIGJlIGEgYmVzdCBwcmFjdGljZXMgZG9j dW1lbnQgdG8gaW52aXRlIHRvb2xzCj4gPiBkZXZlbG9wZXJzIHRvIHVuZGVyc3RhbmQgYW5kIGlt cGxlbWVudCBsaWNlbnNlcyBtZWNoYW5pc20/ICAoQXMgSQo+ID4gdW5kZXJzdGFuZCBpdCdzIG5v dCB0aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0KS4KPiA+Cj4gPgo+ID4KPiA+Cj4gPgo+ID4gLS0K PiA+IEthcmwgRHVib3N0IC0gaHR0cDovL3d3dy53My5vcmcvUGVvcGxlL2thcmwvCj4gPiBXM0Mg Q29uZm9ybWFuY2UgTWFuYWdlciwgUUEgQWN0aXZpdHkgTGVhZAo+ID4gICAgUUEgV2VibG9nIC0g aHR0cDovL3d3dy53My5vcmcvUUEvCj4gPiAgICAgICAqKiogQmUgU3RyaWN0IFRvIEJlIENvb2wg KioqCj4gPgo+ID4KPiA+Cj4gPgo+ID4KPiA+Cj4KPgo+IC0tCj4gPE06RC8+Cj4KPiBNLiBEYXZp ZCBQZXRlcnNvbgo+IGh0dHA6Ly93d3cueHNsdGJsb2cuY29tLwo+CgoKCi0tIAo8TTpELz4KCk0u IERhdmlkIFBldGVyc29uCmh0dHA6Ly93d3cueHNsdGJsb2cuY29tLwo= ------=_Part_35481_20094333.1149846891633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline TGV0cyB0cnkgdGhpcyBhZ2FpbiB0byBldmVyeW9uZSBpbnN0ZWFkIG9mIGp1c3QgS2FybCA6KSAo c29ycnkgZm9yIHRoZSBkdXBsaWNhdGUsIEthcmwhKTxicj48YnI+QW5kIHRoZSBmaWxlIGFjY2Vz cyBwcm9ibGVtIGlzIG5vdyBmaXhlZC48YnI+LS0tPGJyPjxicj5vb29wcy4uLiBmb3Jnb3QgdG8g YWRkIHRoZSBbMV0gZm9vdGVyLjxicj48YnI+SSB3YXMgaW50ZW5kaW5nIHRoaXMgdG8KYmUgYSBx dWVzdGlvbjombmJzcDsgQ2FuIHRoZXJlIGJlIG1vcmUgdGhhbiBvbmUgY2F0ZWdvcnkgZWxlbWVu dCB3aXRoIHRoZQpzYW1lIHZhbHVlIGZvciBsYWJlbD8mbmJzcDsgSSBuZWVkIHRvIGxvb2sgdGhp cyB1cCwgYnV0IGlmIGFueWJvZHkga25vd3Mgb2ZmCmhhbmQgSSB3b3VsZCBhcHByZWNpYXRlIHRo ZSB0aW1lIHNhdmVkLgo8YnI+PGJyPklmIHRoZXkgY2FuIG5vdCwgdGhlbiBuYW1lc3BhY2VzIGNv bWUgaW50byBwbGF5IHRvIGFsbG93CnNvbWVoaW5nIGxpa2UgbGljZW5zZTpjYy1ieS1zYS4mbmJz cDsgQW5kIHllcywgSSBoYXZlIHRoZSBjb2RlIGF2YWlsYWJsZSB0bwptYWtlIGVhc3kgdGhlIHBy b2JsZW0gd2l0aCBRTmFtZXMgaW4gY29udGVudC4mbmJzcDsgSW4gZmFjdCwgaWYgeW91IGFjY2Vz cwpbMV0sIFsyXSB5b3UgY2FuIHByb2JhYmx5IGZpZ3VyZSBvdXQgZm9yIHlvdXJzZWxmIHdoYXQg SSBhbSByZWZlcmluZwp0by4mbmJzcDsgSSB3b3VsZCBuZWVkIHRvIGN1c3RvbWl6ZSB0aGUgY29k ZSBiYXNlIHRvIGJlIGEgYml0IG1vcmUgc3BlY2lmaWMsCmJ1dCB0aGF0cyBub3QgYSBiaWcgaXNz dWUgYXMgaXRzIGxlc3MgdGhlbiAxMCBtaW51dGVzIHdvcnRoIG9mIGNvZGluZy4KPGJyPjxicj5P bmUgdGhpbmcgSSBqdXN0IG5vdGljZWQgd2hlbiB2aXNpdGluZyB0aGUgc2Vjb25kIGxpbmsgaXMg dGhhdAp0aGUgc291cmNlIGZpbGVzIHNlZW0gdG8gYmUgaW5hY2Nlc3NpYmxlLiZuYnNwOyBJJ2xs IHNlZSB3aGF0IHRoZSBwcm9ibGVtCmlzLCBhbmQgaWYgbmVjZXNzYXJ5IHBsYWNlIHRoZSBmaWxl cyBvbiBhbm90aGVyIHNlcnZlciBhbmQgdXBkYXRlIHRoYXQKcG9zdCBhY2NvcmRpbmdseS4mbmJz cDsgSWYgeW91IGZpbmQgdGhleSBhcmUgdW5hY2Nlc3NpYmxlLCB0aGlzIGlzIHdoeSwKYWx0aG91 Z2ggSSBhbSBnb2luZyB0byBsb29rIGludG8gdGhpcyBub3csIHNvIGJ5IHRoZSB0aW1lIGFueW9u ZSBvdGhlcgp0aGFuIHRob3NlIGluIEV1cm9wZSsgcmVhZCB0aGlzLCBpdCBzaG91bGQgbW9zdCBk ZWZpbml0ZWx5IGJlIGZpeGVkLgo8YnI+PGJyPlsxXSA6IDxhIGhyZWY9Imh0dHA6Ly93d3cub3Jl aWxseW5ldC5jb20veG1sL2Jsb2cvMjAwNS8wOC9wYXJ0XzJfYXNzZXRzX2F0b21fZmVlZHNfYW5k X2EuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3Lm9yZWlsbHluZXQuY29tL3htbC9ibG9n LzIwMDUvMDgvcGFydF8yX2Fzc2V0c19hdG9tX2ZlZWRzX2FuZF9hLmh0bWwKPC9hPjxicj5bMl0g OiA8YSBocmVmPSJodHRwOi8vd3d3Lm9yZWlsbHluZXQuY29tL3htbC9ibG9nLzIwMDUvMDkvcGFy dF8zX2Fzc2V0c19hdG9tX2ZlZWRzX2FuZF9hLmh0bWwiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cmh0dHA6Ly93 d3cub3JlaWxseW5ldC5jb20veG1sL2Jsb2cvMjAwNS8wOS9wYXJ0XzNfYXNzZXRzX2F0b21fZmVl ZHNfYW5kX2EuaHRtbDwvYT48YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5P biA2LzkvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5NLiBEYXZpZCBQZXRlcnNvbjwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzp4bWxoYWNrZXJAZ21haWwuY29tIj4KeG1saGFja2VyQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2PjxzcGFuIGNs YXNzPSJxIj4mZ3Q7Jmd0OyAxLiBGZWVkIGNvbXBvc2VkIHdpdGggbXVsdGlwbGUgc291cmNlcyB3 aXRoIGRpZmZlcmVudCBsaWNlbnNlcy4KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4g YSBmZWVkIGFnZ3JlZ2F0b3IgY3JlYXRlcyBhIGZlZWQgZnJvbSBkaWZmZXJlbnQgc291cmNlczxi cj4oZmVlZHMpIHdpdGggZGlmZmVyZW50IGxpY2Vuc2VzLCB3aGF0IHNob3VsZCBiZSB0aGUgbGlj ZW5zZSBvZiB0aGU8YnI+cmVzdWx0aW5nIGZlZWQ/ICZsdDsmbHQ7Cjxicj48YnI+PC9zcGFuPjwv ZGl2PjxkaXY+VmVyeSBpbXBvcnRhbnQgcG9pbnQgS2FybCEmbmJzcDsgVGhhbmtzIGZvciBicmlu Z2luZyBpdCB0byB0aGUgc3VyZmFjZSA6KTwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9InEiPjxicj48 YnI+Jmd0OyZndDsgRGVmaW5pbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgYXR0cmlidXRlL2VsZW1l bnQgaXMgY29vbCwgYnV0IG9uIHRoZTxicj5zaWRlIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBpdCdz IG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSBieSBjb25zdW1pbmcKPGJyPnByb2R1Y3RzLiBBcyBJ IHNhaWQgaW4gYSBwcmV2aW91cyBtZXNzYWdlLCBpdCdzIGEgdG91Z2ggcHJvYmxlbS4gJmx0OyZs dDs8YnI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2Pkl0ICpzZWVtcyogdGhhdCB0aGUgY2F0ZWdvcnkg ZWxlbWVudCB3aXRoIEBzY2hlbWUsIEBsYWJlbCwgQHRlcm0gY291bGQgYWN0IHBhcnRpY3VsbGFy eSB3ZWxsIGluIHJlZ2FyZHMgdG8gYWxsb3dpbmcgZm9yIGEgaHVtYW4gcmVhZGFibGUgZGVmaW5p dGlvbiwgYSBodW1hbi9tYWNoaW5lIHJlYWRhYmxlIGxhYmVsLCBhbmQgYSBodW1hbiBidXQgbW9y ZSBpbXBvcnRhbnRseSBtYWNoaW5lIHJlYWRhYmxlIHNjaGVtZSB0aGF0IGNvdWxkIHJlcHJlc2Vu dCB0aGUgJnF1b3Q7cnVsZXMmcXVvdDsgZGVmaW5pdGlvbiBmaWxlIGluIHdoaWNoIGNvdWxkIGJl IHBhcnNlZCBhbmQgdXNlZCBhcyB0aGUgcGFzcy9mYWlsIG1ldGhvZCB0byBkZXRlcm1pbmUgd2hp Y2ggbGljZW5zZSBib3RoIGNhbiBhcHBseSBhcyB3ZWxsIGFzIHdoaWNoIG9uZSBiZXN0IGFwcGxp ZXMgdG8gdGhlIHNpdHVhdGlvbi4KPGJyPjxicj5XaGF0IEkgbWVhbiBieSB0aGlzIGlzIHRoYXQg aWYgdGhlcmUgd2VyZSB0aHJlZSBjYXRlZ29yeSBlbGVtZW50cyBpbiB3aGljaCBlYWNoIGNvbnRh aW5lZCBAbGFibGU9JnF1b3Q7bGljZW5zZSZxdW90OyBbMV0sIGlmIGEgYmVzdCBwcmFjdGljZXMg ZG9jIHN1Z2dlc3RlZCBvcmRlcmluZyB0aGVtIGZyb20gbW9zdCBjb25maW5pbmcgdG8gbGVhc3Qg KHVzaW5nIGEgMTAwJSBjb21tZXJjaWFsIHVzZSAmZ3Q7IDEwMCUgbm9uLWNvbW1lcmNpYWwgKG9y IHdvdWxkIHRoYXQgbmVlZCB0byBiZSB0aGUgb3RoZXIgd2F5IGFyb3VuZCB0byBtYWtlIHByb3Bl ciBzZW5zZT8pIHVzZSBwYXR0ZXJuIGZvciBvcmRlcmluZyB0aGUgY2F0ZWdvcnkgZWxlbWVudHMp LCB0aGVuIGFzIHNvb24gYXMgdGhleSByZWFjaGVkIHRoZSBwb2ludCBpbiB3aGljaCB0aGV5IHBh c3NlZCBhbGwgcnVsZXMgZm9yIGEgZ2l2ZW4gc2NoZW1lLCB0aGUgbWFjaGluZSBjb3VsZCB0aGVt IHN0b3AgcHJvY2Vzc2luZyBzY2hlbWVzIGFuZCBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgcmVzdCBv ZiB0aGUgcHJvY2Vzc2luZyBiYXNlZCBvbiB0aGUgc2V0IG9mIHJ1bGVzIHNldCBmb3J0aCBpbiB0 aGUgY3VycmVudCAmcXVvdDtpbi1wcm9jZXNzJnF1b3Q7IHNjaGVtZS4mbmJzcDsgVAo8YnI+PGJy Pmhpcywgb2YgY291cnNlLCB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGJlc3Qgd2F5IHRvIGJ1aWxk IG91dCB0aGUgc2NoZW1lIGZpbGUgd291bGQgYmUgdG8gc3RhcnQgd2l0aCB0aGUgcGFzcy9mYWls ICZxdW90O3F1ZXN0aW9ucyZxdW90OyB0byB0aGVuIGZvbGxvdyB3aXRoIHdoYXQgY2FuIGFuZCBj YW4gbm90IGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgZmluYWwgb3V0cHV0LiZuYnNwOyBPYnZpb3Vz bHkgZnJvbSBhIG1hY2hpbmUgc3RhbmRwb2ludCB0aGlzIHdvdWxkIGFsbG93IGZvciB0aGUgbW9z dCBlZmZpY2llbnQgdXNhZ2Ugb2YgWE1MIGFzIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgdG8gY2xp bWIgdXAgYW5kIGRvd24gdGhlIHRyZWUgbG9va2luZyBmb3IgdGhlIG5leHQgc2V0IG9mIHByb2Nl c3NpbmcgcnVsZXMgb25jZSBhIDEwMCUgcGFzcyBsZXZlbCBoYXMgYmVlbiByZWFjaGVkLiZuYnNw OyBUaGlzIHdvdWxkIGFsbG93IGZvciBmb3J3YXJkIG9ubHkgcmVhZGVycyB0byBiZSBpbXBsZW1l bnRlZCwgYW5kIHdvdWxkIG9idmlvdXNseSB3b3JrIHdlbGwgd2l0aCB0aGUgc3RyZWFtaW5nIFNB WCsgaW1wbGVtZW50YXRpb25zLgo8YnI+PGJyPk9mIGNvdXJzZSB0aGlzIGxlYWRzIG5pY2VseSBp bnRvLi4uIDwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9InEiPjxicj48YnI+Jmd0OyZndDsgMi4gU2hv dWxkIHRoZXJlIGJlIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQgdG8gaW52aXRlIHRvb2xzPGJy PmRldmVsb3BlcnMgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IGxpY2Vuc2VzIG1lY2hhbmlz bT8mbmJzcDsmbmJzcDsoQXMgSTxicj4KdW5kZXJzdGFuZCBpdCdzIG5vdCB0aGUgcHVycG9zZSBv ZiB0aGlzIGRyYWZ0KS4gJmx0OyZsdDsKPGJyPjxicj48L3NwYW4+PC9kaXY+PGRpdj5ZZXMgcGxl YXNlISA6RDwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwYmI4MWY1MjI4NTk3N2Ff NiI+PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNi85LzA2LCA8YiBj bGFzcz0iZ21haWxfc2VuZGVybmFtZSI+S2FybCBEdWJvc3Q8L2I+ICZsdDs8YSBocmVmPSJtYWls dG86a2FybEB3My5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CmthcmxAdzMub3JnPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0 OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4 OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8YnI+UmVhZGluZyB0aGUgZXhhbXBsZSBmcm9tPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly9pZXRmcmVwb3J0Lmlzb2Mub3JnL2lkcmVmL2RyYWZ0LXNuZWxsLWF0b21wdWItZmVlZC1s aWNlbnNlLyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vaWV0ZnJlcG9ydC5pc29jLm9yZy9pZHJlZi9k cmFmdC1zbmVsbC1hdG9tcHViLWZlZWQtbGljZW5zZS8KPC9hPjxicj5bW1s8YnI+My4mbmJzcDsm bmJzcDtUaGUgJ2xpY2Vuc2UnIGxpbmsgcmVsYXRpb24KPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtBbiBBdG9tIGxpbmsgZWxlbWVudCB3aXRoIGEgJ3JlbCcgYXR0cmlidXRlIHZhbHVl IG9mICdsaWNlbnNlJyBpczxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VkIHRvIGFzc29j aWF0ZSBhIGNvcHlyaWdodCBsaWNlbnNlIHdpdGggYW4gQXRvbSBGZWVkIG9yIEVudHJ5Ljxicj48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXRvbSBlbnRyeSwgZmVlZCBhbmQgc291cmNlIGVs ZW1lbnRzIE1BWSBlYWNoIGNvbnRhaW4gYW55IG51bWJlciBvZgo8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7bGljZW5zZSBsaW5rcyBidXQgTVVTVCBOT1QgY29udGFpbiBtb3JlIHRoYW4gb25l IHdpdGggdGhlIHNhbWUgaHJlZjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt2YWx1ZS4mbmJz cDsmbmJzcDtUaGUgSVJJIHNwZWNpZmllZCBieSB0aGUgbGluaydzICdocmVmJyBhdHRyaWJ1dGUg U0hPVUxEIGJlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RlcmVmZXJlbmNlYWJsZSB0byBy ZXR1cm4gYSBtYWNoaW5lIG9yIGh1bWFuLXJlYWRhYmxlIHJlcHJlc2VudGF0aW9uCjxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtvZiB0aGUgbGljZW5zZS48YnI+PGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0ltcGxlbWVudG9ycyBzaG91bGQgbm90ZSB0aGF0LCB1bmxpa2UgdGhlIEF0b20g cmlnaHRzIGVsZW1lbnQsIHdoaWNoPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NwZWNpZmll cyBhIGh1bWFuLXJlYWRhYmxlIHN0YXRlbWVudCBvZiB0aGUgcmlnaHRzIGhlbGQgb3ZlciBhIGVu dHJ5PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yIGZlZWQsIGxpY2Vuc2UgbGlua3MgYXBw bHkgb25seSB0byB0aGUgaW5mb3JtYXRpb25hbCBjb250ZW50IG9mCjxicj50aGU8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29udGFpbmluZyBlbGVtZW50LiZuYnNwOyZuYnNwO1RoYXQgaXMs IHRoZSBwcmVzZW5jZSBvZiBhIGxpY2Vuc2UgbGluazxicj5yZWxhdGlvbjxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt3aXRoaW4gYW4gQXRvbSBmZWVkIGVsZW1lbnQgZG9lcyBub3QgZXh0ZW5k IGEgbGljZW5zZSBvdmVyIHRoZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt2YXJpb3VzIGNv bnRhaW5lZCBlbnRyeSBlbGVtZW50cy4mbmJzcDsmbmJzcDtMaWtld2lzZSwgdGhlIHByZXNlbmNl IG9mIGEKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xpY2Vuc2UgbGluayB3aXRoaW4gYW4g QXRvbSBzb3VyY2UgZWxlbWVudCBkb2VzIG5vdCBleHRlbmQgYSBsaWNlbnNlPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO292ZXIgdGhlIGluZm9ybWF0aW9uYWwgY29udGVudCBvZiB0aGUgY29u dGFpbmluZyBlbnRyeS48YnI+XV1dPGJyPjxicj4tLSBzbmVsbC1hdG9tcHViLWZlZWQtbGljZW5z ZS0wNi50eHQ8YnI+PGEgaHJlZj0iaHR0cDovL2lldGZyZXBvcnQuaXNvYy5vcmcvaWRyZWYvZHJh ZnQtc25lbGwtYXRvbXB1Yi1mZWVkLWxpY2Vuc2UvIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0i cmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPgoKaHR0cDovL2ll dGZyZXBvcnQuaXNvYy5vcmcvaWRyZWYvZHJhZnQtc25lbGwtYXRvbXB1Yi1mZWVkLWxpY2Vuc2Uv PC9hPjxicj4jcGFnZS0zPGJyPlRodSwgMTMgQXByIDIwMDYgMTk6Mjc6NTQgR01UPGJyPjxicj48 YnI+IyBTb21lIHF1ZXN0aW9ucyBhYm91dCBzcGVjaWZpYyB1c2UgY2FzZXM8YnI+PGJyPjEuIEZl ZWQgY29tcG9zZWQgd2l0aCBtdWx0aXBsZSBzb3VyY2VzIHdpdGggZGlmZmVyZW50IGxpY2Vuc2Vz Lgo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBhIGZlZWQgYWdncmVnYXRvciBjcmVh dGVzIGEgZmVlZCBmcm9tIGRpZmZlcmVudCBzb3VyY2VzPGJyPihmZWVkcykgd2l0aCBkaWZmZXJl bnQgbGljZW5zZXMsIHdoYXQgc2hvdWxkIGJlIHRoZSBsaWNlbnNlIG9mIHRoZTxicj5yZXN1bHRp bmcgZmVlZD88YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ZlZWQgKGxpY2Vuc2UgPz8/ KTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW50cnkgKGxpY2Vuc2Ug QSkgZnJvbSBmZWVkIFgKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBl bnRyeSAobGljZW5zZSBCKSBmcm9tIGZlZWQgWTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZW50cnkgKGxpY2Vuc2UgQikgZnJvbSBmZWVkIFk8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudHJ5IChsaWNlbnNlIEEpIGZyb20gZmVlZCBYPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnRyeSAobGljZW5zZSBDKSBm cm9tIGZlZWQgWjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCmPGJy Pjxicj5EZWZpbmluZyB0aGUgc2VtYW50aWNzIG9mIHRoZSBhdHRyaWJ1dGUvZWxlbWVudCBpcyBj b29sLCBidXQgb24gdGhlCjxicj5zaWRlIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBpdCdzIG5vdCBj bGVhciB3aGF0IHNob3VsZCBiZSBieSBjb25zdW1pbmc8YnI+cHJvZHVjdHMuIEFzIEkgc2FpZCBp biBhIHByZXZpb3VzIG1lc3NhZ2UsIGl0J3MgYSB0b3VnaCBwcm9ibGVtLjxicj48YnI+Mi4gU2hv dWxkIHRoZXJlIGJlIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQgdG8gaW52aXRlIHRvb2xzPGJy PmRldmVsb3BlcnMgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IGxpY2Vuc2VzIG1lY2hhbmlz bT8mbmJzcDsmbmJzcDsoQXMgSQo8YnI+dW5kZXJzdGFuZCBpdCdzIG5vdCB0aGUgcHVycG9zZSBv ZiB0aGlzIGRyYWZ0KS48YnI+PGJyPjxicj48YnI+PGJyPjxicj4tLTxicj5LYXJsIER1Ym9zdCAt IDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1Blb3BsZS9rYXJsLyIgdGFyZ2V0PSJfYmxhbmsi IG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5o dHRwOi8vd3d3LnczLm9yZy9QZW9wbGUva2FybC8KPC9hPjxicj5XM0MgQ29uZm9ybWFuY2UgTWFu YWdlciwgUUEgQWN0aXZpdHkgTGVhZDxicj4mbmJzcDsmbmJzcDsgUUEgV2VibG9nIC0gCjxhIGhy ZWY9Imh0dHA6Ly93d3cudzMub3JnL1FBLyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LnczLm9y Zy9RQS88L2E+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyoqKiBCZSBT dHJpY3QgVG8gQmUgQ29vbCAqKio8YnI+PGJyPjxicj48YnI+PGJyPjxicj48L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj4KPGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGNs YXNzPSJlIiBpZD0icV8xMGJiODFmNTIyODU5NzdhXzciPi0tIDxicj4mbHQ7TTpELyZndDs8YnI+ PGJyPk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cueHNsdGJsb2cuY29t LyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIj4KaHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPgo8L3NwYW4+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj4mbHQ7 TTpELyZndDs8YnI+PGJyPk0uIERhdmlkIFBldGVyc29uPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cu eHNsdGJsb2cuY29tLyI+aHR0cDovL3d3dy54c2x0YmxvZy5jb20vPC9hPgo= ------=_Part_35481_20094333.1149846891633-- From owner-atom-syntax@mail.imc.org Fri Jun 09 10:27:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohxX-0005DZ-Bw for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 10:27:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohxV-0004Ns-WC for atompub-archive@lists.ietf.org; Fri, 09 Jun 2006 10:27: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 k59E2gpp076647; Fri, 9 Jun 2006 07:02: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 k59E2gjC076645; Fri, 9 Jun 2006 07:02: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 k59E2faT076633 for ; Fri, 9 Jun 2006 07:02:42 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i31so88285wra for ; Fri, 09 Jun 2006 07:02: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=GTyHYinigVPgaDiZ/sap2ofXvgaj+Qd84lMwAY4aHSDvZzzg9gKQtcF3lnwpukF/0JVErfoH4zWqaRns4xkmz61Jz+B3e3k034/IqM3o1LWScw8AkIY9rGZki+5KMeXrGcUIJr966ZYjG1ffha/qvGMtnZZe/isthx7yczmLZzc= Received: by 10.54.128.19 with SMTP id a19mr1899603wrd; Fri, 09 Jun 2006 07:02:41 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 27sm4313749wrl.2006.06.09.07.02.40; Fri, 09 Jun 2006 07:02:41 -0700 (PDT) Message-ID: <44897F7E.8020602@gmail.com> Date: Fri, 09 Jun 2006 07:02:38 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Copyright, licensing, and feeds 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: 9466e0365fc95844abaf7c3f15a05c7d Eric Scheid wrote: > On 9/6/06 4:23 PM, "Karl Dubost" wrote: > >> 1. Feed composed with multiple sources with different licenses. >> When a feed aggregator creates a feed from different sources >> (feeds) with different licenses, what should be the license of the >> resulting feed? >> >> feed (license ???) >> entry (license A) from feed X >> entry (license B) from feed Y >> entry (license B) from feed Y >> entry (license A) from feed X >> entry (license C) from feed Z > > either no license element at the the feed level (since every entry has their > own license), or maybe a license that refers to the collection (eg. you > could expose a license for your Top 10 List without necessarily claiming any > license for the 10 items in the list). > In the Feed License Draft, feed's a licensed independently of their contained entries. There is no interaction between the licenses. - James From owner-atom-syntax@mail.imc.org Sat Jun 10 00:49:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FovPx-0007vF-7w for atompub-archive@lists.ietf.org; Sat, 10 Jun 2006 00:49:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FovPr-0002eL-Of for atompub-archive@lists.ietf.org; Sat, 10 Jun 2006 00:49: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 k5A4Xv3v098117; Fri, 9 Jun 2006 21: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 k5A4XvOq098115; Fri, 9 Jun 2006 21: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 pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5A4XtBO097804 for ; Fri, 9 Jun 2006 21:33:56 -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); Sat, 10 Jun 2006 14:18:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 10 Jun 2006 14:17:59 +1000 Subject: Re: Copyright, licensing, and feeds From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <44897F7E.8020602@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: d17f825e43c9aed4fd65b7edddddec89 On 10/6/06 12:02 AM, "James M Snell" wrote: > In the Feed License Draft, feed's a licensed independently of their > contained entries. There is no interaction between the licenses. Ah, no inheritance. Makes sense really, since if that was in the spec it would fail for aggregators that are not aware of that inheritance. e. From owner-atom-syntax@mail.imc.org Mon Jun 12 12:20:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpp9U-00035D-Fb for atompub-archive@lists.ietf.org; Mon, 12 Jun 2006 12:20:32 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpp9T-0000s1-2t for atompub-archive@lists.ietf.org; Mon, 12 Jun 2006 12:20: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 k5CG03dq075125; Mon, 12 Jun 2006 09:00: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 k5CG03qM075124; Mon, 12 Jun 2006 09:00: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 [10.20.30.249] (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 k5CG00qN075056; Mon, 12 Jun 2006 09:00:02 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 Jun 2006 08:59:58 -0700 To: Atom WG , atom-protocol@imc.org From: Paul Hoffman Subject: Re: 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: 8b431ad66d60be2d47c7bfeb879db82c At 1:49 PM -0700 5/23/06, 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! We are tentatively scheduled for Wednesday afternoon; see . I say "tentatively" because the schedule will probably shift a bit for the next two weeks; my guess is that we are 80% likely to stay in the same spot. I have not received any offers to talk about "Overlap with calendar formats" or "Overlap with mail" at the BoF, but am still quite receptive to people making such offers. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Jun 14 15:27:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqb1i-0001Yl-OA for atompub-archive@lists.ietf.org; Wed, 14 Jun 2006 15:27:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqb1g-00065i-4y for atompub-archive@lists.ietf.org; Wed, 14 Jun 2006 15:27:42 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5EI291U058646; Wed, 14 Jun 2006 11: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 k5EI29PM058645; Wed, 14 Jun 2006 11: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5EI24rd058607 for ; Wed, 14 Jun 2006 11:02:08 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 45595 invoked by uid 17064); 14 Jun 2006 18:02:03 -0000 Received: from unknown (HELO [10.20.30.24]) ([195.101.242.1]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 14 Jun 2006 18:02:03 -0000 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: atom-syntax Syntax From: Henry Story Subject: Atom N3 Date: Wed, 14 Jun 2006 20:02:00 +0200 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: 9182cfff02fae4f1b6e9349e01d62f32 A new, clearer more concise ontology for atom is now available at https://sommer.dev.java.net/atom/ It comes with an XSLT style sheet to transform atom feeds into turtle, a subset of N3 [1], and is released under a BSD license. Please feel free to contribute bug reports, patches and any other feedback to me or to the mailing list at http://groups.google.com/ group/atom-owl/ Sincerely, Henry Story [1] http://blogs.sun.com/roller/page/bblfish/20060614 Home page: http://bblfish.net/ Sun Blog: http://blogs.sun.com/bblfish/ From owner-atom-syntax@mail.imc.org Sat Jun 17 20:05:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrknV-0004j4-6G for atompub-archive@lists.ietf.org; Sat, 17 Jun 2006 20:05:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrknS-0007Nk-P4 for atompub-archive@lists.ietf.org; Sat, 17 Jun 2006 20:05: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 k5HMpokv072066; Sat, 17 Jun 2006 15:51: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 k5HMposG072065; Sat, 17 Jun 2006 15:51: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 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 k5HMpmwm072052 for ; Sat, 17 Jun 2006 15:51:48 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so903018nfc for ; Sat, 17 Jun 2006 15:51: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:mime-version:content-type; b=SsfU3zSCfNAcQjYhIhnqOVrSI+vX6uQ+Dg7kIfAvthQI0/2B0JCtnjdzaLzeMYZ97IErT3J2yvxxC7trWnJFc8R6Pj/xbPOXLo+8g4LT/4xxANYPIxgA2Tpay5wVjGyrlq+mFHDLMyA7WN17G2xDqNmTsTG9Bq6lyValMat3g9M= Received: by 10.48.242.19 with SMTP id p19mr4024299nfh; Sat, 17 Jun 2006 15:51:46 -0700 (PDT) Received: by 10.49.34.9 with HTTP; Sat, 17 Jun 2006 15:51:46 -0700 (PDT) Message-ID: Date: Sat, 17 Jun 2006 16:51:46 -0600 From: "M. David Peterson" To: "atom-syntax Syntax" Subject: Atom in the latest Indigo MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_133380_16866862.1150584706906" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_Part_133380_16866862.1150584706906 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I assume you all are already aware, but just in case > http://blogs.msdn.com/yassers/archive/2006/06/15/632436.aspx If not mistaken, I think this would allow me to pretty much kill the AtomicRSS project. Yay! Less projects on my plate is ALWAYS a good thing :D -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 ------=_Part_133380_16866862.1150584706906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I assume you all are already aware, but just in case > http://blogs.msdn.com/yassers/archive/2006/06/15/632436.aspx

If not mistaken, I think this would allow me to pretty much kill the AtomicRSS project.

Yay! Less projects on my plate is ALWAYS a good thing :D

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 ------=_Part_133380_16866862.1150584706906-- From owner-atom-syntax@mail.imc.org Sun Jun 18 03:48:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frs0o-0005u4-Ps for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 03:48:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frs0m-0004j9-C7 for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 03:48: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 k5I7V7Nm093577; Sun, 18 Jun 2006 00:31: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 k5I7V7NU093576; Sun, 18 Jun 2006 00:31: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 smtp.planeetta.net (smtp.planeetta.net [84.234.64.6]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5I7V6Kr093534 for ; Sun, 18 Jun 2006 00:31:06 -0700 (MST) (envelope-from boss@gregerhaga.net) Received: from web02.planeetta.net (web02.planeetta.net [84.234.64.202]) by smtp.planeetta.net (8.12.10/8.12.10) with ESMTP id k5I7Uxic021904 for ; Sun, 18 Jun 2006 10:31:00 +0300 Received: (qmail 541 invoked from network); 18 Jun 2006 10:30:59 +0300 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 Jun 2006 10:30:59 +0300 Received: from a85-156-202-37.elisa-laajakaista.fi (a85-156-202-37.elisa-laajakaista.fi [85.156.202.37]) by webmail.gregerhaga.net (Horde MIME library) with HTTP; Sun, 18 Jun 2006 10:30:59 +0300 Message-ID: <20060618103059.tl519957cwg0448c@webmail.gregerhaga.net> Date: Sun, 18 Jun 2006 10:30:59 +0300 From: boss@gregerhaga.net To: "M. David Peterson" Cc: atom-syntax Syntax Subject: Re: Atom in the latest Indigo References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Quoting "M. David Peterson" : > I assume you all are already aware, but just in case > > http://blogs.msdn.com/yassers/archive/2006/06/15/632436.aspx > > If not mistaken, I think this would allow me to pretty much kill the > AtomicRSS project. > > Yay! Less projects on my plate is ALWAYS a good thing :D > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 and what is special about that? Just a way to generate feeds. -- http://www.gregerhaga.net From owner-atom-syntax@mail.imc.org Sun Jun 18 05:49:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frtuj-0000cJ-NN for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 05:49:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frtuh-0005ep-8T for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 05:49: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 k5I8bjbe008875; Sun, 18 Jun 2006 01:37: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 k5I8bjNB008874; Sun, 18 Jun 2006 01:37: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.190]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5I8bhj3008859 for ; Sun, 18 Jun 2006 01:37:44 -0700 (MST) (envelope-from xmlhacker@gmail.com) Received: by nf-out-0910.google.com with SMTP id c31so938340nfb for ; Sun, 18 Jun 2006 01:37: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:references; b=Yf892B54/70OP0wja8qkL0R7JXDOM4uyod3bqjzJo8WrYDLf/gzkAOBB/HWXbDfx8ZgI/UeAvNW7lc9gpY07sQRhILAeOcPml/Rcc7bRMEg6O/vqes0dBKYcyNAGJ8qzKehWW8FntM4fbluc8xgWkoUyHOnyFFZ481cUqxbJJOY= Received: by 10.48.216.14 with SMTP id o14mr4317311nfg; Sun, 18 Jun 2006 01:37:42 -0700 (PDT) Received: by 10.49.34.9 with HTTP; Sun, 18 Jun 2006 01:37:42 -0700 (PDT) Message-ID: Date: Sun, 18 Jun 2006 02:37:42 -0600 From: "M. David Peterson" To: "boss@gregerhaga.net" Subject: Re: Atom in the latest Indigo Cc: "atom-syntax Syntax" In-Reply-To: <20060618103059.tl519957cwg0448c@webmail.gregerhaga.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_134793_31499248.1150619862624" References: <20060618103059.tl519957cwg0448c@webmail.gregerhaga.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.6 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a ------=_Part_134793_31499248.1150619862624 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Generate Atom feeds natively, yes. I need to study it more, but from first look it seems that this would allow for a MUCH simpler way to extract the data from the feed engine, and output the feed as Atom instead of the cross-over RSS that is currently output. But again, I need to look into this more... I may be assuming to much here... On 6/18/06, boss@gregerhaga.net wrote: > > Quoting "M. David Peterson" : > > > I assume you all are already aware, but just in case > > > http://blogs.msdn.com/yassers/archive/2006/06/15/632436.aspx > > > > If not mistaken, I think this would allow me to pretty much kill the > > AtomicRSS project. > > > > Yay! Less projects on my plate is ALWAYS a good thing :D > > > > -- > > /M:D > > > > M. David Peterson > > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 > > and what is special about that? Just a way to generate feeds. > -- > http://www.gregerhaga.net > > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 ------=_Part_134793_31499248.1150619862624 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Generate Atom feeds natively, yes.  I need to study it more, but from first look it seems that this would allow for a MUCH simpler way to extract the data from the feed engine, and output the feed as Atom instead of the cross-over RSS that is currently output.

But again, I need to look into this more...  I may be assuming to much here...

On 6/18/06, boss@gregerhaga.net <boss@gregerhaga.net> wrote:
Quoting "M. David Peterson" < xmlhacker@gmail.com>:

> I assume you all are already aware, but just in case >
> http://blogs.msdn.com/yassers/archive/2006/06/15/632436.aspx
>
> If not mistaken, I think this would allow me to pretty much kill the
> AtomicRSS project.
>
> Yay! Less projects on my plate is ALWAYS a good thing :D
>
> --
> /M:D
>
> M. David Peterson
> http://mdavid.name | http://www.oreillynet.com/pub/au/2354

and what is special about that? Just a way to generate feeds.
--
http://www.gregerhaga.net




--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 ------=_Part_134793_31499248.1150619862624-- From owner-atom-syntax@mail.imc.org Sun Jun 18 08:40:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrwZQ-0000Zr-Mw for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 08:40:04 -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 1FrwZQ-0000yB-LR for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 08:40:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FrwXB-0005B6-HX for atompub-archive@lists.ietf.org; Sun, 18 Jun 2006 08:37: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 k5ICOntY060002; Sun, 18 Jun 2006 05:24:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5ICOnQa060001; Sun, 18 Jun 2006 05:24:49 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from atlas.jabber.org (postfix@atlas.jabber.org [208.245.212.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5ICOmft059995 for ; Sun, 18 Jun 2006 05:24:49 -0700 (MST) (envelope-from stpeter@atlas.jabber.org) Received: by atlas.jabber.org (Postfix, from userid 1005) id 0664E21A39F; Sun, 18 Jun 2006 07:24:47 -0500 (CDT) From: "Peter Saint-Andre" To: atom-syntax@mail.imc.org Subject: Please confirm (conf#b9cfd6842edca838fe933fde4ef35abe) Date: Sun, 18 Jun 2006 07:24:47 CDT X-AskVersion: 2.5.2 (http://www.paganini.net/ask) X-ASK-Auth: 1150633487-c43c61bbe0fd913c1726f0a1b1b894a4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit In-Reply-To: <20060618122437.48CFA21A4D7@atlas.jabber.org> Message-Id: <20060618122447.0664E21A39F@atlas.jabber.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 << IMPORTANT INFORMATION! >> This is an automated message. The message you sent (attached below) requires confirmation before it can be delivered. To confirm that you sent the message below, just hit the "R"eply button and send this message back (you don't need to edit anything). Once this is done, no more confirmations will be necessary. This email account is protected by: Active Spam Killer (ASK) V2.5.2 - (C) 2001-2004 by Marco Paganini For more information visit http://www.paganini.net/ask --- Original Message Follows --- From: atom-syntax@mail.imc.org To: stpeter@jabber.org Subject: STPETER@JABBER.ORG (Original message truncated) From owner-atom-syntax@mail.imc.org Mon Jun 19 10:09:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKRN-0000zL-S7 for atompub-archive@lists.ietf.org; Mon, 19 Jun 2006 10:09:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKQs-0000gc-IB for atompub-archive@lists.ietf.org; Mon, 19 Jun 2006 10:08: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 k5JDuOj0076597; Mon, 19 Jun 2006 06:56: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 k5JDuOMH076596; Mon, 19 Jun 2006 06:56: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JDuOkE076585 for ; Mon, 19 Jun 2006 06:56:24 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 94563 invoked by uid 17064); 19 Jun 2006 13:56:23 -0000 Received: from unknown (HELO [192.168.30.13]) ([84.4.17.74]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Jun 2006 13:56:23 -0000 In-Reply-To: <4496A74F.2090906@rbg.informatik.tu-darmstadt.de> References: <4496A74F.2090906@rbg.informatik.tu-darmstadt.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E290F96-DD38-4859-9ECE-AA9C91ED73B8@bblfish.net> Cc: Atom Syntax , atom-owl@googlegroups.com Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Dublin Core and Atom: Any plans for an (Informational) RFC? Date: Mon, 19 Jun 2006 15:56:18 +0200 To: Andreas Sewe 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: ea4ac80f790299f943f0a53be7e1a21a The Atom-OWL group is working on an ontology for Atom. You can find the latest version here https://sommer.dev.java.net/atom/ It comes with a XSLT 2.0 and XQuery 1.0 transform from atom xml to atom-owl. (The XQuery transform is the best). We were thinking of adding relations from the atom-owl vocabulary to the DC vocabulary. Have a look at what is there now, and let us know what you think. Henry On 19 Jun 2006, at 15:31, Andreas Sewe wrote: > > I wonder whether there are any plans of publishing an (perhaps > Informational) RFC on the use of DCMI Metadata Terms in conjunction > with Atom feeds and entries? > > Given both the popularity of that vocabulary in the various flavors > of RSS and the fact that it offers numerous useful refinements of > Atom's built-in metadata (I still remember the PaceDate* debate), > this seems like a good idea to me. So, are there already efforts in > this direction? > > Regards, > > Andreas Sewe From owner-atom-syntax@mail.imc.org Mon Jun 19 10:50:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsL5C-0002Z8-Ea for atompub-archive@lists.ietf.org; Mon, 19 Jun 2006 10:50:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsL5A-0005Ms-Pn for atompub-archive@lists.ietf.org; Mon, 19 Jun 2006 10:50: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 k5JDW7Xn073090; Mon, 19 Jun 2006 06:32: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 k5JDW7lY073089; Mon, 19 Jun 2006 06:32: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JDW5Wh073080 for ; Mon, 19 Jun 2006 06:32:06 -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 1FsJrI-0005W2-Nw for atom-syntax@imc.org; Mon, 19 Jun 2006 15:32:04 +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 1FsJrI-0003wu-K1 for atom-syntax@imc.org; Mon, 19 Jun 2006 15:32:04 +0200 Message-ID: <4496A74F.2090906@rbg.informatik.tu-darmstadt.de> Date: Mon, 19 Jun 2006 15:31:59 +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: Dublin Core and Atom: Any plans for an (Informational) RFC? 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: 1ac7cc0a4cd376402b85bc1961a86ac2 I wonder whether there are any plans of publishing an (perhaps Informational) RFC on the use of DCMI Metadata Terms in conjunction with Atom feeds and entries? Given both the popularity of that vocabulary in the various flavors of RSS and the fact that it offers numerous useful refinements of Atom's built-in metadata (I still remember the PaceDate* debate), this seems like a good idea to me. So, are there already efforts in this direction? Regards, Andreas Sewe From owner-atom-syntax@mail.imc.org Fri Jun 23 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 1FtrH9-00018j-A7 for atompub-archive@lists.ietf.org; Fri, 23 Jun 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 1FtrH5-0003wk-U1 for atompub-archive@lists.ietf.org; Fri, 23 Jun 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 k5NJ78ne074815; Fri, 23 Jun 2006 12:07: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 k5NJ78ZS074814; Fri, 23 Jun 2006 12:07: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 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 k5NJ76rr074793 for ; Fri, 23 Jun 2006 12:07:07 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i23so672068wra for ; Fri, 23 Jun 2006 12:07: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=TOBOiGXc6t0hepBfwPGy+467qzsk80HYkFpFvRrBm7JM42DZT0WaV9q6hkGQRhSGkccSVSqEcxMjQzMlvL6/7v+KGeLFR+0lORNk5Uh4F0IhS0ijYQTPQp0hykvybRYBNrpYjSeVTlnvRT64coHfkojjJoJznkCn2+USea9W6p4= Received: by 10.54.98.5 with SMTP id v5mr3658824wrb; Fri, 23 Jun 2006 12:07:06 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 29sm1428274wrl.2006.06.23.12.07.02; Fri, 23 Jun 2006 12:07:05 -0700 (PDT) Message-ID: <449C3BD4.3070203@gmail.com> Date: Fri, 23 Jun 2006 12:07:00 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax Subject: Feed Thread approved as a Proposed Standard 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 Just a general FYI.. The IESG has approved the Atom Threading Extensions (aka "feed thread") as a Proposed Standard making it the first standardized syndication extension. It is now in the RFC Editors queue and will be assigned an RFC #. I would like to extend my thanks and appreciation to the members of the WG who offered constructive feedback on the spec. I know we all didn't see eye-to-eye on various aspects of the extension, but the spec was significantly improved through the open discussions and debate we had here on the list. - James From owner-atom-syntax@mail.imc.org Fri Jun 23 15:44:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtraI-0003JY-0E for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 15:44:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtraG-0004Tz-LO for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 15:44: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 k5NJYocJ082065; Fri, 23 Jun 2006 12:34: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 k5NJYouX082063; Fri, 23 Jun 2006 12:34: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.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5NJYmIA082031 for ; Fri, 23 Jun 2006 12:34:49 -0700 (MST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 23 Jun 2006 19:34:43 -0000 Received: from p508FBF43.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.191.67] by mail.gmx.net (mp028) with SMTP; 23 Jun 2006 21:34:43 +0200 X-Authenticated: #1915285 Message-ID: <449C424E.4020304@gmx.de> Date: Fri, 23 Jun 2006 21:34:38 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: James M Snell CC: atom-syntax Subject: Re: Feed Thread approved as a Proposed Standard References: <449C3BD4.3070203@gmail.com> In-Reply-To: <449C3BD4.3070203@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d James M Snell schrieb: > Just a general FYI.. > > The IESG has approved the Atom Threading Extensions (aka "feed thread") > as a Proposed Standard making it the first standardized syndication > extension. It is now in the RFC Editors queue and will be assigned an > RFC #. > > I would like to extend my thanks and appreciation to the members of the > WG who offered constructive feedback on the spec. I know we all didn't > see eye-to-eye on various aspects of the extension, but the spec was > significantly improved through the open discussions and debate we had > here on the list. Congratulations. Related to this, I'd still like to find out the background history on why this is on the standards track. It was claimed that extensions to standards track documents need to be on the standards track as well, but that doesn't seem to be correct, as far as I can tell. It certainly doesn't make sense (because it would prohibit experimental extensions to standards track protocols), nor does it reflect past decisions (for instance, see RFC2774 and RFC4437). (sorry for getting off-topic) Best regards, Julian From owner-atom-syntax@mail.imc.org Fri Jun 23 16:26:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsEN-0007Wq-1w for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:26:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsEL-0001UK-My for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:26: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 k5NKFb2R092059; Fri, 23 Jun 2006 13:15: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 k5NKFbSU092058; Fri, 23 Jun 2006 13:15: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 [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 k5NKFWa7092035; Fri, 23 Jun 2006 13:15:32 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <449C424E.4020304@gmx.de> References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> Date: Fri, 23 Jun 2006 13:15:30 -0700 To: Julian Reschke , James M Snell From: Paul Hoffman Subject: Re: Feed Thread approved as a Proposed Standard Cc: atom-syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 At 9:34 PM +0200 6/23/06, Julian Reschke wrote: >Related to this, I'd still like to find out the background history >on why this is on the standards track. It was claimed that >extensions to standards track documents need to be on the standards >track as well, but that doesn't seem to be correct, as far as I can >tell. It is not correct that they *need* to be, but there is no reason for them not to be. In general: - If a protocol is worked on in an open context, standards track is preferred - If a protocol is worked on in private and the author doesn't want to take changes from others, Informational is most appropriate - If a protocol is really an experiment that may not even get implemented, Experimental is most appropriate >It certainly doesn't make sense (because it would prohibit >experimental extensions to standards track protocols), nor does it >reflect past decisions (for instance, see RFC2774 and RFC4437). It is not clear to me how people can so consistently misread RFC 2026, which is the current definition for when something should be an Experimental RFC. Both examples you give are poster children for the Inappropriately Labelled RFC Foundation. >(sorry for getting off-topic) Not off-topic at all, given that we will probably have more extensions in the future. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Jun 23 16:44:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsVj-0007dZ-S9 for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:44:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsVh-0002m5-Gb for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:44: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 k5NKYJTo097033; Fri, 23 Jun 2006 13:34: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 k5NKYJqU097032; Fri, 23 Jun 2006 13:34: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.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NKYAgR096991 for ; Fri, 23 Jun 2006 13:34:18 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so556026nfc for ; Fri, 23 Jun 2006 13:34: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=GWcRHnGqc1hoKQwGIz94X82afvjvJHGo3aTNpi/BbOhHyCkvvgs/rml6lj5ng/tDj16uekJVkLj7RjdPgx2l3SKkv4uoy+6HaUheEBphMbl3aJjXo8t0ldrxoQ+VKEa410fV4ShELcf7VCWpa263XTPdUp+JZVT+vUaJeAOZegU= Received: by 10.48.229.20 with SMTP id b20mr2784065nfh; Fri, 23 Jun 2006 13:34:09 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Fri, 23 Jun 2006 13:34:09 -0700 (PDT) Message-ID: <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.gmail.com> Date: Fri, 23 Jun 2006 16:34:09 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Feed Thread approved as a Proposed Standard Cc: "Julian Reschke" , "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: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> 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 6/23/06, Paul Hoffman wrote: > > It is not correct that they *need* to be, but there is no reason for > them not to be. In general: > > - If a protocol is worked on in an open context, standards track is preferred > The most important parts of an "open" context are well-documented decisions. That didn't happen here. It is surely appropriate for IETF members to suggest an alternate status for the document, no matter what the IESG eventually decides. In this case, an appeal to "the rules" was made, but RFC 2026 does not place limits on the sort of feedback the community may give. In effect, an effort was made to end the discussion, rather than address the issue. I don't feel the community has control of this document, and that bothers me. n.b. -- not inviting a rebuttal. -- Robert Sayre From owner-atom-syntax@mail.imc.org Fri Jun 23 16:59:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtskL-00029H-0t for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:59:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtskJ-0004FD-J3 for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 16:59: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 k5NJmUtT085535; Fri, 23 Jun 2006 12:48: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 k5NJmUMN085534; Fri, 23 Jun 2006 12:48: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 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 k5NJmT1s085526 for ; Fri, 23 Jun 2006 12:48:29 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 57so721157wri for ; Fri, 23 Jun 2006 12:48:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oox/dPqsLWZAtOOkuMvvDQv8VNILbyQbDdQO8OOZMyOXroQ2RoYXeOHpuqi0BGU+CdyVjNJTJljI/UkCMWzqEdbeAJVI/I7/rKWGQk7lqXTyY1EvT/uwqR2uyECop0md46TOJr8vqIdkVeIrZfFjM2h7hJsrYkbGsDY1SlzzUfo= Received: by 10.54.139.1 with SMTP id m1mr4861441wrd; Fri, 23 Jun 2006 12:48:24 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id g5sm2459673wra.2006.06.23.12.48.22; Fri, 23 Jun 2006 12:48:23 -0700 (PDT) Message-ID: <449C4584.8010502@gmail.com> Date: Fri, 23 Jun 2006 12:48:20 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed Thread approved as a Proposed Standard References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> In-Reply-To: <449C424E.4020304@gmx.de> 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: 3e15cc4fdc61d7bce84032741d11c8e5 I put this on the standards track (as opposed to being experimental) primarily for the fact that it is currently being used in production environments. IBM and SixApart, for instance, have both deployed non-experimental applications that utilize the extension. 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. -- http://www.ietf.org/tao.html#anchor44 I believe that it's already clear that there is interest in implementing feed thread and that the spec will work. Regarding the bit about extensions needing be on the standards track because Atom is, I think that's wrong. There is a place for experimental RFC's, in fact, that's likely where things like the feed rank and person construct extensions are likely to initially end up. - James Julian Reschke wrote: > James M Snell schrieb: >> Just a general FYI.. >> >> The IESG has approved the Atom Threading Extensions (aka "feed thread") >> as a Proposed Standard making it the first standardized syndication >> extension. It is now in the RFC Editors queue and will be assigned an >> RFC #. >> >> I would like to extend my thanks and appreciation to the members of the >> WG who offered constructive feedback on the spec. I know we all didn't >> see eye-to-eye on various aspects of the extension, but the spec was >> significantly improved through the open discussions and debate we had >> here on the list. > > Congratulations. > > Related to this, I'd still like to find out the background history on > why this is on the standards track. It was claimed that extensions to > standards track documents need to be on the standards track as well, but > that doesn't seem to be correct, as far as I can tell. It certainly > doesn't make sense (because it would prohibit experimental extensions to > standards track protocols), nor does it reflect past decisions (for > instance, see RFC2774 and RFC4437). > > (sorry for getting off-topic) > > Best regards, Julian > From owner-atom-syntax@mail.imc.org Fri Jun 23 17:12:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftswg-0000Rk-ER for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 17:12:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftswf-0005BD-3N for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 17:12: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 k5NL35cu004058; Fri, 23 Jun 2006 14:03: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 k5NL35rO004057; Fri, 23 Jun 2006 14:03: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 [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 k5NL31Js004033; Fri, 23 Jun 2006 14:03:01 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.gmail.com> References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.gmail.com> Date: Fri, 23 Jun 2006 14:02:55 -0700 To: "Robert Sayre" From: Paul Hoffman Subject: Re: Feed Thread approved as a Proposed Standard Cc: "Julian Reschke" , "James M Snell" , atom-syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 4:34 PM -0400 6/23/06, Robert Sayre wrote: >It is surely appropriate for IETF members to suggest an alternate >status for the document, no matter what the IESG eventually decides. That's one view, and an unfortunately common one. The view I prefer is "follow RFC 2026 because no one is going to remember the logic for not following it after the RFC is published." Yes, I'm a bit of a priss about these things... >In this case, an appeal to "the rules" was made, but RFC 2026 does not >place limits on the sort of feedback the community may give. Correct. It is up to the IESG to decide on a case-by-case basis if there was adequate discussion. >I don't feel the community has control of this document, and that bothers me. Once something is an RFC, the "community" has "control" in that an effort can be made to obsolete a document with a new one, or extend a document with a new one. That is weak control because it takes a lot of effort and elapsed time, and it might not succeed. Fortunately, anyone can form a "community" if they feel like doing the work; they might be listened to. (This in contrast with other standards bodies that do not allow revisions by random developers or other interested parties.) --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Jun 23 17:39:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttG9-0000VA-4Y for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 17:32:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttFb-0002cG-D7 for atompub-archive@lists.ietf.org; Fri, 23 Jun 2006 17:31: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 k5NLKgnX008127; Fri, 23 Jun 2006 14:20: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 k5NLKg7F008126; Fri, 23 Jun 2006 14:20: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NLKewL008119 for ; Fri, 23 Jun 2006 14:20:41 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so571710nfc for ; Fri, 23 Jun 2006 14:20: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kQ3tzB+w070ZNe17hQBQfV7hqHY2VlhtAxw/tM7MzSfGGQRAazFRDKiiflCccVtq2iG4huRsiAYiKqgl4qGfQRrd6mYVq6pKiTcjls3VwlJmZpNvZvZo/eA4C4Y94W2HCJn0T3xiSsSCJM49tav0dRDBtQlCOOGjlRSW2foCNro= Received: by 10.49.55.18 with SMTP id h18mr2828421nfk; Fri, 23 Jun 2006 14:20:40 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Fri, 23 Jun 2006 14:20:39 -0700 (PDT) Message-ID: <68fba5c50606231420h5edc2f5y5732ce21c3a12ae0@mail.gmail.com> Date: Fri, 23 Jun 2006 17:20:39 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Feed Thread approved as a Proposed Standard Cc: "Julian Reschke" , "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: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.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 6/23/06, Paul Hoffman wrote: > > >I don't feel the community has control of this document, and that bothers me. > > Once something is an RFC, the "community" has "control" in that an > effort can be made to obsolete a document with a new one, I guess those scare quotes are appropriate, but the underlying point is that I now have a Proprietary Standard designation for this document. That's a bummer, because the stewardship of RFC4287 is also in a similarly worrisome state. Open standards are not made by people paid to write mailing list posts until everyone else gives up. I know I don't have the bandwidth to cut through the brazen obfuscation anymore. -- Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jun 24 14:52:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuDF3-0003lU-Ha for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 14:52:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuD1a-0001Lz-N2 for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 14:38: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 k5OILOjt021274; Sat, 24 Jun 2006 11:21: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 k5OILOMe021273; Sat, 24 Jun 2006 11:21: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OILKEX021244 for ; Sat, 24 Jun 2006 11:21:21 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so707646nfc for ; Sat, 24 Jun 2006 11:21: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=OgNcXdtTDP42bOtNmHelxCO6CQo71xZyhu/JybKbfh7XEiGxruBILwlPzsNhtN9RS7pBXOMYOlRUyAiH283N8VaYYtcrxdbH++ExvQpzwC+oroaZF78AKFIYgP74oRDRMOb+iDH+4/hmFYc5cgfp16hoefGho4COJapMh0nVEC0= Received: by 10.48.255.5 with SMTP id c5mr2089492nfi; Sat, 24 Jun 2006 11:21:20 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Sat, 24 Jun 2006 11:21:20 -0700 (PDT) Message-ID: <68fba5c50606241121w23513980o77019469c1e4510a@mail.gmail.com> Date: Sat, 24 Jun 2006 14:21:20 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Feed Thread approved as a Proposed Standard Cc: "Julian Reschke" , "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-Transfer-Encoding: 7bit Content-Disposition: inline References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.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: 7d33c50f3756db14428398e2bdedd581 On 6/23/06, Paul Hoffman wrote: > > The view I prefer > is "follow RFC 2026 because no one is going to remember the logic for > not following it after the RFC is published." Yes, I'm a bit of a > priss about these things... I'm alarmed that this specification is on the standards track in a vendor-controlled namespace. I notice Sam Hartman raised this point in IESG discussion, but I don't see a record of its resolutoin. What were the procedures followed, and how can it be said that the IETF has change control here? -- Robert Sayre From owner-atom-syntax@mail.imc.org Sat Jun 24 15:19:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuDfO-0005jY-PW for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 15:19:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuDfN-0005Wz-D4 for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 15:19: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 k5OJ9cxL032673; Sat, 24 Jun 2006 12: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 k5OJ9ci7032672; Sat, 24 Jun 2006 12: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 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 k5OJ9aUY032662 for ; Sat, 24 Jun 2006 12:09:37 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 57so870800wri for ; Sat, 24 Jun 2006 12:09:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=WPF3iDT+9JTHrggfUvnDMmWtknXBZdZHAEKlBdHMSWiKriXF4s1k+bRZEBVbRyslVAvAz1VVglWXVt4W0RssZnsprQfqi0kTvwx3KPd1XQssGXQzn1MYKan9tNgIYvQcIsQ2Xol5w8jfyTXT+PfWI7FbVSdOSBC3maVi5cVMbzs= Received: by 10.54.151.7 with SMTP id y7mr5011525wrd; Sat, 24 Jun 2006 12:09:36 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 14sm4784299wrl.2006.06.24.12.09.35; Sat, 24 Jun 2006 12:09:35 -0700 (PDT) Message-ID: <449D8DEC.5010304@gmail.com> Date: Sat, 24 Jun 2006 12:09:32 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax Subject: Re: Feed Thread approved as a Proposed Standard References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.gmail.com> <68fba5c50606241121w23513980o77019469c1e4510a@mail.gmail.com> In-Reply-To: <68fba5c50606241121w23513980o77019469c1e4510a@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: 8abaac9e10c826e8252866cbe6766464 It's not a vendor controlled namespace; it's an individual controlled namespace that I'm more than happy to delegate to the IESG. The IETF has complete change control of the spec at this point -- including changing the XML namespace used by the extension if doing so would be appropriate. I trust the IESG and the RFC editor to do whatever is deemed to be appropriate. - James p.s. FUD is generally more effective when not based on generally false and easily refuted assumptions Robert Sayre wrote: > On 6/23/06, Paul Hoffman wrote: >> >> The view I prefer >> is "follow RFC 2026 because no one is going to remember the logic for >> not following it after the RFC is published." Yes, I'm a bit of a >> priss about these things... > > I'm alarmed that this specification is on the standards track in a > vendor-controlled namespace. > > > > I notice Sam Hartman raised this point in IESG discussion, but I don't > see a record of its resolutoin. What were the procedures followed, and > how can it be said that the IETF has change control here? > From owner-atom-syntax@mail.imc.org Sat Jun 24 17:56:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuG7O-0005h9-U6 for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 17:56:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuG7N-0002L4-Iz for atompub-archive@lists.ietf.org; Sat, 24 Jun 2006 17:56: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 k5OLkD6D069555; Sat, 24 Jun 2006 14:46: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 k5OLkDlV069554; Sat, 24 Jun 2006 14:46: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 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 k5OLkAs1069531 for ; Sat, 24 Jun 2006 14:46:11 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so720199nfc for ; Sat, 24 Jun 2006 14:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iOrXcxBkTJb49rM00/9VbhcMTNB9DeM9hadZZ+xA7ZkVntLkXNWHEUhxm1HyEYF2GcGSPjZM7jFTH29x5okXOtyxKF2dL9MN5eOUYT+uRksS0nwrFetHQqXrLiw/Q5XbjQnQUBktTgWJG/G3FPXqIG8N8+0o4YhnMA8aRG0KeNk= Received: by 10.49.64.2 with SMTP id r2mr3666357nfk; Sat, 24 Jun 2006 14:46:10 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Sat, 24 Jun 2006 14:46:10 -0700 (PDT) Message-ID: <68fba5c50606241446u628a5239q8dcd68c1e084364a@mail.gmail.com> Date: Sat, 24 Jun 2006 17:46:10 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: Feed Thread approved as a Proposed Standard Cc: atom-syntax In-Reply-To: <449D8DEC.5010304@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <449C3BD4.3070203@gmail.com> <449C424E.4020304@gmx.de> <68fba5c50606231334ia788d2bk7a306bbf87e94ffe@mail.gmail.com> <68fba5c50606241121w23513980o77019469c1e4510a@mail.gmail.com> <449D8DEC.5010304@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: b19722fc8d3865b147c75ae2495625f2 On 6/24/06, James M Snell wrote: > > It's not a vendor controlled namespace; it's an individual controlled > namespace Irrelevant. > that I'm more than happy to delegate to the IESG. > > The IETF has complete change control of the spec at this point -- > including changing the XML namespace used by the extension if doing so > would be appropriate. I trust the IESG and the RFC editor to do > whatever is deemed to be appropriate. The IESG approved it with no directions to the RFC editor. So your conjecture comes at the wrong juncture. If you were qualified to answer my message, that would be obvious. I'll note that you failed to answer a single question I asked, which tells me they were good ones. > > p.s. FUD is generally more effective when not based on generally false > and easily refuted assumptions > This is content-free flaming. But I'll note there was nothing false in my message. And you didn't refute anything either. I'd say you're just trying to intimidate people. -- Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jun 26 18:17:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzOL-0007D8-Pv for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 18:17:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzOH-0005HB-6K for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 18:17: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 k5QLrvx0096479; Mon, 26 Jun 2006 14:53: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 k5QLrv2I096478; Mon, 26 Jun 2006 14:53: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 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 k5QLrt9k096446 for ; Mon, 26 Jun 2006 14:53:56 -0700 (MST) (envelope-from nicolas1.krebs3@netcourrier.com) Received: from netcourrier.com (netcourrier-1m.netcourrier.com [194.158.104.101]) by netc-relay-3m.netcourrier.com (Postfix) with SMTP id 6327AB1D0 for ; Mon, 26 Jun 2006 23:53:54 +0200 (CEST) Received: from [85.68.10.110] by netcourrier-1m.netcourrier.com via html interface From: Nicolas Krebs To: atom-syntax@imc.org Subject: [RFC 4287] unicity of atom:category element Date: Mon, 26 Jun 2006 23:53:54 +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 k5QLru9k096449 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Thanks for your previous answer. Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287 ( http://tools.ietf.org/html/rfc4287#section-4.2.2 ) > 4.2.2.1. The "term" Attribute > The "term" attribute is a string that identifies the category Is the term attribute an unique identifiers ? How can i manage the homonym ? Could an atom 1.0 feed contain some item whith " and other item with " where the first Java is not the same as the second ? From owner-atom-syntax@mail.imc.org Mon Jun 26 18:40:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzlC-0003me-2Q for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 18:40:50 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzl7-0006pY-IT for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 18:40: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 k5QMN2Kp005908; Mon, 26 Jun 2006 15:23: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 k5QMN2CW005907; Mon, 26 Jun 2006 15:23: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 mail.gmx.net (mail.gmx.de [213.165.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5QMMxwT005866 for ; Mon, 26 Jun 2006 15:23:00 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Jun 2006 22:22:53 -0000 Received: from xdsl-213-196-254-143.netcologne.de (EHLO klangraum) [213.196.254.143] by mail.gmx.net (mp030) with SMTP; 27 Jun 2006 00:22:53 +0200 X-Authenticated: #163624 Date: Tue, 27 Jun 2006 00:23:09 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: [RFC 4287] unicity of atom:category element Message-ID: <20060626222309.GB14985@klangraum> Mail-Followup-To: atom-syntax@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a * Nicolas Krebs [2006-06-27 00:15]: > Could an atom 1.0 feed contain some item whith > " somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' /> > and other item with > " somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' /> > where the first Java is not the same as the second ? The term is machine readable. The label is human readable. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Mon Jun 26 19:14:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0Hx-0003SY-O4 for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 19:14:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0Hw-0003JY-9x for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 19:14: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 k5QMx9sq017587; Mon, 26 Jun 2006 15:59: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 k5QMx9ix017586; Mon, 26 Jun 2006 15:59: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 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 k5QMx7jU017539 for ; Mon, 26 Jun 2006 15:59:08 -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 6891C4F792E for ; Mon, 26 Jun 2006 16:59:01 -0600 (MDT) Message-ID: <44A066B5.4040200@jabber.org> Date: Mon, 26 Jun 2006 16:59:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: atom-syntax@imc.org Subject: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt] X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org Content-Type: multipart/mixed; boundary="------------010304070201000005010007" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is a multi-part message in MIME format. --------------010304070201000005010007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI... -------- Original Message -------- Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt Date: Mon, 26 Jun 2006 18:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-atompub-notify-05.txt Pages : 17 Date : 2006-6-26 This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-saintandre-atompub-notify-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-saintandre-atompub-notify-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml --------------010304070201000005010007 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="draft-saintandre-atompub-notify-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-saintandre-atompub-notify-05.txt" Content-Type: text/plain Content-ID: <2006-6-26163404.I-D@ietf.org> --------------010304070201000005010007 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="file:///tmp/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------010304070201000005010007-- From owner-atom-syntax@mail.imc.org Mon Jun 26 20:27:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1Qb-0007NE-3Z for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 20:27:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1QZ-0002yS-OH for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 20:27:41 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5R0Ee3b041575; Mon, 26 Jun 2006 17:14: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 k5R0Eem7041574; Mon, 26 Jun 2006 17:14: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 [10.20.30.249] (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 k5R0Econ041557 for ; Mon, 26 Jun 2006 17:14:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 26 Jun 2006 17:14:25 -0700 To: Atom WG From: The IESG Subject: Protocol Action: 'Atom Threading Extensions' to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 The IESG has approved the following document: - 'Atom Threading Extensions ' 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 Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt Technical Summary This draft proposes some extensions to the Atom Syntax specification so that the relationship of one Atom entry to another (for example, when one entry is a comment on a blog post which is another entry). Working Group Summary This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft was fairly lengthy, and resulted in a number of changes to the draft. Protocol Quality As of May 2006, Feed Thread support has several independent implementations andeven some interoperability testing. This document was reviewed for the IESG by Lisa Dusseault. From owner-atom-syntax@mail.imc.org Mon Jun 26 20:48:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv1kf-0002h6-CW for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 20:48:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv1ke-00049w-1n for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 20:48: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 k5R0ZOCq048448; Mon, 26 Jun 2006 17:35: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 k5R0ZODr048447; Mon, 26 Jun 2006 17:35: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 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 k5R0ZM8T048437 for ; Mon, 26 Jun 2006 17:35:23 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so957434nfc for ; Mon, 26 Jun 2006 17:35:21 -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=kiqDPV6Kk8xWPlYELPKWhVgH99Z5IiBYZZcYaa3//OewNBfnGZ1W7Xb78cdPn8vxsA/gPlavf0G4fG9S4Fg9Kp4YwZUspkMz4TO4v7gnEK8ZpCQ6GQk3h5QuvFnsUDTn8+Ul7AJO2CnB6Qvr6N0MJLcexCewYCXoDw3XMBf9GhE= Received: by 10.48.242.3 with SMTP id p3mr5166736nfh; Mon, 26 Jun 2006 17:35:21 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Mon, 26 Jun 2006 17:35:21 -0700 (PDT) Message-ID: <68fba5c50606261735x478e1311s335e041fda54a298@mail.gmail.com> Date: Mon, 26 Jun 2006 20:35:21 -0400 From: "Robert Sayre" To: "Atom WG" Subject: Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard 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: 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 6/26/06, The IESG wrote: > > Working Group Summary > > This is not a WG draft. Nevertheless, the AtomPub WG discussion on this draft > was fairly lengthy, and resulted in a number of changes to the draft. > Who wrote this summary? Even Paul went on the record saying there was no consensus on several aspects of the document. This summary makes it sound like it underwent a number of friendly suggestions, rather than disapproval by at least half of the commenters, interupted only by incorrect readings of RFC2026 and obfuscation by the document author. -- Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jun 26 21:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv29U-0001pb-E3 for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 21:14:04 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv29T-0007JK-3C for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 21:14: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 k5R0xWkh055998; Mon, 26 Jun 2006 17:59: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 k5R0xWfG055997; Mon, 26 Jun 2006 17:59: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 [10.20.30.249] (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 k5R0xU5c055985 for ; Mon, 26 Jun 2006 17:59:31 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <68fba5c50606261735x478e1311s335e041fda54a298@mail.gmail.com> References: <68fba5c50606261735x478e1311s335e041fda54a298@mail.gmail.com> Date: Mon, 26 Jun 2006 17:59:28 -0700 To: "Atom WG" From: Paul Hoffman Subject: Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 8:35 PM -0400 6/26/06, Robert Sayre wrote: >On 6/26/06, The IESG wrote: >> >>Working Group Summary >> >>This is not a WG draft. Nevertheless, the AtomPub WG discussion on >>this draft >>was fairly lengthy, and resulted in a number of changes to the draft. >> > >Who wrote this summary? Probably Lisa. >Even Paul went on the record saying there was >no consensus on several aspects of the document. Right. The statement above doesn't say anything about consensus. >This summary makes it >sound like it underwent a number of friendly suggestions, rather than >disapproval by at least half of the commenters, interupted only by >incorrect readings of RFC2026 and obfuscation by the document author. Your reading might differ from others'. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Jun 26 22:30:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3L4-0003FW-7b for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 22:30:06 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv3L2-0004fn-TH for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 22:30: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 k5R2CCnF078521; Mon, 26 Jun 2006 19:12: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 k5R2CCZH078520; Mon, 26 Jun 2006 19:12: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5R2C7NW078485 for ; Mon, 26 Jun 2006 19:12:11 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so964881nfc for ; Mon, 26 Jun 2006 19:12: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=W+CVmHu99KCEauf71c3knx8tiFMPPK4JfverIDd6tx4DMy94O5Zfkv4JUYlkp6ecFV8mEiuH9PAEWV4wCeCTK5og5XpYva5w4qzIWQSSLK8dDtRfMTOGpJIMk00bHizjA6kR71Rw7TfTQPK5B4/NrkGP7f9bQ7vGsbk7Qz49hxA= Received: by 10.49.19.11 with SMTP id w11mr5215085nfi; Mon, 26 Jun 2006 19:12:07 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Mon, 26 Jun 2006 19:12:07 -0700 (PDT) Message-ID: <68fba5c50606261912x167271o8e3bac03034fabdd@mail.gmail.com> Date: Mon, 26 Jun 2006 22:12:07 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard Cc: "Atom WG" 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: <68fba5c50606261735x478e1311s335e041fda54a298@mail.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: cf4fa59384e76e63313391b70cd0dd25 On 6/26/06, Paul Hoffman wrote: > > Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like "WG is OK with this." It's perfectly natural to question and appropriate things that seem out of the ordinary. In the future, please save the oblique answers for someone who cares to hear them. -- Robert Sayre From owner-atom-syntax@mail.imc.org Mon Jun 26 22:36:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv3Rh-0005XB-Cz for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 22:36:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv3Rf-0005CV-1k for atompub-archive@lists.ietf.org; Mon, 26 Jun 2006 22:36: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 k5R2NJaO082337; Mon, 26 Jun 2006 19:23: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 k5R2NJ36082336; Mon, 26 Jun 2006 19:23: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.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5R2NHmc082317 for ; Mon, 26 Jun 2006 19:23:18 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so965702nfc for ; Mon, 26 Jun 2006 19:23:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sicR3/1749p4pVHjl9HcgY7C7MdDIycygHP5aQ2c8UhKVh2mU9G6wvwQv9WD/9+jN84na1/rFQYHmxxDDo4OjOSYCu/gXHy5DhR2hqkoHg+GAA9RjBSNgFhpuyC7DnrztPftaTOLLphwDkufmbeW74K2g3HAVaSkOHC/cnTigjI= Received: by 10.49.3.3 with SMTP id f3mr5215181nfi; Mon, 26 Jun 2006 19:23:17 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Mon, 26 Jun 2006 19:23:17 -0700 (PDT) Message-ID: <68fba5c50606261923k16913626gdc95348cc63e5851@mail.gmail.com> Date: Mon, 26 Jun 2006 22:23:17 -0400 From: "Robert Sayre" To: "Paul Hoffman" Subject: Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard Cc: "Atom WG" In-Reply-To: <68fba5c50606261912x167271o8e3bac03034fabdd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50606261735x478e1311s335e041fda54a298@mail.gmail.com> <68fba5c50606261912x167271o8e3bac03034fabdd@mail.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: 93238566e09e6e262849b4f805833007 On 6/26/06, Robert Sayre wrote: > On 6/26/06, Paul Hoffman wrote: > > > > Your reading might differ from others'. > > I've read a lot of these, so I know this synopsis differs others. > Usually they stuff like "WG is OK with this." It's perfectly natural > to question and appropriate things that seem out of the ordinary. er, a little steamed here, that's not English. It's perfectly natural to question whether things that seem out of the ordinary are appropriate. Anyway, you don't seem to have accurate answers on the process when it doesn't match the outcome you're looking for. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue Jun 27 07:57:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCC7-0007XB-Cr for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 07:57:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvCC4-0007AU-03 for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 07:57: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 k5RBdFAE059075; Tue, 27 Jun 2006 04:39: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 k5RBdFdP059074; Tue, 27 Jun 2006 04:39:15 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nz-out-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 k5RBdE2D059067 for ; Tue, 27 Jun 2006 04:39:14 -0700 (MST) (envelope-from t.broyer@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so1405962nzi for ; Tue, 27 Jun 2006 04:39: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Iup0AQWJ9Kx6gwxIwkQVc0dWViPzvfCsQ+1Qw9wpzM45nxRERAzLFUddytmC0s/NaPu8ux7w7SVkqjdDLyL9klFgcNvCyvXL3fB8X/S27APsinA4Okuwp6t3jlu33YzY/G+VJ5xBHa5wQXTVlkNB4dyEU/BHwjI3K5trcLUXnOw= Received: by 10.65.59.4 with SMTP id m4mr7291398qbk; Tue, 27 Jun 2006 04:39:14 -0700 (PDT) Received: by 10.65.11.14 with HTTP; Tue, 27 Jun 2006 04:39:13 -0700 (PDT) Message-ID: Date: Tue, 27 Jun 2006 13:39:13 +0200 From: "Thomas Broyer" To: Atom-Syntax Subject: Re: [RFC 4287] unicity of atom:category element In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 2006/6/26, Nicolas Krebs: > Excerpt quoted from section 4.2.2 of urn:ietf:rfc:4287 > ( http://tools.ietf.org/html/rfc4287#section-4.2.2 ) > > > 4.2.2.1. The "term" Attribute > > > The "term" attribute is a string that identifies the category > > Is the term attribute an unique identifiers ? My interpretation of atom:category is that scheme+term defines a unique identifier, much the same as a QName in XML. I might be wrong however, as RFC4287 is completely silent on this... > How can i manage the homonym ? Use different categorization schemes ;-) > Could an atom 1.0 feed contain some item whith > " somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' /> > and other item with > " somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' /> Yes. Note that you could also have those two atom:category elements in the same atom:entry, as RFC4287 puts no constraint at all on categories (unlike atom:link elements). > where the first Java is not the same as the second ? With the same scheme and term, aggregators (or other Atom processors) are very likely to consider them the exact same category. I think the producer of such a feed would be wrong using the same scheme and term for (conceptually) different categories... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Jun 27 11:45:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFkx-0003hJ-TM for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 11:45:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvFku-0008JB-DW for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 11:45: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 k5RFVWX6019288; Tue, 27 Jun 2006 08:31: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 k5RFVWjI019284; Tue, 27 Jun 2006 08:31: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 smtp1.afp.com (smtp1.afp.com [158.50.208.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RFVVTU019244 for ; Tue, 27 Jun 2006 08:31:32 -0700 (MST) (envelope-from laurent.lemeur@afp.com) Received: by smtp1.afp.com (Sendmail, from userid 1007) id 8B698466F5; Tue, 27 Jun 2006 17:28:11 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp1.afp.com (Sendmail) with ESMTP id 6836A462FBfor ; Tue, 27 Jun 2006 17:28:11 +0200 (CEST) Received: from SMDL05 ([158.50.180.103])by alox.afp.com (8.12.9/8.12.9) with ESMTP id k5RFT3OD007349for ; Tue, 27 Jun 2006 17:29:06 +0200 (METDST) Message-Id: <200606271529.k5RFT3OD007349@alox.afp.com> From: "Laurent Le Meur" To: Subject: RE: [RFC 4287] unicity of atom:category element Date: Tue, 27 Jun 2006 17:29:05 +0200 MIME-Version: 1.0 Content-Type: text/plain;charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaZby/bBahtsI1cRl6ho6T7rnH/uAAibxew In-Reply-To: <20060626222309.GB14985@klangraum> X-MailScanner: Found to be clean Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da > > Could an atom 1.0 feed contain some item whith > > " > somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' > /> > > and other item with > > " > somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' /> > > where the first Java is not the same as the second ? > > The term is machine readable. The label is human readable. > > scheme='http://www.example.org/cat/' > term='http://www.example.org/cat/Technology/Coding/Java/' > label='Java' > /> > scheme='http://www.exmple.org/' > term='http://www.example.org/cat/Technology/Sun/Java/' > label='Java' > /> > > Regards, > Aristotle Pagaltzis // Aristotle, I agree with your statement but feel your example somewhat misleading. From my understanding: - A 'term' is a token (syntactically a string) used for indexing; in the absence of an associated scheme it is processed as a free keyword/tag. There's no real reason to make it a URI, but it can be a number (eg ISBN code). - A 'scheme' is the identifier of a controlled vocabulary = a set of terms. It's an IRI. It is optional, but 'scopes' the term, so ambiguities are avoided. If present {scheme,term} is a tuple that unambiguously identifies a resource. {http://www.software.org/, java} and { http://www.island.org/ , java} are clearly different categories. A note regarding the {scheme, code} tuple: the spec does not indicate how more information about the category can be found, using some form of concatenation of the scheme URI + term. - A 'label' is a human readable string associated with a category code (term). A note regarding 'label':= limitations of the spec are: - it is not possible to represent several labels in different languages - it is not possible to apply i18n attributes like 'dir' to a label. Best regards Laurent Le Meur AFP -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This e-mail, and any file transmitted with it, is confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. For more information on Agence France-Presse, please visit our web site at http://www.afp.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-atom-syntax@mail.imc.org Tue Jun 27 12:13:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGC0-0000X3-5P for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:13:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGBw-0003oP-Ka for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:13: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 k5RFqucV025383; Tue, 27 Jun 2006 08:52: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 k5RFqugu025382; Tue, 27 Jun 2006 08:52: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.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RFqtaL025376 for ; Tue, 27 Jun 2006 08:52:55 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 69so194639wra for ; Tue, 27 Jun 2006 08:52: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=Hdo0s2qtfSG4Il76LjNwG95k6lT/5GJys2+t3Be7GerYyiaFO6AAByDQ/VqzGViFwAUP/vVtIge09JOBnubae4rTZvumtihiUyOve4pyOLa76EwuOEcKkEIV/wsiS+6CC0P0NO0icgIcs3TAxS2zzyWQZwxZvt04bNSHTfjv8rw= Received: by 10.54.119.2 with SMTP id r2mr93510wrc; Tue, 27 Jun 2006 08:52:54 -0700 (PDT) Received: from ?9.45.124.119? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 28sm1849152wrl.2006.06.27.08.52.53; Tue, 27 Jun 2006 08:52:53 -0700 (PDT) Message-ID: <44A15454.6050005@gmail.com> Date: Tue, 27 Jun 2006 08:52:52 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: [RFC 4287] unicity of atom:category element References: <200606271529.k5RFT3OD007349@alox.afp.com> In-Reply-To: <200606271529.k5RFT3OD007349@alox.afp.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: 00e94c813bef7832af255170dca19e36 Slight addition to this, The scheme not only disambiguates the term, it also identifies the means of interpreting the term. For instance, Tim Bray's feed uses a scheme/term combo that can be concatenated to form a meaningful, dereferencable URI. - James Laurent Le Meur wrote: >>> Could an atom 1.0 feed contain some item whith >>> ">> somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Coding/Java/' >> /> >>> and other item with >>> ">> somexmlns:href='http://www.tbray.org/ongoing/What/Technology/Sun/Java/' /> >>> where the first Java is not the same as the second ? >> The term is machine readable. The label is human readable. >> >> > scheme='http://www.example.org/cat/' >> term='http://www.example.org/cat/Technology/Coding/Java/' >> label='Java' >> /> >> > scheme='http://www.exmple.org/' >> term='http://www.example.org/cat/Technology/Sun/Java/' >> label='Java' >> /> >> >> Regards, >> Aristotle Pagaltzis // > > Aristotle, > > I agree with your statement but feel your example somewhat misleading. From my > understanding: > > - A 'term' is a token (syntactically a string) used for indexing; in the absence > of an associated scheme it is processed as a free keyword/tag. There's no real > reason to make it a URI, but it can be a number (eg ISBN code). > > - A 'scheme' is the identifier of a controlled vocabulary = a set of terms. It's > an IRI. It is optional, but 'scopes' the term, so ambiguities are avoided. If > present {scheme,term} is a tuple that unambiguously identifies a resource. > {http://www.software.org/, java} and { http://www.island.org/ , java} are > clearly different categories. > > A note regarding the {scheme, code} tuple: the spec does not indicate how more > information about the category can be found, using some form of concatenation of > the scheme URI + term. > > - A 'label' is a human readable string associated with a category code (term). > > A note regarding 'label':= limitations of the spec are: > - it is not possible to represent several labels in different languages > - it is not possible to apply i18n attributes like 'dir' to a label. > > Best regards > Laurent Le Meur > AFP > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > This e-mail, and any file transmitted with it, is confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email. > > For more information on Agence France-Presse, please visit our web site at http://www.afp.com > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > From owner-atom-syntax@mail.imc.org Tue Jun 27 12:34:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGVk-0004uI-14 for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:34:00 -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 1FvGVj-0006Fe-Vx for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:34:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvGOY-0000kJ-9U for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:26: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 k5RGBOWl030365; Tue, 27 Jun 2006 09:11: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 k5RGBOpF030364; Tue, 27 Jun 2006 09:11: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 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 k5RGBMj9030358 for ; Tue, 27 Jun 2006 09:11:23 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so1053388nfc for ; Tue, 27 Jun 2006 09:11:21 -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=jxhUdfPRPLjSvqQBnmOWO3qW4lLY69Injiv8P/dsRPE0hDblAP/w5geZYz14QZX/pjuzMm3GSHggA6ZdqVJlv/tzZe9A6i3PhVBlTegLNTUQJZj7ef1/4t78MUvJD+wKr5vkgt5Bv/MBgXGPCaWrem3UfPD78Y3Ox3tbue2kQ08= Received: by 10.49.51.10 with SMTP id d10mr5728340nfk; Tue, 27 Jun 2006 09:11:21 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Tue, 27 Jun 2006 09:11:21 -0700 (PDT) Message-ID: <68fba5c50606270911t3cc253ecp6fa8959b3ad9cd9@mail.gmail.com> Date: Tue, 27 Jun 2006 12:11:21 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: [RFC 4287] unicity of atom:category element Cc: atom-syntax@imc.org In-Reply-To: <44A15454.6050005@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606271529.k5RFT3OD007349@alox.afp.com> <44A15454.6050005@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.2 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 6/27/06, James M Snell wrote: > > Slight addition to this, > > The scheme not only disambiguates the term, it also identifies the means > of interpreting the term. For instance, Tim Bray's feed uses a > scheme/term combo that can be concatenated to form a meaningful, > dereferencable URI. There's no spec text to back this up. A convention might emerge, but let's not BS it. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue Jun 27 12:44:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGg1-0007vv-4L for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:44:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGfz-0007zV-MF for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 12:44: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 k5RGSYHw036741; Tue, 27 Jun 2006 09:28: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 k5RGSYZB036740; Tue, 27 Jun 2006 09:28: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 mail1.webfaction.com (IDENT:U2FsdGVkX1+Tu47S2ktPLgsN8pvtJvRzvr9YR+wt5mk@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RGSXtK036726 for ; Tue, 27 Jun 2006 09:28:33 -0700 (MST) (envelope-from sh@defuze.org) Received: from [192.168.1.2] (host81-159-19-169.range81-159.btcentralplus.com [81.159.19.169]) (authenticated bits=0) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k5RGSSHt006804; Tue, 27 Jun 2006 11:28:31 -0500 Message-ID: <44A15CA3.8030405@defuze.org> Date: Tue, 27 Jun 2006 17:28:19 +0100 From: Sylvain Hellegouarch Reply-To: sh@defuze.org User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Peter Saint-Andre CC: atom-syntax@imc.org Subject: Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt] References: <44A066B5.4040200@jabber.org> In-Reply-To: <44A066B5.4040200@jabber.org> 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 k5RGSYHw036741 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Nice work Peter. Very nice. Peter Saint-Andre a =E9crit : > FYI... > > > -------- Original Message -------- > Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt > Date: Mon, 26 Jun 2006 18:50:01 -0400 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Transporting Atom Notifications over the Extensible Messaging > and Presence Protocol (XMPP) > Author(s) : P. Saint-Andre, et al. > Filename : draft-saintandre-atompub-notify-05.txt > Pages : 17 > Date : 2006-6-26 > =09 > This memo describes a method for notifying interested parties about > changes in syndicated information encapsulated in the Atom feed > format, where such notifications are delivered via an extension to > the Extensible Messaging and Presence Protocol (XMPP) for publish- > subscribe functionality. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.= txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the use= rname > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-saintandre-atompub-notify-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-saintandre-atompub-notify-05.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > =20 > -----------------------------------------------------------------------= - > > Content-Type: text/plain > Content-ID: <2006-6-26163404.I-D@ietf.org> > > > =20 > -----------------------------------------------------------------------= - > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > =20 From owner-atom-syntax@mail.imc.org Tue Jun 27 16:39:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKL2-0008MI-R0 for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 16:39:12 -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 1FvJvQ-0005O4-3g for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 16:12:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJtd-0004kw-FV for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 16:10: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 k5RJwxgH007939; Tue, 27 Jun 2006 12:58: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 k5RJwxn7007938; Tue, 27 Jun 2006 12:58: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 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 k5RJwvLJ007916 for ; Tue, 27 Jun 2006 12:58:58 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id x29so11924nfb for ; Tue, 27 Jun 2006 12:58:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QMMyW2AtcFDexZYaFyjzZGCVFpTpqbpm5jDleDXZUbz7eTB0E4l3vL47uiFJ94LKbRIDCdqmv9vqymCOF5Ew/J+kiGnky8bJDVft62o0FCw73VbqX4yap1VeQUq4hGqiaxuGcQNS/YS/X0CsUX1l/FUGzIfT/gZURRYUfddcpeM= Received: by 10.49.95.3 with SMTP id x3mr42957nfl; Tue, 27 Jun 2006 12:58:56 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Tue, 27 Jun 2006 12:58:56 -0700 (PDT) Message-ID: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> Date: Tue, 27 Jun 2006 15:58:56 -0400 From: "Robert Sayre" To: "Atom Syntax" Subject: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.2 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f When XHTML content is used, "The XHTML div element itself MUST NOT be considered part of the content." -------- This is hard to test with aggregators, but conforming libraries definitely need to get this right. http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests -- Robert Sayre From owner-atom-syntax@mail.imc.org Tue Jun 27 18:29:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvM3T-0008AR-IJ for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 18:29:11 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvM3R-0003Zu-2J for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 18:29: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 k5RMHF5h053119; Tue, 27 Jun 2006 15:17: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 k5RMHFD1053118; Tue, 27 Jun 2006 15:17: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 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 k5RMHDTq053087 for ; Tue, 27 Jun 2006 15:17:14 -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 6A2EE4F82C1; Tue, 27 Jun 2006 16:17:08 -0600 (MDT) Message-ID: <44A1AE63.1070500@jabber.org> Date: Tue, 27 Jun 2006 16:17:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: sh@defuze.org Cc: atom-syntax@imc.org Subject: Re: [Fwd: I-D ACTION:draft-saintandre-atompub-notify-05.txt] References: <44A066B5.4040200@jabber.org> <44A15CA3.8030405@defuze.org> In-Reply-To: <44A15CA3.8030405@defuze.org> X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010702070008030804070309" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a cryptographically signed message in MIME format. --------------ms010702070008030804070309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, the underlying XMPP publish-subscribe spec has been updated as well: http://mail.jabber.org/pipermail/standards-jig/2006-June/011643.html Peter Sylvain Hellegouarch wrote: > Nice work Peter. Very nice. > > Peter Saint-Andre a écrit : >> FYI... >> >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-saintandre-atompub-notify-05.txt >> Date: Mon, 26 Jun 2006 18:50:01 -0400 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Transporting Atom Notifications over the Extensible >> Messaging >> and Presence Protocol (XMPP) >> Author(s) : P. Saint-Andre, et al. >> Filename : draft-saintandre-atompub-notify-05.txt >> Pages : 17 >> Date : 2006-6-26 >> >> This memo describes a method for notifying interested parties about >> changes in syndicated information encapsulated in the Atom feed >> format, where such notifications are delivered via an extension to >> the Extensible Messaging and Presence Protocol (XMPP) for publish- >> subscribe functionality. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-05.txt >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoa5jNF1RSzyt3NURAo0BAJwPVdqCNgkyvQ9CMx4Zp9cGvwgl7wCdGiCG Mvo2dh9OPsPugw6WzHAmRfQ= =5JX4 -----END PGP SIGNATURE----- --------------ms010702070008030804070309 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 hkiG9w0BCQUxDxcNMDYwNjI3MjIxNzA3WjAjBgkqhkiG9w0BCQQxFgQUkCNFA8lJv61lECkS 1Iex35xK4iIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAHnMKfDDNkPZW4J1EUSycws2I5zXjPvQ 6Baw8CSKSw/ObZfbEmlLQVX0q/NJZIW1d/kXioiNLBlfiuW3KO8rTU7HUKHxL3tFSSApC35w fL7LUSvCoBKeB94L0T46q2Exh6trY+M2oZczR2cnX7ypiLF49SoVPo6zFXFIM0PphqqGewgG eCYLtcv8efIHXHlhSPtDOUu72Mw8TrDN/IRZSZwvyKm9r8jmXKcGLKXnlesAyVd51Dj47cFm PKXWdGeCRT/zhAnmmSc+fbHe8iAxIq3lPL0a2+3AnWeJhfTV4vTAv+MuEIYPzrJGEoJwOTI6 794BMkJ2wq3IGeYZTATF6RsAAAAAAAA= --------------ms010702070008030804070309-- From owner-atom-syntax@mail.imc.org Tue Jun 27 19:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvN8x-0007JA-ST for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 19:38:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvN8v-0003tQ-4s for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 19:38: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 k5RNRSWM076115; Tue, 27 Jun 2006 16:27: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 k5RNRSUf076114; Tue, 27 Jun 2006 16:27: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 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 k5RNRRr6076107 for ; Tue, 27 Jun 2006 16:27:28 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so1977296pyf for ; Tue, 27 Jun 2006 16:27: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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qzXiR287zVvGyySni3ae5ckZ1Pr3zgNNhpPsmyHKIpUcMFXKyFyQBuYPsqTdK/6BH6ROjHgzntah8K2iXvyyuAgJapwpaFQwVPP1zHDvaKmOeebwf6vRR+pyRJGmQkbToSspC9ic1c08WJEEVqhar33f+JXJ6UZAG4ShG9k1owM= Received: by 10.35.121.9 with SMTP id y9mr171346pym; Tue, 27 Jun 2006 16:27:26 -0700 (PDT) Received: from ?172.30.1.26? ( [66.100.255.7]) by mx.gmail.com with ESMTP id z52sm2011788pyg.2006.06.27.16.27.25; Tue, 27 Jun 2006 16:27:26 -0700 (PDT) Message-ID: <44A1BEDC.9030402@gmail.com> Date: Tue, 27 Jun 2006 16:27:24 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> In-Reply-To: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@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: 9182cfff02fae4f1b6e9349e01d62f32 Please define "conformance" in regards to this test. That is, what is the exact behavior that a library must perform when a code library has an API like, "getContent" on the content element. e.g., is a parser not conformant if it passes the DIV on to the consuming application with the expectation that the application is responsible for "doing the right thing" with it? Robert Sayre wrote: > > When XHTML content is used, > > "The XHTML div element itself MUST NOT be considered part of the content." > > > > -------- > > This is hard to test with aggregators, but conforming libraries > definitely need to get this right. > > http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests > From owner-atom-syntax@mail.imc.org Tue Jun 27 19:53:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNN2-0007mf-AW for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 19:53:28 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvNN0-0000BC-V8 for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 19:53: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 k5RNVWBN077469; Tue, 27 Jun 2006 16:31: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 k5RNVW99077468; Tue, 27 Jun 2006 16:31: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.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RNVUZp077458 for ; Tue, 27 Jun 2006 16:31:31 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so1111005nfc for ; Tue, 27 Jun 2006 16:31:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h6l4zGOCDO+zsNNFPevs0fThAHWmh40f1nU2/50rrYjv2XD88mDG3l35/khgvgZu1oB7kQh4o0uyMlMqiuzmiFhQ9z/b6JaEk/Zj1ozqEjNbrmSo05HqgNiCi5XvFoMj996yPj2ccfstMByJAJ9rGTZXLifsbrQexSiPdBG1PtQ= Received: by 10.49.19.14 with SMTP id w14mr197764nfi; Tue, 27 Jun 2006 16:31:30 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Tue, 27 Jun 2006 16:31:30 -0700 (PDT) Message-ID: <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> Date: Tue, 27 Jun 2006 19:31:30 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Cc: "Atom Syntax" In-Reply-To: <44A1BEDC.9030402@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@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: 798b2e660f1819ae38035ac1d8d5e3ab On 6/27/06, James M Snell wrote: > Please define "conformance" in regards to this test. That is, what is > the exact behavior that a library must perform when a code library has > an API like, "getContent" on the content element. > > e.g., is a parser not conformant if it passes the DIV on to the > consuming application with the expectation that the application is > responsible for "doing the right thing" with it? Don't be dense. Would the parser be conformant if it passed on the feed, entry, and div elements with that expectation? I'll file a bug on UFP and I bet you it'll get fixed without a question, because there won't be a bad-faith interpretation to fight. That's two demerits this week for you. Tsk tsk. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Tue Jun 27 20:00:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNU2-0001hk-EF for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 20:00:42 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvNTz-00010c-QG for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 20:00: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 k5RNmhHT083544; Tue, 27 Jun 2006 16:48: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 k5RNmgiT083543; Tue, 27 Jun 2006 16:48:42 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RNmfLQ083519 for ; Tue, 27 Jun 2006 16:48:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so1982599pyf for ; Tue, 27 Jun 2006 16:48: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=fGpiokZqOecVx/9hpDaMZll0SsLKiF3F7O8L6/AVMR8kFByX3BgmswP4h/MIN3/+Yy66VhVlpw7lmXzOfXWpxXHAoLiks4OGHJpnYXFGfft+MFz4ZY5RBI6cYot0k/3S08uZtqyFJgde3Xoizr6QywXEiQHXUX6/uisyLuNe9Qc= Received: by 10.35.63.2 with SMTP id q2mr167491pyk; Tue, 27 Jun 2006 16:48:41 -0700 (PDT) Received: from ?172.30.1.39? ( [66.100.255.7]) by mx.gmail.com with ESMTP id h41sm1869796pyh.2006.06.27.16.48.40; Tue, 27 Jun 2006 16:48:40 -0700 (PDT) Message-ID: <44A1C3D7.8060402@gmail.com> Date: Tue, 27 Jun 2006 16:48:39 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> In-Reply-To: <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@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: 0bc60ec82efc80c84b8d02f4b0e4de22 I'm shooting for at least five demerits. Otherwise, the week will be completely sunk. And yes, the parser would be conformant. Abdera is conformant even tho it is possible to use Abdera to produce and read invalid Atom. Returning the div in the "getContent" method is incorrect and I'm fixing that now; making the div available for the application using Abdera should be ok. I want to make sure this conformance test isn't saying that the parser must hide the div completely. - James Robert Sayre wrote: > On 6/27/06, James M Snell wrote: >> Please define "conformance" in regards to this test. That is, what is >> the exact behavior that a library must perform when a code library has >> an API like, "getContent" on the content element. >> >> e.g., is a parser not conformant if it passes the DIV on to the >> consuming application with the expectation that the application is >> responsible for "doing the right thing" with it? > > Don't be dense. Would the parser be conformant if it passed on the > feed, entry, and div elements with that expectation? I'll file a bug > on UFP and I bet you it'll get fixed without a question, because there > won't be a bad-faith interpretation to fight. That's two demerits this > week for you. Tsk tsk. > From owner-atom-syntax@mail.imc.org Tue Jun 27 22:22:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPhf-0006vP-LH for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 22:22:56 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvPhb-0004ld-2k for atompub-archive@lists.ietf.org; Tue, 27 Jun 2006 22: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 k5S2Bo21031182; Tue, 27 Jun 2006 19:11: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 k5S2Bovu031181; Tue, 27 Jun 2006 19:11: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 bay0-omc3-s20.bay0.hotmail.com (bay0-omc3-s20.bay0.hotmail.com [65.54.246.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5S2Bn51031138 for ; Tue, 27 Jun 2006 19:11:49 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([64.4.19.75]) by bay0-omc3-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 19:11:43 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 27 Jun 2006 19:11:43 -0700 Message-ID: Received: from 81.179.83.121 by BAY109-DAV3.phx.gbl with DAV; Wed, 28 Jun 2006 02:11:43 +0000 X-Originating-IP: [81.179.83.121] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: "Atom Syntax" References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Wed, 28 Jun 2006 03:11:44 +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: 28 Jun 2006 02:11:43.0676 (UTC) FILETIME=[3365FFC0:01C69A58] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Robert Sayre wrote: > When XHTML content is used, > > "The XHTML div element itself MUST NOT be considered part of the content." > > FWIW, most aggregators that I've tested do not strip the div element. Regards James From owner-atom-syntax@mail.imc.org Wed Jun 28 03:03:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvU5M-0001xz-Rk for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 03:03:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvU5L-0005BO-GN for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 03:03: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 k5S6oxIX027276; Tue, 27 Jun 2006 23:50: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 k5S6oxat027275; Tue, 27 Jun 2006 23:50: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.webfaction.com (IDENT:U2FsdGVkX1/ywtRtw2e7T7dcJaIPQIeXKzcnROUaq+M@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5S6owRk027260 for ; Tue, 27 Jun 2006 23:50:58 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (IDENT:U2FsdGVkX1/frHK+QHXIijnt3O1mmBI6L420z0JwMuA@localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k5S6ouwJ000436; Wed, 28 Jun 2006 01:50:56 -0500 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id k5S6otga000433; Wed, 28 Jun 2006 07:50:55 +0100 X-Authentication-Warning: mail1.webfaction.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.webfaction.com with HTTP; Wed, 28 Jun 2006 07:50:55 +0100 (BST) Message-ID: <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> In-Reply-To: <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> Date: Wed, 28 Jun 2006 07:50:55 +0100 (BST) Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests From: "Sylvain Hellegouarch" To: "Robert Sayre" 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: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > > On 6/27/06, James M Snell wrote: >> Please define "conformance" in regards to this test. That is, what is >> the exact behavior that a library must perform when a code library has >> an API like, "getContent" on the content element. >> >> e.g., is a parser not conformant if it passes the DIV on to the >> consuming application with the expectation that the application is >> responsible for "doing the right thing" with it? > > Don't be dense. Would the parser be conformant if it passed on the > feed, entry, and div elements with that expectation? I'll file a bug > on UFP and I bet you it'll get fixed without a question, because there > won't be a bad-faith interpretation to fight. That's two demerits this > week for you. Tsk tsk. > Could this teasing please stop? It noises the debate and starts being *really* annoying for all of us. If you two have issues, do that in private as this is not the right place. Thanks, - Sylvain From owner-atom-syntax@mail.imc.org Wed Jun 28 03:56:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUu0-00040i-34 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 03:56:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUty-0007wQ-O7 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 03:56: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 k5S7h3kh045433; Wed, 28 Jun 2006 00:43: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 k5S7h3UP045431; Wed, 28 Jun 2006 00:43: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 vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5S7h2JB045417 for ; Wed, 28 Jun 2006 00:43:02 -0700 (MST) (envelope-from rubys@intertwingly.net) Received: from [192.168.2.103] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11.20060308/8.12.11) with ESMTP id k5S7gxnK031721; Wed, 28 Jun 2006 03:42:59 -0400 Message-ID: <44A23302.8010203@intertwingly.net> Date: Wed, 28 Jun 2006 03:42:58 -0400 From: Sam Ruby User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> In-Reply-To: <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@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: 7bac9cb154eb5790ae3b2913587a40de Robert Sayre wrote: > > I'll file a bug > on UFP and I bet you it'll get fixed without a question http://sourceforge.net/tracker/index.php?func=detail&aid=1474256&group_id=112328&atid=661937 - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Jun 28 04:01:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUz4-0000Cq-OY for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 04:01:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUz1-0008Q4-Bm for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 04:01: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 k5S7kkFJ046850; Wed, 28 Jun 2006 00:46: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 k5S7kk8Y046849; Wed, 28 Jun 2006 00:46: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 satakieli.dnainternet.net (satakieli.dnainternet.net [212.149.75.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5S7ki50046806 for ; Wed, 28 Jun 2006 00:46:45 -0700 (MST) (envelope-from hsivonen@iki.fi) Received: from [217.140.228.82] (217-140-228-82.adsl-net.finnetcom.net [217.140.228.82]) by satakieli.dnainternet.net (Postfix) with ESMTP id 495CFCC53 for ; Wed, 28 Jun 2006 10:46:37 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44A1BEDC.9030402@gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31848969-490A-4CF3-956B-1FA4AF79F96C@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Wed, 28 Jun 2006 10:46:35 +0300 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: bb8f917bb6b8da28fc948aeffb74aa17 On Jun 28, 2006, at 02:27, James M Snell wrote: > That is, what is > the exact behavior that a library must perform when a code library has > an API like, "getContent" on the content element. One sane behaviour is to return an org.w3c.dom.DocumentFragment with the deep copies of the children of the namespace div with the xml:base and xml:lang context pushed down on each child. That's a bit awkward, so I guess using a placeholder root element with the xml:base and xml:lang context would make sense, provided that the API doc says that the root is not part of the logical content. This could be emphasized by using a root in a private namespace instead of an XHTML div. (Just to be obnoxious enough to make sure users of the API take note. :-) Or, alternatively, the API could construct a full XHTML nu.xom.Document or org.w3c.dom.Document and thereby unify the return value for type="application/xhtml+xml", type="text/html", type="xhtml" and type="html". (Assuming, that is that the library runs TagSoup and automatically converts HTML to XHTML.) Actually, I think this would be the best way. In any case, returning a String as the value of the content means that the library is not fully doing its job when the logical value is an XML document fragment. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Jun 28 08:40:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZL6-0006fY-9j for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 08:40:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZFF-0002D5-Hq for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 08:34: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 k5SCM72I043758; Wed, 28 Jun 2006 05: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 k5SCM77D043757; Wed, 28 Jun 2006 05: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 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 k5SCM6gV043751 for ; Wed, 28 Jun 2006 05:22:06 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so847820wra for ; Wed, 28 Jun 2006 05:22: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=tguEgWQbdNPk4xDHwpCX6DR9xVGtABSlKYhrLzM5cM8XnO/t8YbLmzIXa5SNlPYTm/f0p6bONpe4pEEctU3VBtXCh+708KBM9cxjBlnigFBnULTIOmGSEHT2hy+/6ZY3NU2oIiKFqs3KSRQ7OVCh2Hug7FA/K2PMkN2pOFrgXqo= Received: by 10.54.80.12 with SMTP id d12mr812938wrb; Wed, 28 Jun 2006 05:22:05 -0700 (PDT) Received: from ?9.33.67.67? ( [129.33.1.37]) by mx.gmail.com with ESMTP id 12sm127189wrl.2006.06.28.05.22.05; Wed, 28 Jun 2006 05:22:05 -0700 (PDT) Message-ID: <44A27468.5060502@gmail.com> Date: Wed, 28 Jun 2006 05:22:00 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: sh@defuze.org CC: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> In-Reply-To: <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hey Sylvain, On this one, I'm being very serious. I need to know what "conformance" means. Hiding the div completely from users of Abdera would mean potentially losing important data (e.g. the div may contain an xml:lang or xml:base) or forcing me to perform additional processing (pushing the in-scope xml:lang/xml:base down to child elements of the div. It also has ease-of-use ramifications on the API. So I really do need a solid answer on this one. - James Sylvain Hellegouarch wrote: >> On 6/27/06, James M Snell wrote: >>> Please define "conformance" in regards to this test. That is, what is >>> the exact behavior that a library must perform when a code library has >>> an API like, "getContent" on the content element. >>> >>> e.g., is a parser not conformant if it passes the DIV on to the >>> consuming application with the expectation that the application is >>> responsible for "doing the right thing" with it? >> Don't be dense. Would the parser be conformant if it passed on the >> feed, entry, and div elements with that expectation? I'll file a bug >> on UFP and I bet you it'll get fixed without a question, because there >> won't be a bad-faith interpretation to fight. That's two demerits this >> week for you. Tsk tsk. >> > > Could this teasing please stop? It noises the debate and starts being > *really* annoying for all of us. If you two have issues, do that in > private as this is not the right place. > > Thanks, > - Sylvain > From owner-atom-syntax@mail.imc.org Wed Jun 28 10:10:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvakh-0004qi-5B for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 10:10:47 -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 1Fva0z-0007YO-AZ for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 09:23:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvZpY-0007R1-8K for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 09:11: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 k5SCSsIu046128; Wed, 28 Jun 2006 05:28: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 k5SCSslR046127; Wed, 28 Jun 2006 05:28: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.webfaction.com (IDENT:U2FsdGVkX1/Q9PoWQ7kYL/QRHboahsCVLqnARBRaLWQ@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SCSq0n046101 for ; Wed, 28 Jun 2006 05:28:53 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (IDENT:U2FsdGVkX18kjUIWDwSjhHSyM2OP6ew1AbH1YHNrNw4@localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k5SCSpn6012141; Wed, 28 Jun 2006 07:28:51 -0500 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id k5SCSp1a012139; Wed, 28 Jun 2006 13:28:51 +0100 X-Authentication-Warning: mail1.webfaction.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.webfaction.com with HTTP; Wed, 28 Jun 2006 13:28:51 +0100 (BST) Message-ID: <58709.194.221.74.7.1151497731.squirrel@mail1.webfaction.com> In-Reply-To: <44A27468.5060502@gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> Date: Wed, 28 Jun 2006 13:28:51 +0100 (BST) Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests From: "Sylvain Hellegouarch" To: "James M Snell" Cc: sh@defuze.org, "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: -2.2 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > Hey Sylvain, > > On this one, I'm being very serious. I need to know what "conformance" > means. Hiding the div completely from users of Abdera would mean > potentially losing important data (e.g. the div may contain an xml:lang > or xml:base) or forcing me to perform additional processing (pushing the > in-scope xml:lang/xml:base down to child elements of the div. It also > has ease-of-use ramifications on the API. So I really do need a solid > answer on this one. > > - James Hi James, I can totally be wrong but as the div tag is added by the Atom processor when creating a content of type XHTML, I believe it should be stripped out when extracting the content to avoid altering the original meaning of the message. That's my understanding anyway. - Sylvain From owner-atom-syntax@mail.imc.org Wed Jun 28 13:03:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdRO-0003zh-L1 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 13:03:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvdRN-0003pS-5Z for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 13:03: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 k5SGn7eX038028; Wed, 28 Jun 2006 09:49: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 k5SGn7DC038027; Wed, 28 Jun 2006 09:49: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 mail.gmx.net (mail.gmx.de [213.165.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5SGn51o037957 for ; Wed, 28 Jun 2006 09:49:05 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 28 Jun 2006 16:48:58 -0000 Received: from xdsl-213-196-226-143.netcologne.de (EHLO klangraum) [213.196.226.143] by mail.gmx.net (mp015) with SMTP; 28 Jun 2006 18:48:58 +0200 X-Authenticated: #163624 Date: Wed, 28 Jun 2006 18:49:16 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Message-ID: <20060628164916.GJ14985@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <44A27468.5060502@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 k5SGn7eX038028 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 * James M Snell [2006-06-28 14:35]: > Hiding the div completely from users of Abdera would mean > potentially losing important data (e.g. the div may contain an > xml:lang or xml:base) or forcing me to perform additional > processing (pushing the in-scope xml:lang/xml:base down to > child elements of the div. How is that any different from having to find ways to pass any in-scope xml:lang/xml:base down to API clients when the content is type=3D"html" or type=3D"text"? I hope you didn=E2=80=99t punt on thos= e? Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Jun 28 13:59:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveKC-0002kF-6L for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 13:59:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveKA-0002DI-O3 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 13:59: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 k5SHkgeX057452; Wed, 28 Jun 2006 10:46: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 k5SHkgAk057451; Wed, 28 Jun 2006 10:46: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SHkfv9057441 for ; Wed, 28 Jun 2006 10:46:41 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id t4so1222628wxc for ; Wed, 28 Jun 2006 10:46: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=k2UIrChRmzmMKlFzwh+ng8G1rLdjUBXXpXY54YSl2bir36ROKdiJL4uFLb9jCzDVplu5fi9CkuHUegWyxA8UmHO3JExgacq1ibzlY39ksppHA5cDKJe23mE6xwoy3z0PIoJ7p3oe3wPgjC2G29o0aPRSFo6gX3V5XAjZ2Vwo9SM= Received: by 10.70.112.9 with SMTP id k9mr1657392wxc; Wed, 28 Jun 2006 10:46:40 -0700 (PDT) Received: from ?192.168.4.55? ( [66.92.95.13]) by mx.gmail.com with ESMTP id h19sm7809990wxd.2006.06.28.10.46.40; Wed, 28 Jun 2006 10:46:40 -0700 (PDT) Message-ID: <44A2C07E.5010106@gmail.com> Date: Wed, 28 Jun 2006 10:46:38 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> In-Reply-To: <20060628164916.GJ14985@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 k5SHkgeX057452 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Our Content interface has methods for getting to that information. - James A. Pagaltzis wrote: > * James M Snell [2006-06-28 14:35]: >> Hiding the div completely from users of Abdera would mean >> potentially losing important data (e.g. the div may contain an >> xml:lang or xml:base) or forcing me to perform additional >> processing (pushing the in-scope xml:lang/xml:base down to >> child elements of the div. >=20 > How is that any different from having to find ways to pass any > in-scope xml:lang/xml:base down to API clients when the content > is type=3D"html" or type=3D"text"? I hope you didn=E2=80=99t punt on th= ose? >=20 > Regards, From owner-atom-syntax@mail.imc.org Wed Jun 28 14:02:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FveN0-0006w6-JL for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 14:02:34 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FveMz-0002IQ-0e for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 14:02: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 k5SHnQ7k058578; Wed, 28 Jun 2006 10:49: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 k5SHnQWl058576; Wed, 28 Jun 2006 10:49: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 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 k5SHnIPr058495 for ; Wed, 28 Jun 2006 10:49:20 -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 <20060628174911.XFGC27023.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Wed, 28 Jun 2006 18:49:11 +0100 Received: from cpc2-stok1-0-0-cust748.bagu.cable.ntl.com ([86.4.234.237]) by aamtaout03-winn.ispmail.ntl.com with ESMTP id <20060628174911.KJKR18889.aamtaout03-winn.ispmail.ntl.com@cpc2-stok1-0-0-cust748.bagu.cable.ntl.com>; Wed, 28 Jun 2006 18:49:11 +0100 Date: Wed, 28 Jun 2006 18:49:08 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <668491148.20060628184908@djpowell.net> To: James M Snell CC: sh@defuze.org, Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests In-Reply-To: <44A27468.5060502@gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@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: c1c65599517f9ac32519d043c37c5336 Wednesday, June 28, 2006, 1:22:00 PM, James Snell wrote: > Hiding the div completely from users of Abdera would mean > potentially losing important data (e.g. the div may contain an xml:lang > or xml:base) I don't think that the div should contain an xml:base, because it isn't valid to use xml:base in XHTML 1.x. As the xhtml:div is added by the producer, it should be removed by the consumer, so there shouldn't be an xml:lang in there either. I wouldn't expect consumers to handle either consistently, so if you are a producer don't do it. I think in my implementation I handle lang and base on the div, and store them out-of-band, but it is more by accident than anything. I would hope that any other xmlns:* declarations on xhtml:div are honoured. Namespaces are so core to XML that making any recommendations about their placement is asking for trouble. > or forcing me to perform additional processing (pushing the > in-scope xml:lang/xml:base down to child elements of the div. I avoid that, it isn't nice as the xml:base will make the XHTML invalid and browser-dependant. In my RDF implementation, I store the lang context, base context, content model, and other stuff out-of-band from the content itself. I do rely on RDF's exclusive canonicalization rules though, to preserve the inscope namespace decls. (I assume that namespace decls aren't strictly allowed in valid XHTML either? Oh well...) > It also has ease-of-use ramifications on the API. So I really do > need a solid answer on this one. You need to preserve a load of context in addition to the content string itself, so expect to have to return these extra properties for each use of Text Constructs in your API. It is a bit of a high-barrier to entry really. (If Atom had been designed in JSON, instead of XML, I wonder if it would have been more sympathetic to the OO/RDBMS crowd, and whether we would have bothered with such fine-grained language tagging?) -- Dave From owner-atom-syntax@mail.imc.org Wed Jun 28 14:17:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvebt-0004hm-Ue for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 14:17:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvebs-0003dP-IK for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 14:17: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 k5SI6BGJ064276; Wed, 28 Jun 2006 11:06: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 k5SI6BBh064275; Wed, 28 Jun 2006 11:06: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.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5SI69q9064230 for ; Wed, 28 Jun 2006 11:06:10 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 28 Jun 2006 18:06:03 -0000 Received: from xdsl-213-196-226-143.netcologne.de (EHLO klangraum) [213.196.226.143] by mail.gmx.net (mp037) with SMTP; 28 Jun 2006 20:06:03 +0200 X-Authenticated: #163624 Date: Wed, 28 Jun 2006 20:06:22 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Message-ID: <20060628180622.GK14985@klangraum> Mail-Followup-To: Atom Syntax References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <44A2C07E.5010106@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 k5SI6BGJ064276 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 * James M Snell [2006-06-28 20:00]: > A. Pagaltzis wrote: > > * James M Snell [2006-06-28 14:35]: > >> Hiding the div completely from users of Abdera would mean > >> potentially losing important data (e.g. the div may contain > >> an xml:lang or xml:base) or forcing me to perform additional > >> processing (pushing the in-scope xml:lang/xml:base down to > >> child elements of the div. > >=20 > > How is that any different from having to find ways to pass > > any in-scope xml:lang/xml:base down to API clients when the > > content is type=3D"html" or type=3D"text"? I hope you didn=E2=80=99t = punt > > on those? > > Our Content interface has methods for getting to that > information. Then stripping the `div` is not an issue, is it? Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Jun 28 15:31:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfl4-0007Jp-Lg for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 15:31:30 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvfl2-0001Qx-6h for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 15:31: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 k5SJGQm9085823; Wed, 28 Jun 2006 12:16: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 k5SJGQbT085822; Wed, 28 Jun 2006 12:16: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 rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SJGQm2085795 for ; Wed, 28 Jun 2006 12:16:26 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from [192.168.0.3] (c-67-182-206-93.hsd1.ut.comcast.net[67.182.206.93]) by comcast.net (rwcrmhc12) with SMTP id <20060628191620m12006r8dme>; Wed, 28 Jun 2006 19:16:20 +0000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060628180622.GK14985@klangraum> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: From: Antone Roundy Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Wed, 28 Jun 2006 13:16:18 -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 k5SJGQm2085817 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 k5SJGQm9085823 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 On Jun 28, 2006, at 12:06 PM, A. Pagaltzis wrote: > * James M Snell [2006-06-28 20:00]: >> A. Pagaltzis wrote: >>> * James M Snell [2006-06-28 14:35]: >>>> Hiding the div completely from users of Abdera would mean >>>> potentially losing important data (e.g. the div may contain >>>> an xml:lang or xml:base) or forcing me to perform additional >>>> processing (pushing the in-scope xml:lang/xml:base down to >>>> child elements of the div. >>> >>> How is that any different from having to find ways to pass >>> any in-scope xml:lang/xml:base down to API clients when the >>> content is type=3D"html" or type=3D"text"? I hope you didn=92t punt >>> on those? >> >> Our Content interface has methods for getting to that >> information. > > Then stripping the `div` is not an issue, is it? Consider this: ... axe Whether there's a problem depends on whether one requests the =20 xml:base, xml:lang, or whatever for the atom:content element itself =20 or for the CONTENT OF the atom:content element, in which case the =20 library could return the values it got from the xhtml:div. Except in =20 unusual cases like this, the result would be identical. Certainly a distinction could be made between how an XML library =20 would handle this vs. how an Atom library would handle it. An Atom =20 processing library might be expected to be able to do things like: * give me the raw contents of the atom:content element * give me the contents of the atom:content element converted to well-=20 formed XHTML (whether it started as text, escaped tag soup, or inline =20 xhtml) In the former case, keeping the div feels like the right thing to do--=20 the consuming app would have to know to remove it. In the latter =20 case, removing the div from xhtml content feels like the right thing =20 to do. But unless the library gives me the xml:base, for example, =20 which applies to the content of the atom:content element (as =20 converted to well-formed xhtml or whatever), as opposed to the =20 xml:base which applied to the atom:content element itself, there's =20 potential for trouble. ...now that I think about it, if the library always returns the =20 xml:base which applies to the content of the element, that could =20 cause trouble too: ... axe Here, if I get xml:base for the content of content, it will be =20 "http://example.com/feu/". Then, if I get the raw content of the =20 element, strip the div, and apply xml:base myself, I'll erroneously =20 use "http://example.com/feu/feu/" as the base URI unless I know to =20 ignore the xml:base attribute on the div. From owner-atom-syntax@mail.imc.org Wed Jun 28 17:08:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhHB-0005vk-E6 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:08:45 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhH8-00074M-MH for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:08: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 k5SKrpKk018039; Wed, 28 Jun 2006 13: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 k5SKrpKl018038; Wed, 28 Jun 2006 13: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 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 k5SKrolT018032 for ; Wed, 28 Jun 2006 13:53:51 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so471522wra for ; Wed, 28 Jun 2006 13:53: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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BqdM38tqLhV7fvJh7vWDHqx3LfeRyPBRWPI42Whv0TeLgr1Ue946stxajJUJrHVHx7qrCCu1PyRID7RxIISMdbcNedmScvODAev+rcj5twFQ6Z7Dh0KNv8eoXCrfq762l8jsy0jsk34/ODcKEqwiPlTnTsOzmlD63KAUNITUICA= Received: by 10.54.100.5 with SMTP id x5mr1187980wrb; Wed, 28 Jun 2006 13:51:25 -0700 (PDT) Received: from ?172.30.1.26? ( [66.100.255.7]) by mx.gmail.com with ESMTP id 8sm1776163wrl.2006.06.28.13.53.46; Wed, 28 Jun 2006 13:53:46 -0700 (PDT) Message-ID: <44A2EC59.1060503@gmail.com> Date: Wed, 28 Jun 2006 13:53:45 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> 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 k5SKrpKk018039 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Antone, Very good write up. The fact that xml:base on div is not valid XHTML is somewhat irrelevant given that there is an identical problem with xml:lang. For instance, if I have
...
 and I drop the div silently, then I'v= e got a problem. Granted, the producer of the atom feed really shouldn't have done this, but we still need to be able to handle it properly if it does happen. The solution I think I'm going to go with is to support both approaches. Our default behavior will be to return the div. A separate API will provide the content without the div. When it doubt, do both. - James Antone Roundy wrote: >=20 > On Jun 28, 2006, at 12:06 PM, A. Pagaltzis wrote: >> * James M Snell [2006-06-28 20:00]: >>> A. Pagaltzis wrote: >>>> * James M Snell [2006-06-28 14:35]: >>>>> Hiding the div completely from users of Abdera would mean >>>>> potentially losing important data (e.g. the div may contain >>>>> an xml:lang or xml:base) or forcing me to perform additional >>>>> processing (pushing the in-scope xml:lang/xml:base down to >>>>> child elements of the div. >>>> >>>> How is that any different from having to find ways to pass >>>> any in-scope xml:lang/xml:base down to API clients when the >>>> content is type=3D"html" or type=3D"text"? I hope you didn=92t punt >>>> on those? >>> >>> Our Content interface has methods for getting to that >>> information. >> >> Then stripping the `div` is not an issue, is it? >=20 > Consider this: >=20 > > ... > > xml:base=3D"http://example.com/feu/"> href=3D"axe.html">axe > > >=20 > Whether there's a problem depends on whether one requests the xml:base, > xml:lang, or whatever for the atom:content element itself or for the > CONTENT OF the atom:content element, in which case the library could > return the values it got from the xhtml:div. Except in unusual cases > like this, the result would be identical. >=20 > Certainly a distinction could be made between how an XML library would > handle this vs. how an Atom library would handle it. An Atom processin= g > library might be expected to be able to do things like: >=20 > * give me the raw contents of the atom:content element > * give me the contents of the atom:content element converted to > well-formed XHTML (whether it started as text, escaped tag soup, or > inline xhtml) >=20 > In the former case, keeping the div feels like the right thing to > do--the consuming app would have to know to remove it. In the latter > case, removing the div from xhtml content feels like the right thing to > do. But unless the library gives me the xml:base, for example, which > applies to the content of the atom:content element (as converted to > well-formed xhtml or whatever), as opposed to the xml:base which applie= d > to the atom:content element itself, there's potential for trouble. >=20 > ...now that I think about it, if the library always returns the xml:bas= e > which applies to the content of the element, that could cause trouble t= oo: >=20 > > ... > > href=3D"axe.html">axe > > >=20 > Here, if I get xml:base for the content of content, it will be > "http://example.com/feu/". Then, if I get the raw content of the > element, strip the div, and apply xml:base myself, I'll erroneously use > "http://example.com/feu/feu/" as the base URI unless I know to ignore > the xml:base attribute on the div. >=20 >=20 From owner-atom-syntax@mail.imc.org Wed Jun 28 17:15:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhO5-0006sX-K0 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:15:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhO3-0007JV-0q for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:15: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 k5SKtYUE018602; Wed, 28 Jun 2006 13:55: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 k5SKtYxg018601; Wed, 28 Jun 2006 13:55: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 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 k5SKtXfA018595 for ; Wed, 28 Jun 2006 13:55:34 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so471811wra for ; Wed, 28 Jun 2006 13:55:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mTtzDtgC+VT6zo7R8Rl8tFWan6nm0NhGZfdkmFTxbt/yehmcEFDRWSLruPzOIWPBFPq/vIZzkOXl/IZ6CH6Uz3L8QBrKXhzNfKfQx3m5tc0pVUJLPrwqUDE95gg5YuArL4ym9wpKW0HrJKi/zQykpgICOI9s4hDNvOPGDIrknc8= Received: by 10.54.143.5 with SMTP id q5mr1229313wrd; Wed, 28 Jun 2006 13:55:32 -0700 (PDT) Received: from ?172.30.1.26? ( [66.100.255.7]) by mx.gmail.com with ESMTP id 33sm1506928wra.2006.06.28.13.55.31; Wed, 28 Jun 2006 13:55:31 -0700 (PDT) Message-ID: <44A2ECC1.80508@gmail.com> Date: Wed, 28 Jun 2006 13:55:29 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <668491148.20060628184908@djpowell.net> In-Reply-To: <668491148.20060628184908@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: 9182cfff02fae4f1b6e9349e01d62f32 David, you're right, ideally the xhtml container div would be nothing but the div, but if it's not, we still need to be prepared to handle it. Silent data loss sucks, if it's silly data :-) - James David Powell wrote: > Wednesday, June 28, 2006, 1:22:00 PM, James Snell wrote: > >> Hiding the div completely from users of Abdera would mean >> potentially losing important data (e.g. the div may contain an xml:lang >> or xml:base) > > I don't think that the div should contain an xml:base, because it > isn't valid to use xml:base in XHTML 1.x. As the xhtml:div is added by > the producer, it should be removed by the consumer, so there shouldn't > be an xml:lang in there either. I wouldn't expect consumers to handle > either consistently, so if you are a producer don't do it. I think in > my implementation I handle lang and base on the div, and store them > out-of-band, but it is more by accident than anything. > [snip] From owner-atom-syntax@mail.imc.org Wed Jun 28 17:28:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhah-0003lt-8I for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:28:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvhae-000836-OS for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:28: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 k5SLG0EW025764; Wed, 28 Jun 2006 14:16: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 k5SLG0w0025763; Wed, 28 Jun 2006 14:16: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 bay0-omc2-s26.bay0.hotmail.com (bay0-omc2-s26.bay0.hotmail.com [65.54.246.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SLFxAs025722 for ; Wed, 28 Jun 2006 14:16:00 -0700 (MST) (envelope-from j4_james@hotmail.com) Received: from hotmail.com ([64.4.19.82]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 14:15:54 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jun 2006 14:15:54 -0700 Message-ID: Received: from 81.179.83.121 by BAY109-DAV10.phx.gbl with DAV; Wed, 28 Jun 2006 21:15:53 +0000 X-Originating-IP: [81.179.83.121] X-Originating-Email: [j4_james@hotmail.com] X-Sender: j4_james@hotmail.com From: "James Holderness" To: References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Wed, 28 Jun 2006 22:15:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: 28 Jun 2006 21:15:54.0358 (UTC) FILETIME=[0A64C160:01C69AF8] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Antone Roundy wrote: > Consider this: > > > ... > > href="axe.html">axe > > Another observation for those of you curious about interoperability... the last time I tested xml:base conformance (which admittedly was a while back) I couldn't find a single aggregator that supported xml:base on the div element. Regards James From owner-atom-syntax@mail.imc.org Wed Jun 28 17:39:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhkn-00082S-Sh for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:39:21 -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 1FvhaF-0007wm-DV for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:28:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvhRm-00078A-6R for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17: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 k5SL7Q5C022644; Wed, 28 Jun 2006 14:07: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 k5SL7Q54022642; Wed, 28 Jun 2006 14:07:26 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SL7ORx022614 for ; Wed, 28 Jun 2006 14:07:25 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so1235570nfc for ; Wed, 28 Jun 2006 14:07:23 -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=oh++Ounk9GNR4UH3kqEIR9pgzTuG246KYrdSd3fGGrr0wyulHNyXkYulkwaG9lC01vfmX1/QQFpgyg24qkZB5WLz8/NwqAaRJDigoohSa1nDjSc4XI51SIVMsrBJNybXb+PkTdPiyPrvxTNalCp2Fu5CzuUb0fGQOqMfcpKIiwA= Received: by 10.49.27.7 with SMTP id e7mr1064054nfj; Wed, 28 Jun 2006 14:07:23 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Wed, 28 Jun 2006 14:07:22 -0700 (PDT) Message-ID: <68fba5c50606281407v2b0c8d4fmacb902a04182ee8c@mail.gmail.com> Date: Wed, 28 Jun 2006 17:07:22 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Cc: "Antone Roundy" , atom-syntax@imc.org In-Reply-To: <44A2EC59.1060503@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.2 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 6/28/06, James M Snell wrote: > > Our default behavior will be to return the div. A > separate API will provide the content without the div. So, standards-off-by-default then? Unbelievable. -- Robert Sayre From owner-atom-syntax@mail.imc.org Wed Jun 28 17:40:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhlt-0000aa-Ih for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:40:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvhlq-0001xq-WF for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:40: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 k5SLJkxq027034; Wed, 28 Jun 2006 14:19: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 k5SLJk4i027033; Wed, 28 Jun 2006 14:19: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.238]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SLJjE5027027 for ; Wed, 28 Jun 2006 14:19:45 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so476163wra for ; Wed, 28 Jun 2006 14:19:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RBDjKg8DOQwpVAvSK7AnMKu85ShNet7qTm4hTssApngaop7t0GUxIQRqpgCmeNmTiTRWnkdT0Wc2Ar7Rt9DnkF7LlQtD4BJAJVKRCKbHYGSkTB6I4KPAyZA3ObiOvsjN4GoWYomciBsR/JS968j6HKu6KXf/GBeMY9MdTslavfs= Received: by 10.54.80.7 with SMTP id d7mr1248859wrb; Wed, 28 Jun 2006 14:19:45 -0700 (PDT) Received: from ?172.30.1.26? ( [66.100.255.7]) by mx.gmail.com with ESMTP id 35sm2961455wra.2006.06.28.14.19.44; Wed, 28 Jun 2006 14:19:44 -0700 (PDT) Message-ID: <44A2F26E.7090001@gmail.com> Date: Wed, 28 Jun 2006 14:19:42 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> In-Reply-To: <44A2EC59.1060503@gmail.com> Content-Type: text/plain; charset=windows-1252 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 Actually, switch this. I realized after I sent this that I had it backwards. The default behavior will be to not return the div. A separate API will provide the content with the div. - James James M Snell wrote: > [snip]...The solution I think I'm going to go with is to support > both approaches. Our default behavior will be to return the div. A > separate API will provide the content without the div. When it doubt, > do both. > > - James > From owner-atom-syntax@mail.imc.org Wed Jun 28 18:02:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi73-0000Wc-1n for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:02:21 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvi1q-0003TZ-3Z for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:56: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 k5SLAYZ9023967; Wed, 28 Jun 2006 14:10: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 k5SLAYXx023966; Wed, 28 Jun 2006 14:10: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.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SLAWm8023958 for ; Wed, 28 Jun 2006 14:10:33 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so1236010nfc for ; Wed, 28 Jun 2006 14:10:32 -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=MUMcRcDHtLUUghQ5yn+9Ct5I/XTl1U6vuHnFW1ii4wX/NhYJfIjuQpHbdSc/d6/ADHcloo/CX8wVljQToxAlTo7JNwEb5EMxhEYL1GAmEsdZLswrjRDGrfjkcJvWOFapPs+ACZy+Tl0FgNyPmzDavFBx8QJriJDBRZ2ec4jl5AI= Received: by 10.49.54.13 with SMTP id g13mr971080nfk; Wed, 28 Jun 2006 14:10:32 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Wed, 28 Jun 2006 14:10:31 -0700 (PDT) Message-ID: <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> Date: Wed, 28 Jun 2006 17:10:31 -0400 From: "Robert Sayre" To: "Antone Roundy" Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests 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: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Irrelevant. The content in the entries below should be handled the same way: ... axe ... axe On 6/28/06, Antone Roundy wrote: > > On Jun 28, 2006, at 12:06 PM, A. Pagaltzis wrote: > > * James M Snell [2006-06-28 20:00]: > >> A. Pagaltzis wrote: > >>> * James M Snell [2006-06-28 14:35]: > >>>> Hiding the div completely from users of Abdera would mean > >>>> potentially losing important data (e.g. the div may contain > >>>> an xml:lang or xml:base) or forcing me to perform additional > >>>> processing (pushing the in-scope xml:lang/xml:base down to > >>>> child elements of the div. > >>> > >>> How is that any different from having to find ways to pass > >>> any in-scope xml:lang/xml:base down to API clients when the > >>> content is type="html" or type="text"? I hope you didn't punt > >>> on those? > >> > >> Our Content interface has methods for getting to that > >> information. > > > > Then stripping the `div` is not an issue, is it? > > Consider this: > > > ... > > axe > > > > Whether there's a problem depends on whether one requests the > xml:base, xml:lang, or whatever for the atom:content element itself > or for the CONTENT OF the atom:content element, in which case the > library could return the values it got from the xhtml:div. Except in > unusual cases like this, the result would be identical. > > Certainly a distinction could be made between how an XML library > would handle this vs. how an Atom library would handle it. An Atom > processing library might be expected to be able to do things like: > > * give me the raw contents of the atom:content element > * give me the contents of the atom:content element converted to well- > formed XHTML (whether it started as text, escaped tag soup, or inline > xhtml) > > In the former case, keeping the div feels like the right thing to do-- > the consuming app would have to know to remove it. In the latter > case, removing the div from xhtml content feels like the right thing > to do. But unless the library gives me the xml:base, for example, > which applies to the content of the atom:content element (as > converted to well-formed xhtml or whatever), as opposed to the > xml:base which applied to the atom:content element itself, there's > potential for trouble. > > ...now that I think about it, if the library always returns the > xml:base which applies to the content of the element, that could > cause trouble too: > > > ... > > href="axe.html">axe > > > > Here, if I get xml:base for the content of content, it will be > "http://example.com/feu/". Then, if I get the raw content of the > element, strip the div, and apply xml:base myself, I'll erroneously > use "http://example.com/feu/feu/" as the base URI unless I know to > ignore the xml:base attribute on the div. > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From owner-atom-syntax@mail.imc.org Wed Jun 28 18:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi72-0000Wc-MN for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:02:20 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvi2j-0003Ue-I0 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 17:57: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 k5SLhIXN034773; Wed, 28 Jun 2006 14:43: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 k5SLhIeU034771; Wed, 28 Jun 2006 14:43: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 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 k5SLhHOZ034728 for ; Wed, 28 Jun 2006 14:43:17 -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 <20060628214310.DSNR15018.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Wed, 28 Jun 2006 22:43:10 +0100 Received: from cpc2-stok1-0-0-cust748.bagu.cable.ntl.com ([86.4.234.237]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060628214310.OZEE1421.aamtaout02-winn.ispmail.ntl.com@cpc2-stok1-0-0-cust748.bagu.cable.ntl.com>; Wed, 28 Jun 2006 22:43:10 +0100 Date: Wed, 28 Jun 2006 22:43:06 +0100 From: David Powell X-Mailer: The Bat! (v3.73 Release Candidate 1) Professional X-Priority: 3 (Normal) Message-ID: <624953985.20060628224306@djpowell.net> To: James M Snell CC: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests In-Reply-To: <44A2ECC1.80508@gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <668491148.20060628184908@djpowell.net> <44A2ECC1.80508@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: 4adaf050708fb13be3316a9eee889caa Wednesday, June 28, 2006, 9:55:29 PM, James Snell wrote: > David, > you're right, ideally the xhtml container div would be nothing but the > div, but if it's not, we still need to be prepared to handle it. Silent > data loss sucks, if it's silly data :-) I'm just looking at it from the perspective of the producer and the consumer. In my consumer implementation, I take the resolved base URI of the div (including any xml:base there), and the language context of the div, discard the div, and store them both out-of-band of the content, with namespace prefixes inline. That's probably good enough. Some post-processing is used to convert the data in the store into a form that allows it to be safely embedded in an HTML page - I've been trying XSLT (with TagSoup for HTML content). I don't think that the div should have lang or base attached, but if it is there, it is better to use it than ignore it, cause it is likely there for a reason. I wouldn't produce feeds like that though. If people start using CSS links in feeds (or even just CSS styling in aggregators), discarding the div could be important. If you're going to supply an API for extracting usable [X]HTML, there are a number of features that consumers might want in some combination: * Forcing the XHTML to use a blank namespace prefix to make it DTD compatable, and removing unused prefixes. * Resolving relative references (which will inevitably be a lossy process) * Removing XSS risks (intentionally lossy) I still keep the original content in a reasonably accurate form though. -- Dave From owner-atom-syntax@mail.imc.org Wed Jun 28 18:05:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviA0-0008Ds-63 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:05:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvi9y-0003sL-Pg for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:05: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 k5SLs0Fr038336; Wed, 28 Jun 2006 14:54: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 k5SLs07J038335; Wed, 28 Jun 2006 14:54: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 sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SLrxt7038297 for ; Wed, 28 Jun 2006 14:54:00 -0700 (MST) (envelope-from antone@geckotribe.com) Received: from [192.168.0.3] (c-67-182-206-93.hsd1.ut.comcast.net[67.182.206.93]) by comcast.net (sccrmhc13) with SMTP id <2006062821535301300b0vr0e>; Wed, 28 Jun 2006 21:53:54 +0000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.com> Content-Transfer-Encoding: 7bit From: Antone Roundy Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Wed, 28 Jun 2006 15:53:52 -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: 8b431ad66d60be2d47c7bfeb879db82c On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: > The content in the entries below should be handled the same way: > > > ... > > axe > > > > > ... > > axe xhtml:div> > > Of course the end result of both should be identical. Is that what you mean by "should be handled the same way"? The question is, if the xhtml:div is stripped by the library before handing it off to the app, how is the app going to get the attributes that were on the div? Is the library going to push those values down into the content or act as if they were on the atom:content element (or something similar to that)? BTW, it just occurred to me that pushing them down into the content won't work. Here's an example where that would fail: ... Oui! Notice that there are no elements inside the xhtml:div for xml:lang to be attached to (and even if there were any, any text appearing outside of them would not have the correct xml:lang attached to it). So it looks like the options (both of a which a single library could support, of course) are: * Strip the div, but provide a way to get the attributes that were on it or * Leave the div From owner-atom-syntax@mail.imc.org Wed Jun 28 18:20:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviP3-0001uH-0v for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:20:57 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviP1-0004GI-L6 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:20: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 k5SM0f0x040484; Wed, 28 Jun 2006 15:00: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 k5SM0fA5040483; Wed, 28 Jun 2006 15: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 satakieli.dnainternet.net (satakieli.dnainternet.net [212.149.75.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SM0eZX040447 for ; Wed, 28 Jun 2006 15:00:41 -0700 (MST) (envelope-from hsivonen@iki.fi) Received: from [84.239.175.252] (unknown [84.239.175.252]) by satakieli.dnainternet.net (Postfix) with ESMTP id 2E7FEC8E1 for ; Thu, 29 Jun 2006 01:00:33 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44A2EC59.1060503@gmail.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23DDE642-60AF-4E84-A47A-865711F54366@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Thu, 29 Jun 2006 01:00:32 +0300 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: 7655788c23eb79e336f5f8ba8bce7906 On Jun 28, 2006, at 23:53, James M Snell wrote: > or instance, if I have
xml:lang="fr">...
 and I drop the div silently, then > I've > got a problem. Dropping the div shouldn't mean dropping the language and base URL context. You need to communicate those anyway in the case they are inherited from higher up in the document tree. (When the script that generates my feed copies node from a document tree to another, it checks the inherited language of the node being copied. If it differs from the inherited language of the insertion target, the newly inserted copy gets an explicit xml:lang.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Jun 28 18:26:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviUJ-0002ZC-Va for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:26:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviUI-0004jF-EL for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:26: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 k5SMBGi2044174; Wed, 28 Jun 2006 15:11: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 k5SMBGNa044173; Wed, 28 Jun 2006 15:11: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SMBGtA044167 for ; Wed, 28 Jun 2006 15:11:16 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 24360 invoked by uid 17064); 28 Jun 2006 22:11:15 -0000 Received: from unknown (HELO [192.168.1.6]) ([83.154.161.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 28 Jun 2006 22:11:15 -0000 In-Reply-To: <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.com> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <494A4BF5-BE18-425A-8237-EF765D3B5253@bblfish.net> Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Thu, 29 Jun 2006 00:11:11 +0200 To: Roundy Antone , atom-owl@googlegroups.com X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Thanks everyone for this really interesting discussion. I have added a note to this effect to the latest atom-owl ontology [1]. In Atom-Owl we could easily do both. [] :content "Oui!"^:xhtml. or we could have [] :content "Oui!"@fr^:xhtml . or [] :content [ :xhtml "oui"; :lang "en" ]. It would be simplest I suppose to have the :xhtml type be defined as always having an
element. Except that of course it would look odd for xhtml content that contains an base tag such as
......
From this discussion it looks like the most reasonable would be to strip the
element. In which case one may wonder what the whole purpose of putting the
in the content really was in the first place. Henry [1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml On 28 Jun 2006, at 23:53, Antone Roundy wrote: > > On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: >> The content in the entries below should be handled the same way: >> >> >> ... >> >> axe >> >> >> >> >> ... >> >> axe> xhtml:div> >> >> > > Of course the end result of both should be identical. Is that what > you mean by "should be handled the same way"? The question is, if > the xhtml:div is stripped by the library before handing it off to > the app, how is the app going to get the attributes that were on > the div? Is the library going to push those values down into the > content or act as if they were on the atom:content element (or > something similar to that)? > > BTW, it just occurred to me that pushing them down into the content > won't work. Here's an example where that would fail: > > > ... > > Oui! > > > > Notice that there are no elements inside the xhtml:div for xml:lang > to be attached to (and even if there were any, any text appearing > outside of them would not have the correct xml:lang attached to it). > > So it looks like the options (both of a which a single library > could support, of course) are: > > * Strip the div, but provide a way to get the attributes that were > on it > or > * Leave the div From owner-atom-syntax@mail.imc.org Wed Jun 28 18:38:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvig7-00015Q-Ke for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:38:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvig6-0005kp-59 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 18:38: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 k5SMO1im048373; Wed, 28 Jun 2006 15:24: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 k5SMO1ia048372; Wed, 28 Jun 2006 15:24: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 bblfish.net (bblfish.net [192.220.66.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SMO0IA048364 for ; Wed, 28 Jun 2006 15:24:00 -0700 (MST) (envelope-from henry.story@bblfish.net) Received: (qmail 31893 invoked by uid 17064); 28 Jun 2006 22:23:58 -0000 Received: from unknown (HELO [192.168.1.6]) ([83.154.161.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 28 Jun 2006 22:23:58 -0000 In-Reply-To: <494A4BF5-BE18-425A-8237-EF765D3B5253@bblfish.net> References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.com> <494A4BF5-BE18-425A-8237-EF765D3B5253@bblfish.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E6EA024-4C1E-41B4-B162-A57A5656EE69@bblfish.net> Cc: Roundy Antone , atom-owl@googlegroups.com, Atom Syntax Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Date: Thu, 29 Jun 2006 00:23:55 +0200 To: Henry Story X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a On the other hand, if one strips the
element, then :xhtml can no longer be an inverse functional property, as contents with different bases could have very different meanings. Just think of xhtml content with a picture, which in one subtree points to bush, and in another one points to Gore, the relative uri references being the same in both cases. This seems to make it more reasonable to create a new literal type which contains the
. (it makes finding duplicates in an rdf database easier). On that topic are there not xhtml ways to create xml:base and xml:lang elements? Should those not perhaps be used instead on the
element? Henry On 29 Jun 2006, at 00:11, Henry Story wrote: > > Thanks everyone for this really interesting discussion. I have > added a note to this effect to the latest atom-owl ontology [1]. > > In Atom-Owl we could easily do both. > > [] :content "Oui!"^:xhtml. > > or we could have > > [] :content "Oui!"@fr^:xhtml . > > or > > [] :content [ :xhtml "oui"; > :lang "en" ]. > > > It would be simplest I suppose to have the :xhtml type be defined > as always having an
element. Except that of course it > would look odd for xhtml content that contains an base tag > such as > >
> ...... >
> > From this discussion it looks like the most reasonable would be to > strip the
element. In which case one may wonder what the > whole purpose of putting the
in the content really was in the > first place. > > Henry > > [1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml > > > On 28 Jun 2006, at 23:53, Antone Roundy wrote: > >> >> On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: >>> The content in the entries below should be handled the same way: >>> >>> >>> ... >>> >>> axe >>> >>> >>> >>> >>> ... >>> >>> axe>> xhtml:div> >>> >>> >> >> Of course the end result of both should be identical. Is that >> what you mean by "should be handled the same way"? The question >> is, if the xhtml:div is stripped by the library before handing it >> off to the app, how is the app going to get the attributes that >> were on the div? Is the library going to push those values down >> into the content or act as if they were on the atom:content >> element (or something similar to that)? >> >> BTW, it just occurred to me that pushing them down into the >> content won't work. Here's an example where that would fail: >> >> >> ... >> >> Oui! >> >> >> >> Notice that there are no elements inside the xhtml:div for >> xml:lang to be attached to (and even if there were any, any text >> appearing outside of them would not have the correct xml:lang >> attached to it). >> >> So it looks like the options (both of a which a single library >> could support, of course) are: >> >> * Strip the div, but provide a way to get the attributes that were >> on it >> or >> * Leave the div From owner-atom-syntax@mail.imc.org Wed Jun 28 19:11:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjBc-0000dV-Sv for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 19:11:08 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvjBY-0004is-5G for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 19:11: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 k5SMXlMS051623; Wed, 28 Jun 2006 15:33: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 k5SMXl09051622; Wed, 28 Jun 2006 15:33: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 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 k5SMXkSb051615 for ; Wed, 28 Jun 2006 15:33:47 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i24so488044wra for ; Wed, 28 Jun 2006 15:33:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KGd6DOYzRILWDWCRmsJFom25gVG8EAWvoyzIqNmnxVrLhHlOnR5F97xkKS/ZR0nUoFGmgMWKFJDkRmCbysWBJRtnHMwXhPD9mU8AY/sRyDs6EHOX4RwdlgL0oF0gRByQfmWd1OzNGxDLNALc/+D/fJoIeLmLbmkr8fWEWarhVxk= Received: by 10.54.128.6 with SMTP id a6mr1335926wrd; Wed, 28 Jun 2006 15:33:45 -0700 (PDT) Received: from ?172.30.1.26? ( [66.100.255.7]) by mx.gmail.com with ESMTP id 10sm2908662wrl.2006.06.28.15.33.44; Wed, 28 Jun 2006 15:33:45 -0700 (PDT) Message-ID: <44A303C7.4030007@gmail.com> Date: Wed, 28 Jun 2006 15:33:43 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <68fba5c50606281410u3d17fec9j56487d8d04f40549@mail.gmail.com> <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.com> In-Reply-To: <2B1368E4-97CC-4782-A0AE-66A1B1973C9A@geckotribe.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: c0bedb65cce30976f0bf60a0a39edea4 I've just made a change in our implementation that in the following case...
Oui!
 Content.getLanguage() will return "fr" Content.getBaseUri() will return "foo/bar" The other possible attributes are still available via a Div interface, but in the default case, things just sort of work themselves out. - James Antone Roundy wrote: > > On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote: >> The content in the entries below should be handled the same way: >> >> >> ... >> >> axe >> >> >> >> >> ... >> >> > href="axe.html">axe >> >> > > Of course the end result of both should be identical. Is that what you > mean by "should be handled the same way"? The question is, if the > xhtml:div is stripped by the library before handing it off to the app, > how is the app going to get the attributes that were on the div? Is the > library going to push those values down into the content or act as if > they were on the atom:content element (or something similar to that)? > > BTW, it just occurred to me that pushing them down into the content > won't work. Here's an example where that would fail: > > > ... > > Oui! > > > > Notice that there are no elements inside the xhtml:div for xml:lang to > be attached to (and even if there were any, any text appearing outside > of them would not have the correct xml:lang attached to it). > > So it looks like the options (both of a which a single library could > support, of course) are: > > * Strip the div, but provide a way to get the attributes that were on it > or > * Leave the div > > From owner-atom-syntax@mail.imc.org Wed Jun 28 20:13:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkA6-00064e-07 for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:13:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvkA4-0004HZ-Db for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:13: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 k5T00wue080750; Wed, 28 Jun 2006 17:00: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 k5T00wvG080749; Wed, 28 Jun 2006 17:00: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.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5T00uWS080709 for ; Wed, 28 Jun 2006 17:00:56 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Jun 2006 00:00:50 -0000 Received: from xdsl-213-196-244-21.netcologne.de (EHLO klangraum) [213.196.244.21] by mail.gmx.net (mp028) with SMTP; 29 Jun 2006 02:00:50 +0200 X-Authenticated: #163624 Date: Thu, 29 Jun 2006 02:01:09 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Message-ID: <20060629000109.GL14985@klangraum> Mail-Followup-To: Atom Syntax References: <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> <23DDE642-60AF-4E84-A47A-865711F54366@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23DDE642-60AF-4E84-A47A-865711F54366@iki.fi> 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: de4f315c9369b71d7dd5909b42224370 * Henri Sivonen [2006-06-29 00:20]: > On Jun 28, 2006, at 23:53, James M Snell wrote: > >or instance, if I have
>xml:lang="fr">...
 and I drop the div silently, > >then I've got a problem. > > Dropping the div shouldn't mean dropping the language and base > URL context. You need to communicate those anyway in the case > they are inherited from higher up in the document tree. Exactly. Regards, -- Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Jun 28 20:16:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkD0-0000WL-Gz for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:16:38 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvkCz-0004eP-2G for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:16: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 k5T06ijY082624; Wed, 28 Jun 2006 17:06: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 k5T06i7w082623; Wed, 28 Jun 2006 17:06:44 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T06hDp082602 for ; Wed, 28 Jun 2006 17:06:43 -0700 (MST) (envelope-from mnot@mnot.net) Received: from [172.21.37.137] (unknown [207.126.230.225]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id EBEC1A32A1 for ; Wed, 28 Jun 2006 20:06:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AFCF4EB-F605-4F8A-858A-7F76521B5759@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Fwd: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt Date: Wed, 28 Jun 2006 17:06:41 -0700 To: Atom-Syntax Syntax X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 As discussed earlier. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 28 June 2006 3:50:01 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Extensions for Multi-Document Syndicated Feeds > Author(s) : M. Nottingham > Filename : draft-nottingham-atompub-feed-history-06.txt > Pages : 17 > Date : 2006-6-28 > > This specification defines three types of syndicated feeds that > enable publication of entries across one or more feed documents. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- > history-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-nottingham-atompub-feed-history-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-nottingham-atompub-feed-history-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-6-28151604.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Jun 28 20:53:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvkmr-0007jl-RR for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:53:41 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvkmq-0000Sg-CQ for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 20:53: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 k5T0XkmS092493; Wed, 28 Jun 2006 17:33: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 k5T0XkBV092492; Wed, 28 Jun 2006 17:33:46 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5T0XimQ092442 for ; Wed, 28 Jun 2006 17:33:45 -0700 (MST) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Jun 2006 00:33:38 -0000 Received: from xdsl-213-196-244-21.netcologne.de (EHLO klangraum) [213.196.244.21] by mail.gmx.net (mp020) with SMTP; 29 Jun 2006 02:33:38 +0200 X-Authenticated: #163624 Date: Thu, 29 Jun 2006 02:33:56 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Message-ID: <20060629003356.GM14985@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@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 k5T0XkmS092493 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 * Antone Roundy [2006-06-28 21:30]: > Consider this: >=20 > > ... > > feu/">axe > > >=20 > Whether there's a problem depends on whether one requests the > xml:base, xml:lang, or whatever for the atom:content element > itself or for the CONTENT OF the atom:content element, in which > case the library could return the values it got from the > xhtml:div. Except in unusual cases like this, the result would > be identical. I can see your argument, but I find this too fine a distinction. The `div` is part of the container when `type=3D"xhtml"` as far as I=E2=80=99m concerned. I=E2=80=99d just merge the information with that o= n the `content` element and pretend there=E2=80=99s no difference. As far as the feed=E2=80=99s *meaning* is concerned, there isn=E2=80=99t, after all. > * give me the raw contents of the atom:content element > * give me the contents of the atom:content element converted to > well-formed XHTML (whether it started as text, escaped tag > soup, or inline xhtml) >=20 > In the former case, keeping the div feels like the right thing > to do -- the consuming app would have to know to remove it. In > the latter case, removing the div from xhtml content feels > like the right thing to do. Yes, that sounds sane. =E2=80=9CGive me the raw contents=E2=80=9D would b= e somehting only an Atom-aware API client would want to do, so it is reasonable to expect that the client knows what to do with the `div` when it finds that the content type was `xhtml`. Anyone who just wants to use the data and doesn=E2=80=99t want to have to care about how Atom works should just ask for XHTML and not care what it was originally packaged as. > ...now that I think about it, if the library always returns the > xml:base which applies to the content of the element, that > could cause trouble too: >=20 > > ... > > href=3D"axe.html">axe > > >=20 > Here, if I get xml:base for the content of content, it will be > "http://example.com/feu/". Then, if I get the raw content of > the element, strip the div, and apply xml:base myself, I'll > erroneously use "http://example.com/feu/feu/" as the base URI > unless I know to ignore the xml:base attribute on the div. I agree, but I don=E2=80=99t see how that=E2=80=99s at all to the point. = Such an API client is just buggy. If they ask for the raw `content` content, then they should also ask for the `content` base URI, not for the content=E2=80=99s base URI. Guiding API clients to avoid such a mistake should be reasonably easy by naming the methods appropriately, ie something like `get_container_content` and `get_container_base` vs `get_content` and `get_base`. (That the first pair of names is so long is fully intentional=E2=80=A6 :-) ) Regards, --=20 Aristotle Pagaltzis // From owner-atom-syntax@mail.imc.org Wed Jun 28 23:14:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvmzI-0004bx-Ha for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 23:14:40 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvmzF-0005HW-4A for atompub-archive@lists.ietf.org; Wed, 28 Jun 2006 23:14: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 k5T2wmgj042734; Wed, 28 Jun 2006 19:58: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 k5T2wmLn042733; Wed, 28 Jun 2006 19:58: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 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 k5T2wkJh042713 for ; Wed, 28 Jun 2006 19:58:47 -0700 (MST) (envelope-from sayrer@gmail.com) Received: by nf-out-0910.google.com with SMTP id q29so12859nfc for ; Wed, 28 Jun 2006 19:58: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=YIDraCOzOHGuJhUYTlt10vm7B1LLAM94Yj1AWcxz1lGBR9OFRcBDb1f+qcmj910Nt8SEjeimQWWlFHe9QAsD1arlQBvh1KE+eD7zX6XbdxZGBoW4krUMfthEtno1oP10eQVDWXlnkBgbw6u4bbQ5P5176GtlcAgBP1d236Iyjlo= Received: by 10.49.68.9 with SMTP id v9mr1230594nfk; Wed, 28 Jun 2006 19:58:46 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Wed, 28 Jun 2006 19:58:45 -0700 (PDT) Message-ID: <68fba5c50606281958k1d2cdb81xd243b2b47175c340@mail.gmail.com> Date: Wed, 28 Jun 2006 22:58:45 -0400 From: "Robert Sayre" To: "James M Snell" Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests Cc: atom-syntax@imc.org In-Reply-To: <44A2F26E.7090001@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> <44A2F26E.7090001@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: ea4ac80f790299f943f0a53be7e1a21a On 6/28/06, James M Snell wrote: > > Actually, switch this. I realized after I sent this that I had it > backwards. The default behavior will be to not return the div. A > separate API will provide the content with the div. > Next time, don't start out with egregious obfuscation, and then kick and scream through tons of list traffic with beyond-bogus arguments. Here's how it started: It's a waste of other people's time. Once or twice is understandable, reasonable people sometimes disagree on basic things. I think we're up to 20 or 30 of these incidents with you, though. At this point, it's not something to be replied to with a smart remark. It belies contempt for your colleagues. We shouldn't have to sit here and listen to specious tripe because it sounds semi-plausible to a non-implementor. It's abusive, and it's much worse than the nasty messages so many of us have sent. -- Robert Sayre From owner-atom-syntax@mail.imc.org Thu Jun 29 03:04:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvqa1-0005xn-61 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 03:04:49 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvqZx-0000z9-OW for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 03:04: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 k5T6oGk6019388; Wed, 28 Jun 2006 23:50: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 k5T6oG9j019387; Wed, 28 Jun 2006 23:50: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 willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T6oFrr019349 for ; Wed, 28 Jun 2006 23:50:15 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5T6o29F017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 06:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvqLi-00007o-5G; Thu, 29 Jun 2006 02:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-protocol-09.txt Message-Id: Date: Thu, 29 Jun 2006 02:50:02 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Publishing Protocol Author(s) : B. de Hora, J. Gregorio Filename : draft-ietf-atompub-protocol-09.txt Pages : 41 Date : 2006-6-28 The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC4287). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-protocol-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28215225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-protocol-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28215225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Thu Jun 29 06:02:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtLv-0001lp-E9 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:02:27 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvtLr-00008w-0t for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:02: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 k5T9nhOH075283; Thu, 29 Jun 2006 02:49: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 k5T9nhqM075282; Thu, 29 Jun 2006 02:49: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 mail1.webfaction.com (IDENT:U2FsdGVkX1/YQE/ByapyH/pI9nVW5WdMZymlAp8iOYM@mail1.webfaction.com [67.15.2.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T9ngJY075273 for ; Thu, 29 Jun 2006 02:49:42 -0700 (MST) (envelope-from sh@defuze.org) Received: from mail1.webfaction.com (IDENT:U2FsdGVkX1/LvIGMdau6KQCU3cfaSfSR7vMxO4g57jc@localhost.localdomain [127.0.0.1]) by mail1.webfaction.com (8.12.11.20060308/8.13.3) with ESMTP id k5T9nf7f019742; Thu, 29 Jun 2006 04:49:41 -0500 Received: (from apache@localhost) by mail1.webfaction.com (8.12.11.20060308/8.12.11/Submit) id k5T9neHA019740; Thu, 29 Jun 2006 10:49:40 +0100 X-Authentication-Warning: mail1.webfaction.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.webfaction.com with HTTP; Thu, 29 Jun 2006 10:49:40 +0100 (BST) Message-ID: <10291.194.221.74.7.1151574580.squirrel@mail1.webfaction.com> In-Reply-To: <44A39EE3.4060206@gmail.com> References: <44A39EE3.4060206@gmail.com> Date: Thu, 29 Jun 2006 10:49:40 +0100 (BST) Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt 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: 79899194edc4f33a41f49410777972f8 James, > > First minor nit: > > Section 8.1: > > When the POST request contains an Atom Entry Document, ... > > that should read "POST response" and not "POST request" I think you make a mistake. POST request is the correct wording here... well it is my understanding. But if you are correct one should read, "a response to a POST request" not "POST response". - Sylvain From owner-atom-syntax@mail.imc.org Thu Jun 29 06:02:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtLG-0000o2-U6 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:01:46 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvtIu-0006sk-I5 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 05:59: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 k5T9ZYsZ071240; Thu, 29 Jun 2006 02:35: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 k5T9ZYYh071239; Thu, 29 Jun 2006 02:35: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T9ZXdF071232 for ; Thu, 29 Jun 2006 02:35:33 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id h27so63430wxd for ; Thu, 29 Jun 2006 02:35:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sLsQ6d1Z0e6eMl/Ukkri77eAWwIcxh1hFSw9TwbDKlpX4uvrxjgZReb5q7vYS1babdak3BouT1KQTc5QFMWzz+npohFkc/VLersBwiRUjHMYOo1c2Wj1dPIwzHwR+KsXI5Do4+/7TtUHbxnIRhxGiYeeiYF0gQ/0e+N/EVYi2kk= Received: by 10.70.14.14 with SMTP id 14mr2797393wxn; Thu, 29 Jun 2006 02:35:33 -0700 (PDT) Received: from ?63.118.136.51? ( [63.118.136.51]) by mx.gmail.com with ESMTP id i10sm324580wxd.2006.06.29.02.35.32; Thu, 29 Jun 2006 02:35:32 -0700 (PDT) Message-ID: <44A39EE3.4060206@gmail.com> Date: Thu, 29 Jun 2006 02:35:31 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: 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: c0bedb65cce30976f0bf60a0a39edea4 First minor nit: Section 8.1: When the POST request contains an Atom Entry Document, ... that should read "POST response" and not "POST request" - James Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : B. de Hora, J. Gregorio > Filename : draft-ietf-atompub-protocol-09.txt > Pages : 41 > Date : 2006-6-28 > > The Atom Publishing Protocol (APP) is an application-level protocol > for publishing and editing Web resources. The protocol is based on > HTTP transport of Atom-formatted representations. The Atom format is > documented in the Atom Syndication Format (RFC4287). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-atom-syntax@mail.imc.org Thu Jun 29 06:07:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtQX-0000ye-95 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:07:13 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvtQP-0000fp-NQ for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:07: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 k5T9fIhJ072906; Thu, 29 Jun 2006 02:41:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5T9fI8E072905; Thu, 29 Jun 2006 02:41:18 -0700 (MST) (envelope-from owner-atom-syntax@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T9fHPK072889 for ; Thu, 29 Jun 2006 02:41:18 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id h27so63921wxd for ; Thu, 29 Jun 2006 02:41: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=ttas11aBE7tweriSqqiglwzFWlD47thS4rPtfxyC0pW2sEFMtp/TnY/sXDgU0hl5fP7Ut9nOzy+XCx34vPt59T+AC441rdGBY5XdVrHjd4EsFdC+jSV1SSGUaVxt1/+Cuxpcn2L5aPUqs4LHzp+MKpdUQopvMeJzwJCkNa9Q/wE= Received: by 10.70.26.17 with SMTP id 17mr2802694wxz; Thu, 29 Jun 2006 02:41:17 -0700 (PDT) Received: from ?63.118.136.51? ( [63.118.136.51]) by mx.gmail.com with ESMTP id h37sm353263wxd.2006.06.29.02.41.15; Thu, 29 Jun 2006 02:41:16 -0700 (PDT) Message-ID: <44A3A03A.9030404@gmail.com> Date: Thu, 29 Jun 2006 02:41:14 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: 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: 41c17b4b16d1eedaa8395c26e9a251c4 I note that the examples in the spec were likely cut-n-pasted from the wiki, for instance: Content- Length: nnn Content- Type: application/atom+xml; charset="utf-8" Content- Location: http://example.org/edit/first-post.atom The space following the "Content-" is intended to get around a wiki bug and should be removed from the samples in the spec. - James Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : B. de Hora, J. Gregorio > Filename : draft-ietf-atompub-protocol-09.txt > Pages : 41 > Date : 2006-6-28 > > The Atom Publishing Protocol (APP) is an application-level protocol > for publishing and editing Web resources. The protocol is based on > HTTP transport of Atom-formatted representations. The Atom format is > documented in the Atom Syndication Format (RFC4287). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-atom-syntax@mail.imc.org Thu Jun 29 06:31:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvtnu-0005yk-KR for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:31:22 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvtnq-0003iZ-5I for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 06:31: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 k5T9skK4076514; Thu, 29 Jun 2006 02:54: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 k5T9sk7D076513; Thu, 29 Jun 2006 02:54: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 wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.193]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5T9sk2Y076498 for ; Thu, 29 Jun 2006 02:54:46 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wx-out-0102.google.com with SMTP id h27so65026wxd for ; Thu, 29 Jun 2006 02:54:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=W/yPGCkowAF9aaFMO5jUJ/Unv+rrZ9pamintnbx5RVBAthYF5Bm0dgVH7iVrz47BMVXyuBp+d53FB2+pnWZoUgeNMKdM9y/+MrYt0i6tv2qQMMMfovzmyF++PALRxMM2K0Fkln7pk8hsVFVT7/R9K7//WJXqjZlxAjOStbYcvnc= Received: by 10.70.26.17 with SMTP id 17mr2817959wxz; Thu, 29 Jun 2006 02:54:45 -0700 (PDT) Received: from ?63.118.136.51? ( [63.118.136.51]) by mx.gmail.com with ESMTP id i35sm358627wxd.2006.06.29.02.54.45; Thu, 29 Jun 2006 02:54:45 -0700 (PDT) Message-ID: <44A3A364.5030005@gmail.com> Date: Thu, 29 Jun 2006 02:54:44 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: <44A39EE3.4060206@gmail.com> <10291.194.221.74.7.1151574580.squirrel@mail1.webfaction.com> In-Reply-To: <10291.194.221.74.7.1151574580.squirrel@mail1.webfaction.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: 8abaac9e10c826e8252866cbe6766464 Ok, reading it again I think you're right, either way, however, the construction of the sentence looks odd. Shortening it up to use your wording below would likely be better: The response to a POST request containing an Atom Entry Document SHOULD contain a Content-Location header that contains the same character-by-character value as the Location header. - James Sylvain Hellegouarch wrote: > James, > >> First minor nit: >> >> Section 8.1: >> >> When the POST request contains an Atom Entry Document, ... >> >> that should read "POST response" and not "POST request" > > I think you make a mistake. POST request is the correct wording here... > well it is my understanding. > > But if you are correct one should read, "a response to a POST request" not > "POST response". > > - Sylvain > > From owner-atom-syntax@mail.imc.org Thu Jun 29 07:34:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvumW-0003cl-Pz for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:34:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvumU-0001HK-E1 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:34: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 k5TBKNuj002707; Thu, 29 Jun 2006 04:20: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 k5TBKNGc002706; Thu, 29 Jun 2006 04:20: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TBKNmq002668 for ; Thu, 29 Jun 2006 04:20:23 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.83] (mail.724.ie [213.94.211.166]) by chilco.textdrive.com (Postfix) with ESMTP id 18FD7DBC77 for ; Thu, 29 Jun 2006 11:20:16 +0000 (UTC) Message-ID: <44A3B770.5010806@dehora.net> Date: Thu, 29 Jun 2006 12:20:16 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests References: <68fba5c50606271258y38ed93cbi1aa4d6c664f56dc0@mail.gmail.com> <44A1BEDC.9030402@gmail.com> <68fba5c50606271631i70ddd24t22f2f8cca68dcfbf@mail.gmail.com> <34711.194.221.74.7.1151477455.squirrel@mail1.webfaction.com> <44A27468.5060502@gmail.com> <20060628164916.GJ14985@klangraum> <44A2C07E.5010106@gmail.com> <20060628180622.GK14985@klangraum> <44A2EC59.1060503@gmail.com> In-Reply-To: <44A2EC59.1060503@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 James M Snell wrote: > Antone, > > Very good write up. The fact that xml:base on div is not valid XHTML is > somewhat irrelevant given that there is an identical problem with > xml:lang. For instance, if I have
xml:lang="fr">...
 and I drop the div silently, then I've > got a problem. Granted, the producer of the atom feed really shouldn't > have done this, but we still need to be able to handle it properly if it > does happen. I don't agree bug compliance is the way to go. If downstream code has to patch against broken providers that's a race to the bottom - it's a culture where specs cease to matter because they can be mercilessly E and E'd. File a bug report instead. Otoh if we have spec'd in a feature here which doesn't sit on top on XML infrastructure properly, that's another matter - "hey, xml lib, handle this element special like, cos atom markup don't care about clean layering" sounds like a problem. We seem to keep doing that with xml:* features (lang, include, base). Atom is to XML as HTML is to SGML? cheers Bill From owner-atom-syntax@mail.imc.org Thu Jun 29 07:38:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvuqY-0004Al-6F for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:38:10 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvuqW-00023T-Q7 for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:38: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 k5TBP6ne003966; Thu, 29 Jun 2006 04:25: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 k5TBP6Xa003965; Thu, 29 Jun 2006 04:25: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TBP6NT003934 for ; Thu, 29 Jun 2006 04:25:06 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.83] (dev2.mcpps.com [213.94.211.166]) by chilco.textdrive.com (Postfix) with ESMTP id 75412DBC8C for ; Thu, 29 Jun 2006 11:25:00 +0000 (UTC) Message-ID: <44A3B88B.6070906@dehora.net> Date: Thu, 29 Jun 2006 12:24:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: <44A39EE3.4060206@gmail.com> <10291.194.221.74.7.1151574580.squirrel@mail1.webfaction.com> <44A3A364.5030005@gmail.com> In-Reply-To: <44A3A364.5030005@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: e1e48a527f609d1be2bc8d8a70eb76cb Hi James, I understand what you mean. We'll patch the English on that sentence next time around. cheers Bill James M Snell wrote: > Ok, reading it again I think you're right, either way, however, the > construction of the sentence looks odd. Shortening it up to use your > wording below would likely be better: > > The response to a POST request containing an Atom Entry Document > SHOULD contain a Content-Location header that contains the same > character-by-character value as the Location header. > > - James > > Sylvain Hellegouarch wrote: >> James, >> >>> First minor nit: >>> >>> Section 8.1: >>> >>> When the POST request contains an Atom Entry Document, ... >>> >>> that should read "POST response" and not "POST request" >> I think you make a mistake. POST request is the correct wording here... >> well it is my understanding. >> >> But if you are correct one should read, "a response to a POST request" not >> "POST response". >> >> - Sylvain >> >> > From owner-atom-syntax@mail.imc.org Thu Jun 29 07:47:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvuzy-0005iJ-Da for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:47:54 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvuzw-0002eV-Vc for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 07:47: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 k5TBQ4RA004177; Thu, 29 Jun 2006 04:26: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 k5TBQ4Ou004176; Thu, 29 Jun 2006 04:26: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TBQ4vB004149 for ; Thu, 29 Jun 2006 04:26:04 -0700 (MST) (envelope-from bill@dehora.net) Received: from [192.168.213.83] (dev2.mcpps.com [213.94.211.166]) by chilco.textdrive.com (Postfix) with ESMTP id 61EB4DBBB5 for ; Thu, 29 Jun 2006 11:25:58 +0000 (UTC) Message-ID: <44A3B8C6.70401@dehora.net> Date: Thu, 29 Jun 2006 12:25:58 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: <44A3A03A.9030404@gmail.com> In-Reply-To: <44A3A03A.9030404@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: cd26b070c2577ac175cd3a6d878c6248 So much for my search/replace skillz. Ok, will fix. cheers Bill James M Snell wrote: > I note that the examples in the spec were likely cut-n-pasted from the > wiki, for instance: > > Content- Length: nnn > Content- Type: application/atom+xml; charset="utf-8" > Content- Location: http://example.org/edit/first-post.atom > > The space following the "Content-" is intended to get around a wiki bug > and should be removed from the samples in the spec. > > - James > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. >> >> Title : The Atom Publishing Protocol >> Author(s) : B. de Hora, J. Gregorio >> Filename : draft-ietf-atompub-protocol-09.txt >> Pages : 41 >> Date : 2006-6-28 >> >> The Atom Publishing Protocol (APP) is an application-level protocol >> for publishing and editing Web resources. The protocol is based on >> HTTP transport of Atom-formatted representations. The Atom format is >> documented in the Atom Syndication Format (RFC4287). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-atompub-protocol-09.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > From owner-atom-syntax@mail.imc.org Thu Jun 29 10:56:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvxwt-0004or-Nd for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 10:56:55 -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 1FvxLU-0001pG-5P for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 10:18:16 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvxGU-0005JS-6L for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 10:13: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 k5TDr0Au038062; Thu, 29 Jun 2006 06:53: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 k5TDr0GR038061; Thu, 29 Jun 2006 06:53: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 mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TDqw8A038028; Thu, 29 Jun 2006 06:52:59 -0700 (MST) (envelope-from sewe@rbg.informatik.tu-darmstadt.de) Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from ) id 1Fvwwz-0006AR-Ej; Thu, 29 Jun 2006 15:52:57 +0200 Received: from ultra11.rbg.informatik.tu-darmstadt.de ([130.83.160.101]) by mx1.freenet.de with esmtpsa (ID sewe2004@freenet.de) (TLSv1:AES256-SHA:256) (Exim 4.62 #2) id 1Fvwwz-0008M4-AO; Thu, 29 Jun 2006 15:52:57 +0200 Message-ID: <44A3DB38.4080206@rbg.informatik.tu-darmstadt.de> Date: Thu, 29 Jun 2006 15:52:56 +0200 From: Andreas Sewe Reply-To: atom-protocol@imc.org 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 Publishing Protocol CC: atom-syntax@imc.org Subject: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt) 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: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Well, the subject says it all; here they are: - It were nice if the example in 7.1 would include @xml:lang, since both workspace/@title and collection/@title are Language-Sensitive. Granted, there might be a Content-Language response header (not shown) to do the job, but IMHO the example would benefit from making language information explicit. - The proposed file extension for APP Introspection Documents (.atomsrv) and its media type (application/atomserv+xml) are inconsistent. It would IMHO be better to use either "atomsrv" or "atomserv" consistently in both file extension and media type. Everything else is just confusing for no good reason. Regards, Andreas Sewe FWIW, I have set the Reply-To to atom-protocol, since it seems to be the more appropriate list to discuss these things -- not that it really matters, given the overlap between atom-syntax's and atom-protocol's audiences... From owner-atom-syntax@mail.imc.org Thu Jun 29 11:48:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvykM-0006ve-3S for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 11:48:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvykK-0001d6-OQ for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 11:48: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 k5TFZ1cd066609; Thu, 29 Jun 2006 08:35: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 k5TFZ10K066606; Thu, 29 Jun 2006 08:35: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TFZ0TZ066566; Thu, 29 Jun 2006 08:35:00 -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 952E6DBC8C; Thu, 29 Jun 2006 15:34:54 +0000 (UTC) Message-ID: <44A3F31D.3090205@dehora.net> Date: Thu, 29 Jun 2006 16:34:53 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: atom-protocol@imc.org CC: atom-syntax@imc.org Subject: Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt) References: <44A3DB38.4080206@rbg.informatik.tu-darmstadt.de> In-Reply-To: <44A3DB38.4080206@rbg.informatik.tu-darmstadt.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Andreas Sewe wrote: > > Well, the subject says it all; here they are: > > - It were nice if the example in 7.1 would include @xml:lang, since both > workspace/@title and collection/@title are Language-Sensitive. Granted, > there might be a Content-Language response header (not shown) to do the > job, but IMHO the example would benefit from making language information > explicit. +1. Which are clients supposed to respect in a conflict, the Content-Language header or the xml:lang, ie, does XML On The Web Failing Miserably, Utterly, And Completely extend to Content-Language+xml:lang? > - The proposed file extension for APP Introspection Documents (.atomsrv) > and its media type (application/atomserv+xml) are inconsistent. It would > IMHO be better to use either "atomsrv" or "atomserv" consistently in > both file extension and media type. Everything else is just confusing > for no good reason. I have no strong prefs here (other than liking "application/app+xml"). cheers Bill From owner-atom-syntax@mail.imc.org Thu Jun 29 12:26:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzLz-0001w3-Cj for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 12:26:55 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzLs-0005Gl-Tu for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 12:26: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 k5TG1SP9076379; Thu, 29 Jun 2006 09:01: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 k5TG1Sd9076377; Thu, 29 Jun 2006 09:01: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 pop.ironclad.net.au ([203.30.247.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TG1QxH076157 for ; Thu, 29 Jun 2006 09:01:27 -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); Fri, 30 Jun 2006 02:01:11 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 30 Jun 2006 02:00:23 +1000 Subject: Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <44A3F31D.3090205@dehora.net> 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 k5TG1RxH076372 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 k5TG1SP9076379 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 30/6/06 1:34 AM, "Bill de h=D3ra" wrote: > Which are clients supposed to respect in a conflict, the > Content-Language header or the xml:lang, ie, does XML On The Web Failin= g > Miserably, Utterly, And Completely extend to Content-Language+xml:lang? xml:lang, if you think of xml being nested. in other words, what is the lang of the atom:content below: HTTP 200 OK Content-Language: ch ... ... ... ... e. From owner-atom-syntax@mail.imc.org Thu Jun 29 13:10:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw01i-00080v-DY for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 13:10:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw01h-0002X9-2D for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 13:10: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 k5TGqhrj093683; Thu, 29 Jun 2006 09:52: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 k5TGqh6M093682; Thu, 29 Jun 2006 09:52: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 chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5TGqhTa093657 for ; Thu, 29 Jun 2006 09:52:43 -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 56490DBE92 for ; Thu, 29 Jun 2006 16:52:37 +0000 (UTC) Message-ID: <44A40554.4060205@dehora.net> Date: Thu, 29 Jun 2006 17:52:36 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Atom Syntax Subject: Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id k5TGqhrj093683 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Eric Scheid wrote: > On 30/6/06 1:34 AM, "Bill de h=D3ra" wrote: >=20 >> Which are clients supposed to respect in a conflict, the >> Content-Language header or the xml:lang, ie, does XML On The Web Faili= ng >> Miserably, Utterly, And Completely extend to Content-Language+xml:lang= ? >=20 > xml:lang, if you think of xml being nested. >=20 > in other words, what is the lang of the atom:content below: >=20 >=20 > HTTP 200 OK > Content-Language: ch > ... >=20 > > > > ... > > ... > > ... > >=20 Hi Eric, I guess my next question is - do we need to tell people this in the=20 protocol spec, or should I Just Know That, Utterly, And Completely ? cheers Bill From owner-atom-syntax@mail.imc.org Thu Jun 29 23:02:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw9HM-0000P2-8W for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 23:02:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw9HJ-0005Eo-OE for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 23: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 k5U2jeDp089870; Thu, 29 Jun 2006 19:45: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 k5U2jeWv089869; Thu, 29 Jun 2006 19:45: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 wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5U2jdWR089860 for ; Thu, 29 Jun 2006 19:45:40 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i11so232231wra for ; Thu, 29 Jun 2006 19:45:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=m/BgYhcac1CBj2W2XISjFev327+JzQR2r36e7ypf3Y49dV6CwSLGJGRttEMONkNkSUpKoH/Yh9rdLTByjkIIO0V1CfydwmhUDHngDRAOjx1Pc6sDnwUrMYlXc6lFIU5L29rho9O1tfLvKbkcV58iR8K0lZ478wr+RqmGLBxnpHE= Received: by 10.54.103.6 with SMTP id a6mr157787wrc; Thu, 29 Jun 2006 19:45:39 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 13sm1577204wrl.2006.06.29.19.45.38; Thu, 29 Jun 2006 19:45:39 -0700 (PDT) Message-ID: <44A4904B.4020705@gmail.com> Date: Thu, 29 Jun 2006 19:45:31 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Atom-Syntax Syntax Subject: Re: Fwd: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt References: <1AFCF4EB-F605-4F8A-858A-7F76521B5759@mnot.net> In-Reply-To: <1AFCF4EB-F605-4F8A-858A-7F76521B5759@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: 944ecb6e61f753561f559a497458fb4f A couple of comments... Section 6 Archive documents are feed documents that contain less recent entries in the feed. The set of entries contained in an archive document published at a particular URI MUST NOT change over time. I definitely understand the motivation for the "MUST NOT" here, but I'm not sure if it's enforceable. For instance, on my blog, I may go back and delete an old entry that appears within an archive feed. Such a change should be reflected in the archive feed. I would recommend changing this to a "SHOULD NOT" with a comment that removing entries from an archive document has a negative impact on the cacheability of the document and the effectiveness of the archive. Section 6.1 The archive document examples do not have the element Mark Nottingham wrote: > > As discussed earlier. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: 28 June 2006 3:50:01 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Extensions for Multi-Document Syndicated Feeds >> Author(s) : M. Nottingham >> Filename : draft-nottingham-atompub-feed-history-06.txt >> Pages : 17 >> Date : 2006-6-28 >> >> This specification defines three types of syndicated feeds that >> enable publication of entries across one or more feed documents. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed-history-06.txt >> >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-nottingham-atompub-feed-history-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-nottingham-atompub-feed-history-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-6-28151604.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Thu Jun 29 23:02:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw9HM-0000PC-BJ for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 23:02:48 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw9HJ-0005Ep-OE for atompub-archive@lists.ietf.org; Thu, 29 Jun 2006 23: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 k5U2i2EP089289; Thu, 29 Jun 2006 19:44: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 k5U2i232089288; Thu, 29 Jun 2006 19:44: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.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5U2i1d8089273 for ; Thu, 29 Jun 2006 19:44:02 -0700 (MST) (envelope-from jasnell@gmail.com) Received: by wr-out-0506.google.com with SMTP id i11so232078wra for ; Thu, 29 Jun 2006 19:44: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=jt3WYahEVi8fpA1zioLEH+ZANZUPvFjhB4tVBVbIsHO6uXZuv8OfVWdpXZAf/Ebl44RvlDeqg0gf7vg0IuTYlPs3FGu0AtbzV7M2+f1OTLBz13IvyzB9Tvvx8olP6sG7EHuerXg6PMRTbFg19S8Z78sxjYBIjnjH4IVU3PcDdg0= Received: by 10.54.60.15 with SMTP id i15mr149581wra; Thu, 29 Jun 2006 19:44:00 -0700 (PDT) Received: from ?192.168.1.104? ( [67.181.218.96]) by mx.gmail.com with ESMTP id 24sm1454702wrl.2006.06.29.19.43.59; Thu, 29 Jun 2006 19:44:00 -0700 (PDT) Message-ID: <44A48FEE.4080507@gmail.com> Date: Thu, 29 Jun 2006 19:43:58 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt References: 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: 21bf7a2f1643ae0bf20c1e010766eb78 A few more comments: Section 4: Note that when an IRI is used for resource retrieval over HTTP, the IRI is first converted to a URI according the procedure defined in [RFC3987] section 3.1. The resource that the IRI locates is the same as the one located by the URI obtained after converting the IRI. IRI to URI conversion is mentioned at least twice in the spec. It would probably be a good idea to eliminate the duplicates Also, the protocol indicates that POST is used for creation of resources, however, POST is only defined on the Collection URI. There has been discussion about and there is an example of (gdata) using the POST method on Member resource edit URI's for purposes other than creation of resources. Perhaps it would make sense to include a note that the behavior of the POST operation on any URI other than the Collection URI is undefined. Section 5.3.2 1. The client PUTs an updated representation to the Member's URI. This should probably be "The client PUTs an updated representation to the Member's edit URI" given that there is a distinction between the Location URI and the edit URI as specified by the edit via (e.g. the gdata api). Also, 2. Upon a successful update of the resource the server responds with a status code of 200. Would not a 204 No Content be appropriate as well given that we're not requiring or recommending the update to return a response? Also, should we recommend that a PUT response contain the entry just like with POST requests? Section 5.3.3 1. The client sends a DELETE request to the Member's URI. Same as section 5.3.2 above. "The client sends a DELETE request to the Member's edit URI" 2. Upon the successful deletion of the resource the server responds with a status code of 200. Same as section 5.3.2 above, a 204 No Content would also be appropriate and is likely desirable in this case given that there is no response entity. Section 7.2.2 appCollection+ should be appCollection* Section 7.2.4 media-type = xsd:string { pattern = "entry,(.+/.+,?)*" } entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" } Aren't these patterns backwards? e.g. the media-type pattern belongs to entry-or-media-type. Section 8.2 In particular, the publishing system in this example filled in some values not provided in the original POST. For example, presumably it ascertained the author's name via the authentication protocol used to establish the right to post. Using the author's name in this example is odd given that the name *is* provided in the original post. Perhaps if the email address of the author were filled in on the created entry it would make more sense. Section 9 The entries in the returned Atom Feed MUST be ordered by their "atom: updated" property, with the most recently updated entries coming first in the document order. Clients SHOULD be constructed in consideration of the fact that changes which do not alter the entry's atom:updated value will not affect the position of the entry in a collection. If the client PUTs an atom:entry with an changed atom:updated, is the server required to honor it? Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. > > Title : The Atom Publishing Protocol > Author(s) : B. de Hora, J. Gregorio > Filename : draft-ietf-atompub-protocol-09.txt > Pages : 41 > Date : 2006-6-28 > > The Atom Publishing Protocol (APP) is an application-level protocol > for publishing and editing Web resources. The protocol is based on > HTTP transport of Atom-formatted representations. The Atom format is > documented in the Atom Syndication Format (RFC4287). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-09.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-atompub-protocol-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-atompub-protocol-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-atom-syntax@mail.imc.org Fri Jun 30 04:32:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwEQt-0003AS-8Q for atompub-archive@lists.ietf.org; Fri, 30 Jun 2006 04:32:59 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwEQr-00068n-QR for atompub-archive@lists.ietf.org; Fri, 30 Jun 2006 04:32: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 k5U8EphN094464; Fri, 30 Jun 2006 01:14: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 k5U8EpPq094463; Fri, 30 Jun 2006 01:14: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 joe.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5U8Em0c094430 for ; Fri, 30 Jun 2006 01:14:49 -0700 (MST) (envelope-from stefan.eissing@greenbytes.de) Received: from [192.168.1.6] (fat-tony.greenbytes.de [192.168.1.6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id B28EB4DCC2; Fri, 30 Jun 2006 10:14:44 +0200 (CEST) In-Reply-To: <1AFCF4EB-F605-4F8A-858A-7F76521B5759@mnot.net> References: <1AFCF4EB-F605-4F8A-858A-7F76521B5759@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <812D5447-97A8-4202-9BF3-DE76F9EAD292@greenbytes.de> Cc: Atom-Syntax Syntax Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt Date: Fri, 30 Jun 2006 10:14:40 +0200 To: Mark Nottingham X-Mailer: Apple Mail (2.752.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Mark, my comments to the document: - much easier to understand with the split of the 3 use cases - very nice that archive documents are supposed to be frozen and fixed (dunno when that changed, but I think it was not so from the start) 2 minor nitpicks (hey, its me): - it seems that "logical feed" and "syndicated feed" is the very same thing. Maybe agreeing on one term would benefit the document? (Or explain the difference...) - should the Atom-formatted Archive Document on page 10 have an fh:archive element? Cheers, Stefan Am 29.06.2006 um 02:06 schrieb Mark Nottingham: > > As discussed earlier. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: 28 June 2006 3:50:01 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Extensions for Multi-Document Syndicated Feeds >> Author(s) : M. Nottingham >> Filename : draft-nottingham-atompub-feed-history-06.txt >> Pages : 17 >> Date : 2006-6-28 >> >> This specification defines three types of syndicated feeds that >> enable publication of entries across one or more feed documents. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- >> history-06.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-nottingham-atompub-feed-history-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-nottingham-atompub-feed- >> history-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-6-28151604.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > > -- > Mark Nottingham http://www.mnot.net/ >